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:
- Keep doing programming after hours
- 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.
I'm a working manager, a scrum master for the team and I manage a 50% product development slash 50% operations team (I'm committing multiple sins, as you can see) so I can very much relate to your struggles. What I've been more or less successfully doing in the last couple of months was nail down my schedule 2-3 weeks in advance. Even if I don't always stick to my plan or get interrupted during, having a slot in my calendar pre-allocated for a certain activity dramatically reduces my cognitive load and allows me to focus on doing the work rather than deciding what to work on. Also, multitasking does work if one of the activities is completely automatic.
I'm very interested in reading the outcome of this balance. Juggling is the focusing on one object long enough to suspend it while focusing on another. You hope you get back to that object fast enough to give it the attention it needs. Writing some sort of complex algorithm or working through a difficult workflow AND managing operates completely outside of one focused contextual ball in a particular state. That ball is rotating, it may have changed shape, it may not even be in the routine anymore. I've tried it once and only once and I quickly learned that it's just not possible to be as effective without focusing on one or the other.
Same here, but with the added perk of having teams in Europe and a couple of Indian Cities, but being based on North America myself.