Priorities and Circles of Dependencies

Once you start as an Engineering Manager, you will likely start getting more requests for work, estimates and other kinds of input than you can handle. When this happens, one technique you can use to help prioritize all of those requests is to think about whether or not you're a bottleneck, and if so, how impactful that is for others.

You can picture this as a circle of dependencies. Each circle impacts different numbers of people. It starts with knowing how you are blocking yourself; then how you're blocking a team member from moving forward; then how you're blocking your team from moving forward; then your colleagues; then your stakeholders; and finally the whole organization.

Starting with how you block yourself, think of a situation where you need to prioritize your team's backlog but you can't do that until you have the stories in the backlog or you meet with a product manager to set the priorities on backlog items. So, create the stories or meet with the PM first. If you can't work with a PM, decide if you can move forward on your own and let the PM know that you did and that you're willing to revisit the sorting. Unblocking yourself can be hard sometimes but knowing that you're doing it is half the battle. See this post with some approaches to help.

The next circle out is when you're blocking a team member from being able to move forward. Yes, this is only one person being blocked, but part of your job is to remove obstacles for your team so don't BE the obstacle! Stay in close touch with your team so that you know when this is happening; or, short of that, make sure you've built trust with your team so that they're comfortable letting you know when it's happening.

After that, the circle to care about is how you may be blocking your colleagues. There are innumerable ways to do this. It could be documentation, estimates, quarterly planning; almost anything. Blocking your colleagues could end up blocking more than just the individuals - it could also mean that you're blocking their teams or your department (planning, for example). 

The key takeaway is that using this approach can help you prioritize what to do next. Looking at it as different circles of dependencies informs your next steps and helps keep you from being a bottleneck. When you've done this and you're still stuck as a bottleneck, it's time for ruthless prioritization.

Don't Say No, Say How Much

As a technical manager, among the many roles you fill are as a protector of your team and as the public face of your team. As the protector, your job is to keep the craziness away from your team as much as possible - things like changing requirements, unreasonable schedules, frequent changes in focus. As the public face of your team, you need to be the team’s advocate, spokesperson, cheerleader and filter.

If you’ve been lucky (like me), you lead a team with highly creative, smart and motivated engineers. There’s a lot of trust among team members and in you personally. This means that you’re going to get an earful if they think some new task or requirement is not to their liking or doesn’t fit the company strategy. They will likely say it in such a way that your stakeholders won’t appreciate it. That’s OK - as long as it stays with you. Even if they’re right, your job is to get them on board to implement the desired change.

When it comes to communicating to stakeholders about this, you can’t say to them, “this will make my team cranky”, or, “my team will think this is dumb”. What you can, and must, do, though is talk about risks, trade-offs, and impacts on schedules and budgets. And better yet, work with your team to start thinking along these lines, too. Not only does it make your job a little easier, but you’re helping the team grow as professionals and to become better communicators. Let’s take an example.

You’re already midway through executing your quarterly plan when you find out that a potential new customer needs to be wowed by your product. But there are some problems with your product that you know about and are on your roadmap to fix - but not this quarter. This is one of those times when the company gets to change your priorities at the drop of a hat. Remember: you and your team are there to provide value and what that means can change for the company. Your team needs you to talk about this change to stakeholders so that the stakeholders understand what they’re asking for. Talk about the risks that this change in priorities will create; talk about what your team will NOT be able to do because of this change; talk about the unplanned financial cost of this change. Basically, be completely rational and back up your arguments with data. Focus on presenting options, not being recalcitrant. This may or may not sway your stakeholders; but it starts an important conversation with them and maybe even points out some things they didn’t think of. And just as important, your team knows that you went to bat for them.

You’ll be able to go back to your “cranky” team and give them the facts from the company’s or product manager’s perspective. This, too, is another opportunity for your team to learn something important about what customers want and why they do what they do.

A former colleague and mentor once told me, “Don’t say no - say how much.” Doing this in a rational way with evidence can really make a difference. It takes practice, but is worth the effort.

Done is Done

For anyone that's worked in an Agile environment, you'll know how difficult it can be to write the definition of done for some stories. As I've talked about it in other posts, stakeholders and engineers have to work hard to make sure they first understand what requirements are before they can agree on what "done" really means. Whether you're defining what "done" means for a story, an epic or a whole project, having it in place and agreed upon with stakeholders is essential and invaluable.

This post is more focused on the day-to-day of "done", though. As a technical manager, one of my pet peeves is when an engineer says, "Yes, it's done. I just need to...". NOPE. Then it's not done. 

Maybe there are a couple bugs open that need fixing; maybe the deployment details are still to do; maybe there are a couple unit tests still to be written. The list could go on and on. As the manager, it's your job to make sure that "done is done" not only for scheduling reasons, but also for quality reasons. Being really meticulous about this also reinforces trust with your stakeholders. If you prove over and over again that done really is done, they'll know they can trust you.

So make sure that your team knows what you expect when a task is declared as done. They'll appreciate it and you'll be able to sleep better at night knowing that one less potential problem is addressed before it happens.

Collaborate or Assign?

When you're working with your team to reach goals, whether they're team goals or company goals, do you work collaboratively with the team or do you assign team members tasks? My experience has shown me that I have more success and a happier, productive team by focusing on collaboration rather than just assigning tasks.

What does that look like and how do you get there? For me, it means that I don't shy away from asking dumb or obvious questions. Over time, my teams have learned that this is one of the ways I go about getting around hidden assumptions and misunderstandings. I've talked about the importance of clear communication with stakeholders around requirements in other posts. But the same holds true within your team. Unless you have very detailed requirements, product goals and customer requests mean different things to different engineers. If I guide the team discussion in such a way to ferret out these assumptions and misunderstandings, we come to a place with clarity about what it is we actually need to do and how we're going to do it.

In addition to asking obvious questions, another way I work through this is to constantly come back to the stories we have on our board for a feature and ask, "OK, if we finish all of these stories, are we DONE?" This is a real opportunity to look at body language (or listen carefully on calls) to find out if there's more to be done. As tempting as it is to just take the team's answer at face value, you'll be thankful later on if you did the work to suss out that there was actually more work to do than you had originally thought. 

By working with the team to create stories and tasks, you not only foster a collaborative team culture, but you diminish risk, too. Assuming that one person (either you or someone else on the team) has all the answers and knows what to do is a recipe for missed deadlines and features that don't delight customers. This reinforces your team's agency to not only diminish risk, but it makes working together more rewarding because every team member knows that their input will be listened to and taken into consideration during planning. This has the added benefit of encouraging people to speak up when they see a problem - even junior engineers.

I don't think that you should never assign tasks to your team; rather, fostering collaboration will help create a happy team with a manageable workload and trust among members. When are times when you need to take control and start assigning? For me, the most obvious answer to that question is during a crisis - like downtime in production or something similar. As a manager, that's a time when you need to lead to get things fixed quickly while not making problems worse. Similarly, there will be times as amanger when your team can't come to agreement and you need to make the decision to move forward. But even in both of these situations, when you have a trusting, collaborative team culture, your team will act as guide rails to help keep you from making mistakes.

Your Magic Spell

Your magic words as a technical manager are, “that’s out of scope”. You need to wield this spell intelligently but ruthlessly. Your team needs you to do it so you can keep their workload manageable and allow them to stay focused. Your manager needs you to do it so that they know why you can succeed.

Now, you don't want to be in the situation where you say that to a product owner right before a release. If that happens, something went wrong. Most likely, it would have to do with one or more assumptions on your part - and the product owners part - that didn't come up early enough to be resolved.

Some companies try to address this with really detailed product specifications. That can work, but it's no guarantee that missed requirements based on assumptions won't come up. I've found that a better way to prevent assumptions that lead to scope creep is close communication, fast iterations and short demos.

To me, those are some of the best aspects of Agile development. Product owners don't always know every requirement before development begins; the same way that developers don't always know how they'll solve requirements until they are into the code. Seeing running code is one of the best ways of coming to a mutual understanding of what all the problems are that a product owner is trying to solve so that your developers really understand what the goals are. It also allows for trade-offs that can help speed development. For example, it's not uncommon for developers to offer some options for difficult or time-consuming requirements that, once adopted, can speed development and still satisfy customer expectations.

I'm not a fan of blaming missed requirements on "bad communication". Go deeper with your stakeholders; take the time to try to find assumptions; talk through outcomes; ask the questions you may not want to know the answers to. By doing these things, you'll prevent yourself from getting into trouble with unexpected scope creep.

Planning is Your Job

As a technical manager, one of the most important things you can do for your team, yourself and your organization is planning. If you're like me, you're good at managing a crisis bug - and you may even enjoy it. Engaging a whole team to focus on one, critical problem; communicating with stakeholders; severely limiting scope. All of these things come into play when you're managing an emergency with your team. Planning is a lot harder and just as, if not more important.

It's harder because it requires you to think way ahead - not just the next sprint or two but 2,3, 4 or even more quarters. Managing tasks one or two sprints into the future is easy compared with looking 6 months or a year into the future. What's important now may not be quite as important in a year. Answering the question, "what are our goals for the next year and how will we get there?" is complicated. You'll have lots of technical things you want to accomplish but making sure you know what the product needs requires working with more than just your technical peers. You need to understand your product strategy, talk with the people in the organization that are in touch with customers and can really help set priorities.

You communicate with stakeholders differently, too. During a crisis, it's "all hands on deck" and you can make decisions quickly and decisively. Planning, though, is all about working with product managers, program managers and the like negotiating priorities and analyzing capacity in an environment where you likely won't have all the details. You're not going to know all the requirements and risks but you'll still need to be able to decide what you can fit in and when.

Having the long term view is critical if you have to coordinate with other teams. They're going to take your plan, look for dependencies and then plan accordingly. You'll need to do this with their plans, too.

My planning skills have gotten better over time, but they could always use improvement so I'm always learning how to plan better. I've been lucky to work with people that are really good at it; or if they're not planners themselves, they know how to challenge me and ask questions to help me refine my plans.

Planning is a critical skill for a technical manager. It takes a lot of practice but the payoff can be huge.

Who's Your Tie-Breaker?

You’re on a team with people that have different titles and roles: product manager, product owner, your boss, principle software engineer, etc. It’s always good in any context to know, when priorities conflict or trade-offs have to be weighed, who the person is that you go to to break that tie. Sometimes it will be your boss; sometimes it’ll be the product manager; sometimes the principle software engineer. The projects you work in intersect in different ways with these and other roles. Understanding those roles will make your job easier which will have a direct impact on your team's productivity.

Think of your tie-breakers as allies, too. They can help you do more and move quickly by removing ambiguity and road blocks. But it's critical that you don't just present problems to be solved to these allies. Your job isn't to make work for others - it's to help reach your organizational goals and create value. This means when you encounter a situation where you need a tie-breaker of any kind, it's up to you to do your homework first. Make sure you can present reasonable options and have thought about the trade-offs. That will help your tie-breaker make an informed decision and feel comfortable that they're not taking on risk by helping you out.

Once you've got your answer, make sure you document it somehow. Maybe it's an email summarizing the decision; maybe it's updating documentation; perhaps it's adding stories to your backlog. The mechanics of it don't really matter as much as documenting it and communicating it to your team and stakeholders. This will help prevent second guessing later on as well as reinforcing your reputation for transparency.

Remember, too, that for some people you are the tie-breaker. When you're the tie-breaker, work with those that are coming to you so that the topics I cover above are addressed. Being decisive is all well and good, but if you make a poor decision because you didn't have all the facts, that's on you.

But what happens if you don't have a tie-breaker? What if things are so changeable or chaotic that you don't have a person to go to? This is definitely a tough spot to be in. My recommendation is to first, start building relationships with people that could become your tie-breakers. This will serve you well in many situations, not just resolving conflicts. Next, transparency becomes even more important if this is the case you're confronting. By keeping people informed, in whatever way is appropriate in your organization, you'll build a reputation for level-headedness and communication. You'll also likely learn whom your tie-breakers are as you get feedback about your decisions. They may not be "official" tie-breakers, but they're a start. Build out relationships with these people.

Knowing how to break ties when it comes to decisions of all kinds in your team and organization will help you become a better manager and teammate. It will help build and reinforce solid relationships that will help you in all aspects of your job.