Distraction Driven Development

One of the hardest things that I've found about transitioning to engineering management is that your time is not your own. Sarah Drasner, in her excellent book Engineering Management for the Rest of Us, refers to this as "interuption-driven work".

That was a new label for me - and it struck a nerve. She's absolutely right. And this was in the first paragraph of the first chapter in her book - seriously - go read it!

When you become a manager, the point of your role is not to do things, but rather to get others to do things and do it as well as they can. Because of that your focus will have to shift to solving problems so that your team is unblocked and can do their job.

• Weird API question? You have to look into it.
• Feature no one knows about? You have to document it.
• Complaint from a stakeholder? You have to investigate it.

Now, sure you will (hopefully) delegate aspects of these distractions to your team to help solve - but they will hit you first.

And that is as it should be - hopefully you can be the receiver of all of the random distractions so that you can at least triage them and put them into your normal ways of working, so that your team can work in the ways that they expect to and do their best work. That's the dream, anyway.

So, yeah, as you become a manger - set your expectations accordingly. You're now a distraction filter.