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.