A while ago, i had a discussion with a coworker about their boss. My coworker was venting a bit about a number of patterns that i recognized from my experience with various managers.
First off, let me say that i’m not a manager. i was a manager for a while and was terrible at it, so not being one to want to repeat mistakes, i haven’t pursued being one since. Being a good manager is incredibly difficult and requires a number of talents that are not included in WSJ Productive Resource Engagement books or whatever the current trend is.
What i do have a lot of experience in is managing my manager. Each manager has their own quirks, but there are certain types of managers that i’ve learned how to train and deal with.
Let me talk a bit about Process Managers.
Process Managers are folk that are in love with the process of management. These are folks smitten by things like JIRA, AGILE, SCRUM, and all the other things that either add or remove things from various checklists that they fetish over. These are people who “want to see progress” and expect their reports to have complete, analytical breakdowns of tasks done within minutes of being assigned. These folk do not do well with things like “discussion” or “revision”, since that requires them to alter the carefully crafted charts and diagrams that they spent all week putting together to impress their own manager.
Some folk might feel that these sorts of managers like to micro-manage, and a number do, but mostly, they’re looking for the dopamine hit of “number goes up” (or down, but basically not “stayed the same” so that they can show “the process works!”).
As a software engineer, we know full well that Life Does Not Work That Way. Asking how long a given task might take is like asking “how long will it take to carve this statue?” You have a rough idea, and can show progress, but as an artist, you have no idea what’s actually in the stone and if you it something unexpected, you have to deal with that. Sometimes you need to alter the design a bit. Sometimes you have to start over. It’s the nature of the art, and that is completely incomprehensible to the Process Manager.
So, how do you manage a Process Manager? You feed them the dopamine they’re looking for. Give them short updates where you specify the work that’s been done and the very short scale work that lies ahead. Give them little things that they can check off of a list. If you need to alter a design or the scale of something changed, give them a new checklist of things to tick off. Track Everything via the ticketing system of choice (Jira, bugzilla, Postit notes on the cube wall, whatever). They’ll grouse, but you gave them delicious mental candy, so they won’t stay mad for long.
Play the game they want to play and they stay happy.
On the other side, realize that they are not invested in your growth and career unless it maps to some form of progress they can chart. So, if you want to go to a conference or learn about something, you need to absolutely qualify it with all the bells and whistles they want to see. Put together an Impact Assessment that highlights what percentage points of improvement you expect to deliver or whatever.
(bit of a side note: Process managers tend to think of reports as ‘resources’. You know, like the copy machine or coffee maker. Mind you, when the coffee maker has a bad day, i replace it, because coffee makers very seldomly self correct. A coffee machine doesn’t perform poorly because it’s kid was up until 3 AM, or because a parent just got a cancer diagnosis. People do, and they’re not going to tell their manager or coworker about that for lots of reasons. People have off days and weeks, and a good manager knows and works with that. The coffee machine also doesn’t angle to get the copy machine’s job, but that’s a different matter.)
i kinda spelled all that out for my co-worker, with the added point that “all of this is temporary”, none of it is actually personal, particularly since the senior engineer on the project has zero complaints, and frankly the stuff the Process Manager is complaining about is stuff like “too much discussion in PRs”. Uhm, you want discussion in PRs. That’s documentation. It also means that folk aren’t just rubber-stamping future bugs into the code. i’d rather there be good conversation in a PR than a bunch of issues being re-opened.
i also gave a bunch of other tips for how to deal with a Process Manager, and maybe i’ll write those up sometime.
A key aspect of a good engineer’s life is dealing with non-technical issues like these. A key aspect of a senior engineer’s life is giving junior folk the insights needed to become a good engineer. Dealing with iffy managers definitely falls into that category.