Part 4 in a series on managing programmers

When I was first thrust into management, I would come home at the end of almost every day frustrated at how little I had accomplished. You see, like most technical managers, I still tried to keep myself involved in the task of actually writing software. I was a “working manager”, and still a developer (“75%!”). On my daily to-do list I had code to write, diagrams to draw, and databases to query.

But I felt like I “never get anything done” because, dammit, now that I was “the boss” everyone kept interrupting me. I found that even on days when I only had two or three meetings scheduled I’d still end up spending most of my day in hallway chats, impromptu one-on-ones, emergency client meetings, and responding to about ten times as many emails and phone calls as I’d had to deal with before I became a manager.

It took me a good deal longer than it should have, but I’ve since made three key realizations:

  1. A manager’s job is more about people than about code.

    A manager’s primary job is to make sure his or her team members are operating at optimum efficiency. That means your job, as a manager, is to remove barriers and pave paths. Your job is to work with and through other people to accomplish goals. You are no longer a do-er. Your primary contribution to the organization is no longer embodied in the code you write, but rather in your performance as the “glue” between individuals, working on stage and behind the curtains to connect people and teams. You are a leader, and your job is to inspire, motivate, mentor, guide, and help other members of the team do the actual doing. Toward this end:

  2. A manager’s job is to keep their team in “flow” as much as humanly possible.

    In “Flow: The Psychology of Optimal Experience“, Mihaly Csikszentmihalyi’s defines a state of flow as “the mental state of operation in which a person performing an activity is fully immersed in a feeling of energized focus, full involvement, and enjoyment in the process of the activity. In essence, flow is characterized by complete absorption in what one does.” (Wikipedia). Most creative professionals, including programmers, do their best work when the are able to achieve a state of flow. This is the moment when as a programmer you’ve got 18 different variables, 7 competing business requirements, and the entire architecture of the system you’re building loaded into your brain as you work through a challenging implementation. It took most of the last hour for you to get yourself to the point where you’re in flow and able to make forward progress toward a solution, and all of that can get flushed down the toilet with one single interruption. Which is why:

  3. Managers endure life in interrupt mode in an attempt to prevent their team from having to step out of flow.

    You no longer get to spend as much time in quiet solitude, working for hours crafting a nearly-perfect solution on a single problem. Rather, you are supposed to be there to run interference and, yes, to run errands for your team. Your new role expects you to be able to juggle multiple balls, multiple projects, and multiple priorities. Which requires, at most times, multiple personalities. In one moment you’re the wise mentor, working with a junior developer to clean up some code or get a test to pass; the next moment you’re the project manager politician fighting to balance a half dozen emergency requests across only three developers or write three dozen user stories before noon; and minutes after that you’re playing the gadfly, prompting your fellow developers to reconsider potentially problematic architecture decisions. And all of this talking and walking and meeting is in selfless service to the goal of trying to keep the rest of your team in flow.

This life in interrupt mode is very hard to take, and is very likely one of the main reasons why many new technical managers bail out of the job. But it also makes for very interesting and exhausting days. Because after you get home and get the kids off to bed you still have your fair share of code to write, diagrams to draw, and databases to query…