7 mins

No longer having the tangible, code-based evidence of a hard day's work when you transition into management can be the hardest part of the role change, but there are ways to harness meta productivity and regain job satisfaction.

Every so often, I have a day where I look up after the last meeting has ended and feel like I’ve gotten absolutely nothing done. I’ve been busy all day long: having conversations, reading documents, and checking in with peers and team members. I’m exhausted, but I’ve accomplished nothing.

Except that’s not at all true. It just feels that way.

When you’re an engineer, the work you do is so tangible. You write code, you do code reviews, you deploy features to production, and you can see the direct results of your work in the systems and applications you work on. You can look back at the end of a day and there’s an obvious trail of progress behind you.

As a manager, it’s not so simple. Sure, you can see the features your team has worked on, but little (if any) of that is code you wrote. Instead, you spend your time doing things like facilitating conversations, leading retros, and coaching folks in 1:1s. There’s no commit log for all of that work, and the feedback loop takes so much longer than a deploy to production.

Teams are systems

From a pure systems-thinking perspective, a software engineering team is just a complex system. As a manager you are responsible for a lot of the inputs to that system, either directly as a leader, or through coordinating with product managers, designers, and other stakeholders to make sure your team has the context they need to be effective. The engineering process you cultivate, the retros you facilitate, the many conversations you have: they’re all inputs. 

The code your team creates is the output of the system: it’s the product of the experience and knowledge of the team that is directed and motivated by all of those inputs. The challenge is that a software engineering team (like most groups of humans) is such a complex system that it’s essentially impossible to connect specific inputs to specific outputs.

Welcome to meta productivity

This puts us in an awkward position as managers. We spend our days doing so many things, but it can be difficult to connect our work directly with the outcomes we’re trying to drive. ‘Did the conversation I had with Robert last week move us closer to hitting our deadline? I guess we’ll find out in a few months!’ is a really frustrating way to gauge how effective you are at your job, and it can make it very difficult to find a regular sense of accomplishment.

Here’s why; all those years you spent writing code before you transitioned to management wired the reward circuits of your brain to value direct productivity: code written, PRs reviewed, features released. When you shift to management, you no longer get to do any of that. Instead, you move into a mode of meta productivity, where your primary output is work done by other people. All of your efforts are focused on helping others produce work more effectively and efficiently, and rewiring your brain to find value and satisfaction in that work isn’t easy.

Manage yourself like you manage your team

Fortunately, there are several practices you likely already use with your team that you can apply to yourself as well to make this transition easier.

Shorten the feedback loop

If you’re leading in a company that has adopted agile principles, your team probably has a rhythm of sprints or iterations, and you likely focus on delivering work iteratively. The reason these practices are important is that they shorten your team’s feedback loop. Instead of waiting until the end of a project to evaluate the success of your work, you get incremental feedback every time you put new changes in front of your customers.

These iterations give us managers an excellent chance to take stock of our effectiveness as well. It can be tempting to only let ourselves enjoy a feeling of accomplishment when our team delivers a major piece of work, but all those weeks and months wondering if our work matters is a recipe for burnout. Instead, look for wins every iteration. Pay attention not only to the software your team delivers, but also to indicators of individual and team growth e.g. improved morale and happiness, increased self-sufficiency and autonomy, deepening team trust, and a more efficient delivery cadence. Allow yourself to celebrate every little win your team accomplishes, because even if you can’t see a connection between your inputs and a specific piece of output, you cultivated the environment where it happened.

To make the practice of celebrating wins even more tangible and useful, you might try keeping a log of them. You’ll find it immediately useful in sharing your team’s achievements with your manager and others in your company. But the real magic in keeping a log is that as the list grows over time, it makes it much easier to see how your team has grown and progressed under your leadership, and how all those little wins have added up into something big.

Retro yourself

Another regular practice of most healthy agile teams is retrospectives. Every week or two, your team pauses to discuss what went well and what didn’t over that previous iteration and possibly make some adjustments for the next one. These meetings give your team a regular cadence of feedback, and over time, they’re a powerful force for improvement.
We’re good at helping our teams find this cycle of feedback, but it’s easy to let our busyness as managers keep us from finding it for ourselves. You might get feedback once or twice a year in a formal 360º review process, or maybe you never get it.  But regular, incremental feedback can be a powerful force for improving yourself and your practice of management.
The easiest way to get this feedback is to just ask for it. You already have a standing 1:1 with everyone on your team, and that gives you an excellent chance to ask for feedback on a regular basis. Here’s a few questions you can try.  

  • Is there anything I do as a manager that’s particularly helpful for you or the team?
  • No manager’s perfect. What’s something I do that you find frustrating?
  • If you were the manager of this team, what’s one thing you’d do differently?

Keep in mind that getting good feedback directly from folks on your team requires significant trust, so you may not get much information at first. But this process of asking for feedback regularly, and responding with kindness and follow-through when you receive it, is one of the most trust-building activities you can engage in. 

Focus on strategic work

As engineers get more senior in their careers, we often encourage them to spend more of their time on strategic work e.g. proposing changes to keep the system healthy, or finding wasteful work and automating it away. It might’ve been the shift from tactical to strategic work that encouraged you to transition into engineering management in the first place.

The good news is that this strategic work is the primary kind of direct productivity that remains available to you as an engineering manager. As your team becomes more self-sustaining and needs less of your time to support them in doing their work, you’ll have more time to focus on strategic initiatives that move your team and your organization forward. It’s not as tangible as writing code, but it can still be very satisfying.

What kind of work am I talking about? You might spend some time thinking about your team’s engineering process and write up a document proposing changes to make your team more efficient. You could dig in on your company’s interview process and advocate for changes to make it more fair for a broader range of applicants. Maybe you notice you’re spending a disproportionate amount of time on status reporting, so you write a bit of code to automate part of the process for you and your fellow managers. All of these things can help you feel some of the direct sense of accomplishment we often find ourselves missing when leading a team.

It just takes time

Transitioning to management isn’t a promotion, it’s a shift to a brand new career. And moving your primary source of job satisfaction from direct to meta productivity is one of the hardest parts of that transition. It can take months to begin to understand it and years to master it, so don’t be frustrated with yourself if you’re struggling to find your footing. Even the most experienced managers still have those days where they wonder what they did all day, but with a little time and practice, those days become less frequent. By focusing on shortening your feedback cycles and finding the kinds of direct productivity that are still available to you as a manager, you’ll be well on your way to finding the deep satisfaction in management that you might have been missing from your years as a developer.