Forem: Ced

Understanding Your Boss's True Motivations

Ced — Thu, 28 Mar 2019 03:29:15 +0000

Everyone you work with has what I call ‘shallow motivations’ and ‘deep motivations’.

The shallow motivations are the things you can come up with if you know where a person lies in the company org chart. So, for instance, if you see that Jane is in sales, you can probably conclude that she’s motivated by landing deals and hitting milestones and winning performance bonuses.

Deep motivations are what you get when you look past the role to consider who they are. This includes how they see their life, who they wanted to be when they were younger, what they desire today, and what they want to achieve in the long arc of their career.

Normally, as a manager, you’ll build a model in your head for each of your subordinates. Knowing how your team functions and what motivates each of them makes it easier for you to do your job. You know which buttons to press. You know the types of task assignments that make their eyes light up. You know who’s at risk of leaving, and who isn’t.

But that’s not what this essay is about. This essay is about doing all of that … to your boss.

Understanding Your Boss

Your boss, like everyone else, has deep motivations. Knowing what these ‘true’ motivations are will be incredibly useful given that you’re working under her, in the same way that understanding ‘true’ motivations for each person on your team makes it easier for you to work with each of them.

But let’s use a concrete example to illustrate this point.

Say that you want to pitch a proposal to your boss. You’ve got a small team of software engineers and designers, and they’re all busy working on a release that’s due in a couple of months. Your proposal is that you want to take two software engineers and a designer and have them work on a smaller project, one that would make it easier to do future releases — that is, all the releases after this one. This would mean dropping one or two minor features from the upcoming release — a small sacrifice, you think, for higher future velocity.

There’s only one hitch: your boss says no. She says that the next release should be your topmost priority, and you should focus on that to the exclusion of all else.

Now comes our question. Would your assessment of this situation change if you found out:

Your boss’s impending promotion is pegged to the delivery of this release. This makes it super important to her, and she is rightly antsy about your request, or
Your boss’s daughter was recently diagnosed with a chronic illness, and she’s been thinking of leaving the company, or
There’s been rumours of the company getting acquired soon, and your boss just wants to cash out.

It’s highly likely that any of these three pieces of information would significantly affect your assessment of the situation. It’s also likely that your actions would differ greatly if you knew these facts beforehand.

The point I’m making here is that if you know of your boss’s true motivations — really know, the same way you know your best friend like the back of your hand — if you know your boss as well as that, then you’re likely to be way more effective when working for her.

This effectiveness presents itself in three ways.

The Benefits of Understanding True Motivations

The first major benefit of understanding your boss’s true motivations is that you’ve now unlocked access to the simplest, safest method to present criticism to her.

Granted, presenting criticism is a big topic, one that’s far larger than just ‘understanding motivations’. We’ll cover the intricacies of that in some later post. For now, though, understanding your boss’s motivation unlocks the most basic form: people are more receptive if you frame criticism in terms of what motivates them. You’ll be surprised at how effective it is to say: “I know you’re interested in accomplishing X, but Y is getting in the way of achieving that. Wouldn’t Z be better at helping us achieve X?”

Concrete example: let’s say that your boss is motivated by an upcoming promotion, and in your company, promotions are tied to the quality of releases. Saying “the way we’re packing our releases now is just slowing us down” is probably going to be a lot less well received compared to “I understand that delivering releases are your highest priority, and that it’s super important that we deliver on time and on target. But the way we’re packing our releases now is just slowing us down in the long run. Shouldn’t we take some time to work on our release process?”

Sufficiently rational bosses should be able to work out the implications of your criticism regardless of how you present it, and see that addressing the core of your complaint would help them with their goals. But bosses are — sadly — humans, not rational calculating machines. Because criticism is a touchy thing, you should do whatever it takes to make the link explicit between your critique and your boss’s true motivations.

This leads us to our second benefit: if you have an accurate model of your boss, you’re going to have a higher probability of success when pitching proposals.

I got this idea from Phillip Guo, currently Assistant Professor of Cognitive Science at UC San Diego. When he was a fairly new assistant professor, Guo wrote a blog post titled Whose Critical Path Are You On? which hugely influenced my thinking on organisational behaviour. Guo wrote:

I just had such a tremendous moment of clarity that captures the essence of all of the interactions I've had with all of my mentors throughout the past 13 years as a student, summer intern, and junior employee in the software industry:

If I was on my mentor's critical path, then they would fight hard to make sure I got the help that I needed to succeed. Conversely, if I wasn't on my mentor's critical path, then I was usually left to fend for myself.

By critical path, I mean the path of work that is critical for their career advancement or fulfillment at the given moment in time. (…) If you get on someone's critical path, then you force them to tie your success to theirs, which will motivate them to lift you up as hard as they can.

When Guo wrote this in 2014, he was thinking of his past experience as PhD student and tech industry intern. He noticed how — if he placed himself in his boss’s critical path — he would have a massive organisational tailwind behind his back. He also noticed how he would have to work a lot harder if he chose to carve a path of his own.

The trite version of this advice seems to be “please your boss and good things will happen” — but it’s not that simple, of course. Your boss might still be a terrible mentor. The key insight here is that if you so choose to get on someone’s critical path, you are essentially staking your success to theirs, which motivates them to help you regardless of their capabilities.

Understanding your boss’s true motivations is my way of saying “know where their critical path lies.” Of course, I don’t mean to argue that you have to get on their path — that decision depends on your personal goals and the context of the organisation you’re in. But it’s always good to know that the option exists, and it’s helpful to know where the space of potential critical-path-proposals lie. This, in turn, means that you get to choose proposals with a higher chance of success.

The third and final benefit to knowing your boss’s true motivations is that you are better able to serve as the shit shield for your team. Why? This is intuitive: if you understand your boss’s true motivations, you’ll be better able to predict her reactions to events within the company. This, in turn, helps you protect your team’s output from the vagaries of organisational life. This is more important than you think: I believe that the bulk of events that you need to handle for your team are directly related to your immediate boss. Learning to work with her is key to your performance as manager; in some situations, you can’t increase the output of your team without first taking your boss’s true motivations into account.

I hope these three benefits are sufficiently compelling to you. And so now we turn to the final question that emerges: how, exactly, are you supposed to divine your boss’s true motivations?

Properly Calibrated Observations

The first thing that we need to address is the fact that most of us naturally create mental models of our bosses in our heads. It is a universal human instinct to generate narratives in order to explain the actions of the people around us. If you ever observe children playing, for instance, you’ll notice that even two year olds would attempt to tell stories to each other.

As human beings, we have a generalised storytelling component in our brains. You observe your boss’s actions and come up with a story to explain her behaviour. If, on multiple occasions, you observe her rejecting proposals, it’s easy for you to conclude “Ah, my boss is quite risk averse.” It’s equally easy for someone else to conclude “Ah, my boss is authoritarian.” The tricky thing is to properly calibrate the narratives you come up with, because it’s too easy to stick to the first compelling narrative that pops into your head.

What I do to prevent this from happening is that I try as much as possible to stick to a three step process.

The first step is to generate multiple competing explanations for some set of observed behaviour. It’s not enough to think “my boss is risk averse” — that’s just one explanation. It’s important to also consider “my boss doesn’t like people challenging her authority” and “my boss has high standards for proposals and I should figure out what they are” and “my boss is clearly bored by badly presented ideas” all at once.

This first step prevents you from sticking to the first story that your brain generates that happen to fit all the facts you observe. If you understand that your brain is a story generation machine, then you’d understand that it’s able to generate other equally compelling stories as well. You should let it run for a bit to see what else it comes up with.

The second step is to assign confidence ratings to each of these stories. For illustrative purposes, I’ll use percentages, but it’s ok to keep this at the level of intuition and feeling — for instance, one of my friends say that he has a ‘feeling of confidence’ and he adds and subtracts from that feeling as he goes.

Say that I’m quite confident my boss is risk averse, since that matches up with other observations I’ve noticed while working with her. However, I’ve also observed her snapping at overly-ambitious subordinates, which lends credence to the idea that she doesn't like to have her authority challenged. I will rate the following stories like so:

My boss is risk averse — 40%
My boss doesn’t like people challenging her authority — 30%
My boss has high standards for proposals — 15%
My boss is clearly bored by badly presented ideas — 15%

My current explanation for her behaviour is that she is risk averse, which is why she’s rejecting all these proposals put before her. If, in the near future, I observe her doing something else, that new observation should strengthen one story and weaken the others, causing me to re-evaluate my notion of her true motivations.

This seems really trite and obvious, but we should remember this is not how our brains normally work! My habit of generating multiple competing stories and updating the likelihood of each is a trained behaviour. It is as unnatural as riding a bicycle, or using chopsticks.

What most people do is the exact opposite: they generate the first plausible story (e.g. “she hates me!”) and then proceed to ignore all disconfirming evidence from that point forward.

This leads us to the third step: actively seek out disconfirming evidence. It’s important to remember that as subordinates, we are not passive observers. It’s one thing to sit around waiting for events to strengthen or weaken specific explanatory narratives, and quite another to take action to test our various hypotheses.

As an example here, I could go to my boss and ask her why she rejected most of the proposals she saw in our last meeting. I could frame this as a desire to “better understand her thinking … in order to present better proposals to her in the future”. Of course, I don’t have to take what she tells me at face value — she could very well be lying. But the very action of asking produces more evidence that I can factor into my judgment of her person.

Takeaways

Failing to understand your boss’s ‘true’ motivations is one of the ways I've seen highly intelligent managers stumble in the early years of their careers. This was surprising to me, until I realised that they weren't taking the time to build accurate intuitions about the people around them.

It's probably worth reiterating here that seeking a deeper understanding of your boss doesn't imply that you have to get on your boss’s critical path ... unless you want to. Nor does this imply that you should become a sycophant.

What it does mean is that it’s always a good idea to build an accurate model of your boss in your head. A more accurate model is built by understanding your boss’s ‘true’ motivations — which will in turn help you when you offer criticism, when you’re making proposals to her, and when you need to protect your team from her actions (though ideally, of course, you won't have to!)

Of course, if we step back and squint our eyes at this entire argument, what I'm saying is functionally equivalent to “take time to understand your boss — the same way you should take time to understand everyone else around you. Do this because being good with people is how you win at organisational life.”

Sometimes complex techniques have simple roots. Understanding ‘true’ motivations is a stellar example of this; it's simply how you get good at emotional intelligence.

This post was originally published on Management for Startups. If you enjoyed this, you'll probably enjoy The Starter Manager Guide.

Getting Process Change to Stick

Ced — Fri, 22 Mar 2019 03:16:55 +0000

Tell me if you’ve heard the story before. You’re in a startup and it’s growing. At some point, the pain of work gets to be too much. People say things like “This can’t continue!” after their seventh all-nighter in so many weeks. Tasks fall through the cracks. Deployments go wrong for totally preventable reasons. Your entire team sees the writing on the wall: we’ve got to change the process.

So, you do what many managers have done in your shoes, and you change the process! Your people eagerly go along with the changes, because things are too painful to continue the way they are. And your job does get better. For now.

Months pass, business picks up and then you — the smart, more experienced manager that you are — well, you begin to think: I can predict where this is going. We’re doing twice as much work as we were six months ago, and hiring is picking up with a three month lag. In four to six months, the current process is going to break down again because we’ll have nearly doubled the team. Wouldn’t it be better to start a process change now?

This time, however, the team is less pleased with the idea. They don’t see the changes that you see coming on the horizon, because they don’t have your context. “I don’t think this is a good idea,” says Gruff Adam. (Every team has a Gruff Adam). He gives reasons. Half the team looks unconvinced.

What do you do? Push through? How do you get your team on board with the changes you want to implement? How do you do this without seeming like a total tool?

Lens One: Where’s the Pain?

I’ve discovered three valuable ways to look at process change that I think is worth talking about. The first way is to look at process change through the lens of pain: pain before the change, pain making the change, and pain after the change.

In the first scenario above, there was a lot of pain before the process change. This often makes initiating a change trivially easy: everyone is in such a bad state that they’re willing to try anything to make it stop, anything at all, as quickly as possible.

In the second scenario, however, the pain from making the change overwhelms the perceived pain from status quo. People are unconvinced, because they think that the temporary pain they’ll have to go through while changing their workflow isn’t justified. You’ll have to do a lot more work in order to get them to move.

Finally, if a process change results in new kinds of pain after switching, then you might find yourself with a mutiny on your hands. You must always monitor any process change for teething problems; not doing so risks three things: first, it risks your team’s willingness to try new process changes in the future, second, it may result in general workplace unhappiness, and third, it may result in markedly lower output of your team — which implies that you have not been doing your job.

I don’t want to understate how risky these three side effects are. Imagine that you are a designer, and that you are used to working with the software tool Sketch. You come in to work and your boss tells you that you must switch to a new suite of internal tools, with no proper explanation. These tools are inferior to Sketch, but your boss ignores your complaints, and reminds you that the busiest part of the year is coming up, and that you should hurry up and master the new tool.

How are you going to feel? Terrible, that’s what. Every hour that you spend at work would be excruciatingly stressful. If a couple of weeks go by and nothing changes, if you feel like your boss isn’t listening to your concerns, then chances are good that you’re going to quit. At the very least, you would distrust future process changes mandated from the top down; your output at work would also be drastically affected.

As a manager, put yourself in your subordinates’s shoes. You wouldn’t like your boss to make drastic changes to your work life, and you wouldn’t be happy if it seemed like she wasn’t listening to you. So don’t do these things when taking on a process change. Instead …

Lens Two: Tell Them What and Why Before, During and After

The second lens is the fundamental formula for doing process change. It consists of three steps:

Before doing the process change, tell them what’s going to happen, and why. This is the part where you may encounter resistance, depending on the relative levels of pain before and during the change. Listen carefully, and make tweaks if the complaints are legitimate. More on this in a bit.
During the change, spend a non-trivial amount of time prodding to get the action to stick. At the same time, listen carefully — through your regularly scheduled one-on-ones, perhaps! — to see if the process change is resulting in new problems. If they are, tweak the process change by announcing what you’ve noticed, what you’re going to change about it, and why.
After the process change has taken, spend a small amount of time monitoring the output of your team, and the potential problems from this change. Once people accept it as ‘the way things are done here’, you may stop.

A couple of quick notes here.

First, why is explaining things before you change so important? Well, put yourself in your direct’s shoes. As a general rule, people dislike random changes. They prefer things to be predictable. Giving them a heads-up and explaining why you think this is necessary is a way of giving them a semblance of control over their environment. At the very least, they know what’s going to happen, so they can anticipate the possible changes to their work.

Second, what should you do if you encounter resistance in step one?

In general, the more painful the proposed process change, the more difficult the resistance you have to overcome. You have three tools at your disposal here: first, you can play up the future pain that you want to avoid. A reasonable team should be convinced by your presentation, especially if the coming pain affects them directly. Second, you can find ways to reduce the pain of your proposal — perhaps by asking for tweaks to your suggested process. I’ve found that saying: “These are good concerns, how can we reduce that difficulty while still preventing the pain X?” to be a good way to elicit constructive criticism from my team. Third, and last, you can rely on your positional power to push things through. This last option is obviously the nuclear one, and in principle I think that you should not use it often. But I also believe that some situations merit using your authority; these are often situations where the pain is so vague so as to be difficult to convince your team of.

I know this sounds ridiculous in the abstract, so here’s a concrete example: I once used my positional power to push through a process change for our sales people. If a sales person wanted some customisation done, he or she would need to fill in a form describing the business context, instead of just describing the feature itself. This was because salespeople often filled in suggestions like “put a button here” — which was a terrible idea given their lack of design or product experience. I forced them to do this against their will; my arguments were never convincing to them, partly because they were not incentivised to think of the future engineering costs to our product.

So, one last question. How much time should you spend on designing your process change, getting buy in, talking it over with your team, etc, before carrying it out?

Lens Three: Reversible and Irreversible Decisions

The third lens is to ask yourself if the process change is reversible. If it is, then you're probably better off moving to step two — implementation! — while making it clear to your team that if things don't work out, you can always go back to the way things were before.

The original form of this idea was from Amazon CEO Jeff Bezos. In his 2015 shareholder letter, Bezos wrote:

Some decisions are consequential and irreversible or nearly irreversible — one-way doors — and these decisions must be made methodically, carefully, slowly, with great deliberation and consultation. If you walk through and don’t like what you see on the other side, you can’t get back to where you were before. We can call these Type 1 decisions.

But most decisions aren’t like that — they are changeable, reversible — they’re two-way doors. If you’ve made a suboptimal Type 2 decision, you don’t have to live with the consequences for that long. You can reopen the door and go back through. Type 2 decisions can and should be made quickly by high judgment individuals or small groups.

As organisations get larger, there seems to be a tendency to use the heavy-weight Type 1 decision-making process on most decisions, including many Type 2 decisions. The end result of this is slowness, unthoughtful risk aversion, failure to experiment sufficiently, and consequently diminished invention*. We’ll have to figure out how to fight that tendency.

* The opposite situation is less interesting and there is undoubtedly some survivorship bias. Any companies that habitually use the light-weight Type 2 decision-making process to make Type 1 decisions go extinct before they get large.

This common-sense rule tells us exactly how much deliberation we should spend in step one of the three step template for introducing process change.

I don't think I've ever heard it expressed as succinctly as Bezos puts it, but I do think the difference is quite clear when you're making decisions. I spent no more than a couple of days when pushing through a process change for our code reviews, but I spent nearly two months when working out changes for our compensation structure.

Takeaways

The worst case scenario when making a process change is to have it fail so badly that your team automatically associates future changes with Bad Things.

The best case scenario is when a process change goes off without a hitch, and you earn brownie points from your subordinates as a responsible, attentive steward of output.

The key idea behind these three lenses is to simply see things through the eyes of your subordinates. Imagine how a process change might disrupt your work as an individual contributor. Imagine how bad it feels to have changes dropped down from on-high, with no feedback loop to correct these changes if things go badly. Imagine how powerless you might feel if your manager dictates change after change, without ever evaluating if each change sets in properly.

These three lenses have helped me greatly when it comes to evaluating and executing a potentially disruptive process change. I've used them to switch up our deployment process, to introduce code reviews to the entire engineering organisation, to create new promotions paths for our engineers, and to change compensation across the entire Vietnam office.

I'm hopeful that these three lenses help you as much as they’ve helped me. Process change is often rightfully dreaded. People dislike change, after all, and new, unproven processes can go wrong in many different ways. But, done well, they don't necessarily have to be scary. With these set of lenses, my hope is that you’ll be in good hands.

This post was originally published at Management For Startups, with an accompanying podcast episode. Subscribe for future updates here, or give this a like if you enjoyed it!

The Costs of Firing Too Quickly

Ced — Fri, 18 Jan 2019 13:34:52 +0000

Last week we talked about the costs of firing too slowly. This week, let’s talk about the opposite: the costs of firing too quickly.

See if you can spot yourself in the following picture: as a manager, you have high standards for performance and you expect a lot from the people you hire. (This is often a natural extension of having high standards for yourself). You may have developed this perspective after working in a high performance organisation; perhaps you came from finance, management consulting, or sales. Or perhaps that’s the way that you naturally are.

After hiring a few duds, you realise that it’s really difficult to hire good people. Your solution — as is the case for many in your shoes — is to conclude that the best way to improve a leaky funnel is to increase the input into the top of the funnel. In other words, you think that the best approach to finding good people is to adopt the philosophy of ‘hire fast, fire fast’. By increasing the number of people who pass through your hiring pipeline, you think to yourself that you might have a shot at finding one or two who sticks around.

Of course, there may be other reasons for arriving at the ‘hire fast fire fast’ philosophy — I’m merely relaying these observations from personal experience. My current theory is that a desire for performance and a familiarity with the concept of a sales conversion funnel leads founders and managers to adopt a hiring approach that sounds good but is frankly quite terrible.

Training? What Training?

Why is ‘hire fast, fire fast’ a bad idea?

Think about the implications of such a policy. One major implication is that you assume people can ‘hit the ground running’. This in turn diminishes the role that training has in a hiring process. Your model of hiring people is: find people, interview people, hire people, have people hit the ground running, and then fire those who don’t.

There are two problems here. The first problem is that the speed at which a new hire becomes productive (‘may hit the ground running’, as you might put it) depends on both their capabilities as well as your ability to train them. In early stage startups, training is often ad-hoc because what you do today may be drastically different three months from now. So not having a good training process in place pretty much means that you’re not able to evaluate new hires on an even keel.

In fact, one of the key things I argue in the Starter Manager Guide is that you need to come up with a systematised training program as soon as it is feasible, so that you may amortise the costs of designing your training. Doing so allows you to evaluate the capabilities of any given new hire, because you have a common base of comparison to evaluate them with. But the implication here is that you need at least a few hires before you know you have a working on-boarding training process.

Trial and error takes time — and it’s no different here than anywhere else.

The second problem is that if you practice ‘hire fast fire fast’, your team will basically be inundated with too many new hires! This means that you’re pretty much guaranteed to not be able to train them properly, since training takes attention and time. If you’re not willing to properly train them, you are setting up your new hires for failure. Worse, you are reducing the output of the team, because they aren’t able to delegate to people who they’re not able to train properly.

There is a third reason firing fast often backfires. That reason has to do with the nature of a startup’s hiring resources. When you were in a high-performance organisation in a large company, it was highly likely that the corporation could pay for people at above market rates.

As a startup, you don’t have these resources. As a general rule, good people never come cheaply, and so it’s unreasonable to expect that you would be able to hire ‘people who may hit the ground running’ at typical startup salaries. To put this another way, by opting to neglect training, you are also opting to go after a segment of the market that you cannot afford.

The Costs of Firing People Too Quickly

Let’s take a moment to discuss the costs of firing people itself.

The first major cost of firing is that you aren’t building up a store of operational knowledge. The longer someone works at your company, the more his or her store of organisational tacit knowledge grows — that is, not just task-related knowledge, but also company-specific know-how that can be used to get things done. This is the sort of knowledge like “talk to Bill if you want this expedited on engineering”, or “tell Jane this is going to affect her next month, so that she can prepare her team”. This sort of knowledge really only emerges the longer someone works at your startup — which is why retention is such a big part of the manager’s job.

The net effect of giving up ‘organisational tacit knowledge’ is that your ability to execute on business strategy would be significantly hampered. Trigger-happy organisations tend not to be very effective organisations. In fact, one of the quickest ways I gauge the effectiveness of an organisation would be to discretely ask about their employee churn rate. Of course, a large chunk of employees leaving is never good news. But if the response I get is that of pride, and the explanation is no deeper than ‘hire fast, fire fast’, then a very specific set of alarm bells go off in my head.

In fact, this point leads us to the second major cost of firing fast: that of lost productivity. Any organisation that treats its hiring as a function of throughput — “oh! let’s throw as many people at the company and see who sticks!” — is going to take up a lot of time managing the influx of new people

Someone is going to have to deal with all these new hires. Someone is going to have to evaluate which candidates deserve to stay and which don’t. Someone is going to have to train these new hires — and if your organisation isn’t big on training, someone is going to have to micro-manage the output of their work. And it’s highly likely that the people who have to deal with your new hires are people who aren’t able to spend their time executing on your business’s given tasks.

New hires aren’t free. They incur an organisational cost before they make you a return on productivity. ‘Hire fast fire fast’ as a policy neglects these costs; they are often implemented by people don’t realise that these costs are very real.

Now, before you say: “I read on the interwebs that startups need not care about efficiency at the beginning!” And I agree with that sentiment. But there is some nuance to that aphorism that we need to remember. In the beginning, startups are a race to viability. Therefore, if something affects your startup’s execution speed towards those goals, then you better fix that thing.

Conclusion

So what is one to do when adopting a hiring policy? I’m not going to tackle that topic in this blog post, since that’s a huge post of its own. But I will say this: ‘hire fast, fire fast’ often implies evaluating people as they are. It implies not putting any amount of work into training.

This is only acceptable if you’re hiring someone senior that you expect would be able to hit the ground running. It’s also acceptable if the person you hire is clearly a terrible fit. In nearly every other situation, firing fast is a bad idea. It’s a bad idea because hiring always incurs an organisational cost. It’s a bad idea because successful execution of a business strategy depends on building a store of tacit operational knowledge, which means taking retention very seriously. And it’s a bad idea because it is, frankly speaking, very tiring on everyone involved.

If you enjoyed this, you might like The Starter Manager Guide.

The Costs of Firing Too Slowly

Ced — Thu, 17 Jan 2019 09:10:42 +0000

Have you ever procrastinated on firing a badly performing subordinate?

Chances are good that you have. Good managers care for their people. An ironic consequence of this is that good managers often have difficulty firing likeable but under-performing subordinates. This happens for a wide variety of reasons. Perhaps you’re delaying it because you want to believe they’re not that bad. Perhaps it’s an employee that you hired away from your old company, or who you’ve got a pretty good relationship with. Or perhaps you’ve never been good with firing, and you tell yourself that you want to create a workplace that ‘feels like a family’.

In my last post on The Manager Ugh Field I talked about the deflector shield your brain throws up to prevent you from tackling the most difficult tasks of management. I told the story of having to overcome an ‘ugh’ field of my own when faced with the firing of an underperforming direct.

I eventually overcame my resistance by reflecting on the consequences of dragging my feet. I realised that not firing him was going to cost my team dearly, and that the costs were ultimately on me if I delayed this for any longer. The thought of those costs was what ultimately got me through.

So let’s discuss these costs today. What are the consequences of procrastinating on a bad employee? Why is firing slowly so bad for your team?

Story One: “We want this place to feel like family”

I’ll tell two stories from my experiences to illustrate the harms from firing too slowly. I’ve changed the names and some of the details, but these are real stories I’ve drawn from my experiences talking to and working with fellow startup folks.

The first story is about a software engineer friend of mine who I’ll call ‘Ron’.

‘Ron’ started his career at an awesome company we’ll call FamilyCorp. FamilyCorp was then a mid-sized startup — between 40 to 60 people — and one of the best places to work in the city it was located in. When you walked into the FamilyCorp offices, you saw beautiful floor-to-ceiling windows and wonderful views of the downtown core.

The founders of FamilyCorp were pretty good managers. They wanted more than anything to make FamilyCorp feel like an awesome place to work at, so they crafted generous maternity and paternity leave policies and had the company values painted on the walls, and created a play room so parents could bring their kids to work. They instilled a ‘no-assholes’ hiring policy. Their nurturing, caring attitude could best be summarised by the CEO’s oft-repeated saying: “we want everyone in FamilyCorp to feel like they’re part of a family.”

There was only one problem.

The problem was that they didn’t fire the under-performers.

Over time, my friend Ron realised that the founders’s obsession with creating a friendly, family-like work environment was causing him to suffer. There were two under-performers on his team. Between them, these two software engineers — who had very nice personalities! — caused a great deal of pain to everyone who had to deal with them. They completed their tasks late, refused to listen to advice from senior engineers, implemented features in whatever way they wished, and generally caused a great deal of trouble as the features they implemented inevitably broke.

Ron, being a talented software engineer, found that he had to pick up the slack. To varying degrees, everyone else on his team had to do extra work as a result of these under-performers. When Ron confronted his manager about this issue, his manager shrugged and said firing decisions weren’t up to him. And when Ron went to the founders, the founders basically said “Have you tried talking it over with them? Maybe you need to learn to communicate better!”

As a result, Ron is now considering leaving the company. This is ironic, and sad: due to a desire to create a super-nice, family-like work environment, the founders inadvertently also created a situation where they would lose their best performers.

Why is this the case? The answer is simple: if you don’t fire bad performers, you are essentially sending a message to the entire company. You are saying “Performance doesn’t matter here. The good people will have to work harder to make up for the deficiencies of the bad people. We don’t care how this makes you feel.”

High performers are usually motivated by growth and mastery. Having to patch over badly-done work, and having to fight absolutely preventable fires as a result of bad teammates usually results in an untenable situation for these individuals. It’s no surprise then, that the first to leave in such environments are usually the better employees — and Ron is but one of a number of high performing individuals on their way out from FamilyCorp.

Story Two: “But he’s my friend”

My second story is about a smaller startup, with an engineering team between 15-20 people. Here, the problems they faced stemmed from their chief technology officer.

(I use the term CTO here loosely, as startups job titles generally don’t matter. But in this case, his position was managerial as well as technical, and it’s the management bit that matters for this story).

I was friends with ‘Ed’, a co-founder at the company. Ed recruited their CTO from his previous company, most likely with the usual promise of future startup riches. I gathered that they were friends, and that Ed felt responsible for bringing him on. And perhaps this person was a good technologist — but alas, this attachment was the root cause of their troubles.

You see, this startup had been around for more than two years … but things were still chaotic and bad. As an outsider, it seemed bizarre to me that my friend would willingly maintain that level of chaos for such an extended period of time; my experience running my company was that it was necessary to constantly fix bad or breaking processes to reign in the problems of growth. Not doing so would lead to Very Bad Outcomes.

You might say that perhaps our companies had different growth rates, and therefore it was wrong of me to compare. That’s a fair point. What bothered me, though, was that his CTO didn’t seem to understand that it was his job to reign in the chaos. Whoever was in charge of the engineering organisation needed to act — not doing so was pretty much a guarantee that they’d destroy the output of the team.

And so the results were predictable: people missed deadlines, worked overtime, felt burnt out and overworked, had terrible productivity (by Ed’s own admission) and were constantly leaving the company. In this way startups are like forest fires: unchecked, their growth would burn through everything.

I told Ed to fire his CTO. Ed’s response? “But he’s my friend. He’s a good guy. He was willing to help me out, and it’d be bad for me to fire him.”

As I write this, Ed still hasn’t taken action. And while he dithers, his people continue to burn.

Takeaways

What are the commonalities in both stories? I think the most important feature that both stories share is that they concern under-performers who happened to be perfectly nice individuals. It’s easy to fire assholes that everyone hates. It’s a lot more difficult to fire friendly folk who happen to do bad work. This is especially true if you are the nurturing sort, and if your instincts as a manager is to build a friendly, welcoming, closely-knit team.

That said, the costs of not firing under-performers are real, even if they are not as visceral. In the case of the bad CTO, every day that he’s allowed to stay in his position is another day that he gets to exercise negative managerial leverage. In the case of my friend Ron, every day that the founders refuse to fire bad performers is another day where a valuable employee is likely to leave.

The way I see it, there are three primary reasons to be wary of keeping bad performers around. The first I’ve already mentioned: that you are sending a message to the rest of your people, in effect telling them “performance doesn’t matter.”

The second reason is that bad performers decrease the output of the team. You shouldn’t ever let this happen, because it means that you aren’t doing your job. While this sounds like a trite conclusion to make, it’s worth remembering that in many cases, bad performers don’t just produce reduced output — instead, they produce negative output, as they create problems that take up the time and attention from your best people.

Worse still if they are bad performers in a managerial role. Managers have a higher capacity to affect output, given that they are in a position of leverage. Having a bad performer be a manager is a surefire way to destroy the productivity of a team.

Third, and last, you should consider the costs of the many versus the cost of one. By this I mean that most managers fear the act of firing — and rightly so! Firing is always scary, even for experienced managers. It has the potential to go horribly wrong.

But the costs of avoiding this painful act should always be juxtaposed against the costs to the rest of the team, should you keep the bad performer around. And for this, ask yourself: are you willing to lose your best people? Are you willing to send the message that performance doesn’t matter? Is your business able to recover from extremely negative output?

These questions have a right and wrong answer. But you probably already know that. You most likely already know what to do.

If you enjoyed this, you might like The Manager Ugh Field. I've recorded a related podcast episode that you may find here. Sign up for the MFS Newsletter to get new posts delivered to your inbox.

The Manager Ugh Field

Ced — Tue, 01 Jan 2019 13:45:07 +0000

Have you ever had something you had to do … and didn’t do it? I know what you’re thinking: “oh, god he’s going to talk about procrastination.” But this isn’t about procrastination — not really. Instead, I want to talk about avoiding things that are emotionally painful.

This post is going to be about the incredibly uncomfortable bits of being a manager.

It’s about that time when you delayed firing a bad direct.

It’s about that difficult work conversation you’ve been putting off.

It’s about that tickle in your brain that reminds you that you’re going to have to bring up an uncomfortable issue with your boss … and you know you’re both not going to enjoy it.

Emotionally painful activities like these trigger something I like to call the 'manager ugh field'. The ugh field is so powerful that your brain flinches from even thinking in the direction of the bad thoughts. Your attention skips right over the issue when you find yourself introspecting. And when you do think about the issue — when, over dinner, or in the shower, your thoughts turn inexorably towards one of these painful situations — you immediately find yourself coming up with excuses to avoid doing that painful thing.

“Oh, I don’t have to fire John … he delivered that small task last week on time. Maybe I’ll give him another month to prove himself.”

“I don’t have to bring up the issue of slow deliveries with Mary on Friday — it’s not that big a deal.”

“I don’t have to talk to my boss about our work culture. I can deal. Really!”

The manager ugh field is what makes management so difficult. In each of these situations, the tickle you feel in your head is a sign that you can't afford to put these things off. In many cases, you already know what you need to do. You are merely trying to avoid the emotional trauma of dealing with it, so you try and put it off for as long as possible. You throw up an ugh field in your head.

But ...

But let's be honest with ourselves, shall we?

You know you’re going to have to fire John sooner or later — you’ve already given him enough opportunities to prove himself over the past three months.

You know you must bring up the issue of slow deliveries with Mary, and on Friday. You’ve been hurting your team for every week that you fail to bring this issue up.

And, finally, you know you have to talk to your boss about the culture of working over time every week. You know this is a cause of burnout for members on your team. You won’t be able to hold on to them for much longer if you don’t.

So what should you do when you’re facing the ugh field? How do you get better at dealing with this?

The Dirty Little Secret of Ugh Fields

Here’s a little secret that I’ve found: the ugh field is an opportunity in disguise.

The human brain is a powerful tool: what's happening when your brain throws up an ugh field is that it's trying to protect you from some painful area of your life. But with this power comes consistency — and this consistency also means that you can use it to your advantage. If you train yourself to detect 'ugh' fields, you may use it to trigger productive introspection sessions — that is, sessions that will help you address the issue head on.

Do you have an ugh field right now? Do you have some topic where you find your attention skipping right by? If so, that’s great news! You’ve just found yourself an opportunity for practice.

The goal of a productive introspection session is for you to focus your full attention on the issue hidden behind an ugh field. This would then allow you to defang the pain that prevents you from dealing with the issue.

Performing this activity requires sustained attention, and this is more difficult than it sounds. During a typical day, your attention is diffused and spread out over a variety of things, like work tasks, chores, and Facebook. You’ll find that your attention, left unchecked, diffuses like light pooling from a large lamp. You’ll need to concentrate your attention first before you may begin the process of productive introspection. This is much like concentrating light through a lens on a single point, before directing the beam on what you want to focus on.

The trick to doing this is meditation. Here are two techniques I’ve found to work for me, one easier to do than the other.

The first, easier technique is known as ‘box breathing’ — a technique developed to ground experts in high-stress situations, like police officers or Navy SEALs. To perform box breathing:

Breathe in through your nose while counting to four slowly. Feel the air enter your lungs.
Hold your breath inside while counting slowly to four. Do not clamp your mouth or nose shut. Simply avoid inhaling or exhaling for four seconds.
Begin to slowly exhale for four seconds.
After exhaling, wait another four seconds with no breathing before inhaling again (that is, before going back to step 1).
Repeat the above steps at least three times. You may choose to perform the above steps four times (about a minute) or as long as necessary until you feel calm and centred.

The second, slightly more difficult technique is mindful meditation. This goes as follows:

Find a quiet, comfortable place to sit in. If you don’t have access to a quiet space, use ear plugs or play some soothing sounds on headphones. Set a timer for five minutes.
As you close your eyes, focus your attention on your breathing. Notice how the air enters your nose, and how it feels as it goes from your nasal cavity to your lungs, and out again.
You’ll begin to notice your mind wondering on all sorts of things. What are you going to have for dinner? Have you forgotten to take the trash out? Isn’t there something you need to prepare for tomorrow’s meeting? Notice these thoughts, accept them as they are, and gently bring your attention back to the sensations you feel as you breathe in and out.
The goal is that by the end of five minutes, your mind is free of all thoughts except for the sensation of your breathing. That’s when you know your attention is sufficiently focused.
If you fail, set another five minutes on the timer and go again.

Once you’re done with this activity, focus your mind on the ugh field. This is the second, more painful step. Ask yourself: why am I feeling this psychic pain? What am I trying to avoid here? What is the source of this pain, exactly?

Each time you feel your attention slipping away, or if you observe your mind quickly offering up reasons that make you feel better, brush this aside and zoom in on what feels painful. Any issue guarded by an ugh field is likely to consist of multiple smaller issues that are painful. Examine each of these like a detective walking around in a crime scene.

This exercise should feel like pressing salt onto a wound — and that’s good! The more salt you apply, the less pain you will feel later. (I know this sounds masochistic and that it probably makes for bad medical advice … but I stand by it. It works!)

You will know that you’ve succeeded when the ugh field is gone … forever.

A Quick Story

I had been putting off the firing of a direct I’ll call ‘Jack’ for more than two months. At some point, however, the tickle in the back of my head got too much to ignore.

I knew that nobody on my team was happy with Jack, thanks to the most recent one-on-one I'd done with the manager of my server team. I knew, also, that some of them thought I had no idea that Jack was performing so badly. They felt resentful that they needed to cover for him. They felt unhappy whenever they had to spend additional time fixing his bad code.

I sat down one afternoon in the office and put in ear plugs. Jack wasn’t in — he took very long lunch breaks— and I closed the door to the company meeting room, set a timer for five minutes, and started meditating.

Then I began to examine my ugh field.

Why was I avoiding this? This was simple: I was avoiding this because firing someone is painful — both for me and for them. Immediately my brain started offering up alternatives: “Oh no, you could give him another chance!” and “But Jack is so likable! You can’t do this to him!”

I brushed aside these alternative voices, and focused on the issue again. The ugh field was still there. My brain was leaning away from the conclusion I needed it to arrive at: that there was no way I could let Jack stay. A month ago, I had already sat down with him, and put him on a performance improvement plan. The manager in charge of my server team was still displeased. He didn’t think whatever improvements Jack had done was good enough.

I sat down and examined my options again. I had already given Jack a second chance. I knew he was a nice guy — this was why I was having such a difficult time. And so I flipped the question: what would happen if I didn’t fire Jack?

The answer: I’d have locked up a slot that I could have given to someone else. We had limited resources at our company, which meant limited seats on the engineering team; I was wasting one seat on a subpar performer.

On top of that, I realised that I was sending a message to the rest of my engineering team. I was telling them: “Performance doesn’t matter. I don’t care that you’re suffering because of Jack’s ineptitude. Just cover for him.”

And I realised that I couldn't let that stand. The pain I was causing others was too great to let Jack stay on. Plus, I was reducing the output of my entire team — something that no manager should ever consciously do.

When I opened my eyes again, I felt the ugh field recede somewhat. It was still there, but the part of my brain that was so quick to pipe in with alternative suggestions was subdued. It only protested weakly as I settled on a plan of action to fire Jack.

I left the room, and did what was necessary later that day.

Takeaways

The manager ugh field is what prevents managers from doing what is necessary in their jobs. Often the worst managerial mistakes you’ll make are mistakes of omission — you didn’t have that painful talk, or you put off that difficult action until it was too late.

The ugh field often exists for a good reason: these painful conversations and actions can go very badly. Firing a bad performer puts you at risk of retribution. Telling your boss things that he or she doesn’t want to hear might land you in hot water.

But the answer to these difficult situations isn’t to avoid thinking about them. The answer is to consider them with a calm, rational mind. You aren’t doing yourself any favours when you let the ugh field fester, and you’re probably harming your entire team in the process.

The good news here is that the ugh field is a consistent mechanism, which means that you can turn it into a strength. Use it like you would an early warning system: train yourself to detect when an ugh field exists, and use that as a trigger to introspect on the issue that you are avoiding. This is difficult, but absolutely worth it: you'll be a better manager once you're able to do so.

I wish you only the best of luck in combating your ugh fields.

If you'd like to read more of this, check out the Starter Manager Guide I've written over at Management For Startups.