What's Next?

One of the most important things to do as an engineering manager is to know what each of your team members is working on and what their next thing to work on will be. This is not sufficient to be a good or great manager, but it’s a critical minimum. By doing this, your team trusts that you’re on top of things, organized, and are holding the big picture for them so that they can focus on what they do best: writing code that creates value.

Knowing what each person is working on and why not only makes sure that your team is working on the right things but it also helps you build a flexible, capable team. This is because by staying on top of work in progress, you understand what team members are strong on, what skills they need to develop and how open they are to new things. Daily stand ups help a lot with this but you need to be looking ahead for each team member for their sake and the sake of the projects you're working on.

Being aware of who is interested and capable of taking on new tasks allows you to build team capability and depth. It also avoids having a single point of failure on the software you work on - that is, only having one person on the team that knows how to work in a particular area of the code. This has multiple benefits: helping team members grow; making your team more resilient; and shifting pressure off of other team members who have become siloed.

As part of knowing what each person is working on, you’ll get a good feel for how long it’s going to take them to finish. This is so that you know when you need to figure out what’s next but also it contributes to the “trust, but verify” philosophy. By keeping these things in mind, you’ll very soon learn which team members are accurate estimators, who needs help, who’s slacking, who’s driving hard, who’s reckless, etc. It tells you a LOT.

Another benefit I've noticed from this practice is that as team members mature, they become adept at keeping an eye on the backlog and knowing what the next thing is. They have a good view of the team's goals and can see where they can add value. Now, you don't want this to become a backlog free-for-all, but again, daily stand-ups are the place to keep en eye on this since team members will talk about when they're wrapping something up and have thought about what's next.

This simple sounding goal has so many benefits; from more productivity to building resilience & depth to building trust in you for your team. It's really paid off for me and I highly recommend it.

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.