Built for Speed or Going off the Rails?

Most of my best writing comes when I’m riled and can harness that energy to put together a strong argument for the best way to get things done. My friends know this, and sometimes I think they wind me up on purpose just to get a strong counterargument to an idea that they know is bad but they can’t quite articulate why.?

So when Luke Stevens shared this blog post with me, I suspected I was being set up. Few things annoy me more than the general arrogance of smart people who assume that general intelligence = “I can do your job better than you.” “Designing for speed by letting the engineers do everything” sounded like a classic example. Prepare to be riled!

[PostHog has] gone beyond a simplistic “free the engineers!” mindset to think deeply about how they structure their company to meet their?goals.

To my pleasant surprise, this was not one of those posts. Sure, there’s a strong element of the “we’re great, be like us!” syndrome that dominates venture-funded tech, even when the reality looks very different. But PostHog also provides a reasoned explanation of why their stripped-down team model works for them, and how they’ve gone beyond a simplistic “free the engineers!” mindset to think deeply about how they structure their company to meet their goals. I love this because, not only have they done the deep work required to build a new kind of product company, but they’re also showing it at a detailed level so others can benefit.

But like any new model, this one comes with some strong caveats that I fear many other companies will miss in their rush to “streamline and speed up.” And just as many developer-led efforts to dump waterfall processes in favor of Agile quickly devolved into a chaotic “screw the documentation and code like hell,” I can see a frustrated engineer using “designing for speed” as an excuse to dump design and product thinking in favor of building crappy products really, really quickly.

I can see a frustrated engineer using “designing for speed” as an excuse to dump design and product thinking in favor of building crappy products really, really?quickly.

So what makes PostHog’s model work and where are the traps for your engineering org?

They redefined the role of the?engineer

PostHog hires product engineers, and for them that’s more than a title. Product engineers not only take full ownership of the features they build, but are also obsessed with customer needs, capable of designing high-quality user experiences, and use experimentation to identify the best path forward. Does this sound like your team?

The Trap: Most software engineers aren’t product engineers

I’ve worked with brilliant engineers over the years, but I wouldn’t classify even some of the best of them as product engineers according to this definition. Technical geniuses? Sure. Amazing thinkers able to hold great complexity in their heads? Yep. But well-rounded, multi-skilled builders who could learn from customers? Well…

By nature, most engineers are problem-solvers and prefer well-defined problems. And if we’re honest, many of them prefer code to people. Talking to customers, exploring alternatives before building, futzing with a UI until it works for the average user rather than a fellow engineer, these are all messy, ill-defined activities. For someone who takes pride in knocking down problems quickly, messiness is frustrating. Put them in charge of defining what to build and they’re more likely to pursue interesting technical challenges or build the first solution that comes to mind rather than digging deeply to find a customer’s underlying needs.

And a word on experimentation: the goal of every software organization should be to find the least expensive way to test and refine its ideas. While coding something is frequently the least efficient way to test an idea, it’s also the only one most engineers choose. When all you have is a hammer, everything looks like a nail. When all you have is a keyboard, everything looks like a coding exercise.?

When all you have is a hammer, everything looks like a nail. When all you have is a keyboard, everything looks like a coding exercise.

Instead of lighter approaches like process flows, user interviews, or static prototypes (or even drawings on a whiteboard), many engineers think, “I can whip something up in a few hours.” Then they start coding, following a trail of problems, refinements, and edge cases, and suddenly a week has passed. Meanwhile, a series of well-drawn pictures and discussions could have already nailed down the ideal feature.

They’re already in their zone of?genius

PostHog is in the perfect environment for this organizational experiment: they’re engineers building for engineers. Instead of having to understand complex business processes or think like a non-technical user, they can start by asking, “Well, what would I want?” Then they can test that idea with a few other team members and they’re good to go. Their job skills and their market expertise align perfectly. Few companies are that lucky.

The Trap: What if you aren’t your customer?

Unless you’re fortunate enough to be building products for fellow software engineers, you’re going to have to think like someone who isn’t you. This takes a level of self-awareness and imagination that many engineers prefer not to pursue. How many times have you or someone on your team responded to a bug report with “working as designed” or by saying, “the code’s fine, they just don’t understand how to use it”?

There’s no third option: “They’ll take what I build and they’ll like it!” Not if you want to stay in business, anyway.

Engineers are great at thinking, “what’s the best way solve this problem?” but there’s often a wide chasm between that and “how do our users want this to work?” So you have two choices:

1. Step out of your comfort zone, become an expert in your business domain, and start to think like (and build for) slow, messy users
2. Outsource that thinking to someone else by including product and design experts on your team

There’s no third option: “They’ll take what I build and they’ll like it!” Not if you want to stay in business, anyway.

They do a lot of relabeled design and product?work

If you just read the first couple of paragraphs of PostHog’s blog post before sharing it with your team, you might assume that they’ve completely eliminated product and design steps from their build process. But if you pay attention you’ll see that they actually invested a lot of energy in defining product rules, vision, and a roadmap, as well as creating an entire design library for their product engineers to use. This investment has paid off handsomely, but it’s disingenuous to say “We just don’t do that anymore.” Instead, they’ve consciously traded flexibility for speed, working inside what the framework can do so they can build more quickly. They also have product and design people on staff to support the teams when needed.

The Trap: Throwing the baby out with the bathwater

Does your team have a well-defined UX toolkit? Do you have a clear product vision that everyone understands? Do you know how to build features that are consistent, usable, and accretive?

Whether it’s because they don’t understand the value, they think they need more flexibility, or they just feel like it’s too late, most companies don’t invest in frameworks that would enable quick development and a consistent experience across features. Instead, they use people with specialized skills to deliver a hand-crafted, artisanal product experience with each new feature. Is this inefficient? Sure. Could you just send those specialists home and create the same quality product with engineers who’ve never done it before? Let’s be honest: no.

So if you want leverage in your product and design roles, if you want fewer designers and definers serving more builders, you have to do the work first. You can’t just hand it over to poorly supported engineers and expect it to go well.

They’re still small enough that this?works

This is a massive caveat: PostHog’s approach works because they’re still relatively small. Every feature team can be a “mini-startup” when you have 37 people across 6 teams because the communication overhead is still manageable. As the number of teams increases, the lines of communication grow geometrically.

PostHog has tried to future-proof their org by building in technical interfaces to isolate and test changes between teams, reducing the risk of one team’s independence trampling another’s effectiveness, but like Spotify’s infamous “squads” model, this structure will be strained as they grow. They’ll have to add more structure, either technically or through communication processes, to maintain their effectiveness. I expect that their experimental approach will help them redesign as they go, but I don’t know if today’s post will hold true when they have 200 engineers in 40 “mini-startups.”

The Trap: Applying small-company solutions to a large?org

Regardless of your company’s size, you need to ask, “What will work here, with the controls and processes that we already have in place?” If your company is larger than 100 people, then highly autonomous “mini-startups” might not be the best approach. Autonomy is critical, but it requires coordination. “We’re free to do what we think is best” must come with the caveat: “as long as we don’t ruin someone else’s day.” If you don’t understand this, then you aren’t building a company, you’re building a time bomb (see also: Crowdstrike).

“We’re free to do what we think is best” must come with the caveat: “as long as we don’t ruin someone else’s day.” If you don’t understand this, then you aren’t building a company, you’re building a time?bomb.

The Takeaway

Speed is great as long as you’re traveling in the right direction. Building a great product isn’t about speed of deployment; it’s about speed of learning. It’s about finding the intersection of user value, functionality, and maintainability. In other words, it’s a process of constantly asking questions, followed by, “What’s the simplest/fastest/cheapest way to answer this question?” Sometimes that means writing code, but many times there’s a better answer. If your entire team is made up of builders and you sent all of the talkers, writers, and drawers away, you’re limiting your options. And that, by definition, is suboptimal.

If your entire team is made up of builders and you sent all of the questioners, writers, and drawers away, you’re limiting your options. And that, by definition, is suboptimal.

Many smart people have looked at someone else’s work and thought, “I could do that.” Dunning and Kruger would say otherwise. The engineer who thinks, “I can build complex systems, so how hard can it be to draw some pictures or figure out what a user needs without writing a bunch of requirements?” is not only guilty of diminishing the contributions of others, but is also setting themselves and their company up for failure.