My Year of Giving Back

I set out this year to spend some time each month thinking about how I could give back some of the learning I've gained over my career. I especially wanted to help new engineering managers transition from writing code (or other technical pursuits) to managing a team of software engineers.

Some of these articles took some effort and some just flowed through my keyboard like magic - but all of them were fun and represent a small part of what I've learned from my managers, mentors and friends. 

I hope you find some useful nuggets in them!

Ruthless Prioritization

How to use "ruthless prioritization" for engineering managers who face conflicting priorities between new software development and maintaining existing systems. It emphasizes the importance of making tough decisions, managing stakeholder expectations, and mentoring team members to ensure sustainable progress while minimizing burnout.

Managing Your Team's Work

Talks about the importance for new technical managers to establish a clear process for how work is brought to their team, as it fosters trust with stakeholders and enhances team productivity by minimizing context switching. By managing work intake effectively, managers can create a predictable workload for their team, navigate exceptions thoughtfully, and maintain stakeholder relationships, ultimately leading to improved performance and value delivery.

Don't Drop the Ball

Strategies for managing frequent priority changes and task overload in technology jobs to reduce stress and avoid missing deadlines. The author shares personal experiences and practical tips, such as using an inbox as a to-do list, setting calendar reminders, and maintaining a handwritten notebook, to help individuals develop their own effective systems for staying organized and on top of their responsibilities.

Who's Your Tie-Breaker?

How to identify "tie-breakers" within a team—individuals who can help make decisions when priorities conflict or trade-offs are necessary. By understanding these roles and establishing relationships with potential tie-breakers, team members can enhance productivity, facilitate decision-making, and ensure transparent communication, ultimately contributing to better organizational outcomes.

Planning is Your Job

Highlights the crucial role of planning for technical managers, emphasizing that effective long-term planning is more challenging yet equally important as crisis management. It discusses the need to set future goals, coordinate with stakeholders, and understand product strategy while refining planning skills through collaboration and ongoing learning to achieve organizational success.

Your Magic Spell

Using the phrase "that's out of scope" judiciously as a technical manager to maintain team focus and manage workload effectively, while also ensuring that stakeholders understand project boundaries. It advocates for close communication and iterative development to clarify assumptions and prevent scope creep, highlighting the benefits of Agile practices in fostering mutual understanding between product owners and developers.

Collaborate or Assign?

Fostering collaboration within a team, rather than simply assigning tasks, leads to greater success and a more productive work environment. By encouraging open communication, addressing hidden assumptions, and actively engaging team members in decision-making, managers can diminish risks and create a culture of trust and agency, although they may need to take control during crises or when consensus cannot be reached.

Done is Done

It's critical to define what "done" means in an Agile environment to ensure that all stakeholders and team members are aligned on project expectations. As a technical manager, it is crucial to enforce that tasks labeled as "done" are genuinely complete, as this not only maintains quality and scheduling but also builds trust with stakeholders by consistently delivering on commitments.

Don't Say No, Say How Much

The dual role of a technical manager as both a protector of the team and a spokesperson to stakeholders, advocating for clear communication about risks and trade-offs rather than outright rejection of new tasks or changes. By framing discussions around the impacts on schedules, budgets, and team capacity, managers can foster understanding while helping their team grow as professionals, reinforcing the importance of evidence-based dialogue in navigating shifting priorities.

Priorities and Circles of Dependencies

Introduces the concept of "circles of dependencies" as a technique for engineering managers to prioritize tasks and requests while recognizing their role as potential bottlenecks. By assessing how their actions impact themselves, team members, colleagues, and the broader organization, managers can effectively identify and eliminate obstacles, ensuring smoother workflows and facilitating better prioritization of their next steps.

What's Next?

Engineering managers must know what each team member is working on and their next tasks, as this fosters trust, organization, and allows team members to focus on their coding. By maintaining awareness of individual workloads and skills, managers can build a flexible and resilient team, prevent knowledge silos, and nurture team members' growth while enhancing overall productivity and collaboration.

Start the Flywheel

Encouraging appreciation for innovation and creativity fosters a culture of innovation, especially for younger engineers who may need guidance in navigating the excitement and subsequent inquiries from others.

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.