Managing Your Team's Work

As a new technical manager, one of the key things you need to get a handle on immediately is to clearly understand how work comes to your team. This is a critical aspect of team management for a few reasons. It builds trust with your stakeholders. It allows your team to focus on their tasks rather than get sidetracked or endure rapid context switching. It helps to create the space for your team members to be as productive as possible every day. Whether you inherit a system or create one, having a clearly defined process for how work comes to your team is a necessary first step in delivering value.

Understanding and controlling how work comes into your team helps reinforce your relationships with stakeholders. We have all worked with stakeholders that are never happy; that always want more, faster. This is the nature of our work and will never go away. However, if you have a well documented process for how work comes into your team and you follow it, over time, even the most impatient or demanding stakeholder will develop trust in your team, its estimates, and its timelines. They may not like it and their trust may be given begrudgingly, but it will be earned. This is because they'll learn that when you say your team can work on a task, even in the future, they'll know you mean it and have a track record of doing just that. Even trust begrudgingly given is trust.

Following a good process for bringing work into your team allows your team members to focus on what's important rather than be a victim of too much context switching. Context switching is a fact of life in a software development team, but having control of the work coming into your team helps diminish the switching by making the team's workload predictable. This helps your team members stay on task, gives your stakeholders predictability and ultimately helps increase your team's velocity.

An important aspect of any process for bringing in work to your team is dealing with exceptions. This almost always means having a discussion with one or more stakeholders about priorities. If a really important task arises, you need to be able to have a clear view on how inserting that task into your current plan will impact other tasks already in the plan. This is true for a two week sprint, a quarterly plan, or even a yearly roadmap. It may be a "plan" to you, but to your stakeholders, those are commitments. You aren't doing yourself or your team any favors by blindly agreeing to every new, critical task that comes in. There are consequences to schedules, budgets, personnel and even, ultimately, the health of your team. It's critical that you can speak to these consequences clearly. Being able to predict consequences is a skill that takes time to develop. You need develop the ability to go from a hunch or gut feeling to being able to document consequences and prove them.

Having a good process and being able to handle exceptions are essential but you still need to be able to pivot when you are overruled by the business, stakeholders or circumstance. One of the key benefits of having engaged stakeholders is that they will sometimes have a better understanding of what the business needs more than you do. This is a consequence of the fact that you're focused on delivering day to day, while they are looking at the whole arc of the business. You will need to get on board with the new priorities and, critically, be able to explain them to the team in such a way that they get on board, too. Convincing your team to pivot when change occurs can be difficult but this, too, is a benefit of trust. Your team needs to trust that when plans are disrupted due to priority changes, they know that you advocated for them and are changing for good reasons. But trust is a two-way street; you need to make sure your team members know that you expect them to push back on questions of priorities. That is, if you have to suddenly ask a team member to perform a task while they’re still working on one, they need to feel free to ask you which one is more important and to tell you what will suffer by switching to the new task; and you need to listen to them.

On a practical level, you'll need the ability to track tasks in your backlog - ideally with an ID of some sort. An ID not only makes talking about a task easier, but it can be tracked from your team's work through pull requests, bugs, requirements, etc.  If you have a ticketing system of any kind, make sure that any work a team member does can be attributed to a ticket. This makes it much easier to know when something is done; it allows your team to make incremental improvements in production systems; and it keeps you from being surprised when a team member doesn’t finish their assigned task because they were actually working on something else.

Getting a handle on how work comes to your team will help all aspects of building and maintaining a highly performant team - from stakeholder engagement to trust. Most importantly, it's one of the important parts of your job that will help you deliver value.

Ruthless Prioritization

 As an engineering manager, more often than not, you will encounter conflicting priorities. This is especially true if you’re managing a team that’s doing new development and maintaining existing code.

Let’s say that your team is developing new software with a hard deadline. But the team members you have working on it were responsible for creating a previous system that’s now in production and needs support - suddenly, a critical bug comes up in that system. This is what ruthless prioritization comes into play. You’re going to have to say no to something and balance a few risks. 

You can put a more junior person (or someone not familiar with the system) on the critical bug in the production system. You can pull an experienced person from the new development effort into the analysis of the critical bug to get a feel for what the problem is, what a possible solution(s) is, and how long it would take them to implement, test and release it. 

If it’s half a day of work for the experienced person, can you spare the experienced dev? Is the context switch too jarring? How many times have you done this recently? Don’t forget that the fix needs to be tested as well as deployed - those are critical pieces that you need to add to the risk equation. Who can do them? Are they trained up on the processes?

If the work is longer than half a day, can you have the experienced dev explain the fix to a new person and expect the fix to get done correctly? It’ll take longer, but now you’re still moving forward on multiple fronts - always a good thing if you can do it.

Having an experienced developer work with the less experienced person has  multiple benefits. It gives the experienced team member the opportunity to mentor another team member. It gives the newbie a chance to learn how the experienced person approaches problems so they can learn the craft of software engineering; and it gives them experience in a new part of the system. By slowing down slightly in this way, you’re increasing your velocity in the future because now you have multiple people that can work in that part of the system - you’ve eliminated a single point of failure.

For green field development, you’re also going to get conflicting priorities. Companies and product managers always want more features, delivered quickly and under budget. Being able to explain tradeoffs and the impact of priority changes to stakeholders, while difficult sometimes, will pay off in better trust with stakeholders, trust in you for your team members and consistent delivery of value.

An important aspect of ruthless prioritization is stakeholder management. If you say no to something or deprioritize something, you need to communicate that and be able to explain it clearly. You need to understand the tradeoffs and, if possible, be able to quantify them. Doing this will not only help reach multiple goals, but it will give your stakeholders confidence that you know what you’re doing and will build trust.

There are going to be times when it’s going to feel like you just can’t prioritize - ruthlessly or otherwise. But you must try - for the sake of your team, the project and your stakeholders. Whether or not you think true multitasking is a myth or is possible, for teams it’s not sustainable. The constant context switches will wear down your team, frustrate your best people and, at worst, lead to burn out.

Giving Back

I'm going to take this blog in a new direction for a while. Rather than focus on working with my hands, I want to share what I've learned while working with my brain.

I'm happy with the success I've had in my career in software, so I'm embarking on a project to give back. I'm going to write a series of articles about the things I've learned in my career including my successes and my failures. I hope that by doing this, I'll give people that are transitioning from writing software to managing a team of software engineers the chance to avoid my mistakes. For those that are already software engineering managers, maybe you'll be able to pick up some useful information, too.

Like many in my position, I didn't plan on getting into management. I was happily writing code and gradually found myself managing projects and other people. Eventually, the company I was working for made it official so I became a manager. This was not an easy transition for me. One of the most difficult parts was figuring out the difference between being a productive coder and being a productive manager. When I was writing code, knowing whether or not I was productive was pretty easy; but as a manager, I'd finish work for a day or a week and wonder what the heck I had actually done for all that time. 

I want this series of articles to help those that are going through this transition to get there faster and become great managers quickly.