March 18, 2019

Lessons from Six Months As A Manager/Developer Hybrid

📖 This Weeks Article

For the last 6 months I've been serving as a hybrid developer/engineering manager. It's been an interesting experience, and because this is a fairly common way to transition into engineering management¹, I thought it might be worthwhile to share some lessons I've learned so far.

1. Time discipline is key

The biggest challenge of this transition was learning to be a manager. It's a whole new job! But the biggest challenge specific to the management/developer split has been managing my time.

I've always been a bit loose with my time management. I do a lot based on my mental state at a particular time; if I'm tired or uninspired I may lean more into grunt work like documentation, code reviews, or more "scripted" code work. If I'm in the zone I'll dive into big tasks, and if someone comes to me with a problem I tend to context shift into it and go from there.

This "time management strategy" hasn't held up at all while trying to balance manager and development strategies. Basically because of the blend of maker and manager schedules. Developers need long uninterrupted periods of time to be productive, while managers tend to operate on a much more social and interrupt driven schedule. They're naturally opposed.

Working with this tension requires discipline and planning. For me personally I've started planning my schedule for the next day at the end of the previous day, batching my checking of Slack/email and being more thoughtful when somebody asks for my time.

Planning my schedule for the next day is a tip I picked up from Deep Work. To close out the day, I review the things I'll need to handle the next day, and block out my calendar with time for different tasks for the next day. This does mean that my calendar always looks completely booked for the current day. So far this has served as a feature not a bug; I can still move things if something urgent comes up and it has a way of encouraging people to schedule less urgent things in advance. Note that scheduling like this doesn't mean you can't change plans; I do all the time. It just means that you start with a plan and can be thoughtful about how you vary off of it.

Batching Slack and email has been something I've known would be good for me forever. It feels good in the moment to be the guy who is constantly available, but the cost of distraction is higher than you think. So far, management has been a catalyst for me buckling down here.

Finally, I get a lot more unexpected requests for my time now than I did previously. I've found that batching my email and Slack reading combined with a willingness to suggest a meeting later in the day or the next morning rather than right now has helped me protect blocks of productivity and focus, without making me an unresponsive manager. Most things can sit for 2 hours without blowing up anyone's day. The key is to ask enough to identify the 5% of things that can't wait.

Those 3 tactics have worked for me, but overall it comes down to being intentional about your time. If you let yourself be blown by the wind while splitting dual responsibilities, one of them will almost always receive the short end of the stick.

2. Team success metrics are the only ones that matter

When you're acting as both a developer and a manager, it can be tempting to hold yourselves to 2 sets of metrics: management metrics and development metrics. This is a mistake. It will cause you to over-prioritize your own tasks and hurt your team's long term growth.

Focusing on personal development metrics and goals can lead to over-prioritizing them for a few reasons. First, development goals tend to be much "cleaner" than management goals; it's easier to tell what you've achieved. Second, if you're transitioning into this role from a dev role, you probably are much more comfortable with these tasks, and so they can act as a safe place where you avoid having to stretch yourself. And finally, if you moved into this role from a senior dev position, it can be easy to tell yourself that this is actually the best way to get stuff done. And you may be right... in the short term.

So what's the antidote? Focus on team productivity and view your own work as just an extra card you have to play in your hand. It's an advantage you have over less technical managers, but if you don't set to working developing other strengths, you're not going to be able to grow, and if you're monopolizing the important work your team won't be able to step up into new roles. So play that card, but do it with caution, and always as a means rather than an end.

3. This isn’t long term sustainable; have a plan

Hybrid Management / Developer roles aren't a long term game. Aside from the scheduling tension I mentioned above, once you move into this role you're either going to be slowly giving up responsibilities and watching your tech skills slowly move off the cutting edge as you focus on learning how to manager your team and developing others to fill the roles you once did, or you're going to be failing as a manager as you try to cling too tightly to your senior individual contributor responsibilities. So if you want to avoid that, it's important to be evaluating how you want your career to evolve. A role like this can be a first step up a chain, or part of a dev to manager pendulum. You also might discover that management isn't for you and decide to move back. I'm committed to this for a set period of time, and that's helped me to work through the days when I wonder what I actually accomplished, and think strategically about what I need to get better at.

4. Best Management resources

So this isn't a learning so much, but as a newbie manager, probably the best thing I can do is point you to the resources I've found helpful. So here are some of the best.

On Engineering Management

• Rands In Repose by Michael Lopp and the book he pulled out of the blog are great little snippets of engineering management gold
• Lara Hogan's Newsletter is full of useful advice, and she's really good about including exercises to help practice what she's describing.

On Management Generally

• Radical Candor is the single most helpful thing I've read while trying to figure out this whole management thing
• Patrick Lencioni's books are all told as "leadership fables" which can seem a bit weird, but in the squishy imprecise world of management, stories can be very effective ways to teach. I've read The Five Dysfunctions of a Team, Death By Meeting and Silos, Politics, and Turf Wars. They've all been great and I plan to read more of his stuff.

On Structuring My Time

• I reviewed it last week, but Deep Work was super helpful in thinking through how to balance my time.

On Career Path

• I linked this one above, but if you didn't click through then Charity Major's post on the Engineer/Manager Pendulum has been really helpful for pushing me to think through where I want to go next.

🔗 New Site Content

Since my book review from last week accidentally went live on the site at the same time as my newsletter last week, there's nothing new on the site this week. Oops!

😎 Cool Stuff

• Another great React post from Dan Abramov this week, and this one actually ties into the post I'm hoping to write for next week's newsletter :)
• Storybook 5 came out, which is a good excuse to mention that I've been using Storybook for ~6 months now and really like it as a way to facilitate discussions with non-devs about reusable components