The Power of Principled Thinking

My biggest takeaway from Amazon's LPs has nothing to do with the principles themselves.

Everybody thinks they know the secret to Amazon's success. Most people point to the Leadership Principles (LPs). "Customer Obsession," "Bias for Action," "Dive Deep." They're famous, and countless companies have tried to copy them, hoping to bottle the magic.

But focusing on the specific principles is a mistake. Almost every company has a list of values hanging on a wall, and those words themselves aren't magic. The real secret is much harder to copy.

What matters most is whether people actually stick to the principles.

At Amazon, the LPs are the operating system. They show up in every document, every performance review, and every big decision. People actually use them.

This might lead you to ask a couple of natural questions. Does strictly following a set of principles only work for a giant company like Amazon? And do the principles themselves even matter, or could they be different?

When I worked in Prime Video, we were relentlessly customer-obsessed. We bent over backwards to support legacy clients, like the Prime Video app that came pre-installed on older smart TVs. These apps couldn't be updated, but we performed heroics on the backend to keep them working long after the TVs themselves were end-of-lifed. We even figured out how to give some of them the ability to live stream, even though the application never originally shipped with that feature.

There was a clear downside to this. A huge amount of our engineering bandwidth was spent supporting this long tail of devices, thousands and thousands of legacy clients, instead of being as invested as we could have been in new products and features.

But that was the choice we had made. The principle of "Customer Obsession" meant we chose to prioritize the experience for our existing customers, and we accepted the consequence, we would be slower to innovate on the core product for newer devices.

Now that I'm on my own as a creator, my context is completely different, so my principles are different. My guiding principles aren't exactly like "Customer Obsession." The three I’ve developed thus far are:

• Obsess Over Quality

• You Can Do More Than You Think.

• Be A Badass

These new principles lead to completely different choices. "Obsess Over Quality" means I might spend an extra day (or week) editing a video to get it just right, even if it means publishing less often.

"You Can Do More Than You Think" is a reminder to take on ambitious projects that stretch my skills, rather than just producing easy content. Projects typically take as long the time you allot to them. Doing more means just assuming I can do more.

And "Be A Badass" is my filter for making sure that what I do create is something I am truly proud of. The trade-off is that I can't move as fast as someone who prioritizes volume, but the benefit is that I am building a body of work that I stand behind completely.

How to Find Your Own Principles

We should think of principles as practical tools for making decisions. Their power is that they reduce the heavy cognitive load of starting from scratch on every tough choice, which gives you the confidence to act decisively. The easiest way to find your own is to look at your past behavior and the choices you made when you were proudest of the outcome. Ask yourself these questions:

1. Think about a project or piece of work you were exceptionally proud of. What did you prioritize to make it so great? Was it the speed of delivery, the depth of the research, the creativeness, the simplicity of the final output, or the level of polish?

2. What did you have to sacrifice to achieve that quality? Did you say 'no' to adding more scope? Did you have to de-prioritize speed? Did you sacrifice broad consensus to pursue a unique vision?

3. Now, turn that choice into a statement. A great template is: "I value [the thing you prioritized] even if it means [the thing you sacrificed]." For example: "I value shipping a high-quality, polished product, even if it means I publish less frequently." That statement is the true essence of my "Obsess Over Quality" principle.

It's also important to know that it is perfectly fine, and even normal, if some of your principles seem to be in opposition to each other. You might have one principle about moving fast and another about ensuring high quality. The goal isn't to create a a list of things that never conflicts. The point is to use the tension between your principles to make a conscious choice.

Case Study: How Linear Breaks the Rules

These stories show how powerful principled thinking can be for a giant company and a solo creator. To see how it works at the startup level, I talked to the team at Linear.

There’s a standard playbook for startups. Companies scale by hiring fast, having their PMs focused on every aspect of their product, and moving fast by shipping not-so-perfect software.

Then there’s Linear.

The issue-tracking and project management tool has gained a cult-like following not just for its speed and design, but for the radically principled and counterintuitive way the company operates. They famously have no career ladder for engineers, no product managers (until very recently, they just hired one), and a strict zero-bug policy.

Last week, that notoriety was validated in a big way: Linear announced an $82 million Series C funding round, valuing the company at $1.25 billion.

To understand what makes them tick, I sat down with Sabin Roman, the first Engineering Manager at Linear.

Here are the highlights from our discussion on how Linear builds software by breaking all the rules.

On a "Zero-Bug" Policy

Perhaps one of Linear's most daunting principles is their 'zero-bug' policy. I asked Sabin to explain how this works in practice and what it really means to eliminate the bug backlog, assuming that such a hard line must come at a significant cost.

Sabin Roman: The principle behind it is fairly simple: if there is a bug then we need to fix it. And if we need to fix it, we might as well fix it now. If we fix the bugs now rather than later, our customers will be happy to use a product that works as they expect.

Of course, not all bugs are the same. Engineers use their best judgement to make a deliberate decision if a bug is worth fixing or not. For example, we may have a bug that we can’t reproduce and it’s impacting just a few users. We will reach out for more details and if there is no answer, we will just close it as “won’t fix”. If more reports come in the future, we will address it then.

Once we introduced this practice, we realized that the hard part was only the first month, when the backlog of bugs needed to be cleaned. After the first month, the influx of bugs was around 2-2.5 bugs per engineer per week. Which is not a high price to pay for building a product that does not disappoint.

On Having No (or Few) Product Managers

I pressed Sabin on their famous 'no PMs' principle, asking what 'broke' that led them to recently hire one. I also questioned if it's truly efficient to expect engineers to wear the PM hat instead of having specialized roles.

Sabin Roman: In the first years of Linear, we didn’t have the role of a PM, however we did have product people. Our founders are incredibly good at product and we hired engineers and designers that share the same passion.

That changed when the product surface increased significantly. We started building features for other personas beyond engineers. And not just for smaller startups, but companies with thousands of employees. So it became really important to have a clear vision around where Linear is going and how everything we build fits into that vision. This is why Nan joined Linear 3 years ago as Head of Product. And since then another product manager has recently joined as well.

But the boundaries between product, design and engineering are intentionally vague. Product does more of the upfront discovery and builds a high level roadmap. However, when it comes to building a certain feature, we all work together to figure out the scope, what’s the best user experience, when it’s ready to be rolled out. And we do this through a lot of iteration: talking, building, showing, discussing and repeating, until it feels good.

This way of working incentivises learning from each other, building a common taste in product and trusting each other to take the right decisions without micromanaging.

On Hiring for a Principled Culture

A unique culture requires a unique way to find talent. I asked Sabin to elaborate on Linear's famous work-trial hiring process and how they find people who can thrive in such a principled environment. After he explained the trial, I asked about its success rate.

Sabin Roman: The engineering work trial is a week that the candidate spends with the team, working on a greenfield project. The project requirements are intentionally high level. This gives the candidate the freedom to drive the product direction, decide what the scope of the project should be and what they can actually build during that one week. They will be forced to do trade-offs, and that’s how we assess their judgement. Ultimately, what I tell every candidate is to build something that they will be proud of by the end of the week.

We also set up a project team, with engineers and designers that are there to help. But ultimately, the final call on what gets built belongs to the candidate.

Worth mentioning, we have a full interview process before the work trial. If we invite someone to do a work trial, we’re already highly confident that they are a good fit. What we want to see is how they work on open ended problems, in a team that is highly autonomous. And of course, they are interviewing us as well.

Are You a Startup or a Boutique?

To get right to the heart of their unique position in the market, I asked Sabin to clarify a fundamental question: given their deliberate, quality-focused approach to growth, both for employees and product, does Linear see itself as a high-growth startup or something more like a boutique software house? This led to a discussion about their primary bottleneck.

Sabin Roman: Linear is a startup. We've raised funding, most recently our Series C at a $1.25B valuation, and we're growing fast.

I never thought of us as a "boutique software house" - though that does sound pretty cool! - but we are deliberate about quality. Karri, our founder, recently gave a talk at Config on this - which we later turned into a blog post. He talks about how taking your time and shipping quality products is a real business strategy. Not just an artistic or nice-to-have thing. Quality experiences are somewhat rare these days, so you stand out when you can deliver one. And it means your churn is lower and word-of-mouth referrals higher.

If you look at our growth, both in terms of revenue, size of our customers, amount of features we are building, we are clearly a fast growing startup. But growth was never what we optimized for. We wanted to build a product that people love using. A product that is as intuitive to small and large customers. And if that means we sometimes take longer to ship, we are fine with that.

On Having No Career Ladder

One of the most radical aspects of Linear's culture is its flat hierarchy. I asked Sabin how the company handles difficult decisions and maintains order without a traditional career ladder, where seniority often dictates the outcome.

Sabin Roman: That’s a good question, especially in a company like Linear, where people do have strong opinions.

Ultimately we believe that the best idea should win, no matter who comes up with it. And we are fortunate enough to have hired people that truly care about the product above all else.

In practice when we can’t agree on something, it probably means a few things. We either don’t have the same understanding of the problem, or we’re optimizing for different use-cases. Sometimes, both competing directions are viable and likely to be right. So, we might as well pick one quickly, ship fast, and let the users decide.

Of course, we also end up in standstills sometimes. This is why each project has a project lead that ultimately can make the call. Or, if we feel we need more help, we can call in our Head of Product or one of the founders. Everyone loves talking about the product.

On Being "Data-Informed," Not "Data-Driven"

Another pillar of the traditional tech playbook that Linear rejects is A/B testing. I challenged Sabin on this, expressing my surprise at hearing the term 'data-driven' treated as a negative, and asked him to explain their philosophy.

Sabin Roman: We don’t do A/B tests. We prefer talking to customers to understand their pain points, then use our intuition and experience to figure out the right solution. We build that solution fast, get early feedback and iterate.

We also don’t believe in being data-driven. Rather we prefer to call ourselves data-informed. This means that once we do form a strong opinion on what we think we should build, we may check the data to make sure we are not completely off.

I know this may feel highly subjective, but data is also subjective. Of course, you can measure it objectively, but the way you interpret it is already subjective. And the way you act on it is even more subjective. It does give you a good feeling: ‘we're doing the right thing because the data says so’. But if you only look at data, you forget who the customer is. So save all that time, talk to customers and iterate fast.

On The Core Principle: Building Something Magical

To get to the heart of their philosophy, I asked him what would be different if Linear had been built using a more traditional 'big tech' playbook from the start.

Sabin Roman: I was not there in the first years of Linear, but I would imagine the founders learned a lot from their experience in ‘big tech’ companies.

But applying a cookie cutter solution is almost never the right way. Companies are very different. If something works, rather than copying it, first ask yourself why it worked. Context matters a lot.

And the context for Linear was very specific. Linear entered a market that was already saturated, with a simple goal. We will build a project management tool that people love using. So quality was there from day one. And if you optimize for quality rather than growth, a lot of the playbooks don’t apply anymore. We’d probably be doing A/B tests, building user stories, you know - doing the conventional things. Perhaps we’d have built an entirely different company or product - who knows!

A Special Offer from Linear

The folks at Linear have a shared passion for helping teams build better software, and they've generously offered to take $250 off any of their plans for my readers. If their principled approach to software development resonates with you, I encourage you to check them out.

You can claim the offer by using the link here: http://linear.app/partners/a-life-engineered

Newest YouTube Video

Have you ever wondered why some people who start at the same time as you seem to skyrocket up the career ladder? I spent nearly 20 years at Amazon figuring out the subtle signals that leaders look for, and it has nothing to do with working harder. In my latest video, I share the 3 specific behaviors that separate high-potential talent from everyone else.