How to Stay Technical as a Manager 🛠️

Finding the technical work that your team needs and that keeps your skills fresh.

Two weeks ago I published an article about how engineering management is changing, which got an incredible response from the community 🙏

Then, a few days ago, I also had the chance to discuss this topic with Aditya Agarwal on the podcast.

Aditya is a legend: he joined Facebook as employee #10 and, years later, joined Dropbox as CTO when there were like ~20 engineers.

In both cases, he experienced what we call hypergrowth: hiring sprees fueled by incredible user demand + huge VC money, during which you double your headcount every 6 months or so.

Such hypergrowth cycles, during the last decade, created today’s big tech.

However, there is the perception today that big tech is kind of bloated. Too many engineers, overblown management, too many layers — so I asked Aditya whether he thinks that we will ever see such headcount explosions again, or if we are rather heading towards smaller, leaner engineering teams.

Aditya answered with a great insight, which, like all the best insights, looks obvious in retrospect.

Year after year, tech gets better. This makes us more productive, which in turn makes us accomplish more with less. It’s always been so: Facebook is smaller than Microsoft, and the next Facebook is bound to be smaller than today’s Facebook.

So we are all going to be doing more.

But more of what? My bets are the following:

• 🎨 Engineers are becoming full-stack — and not just in coding. They will own entire features, do their own project mgmt, and often talk with customers.

• 🔧 Managers are becoming more technical — they will be expected to contribute with code, practical directions, and being more hands-on.

However, while for engineers this path looks kinda straightforward, for managers it looks… tricky.

Technical work has little overlap with a classic manager’s work, to the point where we developed different career tracks altogether.

So, the natural follow-up question is: how can you stay technical as a manager? This question is actually two separate questions:

1. ❓ How should you contribute technically to your team? — what should you even do? How can you be helpful without 1) becoming a bottleneck, or 2) removing ownership from your teammates?

2. ❓How can you retain your tech skills? — when you can only spend a fraction of your time on actual tech work?

While these are different questions, they are also intertwined. You want to retain the tech skills that are the most helpful to your team, which requires you to understand what kind of technical work is the most valuable for you to do.

So, you need to answer (1) first, to be able to address (2) properly.

In fact, this will be the main angle of this piece: how to stay technical… on your job. And this was not the only possible one 👇

💼 Learning on the job

There is a lot of advice about growing tech skills that looks like: make a side project, read this book, or do this course… in your spare time.

These can be valuable, of course, but I have two objections:

• 🎯 Learning on the job is better — when your learning is attached to a real goal, everything is better. You go deeper, you retain more information, and have a better feedback loop. 80% of your skills are shaped by your job: if you expect to do career-changing learning outside of it, it will not happen.

• 💸 Self-directed learning is a luxury — not everybody can afford to use their spare time for professional growth. You may have family duties, you may have an already demanding job, or you may just not have the extra motivation to do so.

So, today we will focus on how to stay technical as a manager, by making the most out of your work.

Here is our agenda:

• 🔀 Reactive vs Proactive work — let’s start from an unlikely place: your schedule.

• 🙅 Giving up main dev work — making peace with your time and your reliability.

• 👑 Technical manager work — because coding isn’t everything.

• 👯 Coding together — code reviews vs pairing.

• 🔨 Building things — your three best bets: dev tools, tech debt, and exploration.

• ❓ Hard questions — bonus: seven hard questions you should ask yourself to figure out if you are getting behind.

Let’s dive in!

---

🔀 Reactive vs Proactive work

Paul Graham’s essay about Maker’s schedule vs Manager’s schedule has long been a favorite of mine.

TL;DR Paul argues that managers and makers (e.g. engineers, designers, etc.) run on different schedules:

• 🔨 As a Maker, you benefit from long, uninterrupted streaks of time where you do your focus work.

• 🎽 As a Manager, your schedule is run by meetings where you make decisions that move the ball forward.

These schedules are not only very different, they are incompatible.

As a Maker, you shouldn't be bothered with too many meetings, because those come at the expense of your productivity — but managers will drag you into them because that’s how they do their work.

Now, while this makes for a good mental model, I also find it a bit simplistic, especially when applied to technical management. For two reasons:

1. ☯️ Black / white — in engineering, it is rare to find managers who run on a pure manager’s schedule like PG suggests. Everyone is a blend of some maker’s and manager’s work, with the magic being on finding the blend that works best for your team.

2. ⛑️ Support to makers — counterintuitively, one of the major reasons why managers don’t have a lot of guaranteed focus time, is to support makers. Wait what? Hang on with me 👇

I believe a better way to think about your schedule, is in proactive vs reactive terms:

• ➡️ Proactive work — that’s your scheduled, planned work. This is often done in anticipation of your team’s needs: hiring, planning, 1:1s, are all examples of proactive stuff that runs on a schedule.

• ⬅️ Reactive work — that’s unexpected work that reacts to your team’s needs. That’s whenever you need to clarify some specs, jump in on a technical dilemma, handle a resignation, or defuse some conflict.

And here is the thing: managers are naturally subject to way more reactive work than makers, which is what effectively messes up their calendars.

Reactive work is sneaky. It looks like you can lock those two hours of coding on Wednesday, until you get a DM on Slack and figure out that 3 people are stuck and need your intervention.

This divide between reactive vs proactive work is incredibly important — in fact, improving management’s health can often be framed as some version of turning reactive work into proactive:

• Improve career framework → make career conversations more predictable

• Improve design process → reduce reactive changes to specs

• Improve hiring process → make resource allocation more proactive

• …

So, let’s take a step back: why are we nitpicking about people’s schedules now? Because understanding where your time goes is the first step to using it for good.

Which leads us to the very first advice for managers who want to stay technical: