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.” Or, m

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
  • “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.

Product/Culture Duality

At many startups, culture happens organically. It’s just built around the personalities and values of the founders and early team.

But anyone who has built a company before learns a pretty vital lesson: culture is important, and when something is that important you have to be intentional about it.

We wanted to build a company that would endure. We started noticing [these types of] companies have something in commonWe started to realize that we needed to have intention, culture needs to be designed.

Brian Chesky, Co-founder + CEO Airbnb

Another way of thinking about this is that, as a company, you are not just building a product. You’re building an engine, a machine that builds a product. That machine is composed of several pieces:

  • The team you hire.
  • The culture you put in place (deliberately or accidentally). This includes things like what is rewarded/punished, what incentives are in place, etc.
  • The processes you put in place (again, deliberately or accidentally). Formal and informal communication. How decisions are made.

I’d like to make three arguments here:

  • It’s helpful to think of both the “actual” product and the machine as products. Going forward, I’ll call the former the user product and the latter the company product.
  • Your user product and your company product both sprout out of your values.
  • There is a feedback loop between those two products. Your company product (aka your team/culture/process) and your user product both impact each other. They are intertwined.

Two Products

Let’s first discuss the dualism between your user product and your company product. Most people are familiar with the idea of finding product-market fit for your users (or, more generally, finding product-market-channel-model fit for your users). This will involve thinking through things like:

  • Identifying who your core customer is.
  • Understanding their core problems.
  • Offering a solution to their problems.
  • Positioning that solution as being differentiated, via some narrative/brand.
  • Communicating that narrative to your core customers.

In our tech-industry-lean-startup world, you do that iteratively as you learn and grow, but it’s basically the same core loop.

In reality, every company is actually running two of those loops whether they realize it or not. The obvious one is for their user product, but they’re running one for their company product too:

  • Identifying what they need to accomplish, and who will help them be successful.
  • Figuring out what they can offer them as an employer.
  • Positioning their company as a differentiated employer, via an employer brand.
  • Communicating that narrative to potential employees.

Many companies get this second loop wrong. For example, I commonly see early-stage startups trying to mimic the recruiting practices of larger companies. If you’re competing for the same candidates in the same way—against companies that can pay more and have a much more recognized brand—without some unique value proposition, you’re setting yourself up for failure. It’s basic supply and demand. So you have to find a way to differentiate yourself as an employer. My friend/co-author Aline Lerner has written about that here if this is something you’re interested in learning more about.

Your Values Define Your Two Products

OK, so if you’re building a company, you’re building two products and running two loops for each of those products. What shapes those two loops? Especially in your early days, your company’s user product and company product both grow out of your values—your beliefs about how the world is or how it should be.

Values are rarely right or wrong, but they can be substantially different. Let’s take some opposing values and see what effect they might have on a company’s culture or user product.

Let’s start with a company’s view on how decisions should be made:

Data is crucial. Everything can and should be measured, and decisions should be made based on that.vsNot everything can be measured, sometimes you have to use your judgment/instincts when things are ambiguous.

You can kind of imagine what product and culture companies with each of those values might build.

The duality isn’t perfect, though, and it can break down a little. Let’s take a company’s view on relationships/transactions:

The world is generally a zero-sum game. When two parties interact, when one wins, the other loses.vsThe world is not always zero-sum. If you think hard enough, you can come up with ways to align incentives so everyone wins.

Things can potentially diverge here. A company might have a different set of values for “in-group vs. out-group“. For example, a company might treat its employees with a lot of trust, but treat users/customers in a highly adversarial manner. This is actually a natural sociological outcome (as humans, we evolved in tribes/clans), but it might be hard to maintain as a company grows (tribes/clans tend to break down at scale).

Some companies are more interesting in that they seem to have the opposite view-point: employees may not treated very collaboratively or trusted, but when it comes to their users or customers, they are obsessive. I haven’t worked at either Amazon or Apple, but from the outside, they generally seem to be that type of company. It’s like an anti-tribe. Or maybe a cult, I don’t know.

The Two Loops are Inter-Twined

OK, so you have two loops, and they sprout out of your values. But they’re also intertwined and interdependent.

I think in the early days, your company product dominates and it influences the user product you build. You start without a product, without users/customers, and without revenue, so the product you build is shaped by your values, and those values are set by the early team.

But as your company grows, the type of people you attract and the value proposition you offer them is somewhat determined by your user product. Depending on what you build and how you build it, different types of people will want to come work with you. Ultimately, and I’ve written about this before, the revenue model, which is part of your user product, will dominate.

So the lessons are:

  • Be intentional about both the product you build for your users and the “product” you build for your team, especially in the early days.
  • Pick a revenue model with care, since that will probably be the dominant term over time.

Organizational Psychologist vs. Organizational Mechanic

When a team or company is not functioning as it should, two types of problem-solvers often emerge. The organizational psychologist tries to debug the culture. The organizational mechanic tries to debug the process.

The mechanic asks what meetings or what documentation is missing. Organizational mechanics love “reviews” (meetings that force decisions to be made). When it comes to communication, they look at the mechanics of what is said and when (how it is said is less relevant). Mechanics look at the structure and the connections. When all else fails, mechanics become surgeons. They “operate”. They pursue “reorgs” or just plain old lay-offs / firings.

Organizational psychologists are more about the human part of the equation. What incentives has the organization set up? How can those incentives be changed? What is rewarded and what is punished? When it comes to communication, they look at the how and the why.

Really good psychologists can dig in even deeper. They can particularly understand how the psychology of an organizations leaders amplifies and impacts the rest of the organization. Is the CEO a micromanager? Is the Head of HR/People generally a cynic who doesn’t trust people to do what’s right? Is the Head of Product uncomfortable with ambiguity or with quantitative analysis? What effects does that have down the chain-of-command?

Great leaders are able to put both the mechanics and the psychology together. They understand that teams are complex systems of humans. They understand that debugging is cyclic: the mechanics and the process affect the culture and the psychology, but the mechanics and the process are an output of an organizations culture and psychology. You need to look at both sides to solve most problems.