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. We were talking about some of the things we did early on at MongoDB that led to the great momentum we now have. Albert said that a major factor was how obsessed I was with making our users successful with their deployments. That’s true, I was completely obsessed. I had this thing about all the questions on our google group being answered as fast as possible. Day or night, if someone had a problem, I was trying to fix it with them.
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.
The purpose of these meetings is twofold: 1) status updates, and 2) key decision making or the precursor conversations for decision making. I want status updates to be very efficient, well thought out, and delivered only for items that are really required. I want thoughtful conversation on key topics, and I want to cut short conversation when the topics are sufficiently discussed.
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. When things go wrong, they will take all the blame instead of teaching their team.
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. If one of their reports comes to them with a problem, they are more likely to just do the work for them than teach them how to solve the problem.
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. This means that as long as they look good, they don’t mind if other people do too.
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. They do their utmost to prevent their team members from attending meetings with external teams. This makes them a huge bottleneck.
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. They will either advocate actively on behalf of everyone’s ideas, or they will disappear into the woodwork when consensus is not forthcoming. Either way, they cause meetings to grind along without heading towards a resolution.
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.
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. First up: The Hyper-Owner.
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:
At each step, their expected coding time looks something like
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.