I was sitting at my desk, waiting for a meeting to begin. Across the row, one of my colleagues worked away, and since the meeting couldn’t begin without him, I knew that I could safely keep working until he got up to go.

I suddenly realized what I was doing. Really? I was just going to wait for something to happen? This isn’t me! I’m the one who runs around and gets everyone together. I’m the one who works in the background to make things happen. I’m the one who organizes, noodges, and sometimes (when it isn’t my meeting) just shows up on time and works on my laptop while waiting for everyone else to show up.

So, I went and waited. And while I did, I wrote out the following list:

1. I don’t go to the meeting
2. I wait until someone reminds me to go
3. I go and wait until other people show up
4. I gather the troops and try to get the meeting started more quickly
5. I create an agenda to help the meeting go smoothly

I was sitting at my desk, deleting a whole slew of error emails that had just come through. It bothered me that these error emails existed, but I had work to do, and they really weren’t my problem.

1. I ignore error messages
2. I watch the error messages to make sure I haven’t broken anything
3. I investigate error messages, and assign them to the responsible engineers
4. I investigate error messages, and fix the damn things myself
5. I put systems in place to prevent the errors from happening

I was sitting at my desk, annoyed that a tool was acting up.

1. I use tools built by other people
2. When I have a problem with a tool, I send out a broadcast email to see if anyone knows a workaround
3. When I have a problem with a tool, I investigate and send an email to the tool’s creator
4. When I have a problem with a tool, I fix it
5. I extend/create tools to make everyone’s lives easier

The more personal responsibility you feel, the higher up these ladders you get, the more time they take, the less time you have for actual project work. It’s easy to spend your whole day following up on emergent issues, and never getting anything done. On the other hand, it’s also easy (and fun!) to put on the headphones, shut out the world, and count on someone else to let you know if something needs taking care of. I’ve known engineers who’ve had tremendous, debilitating feelings of ownership – who couldn’t let a single error report go by without trying to investigate, and good luck trying to get them to complete any actual tasks. I’ve also known engineers who couldn’t be bothered to check daily error reports to make sure their code was working, and couldn’t be entrusted with anything risky.

In moving from middle management to operations, I’ve gone from an interrupt-driven role which required me to spend most of my time in meetings and to keep constant watch on error counts, to an individual contributor role in which I have to keep my head down and concentrate on project completion – while still attending meetings, keeping a watch on error counts, and looking for ways to automate away repetitive tasks. It’s easy to let yourself drift to one extreme or another – much harder to figure out a good balance.

Worse yet, while it’s sometimes easiest in the moment to fix issues on your own, that’s going to prevent other engineers from developing a sense of ownership for their results. Nor do you want a reputation for being a nag. It’s enough to make you want to camp out at the bottom or top of each list, and forget about the shades of gray in-between.

So, here’s the point in the blog post where I’m supposed to provide an incisive, potentially controversial, thought-provoking insight into how one might cut the Gordian knot – or at least provide some kind of rule of thumb you can fall back on. Alas, I don’t have a witty one-liner that can be packaged up, put on a motivational poster, tweeted and retweeted. In the end, It’s just a matter of time, acclimatization, judgment, and constant vigilance.

Follow me on Twitter