It’s been about two years since I switched career tracks from software engineering to management, and I feel like I’ve learned a ton of lessons, some of which I wish someone had taught me long before I became a manager. Many of them are obvious in retrospect, but I feel like many management lessons are like that. Hopefully, others new to management might find these lessons useful as well.

Delegation and project management

When I was an individual contributor, I thought “delegation” just meant that you ask someone else to do something! But then, things I delegated sometimes got forgotten or went in completely different directions from where I had intended. High Output Management was incredibly helpful in making it clear what I was missing: “Delegation without follow-through is abdication”. I wasn’t checking whether the task is proceding as expected. I feel like this notion should be taught to every tech lead, to every employee: “This is what your manager is doing when they’re being annoying!”

Beyond basic delegation, I didn’t really know how to manage multi-person projects as an individual contributor, even when I was the nominal tech lead. They would regularly run late, and I constantly had to jump in to help pick up the slack. Becoming a manager and forbidding myself from pitching in directly gave me no room to continue being that bad at it.

The main mantra of “who does what by when” from the Manager Tools podcast has been incredibly helpful, because ensuring clarity for those criteria solved many miscommunication headaches; performance and organizational problems also become much easier to uncover. In addition, the “what” has to be based on concrete, unambiguously observable deliverables, not just effort or time spent. In other words, rather than “research options” or “develop X feature”, better deliverables are “write and send out a report” or “release feature X on internal build”. Just relying on some sort of summary status (“Are you on track? Is it green?”), as often happened in teams I’ve been on, is not enough. There’s too much room for miscommunication, misunderstanding, and forecasting error.

These aren’t the only important parts of project management—planning and forecasting are important, too—but it certainly helped!

Task-relevant maturity

Early on, I avoided telling people exactly what to do. I would ask leading questions, reflect questions back at the asker, and hint and nudge them in the direction I thought was right, because I thought that telling people what to do was the mark of a poor manager. “I have good people! I don’t want to micromanage them,” I thought. “I’m here to enable them to do a good job.”

The results weren’t always great, however: work that didn’t meet my expectations, team members getting frustrated about what I wanted. I learned that sometimes, you do have to tell people what they should do, directly and explicitly, and then check up on them frequently. People may never have done this kind of work before, and so they don’t have the tools to solve their problems themselves—their task-relevant maturity is low. Even if they could learn it on the fly, it might take them so long that it’s not worthwhile, or there may be too much risk that they cause something disastrous to happen. In those circumstances, telling them what you want them to do is a teaching moment, and not necessarily a management failure.

In addition, when I was an individual contributor, I never thought about the task-relevant maturity of the team as a whole. I was just responsible for solving problems, doing code reviews, and I never really thought about staffing in any other terms than “do we have enough people to write code”. That was pretty disastrous for the quality of what my team shipped. I had to work overtime to fix up code and catch problematic designs.

Now that I’m responsible for evaluating what kind of work people are ready to do, it’s become much more apparent to me that the team’s collective experience level and expertise should set limits on what kinds of projects we tackle. A software design-heavy project isn’t good for a team of junior coders, for example. Even if they manage to finish the first version of the project, the high cost of maintenance over time would be an incredible waste due to design flaws making the system buggy and fragile.

These days, I think a lot about matching people and teams with appropriate projects, and ensuring that I’m being just directive enough.

It’s possible to be too helpful

On the other hand, despite trying not to be directive early on, I did try to be as helpful as possible as a manager, giving lots of suggestions and helping people solve problems. I thought I was helping my team to produce better quality work! Maybe I was, but I eventually also realized that I was having negative side effects. Being so involved stretched me thin, and more importantly, crowded out my senior engineers from leading and influencing. I had to pull back and delegate this responsibility for technical leadership, so that my team could function more independently of me and the technical leaders I was trying to cultivate actually had chances to lead.

I still struggle with this (I do like software development!), but where I can, I try to ask myself who else could or should be helping instead of me. In addition, rather than making suggestions as I check in on the quality of work and technical strategy (my delegation follow-through), I try to couch my words in terms of expectations rather than suggestions.

Sponsors are critical for career progression

I didn’t really appreciate how important sponsors are for people’s careers until I became a manager, when I started writing performance reviews and putting people up for promotions. Before, when I was a staff engineer (a relatively senior position at my company), I took for granted that people trusted me when I gave peer reviews on who was doing well and on what.

As a manager, though, upper management was much more skeptical of my evaluation of people’s technical skills (rightly so), and so it mattered a lot to have other senior software engineers as sponsors that could vouch for my people, especially as they got to the higher end of seniority. It might sound like politics, but to me, it’s really about chains of trust, where my promotion proposals are treated skeptically like self-signed certificates. Now, I know to seek out sponsors that have the company’s trust when making the case for promotions.

Planning around my energy levels

When I was a software developer, I had a lot more control over my schedule and energy. If I needed a break in a marathon coding session, I could take it! As a manager, though, my days often fill up with meetings, and it’s not easy to just move those around to manage my energy levels. Even if I need a break, it sucks for the other person to cancel a meeting 5 minutes before it starts.

These days, I pre-schedule 30 minute mental breaks, at least once a day if not twice. That time is sacred, not to be spent on email, meeting prep, or any other work—not even mulling about things. Usually, I’ll grab a snack, a cup of tea, and just sit. Sometimes, I’ll try a mindfulness exercise or take a walk. It’s a chance for my brain to disconnect and for me to recharge.

In addition, I used to try to stack all of my one-on-one meetings with my team on one day of the week, in an attempt to reduce my context shifts from “one-on-one” mode to other types of meetings, but that was just too exhausting, not to mention a bit unfair to the people who I met with later in the day. I can’t keep up more than maybe two hours of active listening at a time, so these days, I spread my one-on-ones across the whole week.

Always be selling

I’ve realized I need to always be selling the team’s mission. This was easy to remember when I was quickly growing the team, because I was heavily involved with recruiting and hiring, but it was harder to remember to do when I wasn’t hiring. For the people already on the team,though, I’ve found that if I’m not continuously selling what our mission is and what our plans are in the future, people can feel lost, uninspired, or drift on to thinking about what else is out there.

I can’t say I find this easy. Selling is an emotionally taxing task for me, and I definitely feel more tired as I put in more effort, but it feels worthwhile nonetheless. It’s worth it to have the team feel productive, optimistic, and creative.

These probably aren’t profound lessons, but they weren’t obvious to me when I started, and I feel like they’ll be useful lessons for me no matter where my career takes me, whether it’s back to being an engineer in the future or continuing on as a manager. I tried as much as I could to learn from helpful books like High Output Management, but the real experiences in the past two years reinforced my book learnings and added nuances that I wouldn’t have noticed otherwise. I’m looking forward to what I learn over the next two!