On November 1st, 2016, I gave a talk at the CTO Summit series hosted by NASDAQ. It was a 20 minute talk, updating and expanding on a topic I’ve both blogged and written articles about – how important it is for engineering managers to keep their hands in the codebase they make decisions about. Here it is:  

Last week I was in Israel for the MongoDBeer meetup and an enterprise event, both hosted by Matrix, one of our partners, and a few really great client meetings. One of the things that I don’t get to do often enough these days is work directly with customers on interesting technical challenges, so those client meetings were really quite invigorating. I was reminded of this recently when I was doing a fireside chat with Albert Wenger at NYCode, an event hosted by NextView Ventures.

Everyone with a staff knows they need a staff meeting on a recurring basis, often weekly. And those who don’t have staff are themselves in other people’s staff meetings, making it one of the most common meeting types for anyone to attend. Sadly, there is often ambiguity around what they are for, making them annoying and inefficient. What I Want out of Staff Meetings The purpose of these meetings is twofold: 1) status updates, and 2) key decision making or the precursor conversations for decision making.

Like The Superhero, The Martyr does their team’s work to make up for not managing. However, whereas The Superhero insists on hogging all the interesting work, The Martyr does work that no-one wants to do. When a deadline is looming and things are looking down, they will pull all nighters to finish it themselves rather than do what a manager should do, such as motivating their team, or fixing the deadline.

Like The Martyr, The Superhero does their team’s work to make up for not managing. They are super smart, super capable, and they can often do most or all of the jobs that their reports do better than their reports. They also care deeply about the quality of the product their team works on. Unfortunately, they are not inclined to delegate any of the interesting work, because they want it all for themselves.

The Politician’s main concern is making their bosses and peers think they are doing a great job, and are responsible for every success they can claim, regardless of reality. They are cousin to the Glory Hog, but are far less destructive than them, because their goal is to create a successful environment for themselves. Also, their behavior is driven by confidence, not under-confidence. They are not threatened by their reports’ accomplishments, because they intend to take credit for them.

The Isolationist manager takes their job as a “crap umbrella” to a dysfunctional extreme. They try to limit interactions between their team members and other people in the organization. They take their responsibility toward their team very seriously, and their isolation is a misguided attempt to make them more productive. Behavior in meetings: The Isolationist isn’t so much identified by behavior in meetings, as much as by the influence they have on organizing meetings.

The True Democrat never makes decisions, they only operate by total consensus. This approach will lead to just as much unhappiness in a team as ignoring their input. Egalitarianism is a good foundation for seating charts, opportunities, compensation, and promotions; it is not for strategic decision making. Put another way: fairness is not the same principle as equality. Behavior in meetings: The True Democrat is more concerned with equal speaking time than guiding the meeting towards the best outcome.

The Glory Hog is really bad news. They want to take credit for the work their team does, and are more interested in their own advancement than their team members’ performance and growth. This boss bug is my first example of a cloaking bug, that is, this person will often use subterfuge to prevent their trait from being identified. As such it is very important to be able to distinguish glory hogging from innocuous behavior, and other bugs where the observed behavior can be similar.

The Best Friend manager wants to be friends with their team members more than they want to manage them. Their team members enjoy work and usually get along, but have a tendency to miss deadlines, do not drive the product forward, and over time, lose pride in their work as they accomplish less. A good manager has a team that respects them, and can also make tough decisions that may not make everyone on their team happy.

Recap Last week I started this Debugging the Boss series, to highlight specific traits that lead to management problems. I expect most people will see these traits in themselves or their bosses (I certainly do). I think everyone has some of these traits… in fact every manager should have many of these traits. What’s important is having them in moderation. I’m going to post one of these every week or so until I run out of traits to write about.

Managing in a technology company is one of the charter topics of this blog. I cannot think of any single thing that represents a greater risk to a growing tech firm than the damage that can be done by bad management. A really bad employee can waste resources and time, and lower the morale of those around them; a really bad manager can do more serious harm, in a wider range, that lingers on even after they have been removed or corrected.

Update: I’ve written a much more in-depth article on this topic that was published in Dr. Dobb’s Journal on 1/7/2014. The typical expected path of an engineer goes something like this: Individual Coder Project Lead Team Lead Manager Director At each step, their expected coding time looks something like 90% (Individual Coder) 80% (Project Lead) 50% (Team Lead) 1% (Manager) 0% (Director) This seems wrong. It is not shocking that engineering management is often found to be out of touch with the tech when they aren’t working on it themselves.