One of the bigger changes going from engineer to manager was to redefine what I meant by the question: how are we going to do this? As an engineer I would deconstruct that question to ask what is the software we need to build, and the technical barriers we need to remove, to achieve our goals. As a manager I would deconstruct that question to ask what is the process by which we achieve our goals.

When I wear my manager hat and ask “how are we going to do this?” I get a little frustrated when I get the answer “I don’t know.” But that’s unfair – there are always problems to which we do not know the answer. What makes me frustrated is when the answer comes too quick, when someone says “I don’t know” because they are missing something they feel they need to come up with an answer. I don’t know because we have to write more code before we know if the idea is feasible. I don’t know because the decision is someone else’s, and so on.

You know! If the decision is someone else’s, then the answer to the question is: we are going to do this by asking that other person what they want and how they are going to make that decision. If we don’t know if the idea is feasible, then the answer to the question is: we are going to do this by exploring the feasibility of this technique, and doing another iteration of planning once we know more. “I don’t know because…” is fine because it is an answer of sorts, it lets the team make an answer in the form of a process. “I don’t know.” – ended with a period – is even okay for a moment, if you treat it as meaning “I don’t know so we are going to do this by learning.” It’s the “I don’t know, let’s move on” that I don’t like.

But I’m being a little unfair. It’s my job as a manager to answer at the process level. While I try very hard not to pigeonhole people, maybe I should also work harder at accepting when people establish bounds to their role. When you are trying to produce it can make sense to stay focused, to resist going meta. When you are working in a team, you should rely on the diverse skills of your teammates to let go of certain parts of the project. It can be okay to go heads-down. (Sometimes; and sometimes everyone on the team must lift their heads and respond to circumstance.)

This is a long-winded way of saying that I appreciate more of the difference in perspective of an engineer and a manager. It’s hard to hold both perspectives at once, and harder still to act on both.

In my new project I am returning to development, and entering into the role of working manager, an odd way to say that I am performing the same tasks that I am also managing. I cut myself off from programming when I started management so that I would not let myself be distracted from a new role and the considerable learning I had to do. Returning to programming, I can tell I was right to do so.

Moving between these two mindsets, and two very different ways of working, is challenging. In both I want to be proactive, but as a manager towards people, and as an engineer towards code. With people I’m investing my time in small chunks, trying to keep a good velocity of communication, watching for dropped balls, and the payoffs are largely indirect and deferred. With code it takes time to navigate my next task, I want to focus, I’m constantly trying to narrow that focus. And the payoff is direct and immediate: working code. This narrowed focus is a way to push forward much more reliably, so long as I know which way is forward.

But I’m a working manager. Is now the right time to investigate that odd log message I’m seeing, or to think about who I should talk to about product opportunities? There’s no metric to compare the priority of two tasks that are so far apart.

If I am going to find time to do development I am a bit worried I have two options:

1. Keep doing programming after hours
2. Start dropping some balls as a manager

I’ve been doing a little of both. To mitigate the effect of dropping balls I’ve tried my best to be transparent about this. It may have been effective: I am not doing my best work on X, because I’m trying to do my best work on Y. But I won’t really know if this has worked until later, turnaround on relationship feedback takes a while.

An aside: I’ve been learning a bit about Objectives and Key Results, a kind of quarterly performance analysis structure, and I particularly appreciate how it asks people to attempt to achieve 70% of their identified goals, not 100%. If you commit to 100% then you’ve committed yourself to a plan you made at the beginning of the quarter. You’ve erased your agency to prioritize.

Anyway, onward and upward, and wish me luck in letting the right balls drop.