The Principle of Least Surprises and Stakeholder Management

One thing people often get wrong about software work is stakeholder management, and one thing people get wrong about stakeholder management is minimizing surprises.

This is actually pretty simple. There’s a design principle known as the Principle of Least Surprises (or Astonishment), which generally states that the behavior of a product should not surprise users. Surprises are bad.

The same principle carries over to project execution and stakeholder management. Generally, any project you work on will have stakeholders:

  • Colleagues you work with directly. If you’re an engineer, this might be other engineers, product managers, designers, etc.
  • Other teams that have dependencies on your work (ie your work must get done so their work can get done).
  • Other teams on which your work depends (ie their work must get done so your work can get done).
  • Company/team leadership.
  • People who are inexplicably (from your perspective) excited about or worried about the work you’re doing.

You’ll be a lot more successful, and build a lot more trust, if you minimize surprises with these stakeholders.

Form a mental map of who your stakeholders are, what sort of information they’d want to know and what cadence, and make sure they’re never surprised. For example, it’s bad if your work is delayed, it’s much worse if that’s a surprise. It’s impossible to create zero surprises, but you should be creating near-zero surprises.

And keep on the lookout for unsolicited “checkins”, which can be a leading indicator that people are worried you might surprise them. This isn’t always true, sometimes people just need a status update or a piece of information, but if you’re communicating well and proactively, and people trust you to deliver, the volume of unsolicited checkins you get will be very low.

Things To Do Before And After You Write Code

The most effective engineers I’ve worked with were effective not just because of how they wrote code, but because of things they did when they were not writing code. Here’s my (growing) short list of things you should do before or after you write code.

Before

  1. Understand what you’re building. Do you have specs or requirements? Are they clear? Do you understand what users you’re building for and how they’d use what you’re about to build?
  2. Understand how it might need to change in the future, so you can design for adaptability. Are there any assumptions you’re going to make now that might hinder your ability to adapt your code in the future or expand your functionality.
  3. Understand why you’re building it. If you’re building it, there should be value to your users and the business. What is that value? Do you agree with it?
  4. Understand why build it now. Presumably, there are other things you could spend your time on. Why is this important right now? Is it creating more value than other options? Does it unlock other dependencies that require that this be completed?
  5. Have a plan for how you will build it. Depending on the complexity and the stakeholders, this plan could be a couple sentences you run by a team-mate, like “I’m going to have to modify our data model, which will involve a migration, and change one API call.” For more complicated changes with many stakeholders, this might involve a Request For Comment document, or a fully-fledged Design Document to discuss with your team and other stakeholders. There must be some thought. If you can’t put it in words, you’re not ready to put it in code.
  6. Think through side-effects. Will you stress certain parts of your infrastructure? Have to refactor a part of the code base?
  7. Develop a mental map of stakeholders. Who might you need to check with or communicate with as you build? Your product manager? Designer? Executives/leadership? Someone else on your team who’s irrationally excited about this feature and has been championing it for months? Anyone who would be surprised by any your work, positively or negatively, is a stakeholder.

Note that you might need to do some “pre-work” to figure out some of the above, like #5 and #6. That’s fine. But treat that work as “pre-work” not as actual work.

After

I’m a big believer in follow-through. None of that “get it done and toss it over the wall crap”. This may sound like it’s not your responsibility, but you should always own the quality of what you’re building.

  1. Instrument some metrics / quantitative results. Depending on your product and number of users, this might be very simple or very complicated. But you want quantitative numbers that show how many people are using what you build and how.
  2. Gather qualitative information. Ask to watch someone use what you built. Use products like FullStory.
  3. Do your own QA. Even if you have product managers, QA testers, etc, own your own quality. Figure out what the testing plan is and decide whether it is sufficient or not. Test it yourself. Dogfood it. Ask to roll out incrementally.
  4. Get feedback from users and stakeholders. Have a list of what was successful and what wasn’t. What can be changed in the future? Have a list, even if it’s not going to get worked on now.

You’ll notice as you do these things more and more, that your work will stand out. People will value working with you. The quality of your work will improve. And most of all, you’ll build better and better judgment for how to do your future work.

Disrespectful Design, Part II

What can you do, as a builder, if your job seems to require to employ disrespectful design patterns?

What is Disrespectful Design

First, it’s worth rehashing what Disrespectful Design is. I think there are a few common dimensions:

  • It’s adversarial. It puts the needs of the product (or the company building the product) clearly ahead of the needs of users, and tries to get users to do something. This post about Reddit has a bunch of examples of that, but in general, you’ll find lots of adversarial designs around sign-up flows or invite flows in social products.
  • It caters to System 1 over System 2. It uses dark patterns that cater to people’s automatic minds, their instincts/emotions, over their reason and logic. Vanity metrics that appeal to the ego and make users feel good through short dopamine hits. Infinite feeds that keep users mindlessly scrolling without being aware of how much time has passed.
  • It favors shortterm gratification over longer term benefits. You might feel better after while or immediately after using the product, but it probably has some bad long-term effects.
  • It is paternalistic and often dishonest. It claims to know what’s best for users better than the users themselves. My all-time favorite is: “We track you and invade your privacy, so that when we show you ads, they’re more relevant to you!” but it’s generally more like “You’ll have a better experience if you do X, so we will trick you (not convince you) into doing X. You don’t know what’s best for you, we do.”

Not all products that have these characteristics constitute Disrespectful Design, and there’s a bit of I know it when I see it to it. For example, even products that help people improve over the long-term like fitness apps or meditation apps might employ some of these tools to help people meet their goals. But these apps won’t have all these characteristics.

Why it Happens

A combination of things have overlapped to encourage Disrespectful Design.

  • The proliferation of “free” products. As the saying goes, if the product is free, you are the product. Free products are often monetized using your attention, your data, and your actions, so they need to get as much of that as possible from you so they can show you more ads or try to get you to take some other action.
  • An overly “data-driven” culture. You can very easily A/B test your way into a very disrespectful product. You try something, it juices your metrics, so you do more of it. The data becomes a crutch, and often, the things that are more measurable are short-term, shallow metrics.
  • “Performance”-driven culture. “We’re a meritocracy. If you move the needle, you’ll get rewarded”. Put that together with a data-driven culture, and suddenly you have a lot of builders finding ways to juice short-term metrics so they can get that next promotion or that bonus.
  • Grow-at-all-costs mentality. No doubt that the venture-capital-backed start-up model has created a lot of success, but it does push companies to a “grow-at-all-costs”, “winner-takes-all” type of mentality, where the key metric is growth and everything else be damned.

What You Can Do

So as a builder, if you find yourself working on a product that employs or plans to employ disrespectful design, here is what you can do:

First, decide what you’re OK with. There’s a spectrum here. For me, making a call-to-action in a flow more prominent in a way that makes it easier for users to find is probably fine. Changing it so users mistakenly click on it? Probably not.

Then, try to quantify the damage. Sure, maybe the short-term metric you’re looking at improved, but take a more holistic view. Look at down-funnel metrics. Maybe that sleazy sign-up page converts more users at that stage, but does it create better-engaged users? Unfortunately, the answer is often yes, but not always. For example, apps like Quora and Reddit that block their mobile browser UIs (or make them crappy) as a way to entice users to download their app do piss off a lot of users, but ultimately, convert enough people to the (much more sticky) mobile app that the metrics make it look like it’s worth it.

Look at long-term metrics. Maybe across the funnel, disrespectful design works in the short-term. But long-term, are you building a healthy base of users? Long-term metrics are, unfortunately, really hard to test. By definition, you’d need to wait a long time to see the results of an A/B test. And, during that period, you have extra product and engineering complexity of having multiple active flows. Finally, in some products, it’s really hard to fully isolate effects between control and treatment populations for an A/B test (ie can you fully track an anonymous user over time / devices / locations? can you prevent effects on one population from leaking to the other population? etc).

Next, some negative effects of Disrespectful Design can’t be quantified, but they can be observed. A company that has a reputation for employing Disrespectful Design might have its ability to hire affected. For example, while Reddit definitely has a really talented team, you can’t look at a thread like this and argue that it’s ability to hire more talented people isn’t negatively affected. You can’t easily put a number on that effect, but if you believe that the people you hire are one of the key determinants of your success as a company, hiring brand is a crucial ingredient.

Finally, know when you’re ready to walk away. Life’s too short, your time and talent too valuable. If you’re not comfortable spending your time and energy on a product because of the way it’s being built, and you can’t change things, look elsewhere. It’s hard to walk away from a well-paying job at a well-known company, but it’s also hard to put a price on that feeling of putting your head down, at the end of a long day, and feeling proud of the work you’ve done.

Poetry, Essays, and Code That Lets you Get on with Your Day

A lot of people talk compare good code to poetry. Poetry is generally:

  • Elegant and enjoyable to read.
  • Clever.
  • Of variable information density. Sometimes, a line of poetry can contain multiple meanings. Sometimes, it’s more verbose.
  • Subjective and potentially ambiguous. Different people reading the same poem might interpret it differently.

But often, good code should be more like an essay:

  • Of the right information density. It exposes important information and hides unimportant details. Not too verbose, not too dense.
  • Well-structured and layered. Different layers will expose different levels of detail.
  • As clear and objective as possible. There is one clear interpretation of what’s happening.
  • As simple as possible, but not simpler.
  • Often written and re-written.

If you’re writing hobby code that only you will read and not maintain, write code like poetry. Make magical, whimsical, and fun. Make it clever. Write what flows out of you.

If you’re writing code that others will read and maintain (and as a hint, “future you” is generally an other), write code like an essay. Don’t make it clever or artistic. Make it simple, clear, and easy to read and understand.

It will be read far more often than it was written, and the person reading it probably won’t be looking to enjoy your “art”. They’ll just want to know what the hell is going on so they can get on with their day.

How to Creatively Solve Problems as a Non-Creative Person

In general, there are two ways to be good at something. You can be born with it (be “a natural”), or you can learn how to get good at it. The mistake I see a lot of people make when they want to get good at something is to find “a natural” and ask them for advice. The problem with that is naturals typically can’t actually tell you how to get good at something if you are not, because by definition, they were never not good at the thing they’re good at.

In that vein, I am not a creative person. I consider myself a pretty solid engineer, manager, and occasional product person, and have generally excelled at tasks that require logic or other structured thinking. Creativity, on the other hand, has always been a struggle for me. I’ve always looked on with admiration (and envy) at friends and colleagues who were naturally creative, but I had been able to get by without being creative.

But as my career has progressed, I’ve found that creativity has become more and more important, especially as I started leading teams. In particular, I needed creativity to solve problems effectively. More complex problems required more creativity.

So here’s my list of how to generate creativity if you’re not a naturally creative person. There’s a common theme, which I’ll get to at the end, but first, let’s talk about the tactics.

  • Ask multiple people to solve it independently. You and your team agree that you will go off and independently try to solve the problem, then regroup1. Force people to write down their thoughts. Have two or three people write design docs before you implement a system.
  • Ask multiple people to solve it together. You and your team do a “brainstorming session”. Initially, you cast the net wide: any idea is fair game, and no one can shoot down an idea no matter how crazy it sounds. Then you can start to narrow down the space of possible solutions.
  • Constrain the problem. How would you solve the problem if you only had one day to solve it? How would you solve it if you wanted to do it without any additional cost or head-count? If you didn’t have to worry about existing product and technical debt?
  • Un-constrain the problem. How would you solve the problem if you had effectively endless time, money, and people to throw at it?
  • Invert the problem. Supposed You Wanted to Kill a Lot of Pilots. What if you wanted to achieve the opposite of your intended solution? Does that generate a set of solutions to avoid, or a set of solutions that might be adjacent to them? Are your perceived fears not as bad as you thought?
  • Change your surroundings. To break out of a mental pattern, sometimes you have to break out of a physical one. Travel can help, but even things like spending time in nature or just in a high-ceiling environment can alter your thinking enough to generate creativity.
  • Move. Exercise or walk.
  • Sleep on it. Sometimes a problem just needs more time, and often, when you disconnect and stop actively thinking about a problem, you give your subconscious enough room to interject a solution or your conscious enough time to forget whatever parts of the problem are causing a mental block. Take a long shower. Sleep on it.
  • Ask people who have solved similar problems. How did they solve them? What other solutions did they consider? What did they learn? Is your circumstance similar to theirs?
  • Ask people who have solved un-similar problems. Especially in other domains. Just choose a random person who has solved problems successfully in other domains, give them a little bit of context, and see what they say.

Why they work

Ultimately, creativity involves two competing forces—generating solutions and choosing solutions. System 1 dueling with System 2, or the elephant sparring with the rider, or even just “right-brain” vs “left-brain”. Part of your mind evolved to form abstractions, trying to simplify the world around you to efficiently generate conclusions, while part of your mind evolved to think, ideate, ruminate, and even obsess (it’s what makes us human).

The abstraction-forming part of your brain constantly constrains the world and the set of possible solutions to any problem and tries to minimize your intellectual effort. This can hinder creativity. Solutions are eliminated prematurely, and most of the time, that part of your brain is right. But creativity requires a little delay to that process. Ideas that your brain may not consider at all due to preconceived notions, or ideas that your brain would shoot down right away might require a little nurturing before they’re ready to be sized up.

You can also view this through a probability/statistics lens. For example, having multiple independent brains work on a problem, is, in a sense, increasing variance (since the input variables are more independent), and with creativity, you want more variance. On the other hand, while brainstorming together makes the input variables more dependent, it can also increase variance if it creates room for interactions (often non-linear) between the input variables (ie people building on each others’ ideas).

Do it iteratively

Conventional wisdom is often to do the broad, un-constraining activities first, then work to constrain and limit. I find it’s better to do it iteratively. You can still start with un-constraining activities, but it’s not a funnel, it’s a loop or a ping pong match.


  1. As an example, my company recently parted ways with a marketing agency because they weren’t delivering results, but we still had to generate marketing phrases for our product. We staged a friendly, inter-company competition. Everyone came up with an idea for a phrase, and we tested them in ads. The best-performing ad variation performed significantly better compared to our ex-agency’s best performing ads.

    But you need to be careful with this one. You don’t want a destructive intra-team competitive dynamic about who’s better at coming up with solutions. Your team needs to have a high amount of trust and you need to reinforce that even when brainstorming independently, the goal is to come up with the best solution as a team.

The Hidden Structural Costs of Incompetence

It is costly to have incompetence in your organization. This is obvious. Someone is not performing or delivering at a high level, your product or service suffers, your business suffers.

It is also obvious that as a secondary effect, your team suffers. Other people have to work harder to correct mistakes and pick up the slack. Everyone has less pride in their workmanship.

The thing is, those costs are easily correctable once the person responsible for incompetence departs (willingly or unwillingly) or corrects (gains the will or skill required to do their work correctly). They’re not structural.

There are more subtle hidden structural costs of incompetence, and what they look like depends on where they occur in the organization.

High-level incompetence, at the managerial or executive level results in excessive subversion. In a healthy organization, people trust management to make management decisions. And, as much as I hate top-down hierarchical management, the role of management is to have a broader, more strategic view than any person or team in the rest of the organization. When managerial incompetence occurs, managerial trust is lost. Management loses its ability to direct, nudge, or otherwise “manage”, and becomes ineffective. Employees usually still know well enough to tell managers what they want to hear, but they won’t actually follow-through effectively.

This becomes a structural problem that can’t easily be resolved by changing a manager or two (or even the entire management team). People become subversive, and management has to resort to some combination of carrots/sticks rather than relying on intrinsic motivation and alignment.

Low-level incompetence, on the other hand, results in over-management / micromanagement. This creates a culture where driven, independent-minded employees have one of two choices: either stop being driven and independent-minded, or leave. Which results in more incompetence, and more over-management. This is structural too, in that it is self-reinforcing. The manager’s instinct is now more command-and-control, more management, more deadlines, more check-ins, etc. But that’s the opposite of what’s actually needed.

This is why it is critical to rectify incompetence as quickly and effectively as possible, at any level of the organization.

Of course, this entire post would be lacking if I didn’t clarify that management is always ultimately responsible. Management has the ability to hire, fire, reward, and punish, and so any incompetence is management’s responsibility.

Why Is Cloud Infrastructure So Complicated?

Most modern software teams have no choice but to spend a lot of effort on their infrastructure, often spinning up entire teams to do so (and sometimes placing their best engineers on those teams).

How did cloud infrastructure get so complicated? Why is AWS such a hot mess of insane configurability and complexity? I ponder this a lot. As a manager of software teams, any minute not spent on building an awesome product kills me a little.

I have a few thoughts.

For a minute, back in 2008-2010, things looked different. Heroku had just been launched, and with a few clicks in a GUI and a git push you had your code deployed and accessible.

Fast forward a decade, and now, we’ve got containers, Kubernetes, so-called “serverless” lambdas. Heroku is still around, but most people outgrow it pretty quickly.

Instead, we end up in the complex world of Amazon Web Services, Google Cloud Platform, Azure, etc with their hundreds of services, each with a tremendous amount of configuration and complexity.

Now, maybe you think I’m exaggerating, because you’ve already spend the time necessary to learn/navigate one of those platforms and/or you enjoy that type of work. But any effort spent not directly delivering value to users is wasted on some level. Infrastructure should be simple, it should just work. But it doesn’t. Even simple tasks like estimating what your infrastructure costs might be are a chore on some of these platforms. There are literal venture-backed startups whose business model is to use reinforcement learning to tweak your infrastructure configuration.

Instead of getting simpler, infrastructure got more complicated. Why?

I have a few theories. The first is creator’s bias. AWS, GCP, etc were all born at FAANG-ish companies, who are outliers in terms of the size of their company, their data, their code base. They build tools they would use themselves. But why would 99% of the world’s engineers need the same complex tooling that the biggest software companies in the world need?

It actually gets worse. Because those companies are viewed as (and often are) technologically ahead, the open source community models its software after them (or they contribute tools back to the open source community). Borg inspires Kubernetes (actually born at Google), Mesos, and Docker. MapReduce inspires the Hadoop ecosystem. And so on.

The second big reason is competitive dynamics. The big cloud providers are locked in an existential competitive battle for “the cloud”. This creates a dynamic where more is better. You’d think that competition in markets would lead to better products, but for enterprise or business-to-business products, often it just leads to an arms race for more features and more complexity. More services, more configurability, and ultimately, more complexity. This is how you stay ahead of the competition and how you win the big contracts. Meanwhile, the average developer is just gasping for air.

The third is Heroku’s decline. Heroku could have been so much more, but instead, they were acquired by Salesforce. Instantly, they lose their ability to innovate and become that classic story of “large company buys startup, startup product stagnates / only gets incremental improvements”. And in this case, Salesforce isn’t exactly a beacon of simplicity when it comes to product (it’s a great product, it’s just clunky and enterprisey… just less so than the competitors it displaced). There are a few bright spots like https://render.com/ which I’m keeping an eye on that could pick up where Heroku left off.

I hope this changes. I respect each of the big cloud platforms as businesses, and know that they have some of the smartest engineers working both on them directly, and building software on top of them. But this is all just tremendously inefficient.

Why All Engineers Must Understand Management: The View from Both Ladders

Something interesting has been happening as I’ve been trying to write more about engineering management.

When I wrote advice about micromanaging for managers, a few friends asked me about how to deal with their (micro)manager, so I wrote about how to handle your manager. The latter piece seemed to be a lot more useful. I also wrote about how managers should avoid cognitive biases, and most questions I got were about engineers who felt their managers were victims of those biases. You see the pattern. I write for managers, I get interest from ICs.

It could be that I‘m reaching the wrong audience, but I think there’s something deeper going on.

Dual Ladders

If you work in tech, you’ve heard of the “dual career ladder”. As engineers grow, they can choose to climb the “technical ladder”, or they can climb the “management ladder”. In fact, companies you interview with will often brag about it so much, you’d think they were the ones who invented it! In reality, like most things modern Silicon Valley thinks it invented, the dual ladder has been around for decades. I found mentions that imply it was first made explicit by post-World War II DuPont (which, if true, would put the concept alongside other notable DuPont inventions like nylon, Kevlar, and the concept of ROI — more on the nylon part, in particular, later).

What’s the purpose of the dual ladder?

  • Avoiding the Peter Principle. Engineering and management require different skill-sets, so if a technology company always “promotes” its best engineers to managers, it will end up converting great engineers to bad managers.
  • Attracting, retaining and motivating engineers. If engineers feel like their only path to growth is management, and aren’t interested in it, they might not join, or they might leave, or just stay and not be that motivated.

It’s commonly said that managers of technical teams should understand technology so that they can be effective. It helps them build credibility, coach their staff, and make better technical decisions. I’d like to propose a broader claim: Regardless of which ladder you choose, you should understand the skills needed to ascend the other. Just like managers should understand technical issues, engineers should understand management issues to be effective. In the rest of this piece, I’ll mostly make a case for why this is important, but in future posts, I’ll go deeper on a few selected topics. But before that, let’s do a quick jump into the past.


Remember when we said we’d get back to DuPont and nylon? It’s hard to imagine how the world would be today if DuPont had not been able to offer a brilliant young scientist an opportunity to spend his time doing inventive research on polymers.

Wallace Carothers was teaching Chemistry at Harvard when DuPont approached him and offered him a job as a lab director. He initially declined. It wasn’t that Carothers, who was described as both brilliant and melancholy, enjoyed his teaching job. He actually seemed to dislike teaching. But he just wanted to do research, and had been dealing with bouts of paralyzing depression. He was worried about the industrial pressures of working at DuPont. Nevertheless, DuPont persisted, offering double his salary at Harvard, and explaining that at DuPont, while he would direct a lab, he could spend most of his time inventing. He would write of his days at DuPont:

“Nobody asks any questions as to how I am spending my time or what my plans are. Apparently it is all up to me.”

Carothers’ work led to the invention of both neoprene and nylon, which revolutionized plastic and were used in everything from clothing to military equipment. In fact, nylon became known as the “fiber that won the war” due to its contribution to the Allied victory of World War II.

Despite his success in the lab, Carothers continued to suffer from depression, and tragically took his own life at the age of 41, years before his inventions really took off. But his research was world-changing. It doesn’t seem like DuPont had formalized the “dual ladder” system yet in the 1930’s, and technically he was “director” of his lab, but if DuPont hadn’t offered him money, prestige, and a chance to spend his time doing research and solving technical problems, the world might be a very different place.


Let’s take another example. Meet Arthur Fry, credited with invention of the Post-It Note.

Rumor has it he also invented witty scientist photos

In 1974, Fry was a researcher at 3M, on the technical side of their dual ladder. Frustrated with trying to have bookmarks in his hymnal stay put, he used a unique adhesive developed by Spencer Silver, a fellow chemist at 3M to stick, unstick, and re-stick small pieces of paper, inventing the Post-It Note.

He would go on to get promoted to “corporate researcher”, the highest rung on 3M’s technical ladder, and stay with the company for many more decades. If it wasn’t for the dual ladder, he later said, he’d “have left the company and gone into business for [himself] as an inventor, or joined some small company where they give you a piece of the action.” Instead, he got to spend his time at 3M “staring at the wall or getting [himself] educated” while still “making as much money as a vice president”.


In other words, companies have been finding ways to attract and retain technical talent by providing them with opportunities that don’t force them to become managers or administrators. Of course, the “binary” dual-ladder is a little restrictive, so a lot of companies have more of a “wide ladder” (where there’s a spectrum of management vs. technical contribution) or a “jungle gym” (where mobility between the different types of roles is allowed or encouraged).

Most companies have realized that managers need some understanding of the technical side of things, lest you end up with pointy-haired Dilbert-style managers.

Dilbert.com

On the other hand, many individual contributors (ICs) don’t necessarily feel the need to understand things on the management side. ICs might feel like management is irrelevant to them, or they might have a cynical view on management. Here’s why I think that’s a big mistake.

Understand management because you need those skills

The software companies of today are a far cry from the industrial R&D labs of DuPont and 3M. Most current software development is more of an engineering discipline than it is a science. Sure, managers and ICs have very different day-to-day activities: managers spend more of their time in meetings and talking to people, and ICs spend more focus-time on technical issues. But, most ICs are not working in isolation in some lab in search of a moment of brilliance that will change the world. Modern software development is a heavily collaborative, cross-functional discipline. The brilliance comes in increments and iterations.

As you progress in your career as an IC, you will need skills like the ability to communicate with people on your team and outside your team, the ability to influence others, the ability to coach and mentor others, and so on. These are all skills that are required of managers, but are still very useful for ICs. A manager without these skills will probably fail — an IC without them might just have a stunted career. I’m not saying you need to spend all your time in meetings, or that you need to learn to play corporate politics. But I’ve seen many ICs who are so turned off from anything management-related that they throw the baby out with the bathwater. So don’t shy away from skills that might seem “managerial” just because you’ve decided to grow on the technical ladder — rather, invest in them!

Understand management because it shapes your system

By system, I mean the people processes in your company or team. You’re likely to be on the receiving end of processes designed primarily by managers. Recruiting and hiring? You’ll go through that process. Performance management? You’ll go through that process, too. You’ll witness good management and bad management. You’ll have to manage up. You should understand those processes, why they are designed the way they are, their strengths and weaknesses. And every process has weaknesses.

Let’s zoom in a little on a topic like performance management. Early on in a start-up’s life, the primary goals are execution and survival. Many start-ups don’t have the time, luxury, or experience to think deeply about performance management too deeply. As an engineer, you work on whatever needs to get done, and if you don’t know how to do it, you try to learn it, and through that, you become a better, more knowledgable engineer. If you’re not doing what the company needs you to do, it’s pretty obvious to you and everyone around you. If you continue to not do what the company needs you to do, you’ll probably be a victim of the “fire fast” mantra. Time horizons are short and feedback is swift but chaotic.

As the company grows and matures, things start to change. The company hires (or transitions) managers and “People Ops” folk, who have the experience (or at least the time and mandate) to think about performance management of people on their teams. The company’s time horizon stretches, which makes planning for the future easier. Someone might propose some structure: a 360-degree performance review process run at some regular cadence (once or twice a year). But how does the company evaluate people? Someone proposes a rubric (or “ladder”, maybe even a dual one). How do you reward people? Someone proposes a compensation policy.

Manager A notices that Manager B is a little more “generous” when evaluating members on his team. She proposes a calibration process, to try and maintain standards and fairness across different teams. After every performance, managers hole up in conference rooms to discuss their proposed evaluations and try to maintain consistency.

These processes differ from company to company, depending on the company’s size, maturity, culture, and overall philosophy. But as an engineer, you will be on the receiving end of one of these systems, with its pro’s and con’s. Even if your primary goal isn’t to get promoted, it’s still useful to understand why your company designed (or stumbled into) that particular process. What dimensions are being evaluated and why? Do managers have autonomy to make their own decisions, or are decisions made by impartial committees?

So how can you learn more about all this?

One way to do this is to just ask your manager. Why do we do “calibrations” as part of performance management? Who decides who gets promoted? What are the dimensions you evaluate people against? Sometimes those processes are well-designed and work as intended, but sometimes they’re not. In either case, you should try to understand them.

I actually love it when someone on my team show interest in these things, and value the feedback I get when I explain the reasoning behind some of the processes we’ve built.

I’m going to be writing more about each of these issues, but I’m going to try to do it a little differently. Firstly, I’m going to try to gather multiple perspectives from others, since different companies approach these issues differently and have learned various things about what works and what doesn’t. But more importantly, when I write, from now on, I’m going to try to write with a perspective from both ladders.

“VC Brain”—Dissecting Investor Behavior

Why do so many Venture Capitalists act like assholes? They don’t respond to your email, even though they promised to. When they do, it’s incredibly terse and lacking in punctuation and capitalization (turns out, they only like one type of “capitalization”, the one that sits on tables). Sometimes they ghost you. If you pitch them, they might be very rude. I’ve an investor put his feet up on a table and start browsing his phone—straight out of Silicon Valley. Sometimes they don’t even show up for scheduled meetings.

In reality, some VCs are assholes. But many are not. I’ve been on both sides of the fundraising table, as both an angel investor and as an entrepreneur (usually I’m the entrepreneur, and so I identify more as such). I have many friends who are VCs of all shapes and sizes. Most of them are really nice, down-to-earth people. For a select few, that carries over into their work. But for the majority, interacting with them as VCs exposes you to their “VC Brain”.

Why do reasonably nice, down-to-earth people act like assholes, even if they are not? I think there are a few reasons. It’s not just that they are “busy” (that is definitely part of it, but when a VC and an entrepreneur interact, I’d argue the entrepreneur is probably just as busy as the VC). The very life and social interactions a VC is exposed to trigger some sort of change to their brain.

Balance of Power

VCs have entrepreneurs vying to get in front of them, to pitch them. Then the pitch itself is an attempt to get the VC to give them money. And if they do invest, they become a shareholder and possibly a board member, advising (but also supervising) the business. So VCs are usually in a favorable position when it comes to balance of power.

Of course, every VC occasionally gets exposed to a deal that’s so hot that the balance of power is inverted, and they are the ones that have to jump through hoops to get into the deal. And of course, VCs go through a period where they are fundraising themselves from Limited Partners. But that happens every few years, and the switch turns off again pretty quickly and the favorable position is restored.

Power affects your brain (some studies have indicated that power can even cause brain damage). So constant micro-interactions where you have the upper hand cause you to lose empathy, and to normalize the state where you have the upper hand and can act with perceived impunity.

Context Switching

Another thing that can alter your brain’s biology is frequent context switching. In fact, some studies have shown that the affect can be worse than that of marijuana.

A VCs typical day might include the following:

  • A constant barrage of emails, texts, and tweets.
  • Listening to pitches from entrepreneurs.
  • Doing diligence / conducting reference calls.
  • Corresponding with lawyers.
  • Talking to portfolio companies to get updates and/or help with whatever issue they’re dealing with.
  • Buying sweater vests.

This goes beyond just being busy. We’re all busy. Entrepreneurs are busy as hell, and honestly, we context switch too. But even when we context switch, we usually have a singular goal—making our business successful. VCs are switching between very different tasks.

Transactional Social Interactions

Venture Capital is a relationship business. VCs build relationships with other investors, entrepreneurs, and talent. Many of these relationships can be very deep and long-term.

But day-to-day, VCs also have a lot of more shallow, transactional interactions (see context switching above). This “social context switching” also takes a toll, because it normalizes these types of interactions. And so these interactions might seem shallow or abrupt to you, but they might be a lot more normal for a VC.

Procrastination

We all procrastinate, but we tend to do it more when a task makes us uncomfortable. When I’m on the investing side of things, I dread having to send rejection emails to entrepreneurs, because I know how it feels to get those. So it’s all too easy to put it off. You come up with narratives to justify it, of course. You tell yourself “I want to write a thoughtful email, but that will take time, so I’ll find time later”. The end result is procrastination.

More Empathy

You might read this and think that I’m a VC apologist. Or you might read it and feel like I’m over-generalizing VCs and being critical of them. I don’t know.

But I think a little empathy goes a long way, for both investors and entrepreneurs. Entrepreneurs can do better when interacting with VCs if they are more aware of the world VCs live in. In general, entrepreneurs (myself included) can also be very defensive and insecure about our “babies”, and we can get overly sensitive to any behavior that seems dismissive or disrespectful. We can build thicker skin by understanding that it’s not personal, and not always coming from a place of disrespect.

And, of course, VCs can also do right by entrepreneurs by understanding the types of behaviors they are prone to that might come across negatively. No matter what your day-to-day looks like, a little thoughtfulness and empathy will go a long way. There’s a bare minimum here that can go a long way. Respond to people in a timely manner, even if you’re not interested. Show up for meetings when you schedule them. Be aware that people have poured their blood, sweat, and tears into their businesses. Remind yourself, periodically, of what it’s like to be on the other side of the table.

Disagree and Commit And Prove Yourself Wrong

One management principle I’ve found really powerful is “disagree and commit”, but I’ve often found that it can be easily misapplied.

Let’s first define what the disagree and commit principle is. Here’s Jeff Bezos in Amazon’s 2016 Letter to Shareholders describing the idea:

Use the phrase “disagree and commit.” This phrase will save a lot of time. If you have conviction on a particular direction even though there’s no consensus, it’s helpful to say, “Look, I know we disagree on this but will you gamble with me on it? Disagree and commit?” By the time you’re at this point, no one can know the answer for sure, and you’ll probably get a quick yes. This isn’t one way. If you’re the boss, you should do this too. I disagree and commit all the time.

In short, if you work with passionate, intelligent people, you will be bound to disagree. Hopefully, you and your team are aligned on high-level things like strategy, values and vision, and so the disagreements are more on the tactical side.

In any case, the principle has a few benefits:

  • It surfaces disagreements explicitly, and surfaces them early. This helps your team be more thoughtful about decision-making.
  • It increases the speed of decision-making, because you have a mechanism to move forward without having to get to full consensus.
  • It avoids the type of “design by committee/consensus” traps that often result in low risk-taking.
  • It results in better execution. Once a decision is made, everyone is committed. At least, in theory.

In reality, I’ve that last point (the “commit” piece) difficult for teams. When teams try to simply sprinkle a little “disagree and commit” dust on their existing culture, they often find that it backfires. I call this “naive disagree and commit”.

The problem stems from the obvious fact that most people don’t like being wrong. Of course, the degree of “don’t like being wrong” varies from person to person and situation to situation. But from a social psychology perspective, that characteristic is biologically ingrained in each of us, and it’s called self-justification. When we’re confronted by evidence that we are wrong, our natural reaction isn’t to admit we’re wrong. It’s to double-down and engage in whatever mental gymnastics are necessary to avoid admitting we are wrong to ourselves and others.

It turns out that certain things can kick self-justification into overdrive. For instance, the more publicly and explicitly you hold an opinion, the more likely you are to cling to it. And this is where naive disagree and commit can cause problems.

Let’s say you and your team are debating a potential decision. “I don’t think we should denormalize this data model,” you say, “it might cause consistency issues in the future”. Your team-mates disagree, they think denormalizing will have huge performance improvements and consistency won’t be a big problem. “OK,” you say, “I disagree, but I’m happy to disagree and commit. Let’s denormalize.”

And now, because you’ve made your opinion public and explicit, you’ve just given birth to a tiny little self-justification demon, and that demon is burrowed into your brain—the part of your brain that likes to think you are a smart person who is generally right about things. He’s just sitting there, waiting for opportunities to say, “see, we were right all along”. Depending on how self-aware you are, you may or may not be aware of his existence at all.

People who have generally been successful and right start to ingrain that “being right” into their core identity. The very possibility of being wrong is a self-existential threat. This gets even worse on high-performing teams. For instance, another of Amazon’s leadership values is that leaders “Are Right, A Lot“. And so, if your naive formula is:

  • Hire smart people.
  • Ask them to be “right, a lot”.
  • Ask them to surface when they disagree with decisions.
  • Ask them to then commit to move forward with the decision they disagreed with.
  • Assume that things will just work.

.. your team won’t be set up for success.

The Solution

Does this mean that disagree and commit doesn’t work? Not quite. We don’t to throw the baby out with the bathwater. It’s naive disagree and commit that’s dangerous. To successfully implement disagree and commit, you need to go a step further.

First, you need to foster psychological safety. Research has found that psychological safety (how safe people feel in taking risks and expressing themselves) is correlated with high-performance on teams. People should feel safe expressing disagreement, without worrying too hard about whether they are wrong.

Second, prioritize getting to the right answer over being right. Getting to the right answer means healthy, rigorous debate. It means knowing when to disagree and commit, and when to draw a line in the sand. It means correcting your assumptions or opinions when they’re wrong.

Third, turn any disagreement energy into risk mitigation energy. When people disagree, it’s because they’re worried about some risk. So channel their (or your) energy into trying to mitigate that risk. “You don’t think denormalizing this data model is the right decision because you’re worried about consistency issues? Well, let’s figure out how we can denormalize this model while minimizing the risk of consistency issues.

Third, make it a cultural norm that people aren’t just expected to say they disagree and commit, they are expected to actually fully commit. You don’t want people to say they disagree and commit but still be dealing with their little “I can’t admit I was wrong” demons. You also don’t want people to say they disagree and commit, but then disengage and not put in 100%. What you really want is people who disagree, commit and try to prove themselves wrong.