Eliot's Ramblings

Debugging the Boss: The Politician

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.

General Behavior: Politicians are social creatures, and embody many of the qualities that make good leaders. They are well-liked by their peers, because they invest time in those people they think will make them look good. They speak well and have a natural sense for knowing what people want to hear. They are so attuned, however, that they often seek advancement through this capability alone, putting the good of the team and their mission second.

Behavior in meetings: The Politician will often keep their team out of external meetings, like the Isolationist. This helps them say one thing to their team and another to other stakeholders. Sucking up to the boss is by no means limited to one type of person, but the Politician is particularly adept at it. Watch for them to agree with the boss’ position when they are around, and qualify this agreement in private with their team.

Impact on team: Often their desire to look good leads them to commit their team to impractical goals, but then privately blame them when those goals are not achieved. Their team members will catch on to this eventually and go from adoring their manager to loathing them.

Another impact they can have is to allow high performers or those with great potential to languish if they are not outgoing and charming, because they don’t help the Politician look good. This is the opposite of a manager’s charter – their job is to find those diamonds in the rough and polish them up.

Impact on product: Thankfully the Politician is not a product killer, but they have a near-certain likelihood of keeping it from reaching its potential, because their dedication is to looking good at all times, even when it means they agree with a decision that results in a poor outcome, or making no decision when it would ruffle the wrong feathers.

Trait gone wrong: The ambition to be a key player; also the desire to get along with important people.

Debugging: As with other corrective measures, positive reinforcement is better than negative. Show how their powers can be used for good, rather than ill. Use a positive way to talk about this, by explaining that when politics is used in the service of a goal other than naked ambition, it becomes diplomacy.

Not to be mistaken for: The Isolationist, who seeks to keep their team under the radar for protective reasons. Or the Glory Hog, who may play politics, but is motivated by fear.

Glass as a Presentation Aid?

I’m intrigued by the idea of using Google Glass during a presentation to avoid ever having to look at or touch a computer. I’ve taken a cursory look over the apps that are currently available, and tried out Your Show and Glassentation.

I’m concerned about two things – one, pulling it off at all, meaning making sure that my audience is still focused on my talk and not my gadget, and two, being able to continuously engage the audience while referring to my notes quickly enough to not break the flow.

Any suggestions? At this point I think I’d do well using the Evernote glass app and putting my notes there. Anyone out there who’s seen this done, or done it themselves?

Debugging the Boss: The Isolationist

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.

Impact on team: The Isolationist may have some team members who are very happy to be isolated, some who chafe at their lack of interaction with other teams, and some who are indifferent. The major impact to the team, however, is not lowered morale.

Teams need exposure. Seniority comes with experience, and if a team member’s only point of contact to the world is their manager, they aren’t going to get the experience of working with many people. That makes them poorly positioned to work in any other environment. They also need exposure so that their colleagues know, challenge, and respect them. Without contact with a larger team, they won’t feel like part of a larger team.

Impact on product: Increased risk of failure! Isolated workers are always going to be missing major parts of the story, so they won’t get why what they’re doing matters. These circumstances vastly increase the risk that requirements will not be correctly understood. If, for example, you don’t understand the concerns of your colleagues on the business side, you can’t help catch a mistaken assumption.

Trait gone wrong: Protectiveness, primarily. Isolationism is most often motivated by a sincere desire to help their team. This can be exacerbated by their skepticism of the capabilities of other teams, which, unsurprisingly, may derive from their having been managed by an Isolationist themselves. As well, they might be overconfident, if they think can handle the throughput of syncing their team members with everything they need to know from the meetings they don’t get to.

Debugging: The Isolationist is motivated by concern for their team, so debugging requires refocusing that concern on their team members long-term effectiveness and career development.

Usually an Isolationist has learned the behavior from a poor example, and it’s important to present them with specific examples of ways that problems that cropped up could have been prevented had their team members been more involved in cross-team communication.

One exercise for de-isolating is to select a single team member, and a single project they are involved in, and send them to one carefully chosen meeting (maybe a recurring one) that they could contribute to, or benefit from. Bring an engineer who wrote the code on a project to the next brainstorming meeting for that product.

*Not to be mistaken for: The Politician.

Jira Email Summarizer

I’ve written a Python program to do something fancy with JIRA that I couldn’t get using built-in facilities. You already get notifications from Jira about the tickets you personally care about, based on your notification settings. My tool will give you, additionally, an hourly email in your inbox summarizing all the changes in projects you care about, skipping the the ones you already got direct notifications of. Not only that, but it will make sure that you only ever have one of these summaries in your inbox, by consolidating them when a new summary is generated. It’s only at version 0.2 at the moment, but I’m opening it up today and hopefully some of you will find it useful. Over time, I hope we can polish it some more.

The Motivation

I get Jira notices all day long (at least 300 per day), for a variety of projects. Sometimes I’m in a situation where I want to review and potentially act on these notifications immediately. At other times I take a hiatus from email and focus on meetings, coding, etc., and all those notifications pile up (I’ve written another, more complicated tool to handle these, which I’ll cover later).

When I go from a task back to email mode, and review the ruin that time has wrought on my inbox, one of the things I scan for is the latest Jira developments. However, even with my ticket mail notification pruning tool, the signal to noise ratio was not good enough. Plus, I still had to review each update, email by email.

To Hell With Filters

So why not just do the obvious thing and use filters? Well, I’ve tried filters many many times. The problem is, once I filter something, it’s not in my inbox any more. I have so much other mail piling up in my inbox that I never go looking into the filter folders. So filtered mail is just forever dead to me. In some cases that’s actually just fine, and if there’s something I’ve never read but then need to find, I can search for it. With Jira tickets, however, that isn’t sufficient – I have to stay on top of those.

I looked for a Jira plugin that could help, but there wasn’t anything remotely suitable. If I was going to get any help, I was going to have to write something myself.

Now, I’ve got plenty of high priority code-related work on my plate, so taking the time to write a tool like this required a non-trivial decision. What made me pull the trigger was a convergence of a few things. I was about to go on a work trip, and email always builds up when I travel. This conincided with my recently missing a couple of important Jira notifications due to volume, while other non-Jira emails were slipping through the cracks. I’d been consistently declaring email bankruptcy, about once a month, too.

The Summarizer

Since I was going to have to write my own tool, I could consider what I really wanted:

  • Notifications of changes to tickets that I care about to hit my inbox.
  • A managed TODO list of Jira tickets that have changed with some indication of priority, and if I should look at them.

I started with this quick algorithm:

  • Find all tickets that have changed in last X hours (more on X later)
  • Organize them by what field in the ticket changed
  • Find out what’s changed
  • Put that all into a nicely formatted email

That happens once an hour, and that alone would produce a nice hourly summary.

But what if I don’t deal with Jira for 7 hours? There would be 7 of those summaries to read, and worse, the same ticket might be in all 7, driving me nuts.

So, the program does more than just summarize:

  • First read the inbox, and find any summary email still in there
  • Instead of changes in last hour, go back and combine time frames
  • After sending a new email, automatically archive the older one.

Now I only ever have exactly 1 Jira summary email. To commit bankruptcy: just archive one email and start fresh!

The Jira Email Summarizer is available on Github.

A sample of the output:


SERVER-12351 Correct auditing comments in action_types.txt
   status: Open
   reporter: someone@10gen.com
   assignee: someone@10gen.com
   fixVersions: <version>
   priority: <priority>
   components: Logging,Security

SERVER-12350 Failed update with $mul errors with reference to $inc
   status: Open
   reporter: someone@10gen.com
   assignee: NONE
   priority: Minor - P4
   components: Updates
            Trivial to reproduce, just set a field to a string, then try to multiply it and you get the $inc error:

            db.foo.update({}, {$mul : {a : 2}}, false, {multi : true}, {ordered : false})
            Update WriteResult({

SERVER-12348 dropIndex is incorrectly labeled as auditing only in action_types.txt
   status: Resolved
   reporter: someone@10gen.com
   assignee: someone@10gen.com
   fixVersions: 2.5.5
   priority: Major - P3
   components: Security
            This issue is related to QA-341
            An Assignee
            In Code Review
      by: someone@10gen.com
         Code review url: http://codereview.10gen.com/6284539290714112
      by: xgen-internal-githook/internal-tools+githook@10gen.com
         Message: SERVER-12348 removed false comment from action_types.txt
         Branch: master

SERVER-12347 WriteBatchExecutor should re-use an UpdateDriver across all updates
   status: Open
   reporter: somesone@10gen.com
   assignee: NONE
   fixVersions: Needs Triage
   priority: Major - P3
   components: Internal Code,Performance

[Many more updates]

below supressed since should have gotten email

Video Tracking Capabilities

Are video tracking algorithms good enough to take the feed from a crappy digital camera, and tell me how fast I threw a baseball or how far I hit a golf ball? Last time I toyed with these over a decade ago, probably not, but now, they might be.

Debugging the Boss: The True Democrat

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.

Impact on team: Morale suffers as team members feel their excellence limited by the need to please everyone. Because they don’t feel like they own any particular decision, they de-invest.

Impact on product: When consensus is not easily attained, work grinds to a halt. Even when consensus can be reached the product will be built to the lowest common denominator, without differentiation. It will be be an unopinionated, “me-too” product.

Trait gone wrong: Fairness — this manager wants everyone to have input.

Debugging: Like the Best Friend, this leader needs to understand that their team members lose job satisfaction when they see merit consistently subordinated to consensus. Unlike the Best Friend, reason, not emotion, is the basis for this appeal.

Fairness to a team is not a matter of all members getting an equal say about decisions, it’s about ensuring they all get the opportunity to excel at their job. A manager must choose what decisions to empower their staff to make, matching their abilities to their areas of responsibility.

Someone in this situation has to be forced to make some tough decisions. Assign them homework: next time a debate between two reasonable choices takes more than 20 minutes to resolve in a meeting, the manager has to make the decision. Everyone will be happy they did, and it should start a trend. Even if that choice turns out to be wrong, everyone will still be happier than they’d have been had there been a stalemate. Better to take a stab, and to fail fast, then debate indefinitely.

Not to be mistaken for: The Best Friend. This manager thinks more about fairness, than they care about how people feel.

Debugging the Boss: The Glory Hog

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 Glory Hog can behave a lot like the Hyper-Owner, but the Glory Hog is a much nastier creature, because they are motivated by a real character flaw, not a trait gone overboard. Like the Hyper-Owner, they will attempt to force decisions to go through them, and will suppress ideas that they did not originate. However, unlike the Hyper-Owner, they will actively quash these ideas, rather than stalling them, even if they are good.

The Glory Hog is usually adept at playing politics, which helps them cloak.

Behavior in meetings: In meetings with their reports, the Glory Hog will seem much like a friendly manager with hyper-ownership tendencies, being supportive but putting the brakes on their reports’ ideas. With their peers (other managers), the Glory Hog will introduce any initiatives they think they can take credit for, and it may be hard to recognize their behavior. One potential red flag is they will talk a lot about what they personally did, without mentioning their team.

A very strong telltale of the Glory Hog is that they will do their utmost to prevent meetings from including combinations of their peers, superiors, and their reports, because that venue makes it hardest for them to obscure their scheme. This might make them seem like an Isolationist (to be covered in the future). When those meetings do occur, they will speak on behalf of their reports as much as they can get away with, and may even overtalk them.

General Behavior: Uses the “I” word too much.

Impact on team: Initially, people who report to the Glory Hog may not notice, or care, but over time they will become demoralized in the same way as those reporting to a Hyper-Owner. However, given time they will perceive their boss to be actively harming them. Then they will start putting in the minimal effort they can, and start looking for work elsewhere, since it seems unlikely that their careers will blossom at this company.

Impact on product: As the team shuts down, all progress stops.

Trait gone wrong: Being generous, I’ll say “the desire to impress”.

Debugging: If you find a Glory Hog in your midst, be prepared for a bad outcome. It’s not impossible to redeem one, but be ready for lots of defensiveness and pushback – the Glory Hog is not overly concerned with the harm they are doing around them.

As usual, debugging a boss means connecting the trait gone haywire with the improvement the boss needs to make. In this case, if the buggy boss needs to impress, it must be explained to them that the way to impress is to foster a happy, durable, highly-productive team.

Not to be confused with: The Hyper-Owner, The Isolationist, The Politician.

Notes: There are some variations here. You could have a Glory Hog who also takes all failure on their shoulders, which is at least consistent. The worst kind is the one who takes all the credit and shifts all the blame.

Debugging the Boss: The Best Friend

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.

This is is not to say that establishing a rapport, even a personal relationship with your reports is a bad thing. However, befriending and managing are different things.

Behavior in meetings: Doesn’t demand accountability for slippage. Allows meetings to degenerate into hangout sessions.

Impact on team: Personal responsibility goes down without accountability. Team members can be afforded too much leeway on commitments and job performance. They may like their day-to-day, but their career stagnates because their manager isn’t pushing them to grow. When a shakeup comes, they are poorly positioned. And if team members disagree on important issues, this manager, instead of providing leadership, can be paralyzed by the need to make everyone happy… but we know trying to please everyone all the time means pleasing no-one.

Impact on product: Quality and date slips. Nothing gets done. Too much foosball.

Trait gone wrong: This person cares deeply for everyone on their team, wants them to like them and each other. That’s not a bad thing! But when this desire overrides their responsibility to push their team to be the best they can be, it becomes a management bug.

Debugging: Connect the concept of their team’s suffering gradual loss of pride and career stagnation to the lack of discipline. Discuss the difference between respect and friendship, and the difference between their team members liking them and their team members liking everything they do. By prioritizing friendship over job performance, they’re not actually doing their team favors. Encourage them to have confidence that if they provide leadership, their team will respect them, and respect is always a good basis for friendship.

Not to be confused with: The True Democrat.

Debugging the Boss: The Hyper-Owner


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.

The Hyper-Owner

The Hyper-Owner/micromanager is a manager who bottlenecks their team by forcing all decisions to go through them, never delegating. This can be due to explicit distrust, but more often it is just a subconscious need to control everything. Hyper-ownership can be born from good motivations, but ends up having very bad consequences.

Behavior in meetings: Monopolizing. Sometimes even talks on behalf of people who are in the room.

Impact on team: Vacuums morale out of the team as members perceive the absence of confidence in them. Nobody likes the idea that they are a flunky who is only there because you can’t clone yourself.

Impact on product: The Hyper-Owner materially impacts velocity by delaying decision making. They will also erode the ambition of the product as velocity decreases. Users of the product can be alienated due to feedback that is never acted on.

When the status quo is that this person dictates everything, even a “perfect” micromanager who makes all the right decisions will stifle product development. The culture born of this management style impedes creativity, and punishes telling the Hyper-Owner they are wrong. When the business runs into areas outside this Hyper-Owner’s expertise, what you get is iTunes Ping, for example.

The trait gone wrong: Responsibility. The Hyper-Owner thinks their job is to be responsible for every single decision made at any level below them. It’s good to feel responsible, but bad to prevent the people you manage from feeling responsible too.

Debugging: Let go of your fear, you must. You hired the people on your team because they were the best (right?). Deliberately choose a decision to have a team member make, no matter how small, and then absolutely abide by it. Their decision may lead to an outcome you think is less optimal, but do not revert, rather try to understand the reasoning that led to that decision, and discuss the reasoning with the team member… but do not tell them it was wrong. Think of this process as an investment which will pay dividends in greater reliability and team velocity when your team is a well-oiled machine.

Not to be confused with: The Glory Hog.

Debugging the Boss: Intro

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.

I don’t think I’m exaggerating. Of all the things that make people dislike their job, having a bad boss has got to be in the top two or three. By contrast, “extremely difficult working conditions” isn’t even on that list. Check out all the stories of New Yorkers getting work done under whatever conditions they could during and after Hurricane Sandy for proof of that. Of every single complaint you’ve heard about someone’s working environment, “My boss is an idiot” has got to be the one that makes them the most unhappy.

Because of this, and because MongoDB’s engineering team is growing so rapidly, I have been thinking a lot about management, and some of the traits you find in people that, when found in the extreme, make them bad managers. Recently, my thinking on this has crystallized into a framework that I’m calling “Debugging the Boss.”

It’s basically a field guide to identifying these traits in the wild, along with some advice as to how to cope with these types of managers, both for those who report to them, and for those to whom they report. I think that every boss embodies some of these traits, and having one doesn’t make you a bad boss. The key is making sure you moderate, so that a trait which is ordinarily positive does not become negative. For this reason, my field guide includes a section on what positive trait gone wrong requires debugging.

An example of this, which I will expand on when I post my first entry in this series, would be how a sense of responsibility can become “hyper-ownership”. With this trait, a manager prevents their team from being meaningfully connected to responsibility and decision making.

The Series So Far: