Start the Flywheel

One of the funnest parts of my job as an engineering manager is when someone on the team reaches out and asks, "do you want to see something cool?" This always means that they've come up with a cool solution to a difficult problem or innovated in some unplanned way. While this is really exciting, it's important to exercise some caution at the same time, too. Let me explain.

When something is really innovative, the temptation is to immediately start asking questions like, "Can it do this?", "Will it fix that?" Usually, that means that people are really excited about the implications of what they're seeing. This is where the caution comes in - take the time to pause and express, in a sincere way, how cool what you're looking at is and how much you appreciate the initiative of the engineer that's showing it to you.

Experienced software engineers usually understand this dynamic but younger ones need need some mentoring to understand what's going on. It's critical to explain to them that when other people start peppering them with questions, it's due to the fact that they've already jumped to "what's next" after skipping, "hey this is cool!". In fact, the number of "what's next" kind of questions is directly proportional to how excited they are about what they're seeing.

By taking some time to praise people, you're giving the innovation flywheel some extra momentum. Innovation creates more innovation, so making sure you encourage this in your team is critical.

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.

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.

Don't Drop the Ball

Most jobs, especially in technology, include frequent priority changes, requests for information, and just general to-do list churn every day. This can lead to stress but also to forgetting important things or missing deadlines. I've suffered from this to some degree or another throughout my career and have come up with a couple strategies that help. These are by no means "silver bullets", but they can help me keep up with changes and reduce stress.

I've been kind of forgetful for my whole life. (Friends and family reading this post will heartily agree.) When I was in high school, I played trumpet in the marching band. Our marching band played at football games almost every Saturday in the fall, so this was a regular occurrence for me. I never forgot about the event at the right time, but once or twice a season, I'd forget my trumpet, which, with the possible exception of my band uniform, was the most important part of my being there! Eventually, the band director made sure there was a spare trumpet available for me to use when this happened.

As I started working, I would forget the perfectly decent lunch I had in the refrigerator when I left in the morning. This meant that I'd have to spend money on buying lunches. I fixed this by putting my car keys on top of my lunch in the refrigerator when I made it to be sure I couldn't leave home without it. After doing this trick a few times, I was able to get into the habit of remembering my lunch. Developing this trick, and others like it, have really helped with forgetfulness but also for unexpected requests and dependencies.

Being conscious of this kind of pattern and creating your own tricks for mitigating it will help you in a few different ways in your career. You'll be less likely to forget important things, you'll earn a reputation for staying on top of things, and it will help diminish your stress levels because you know that you're less likely to miss things.

Each of us can develop our own approach to this. My approach to this problem centers around my inbox and my calendar. I don't like having lots of unread email in my inbox. Over time, I've learned to use unread emails as a kind of to-do list. This tends to work better than a written to-do list for me because it's always current in my inbox, whereas a written list has to move from page to page or note to note. The second trick I use is related to my inbox: I create calendar appointments to tackle important things that include an email reminder. I create zero-duration appointments in my calendar with email reminders so that I remember to do things. The emails contain just enough information to be actionable. 

One other tick I use is more analog. I use a hand-written notebook to keep track of my notes during the week. I've tried various electronic versions over the years but a physical notebook is best for me (with my favorite kind of pen, of course). I think the physical use of a pen helps reinforce what I'm writing. But the trick itself is to draw square check-boxes beside to-do items. They're quick and easy to add during meetings and they stand out during those times when I'm looking back over the last few days to see what I need to keep up on. I also just love checking things off of lists. Sometimes, they age out of relevance (even in a short time), but even then, I'll cross them out with an X and still get the pleasure of checking something off of my list.

There are an infinite number of ways to tackle this problem with an almost infinite number of tools to help. I've created a system that, while not perfect, works for me. I encourage you to take some time to come up with a system that will work for you. Don't be afraid to tweak it or even change it wholesale to make it better. Please share your solutions in the comments - I'm always open to change!

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.