Lemon.io (Sponsored)

This week's newsletter is sponsored by lemon.io.

Ship Software Faster with Experienced Engineers

Finding skilled developers is hard—even for seasoned engineering leaders. Traditional hiring cycles can take months while critical features sit in the backlog.

Lemon.io removes the guesswork by rigorously vetting engineers and matching you with top talent in just 48 hours.

Need to scale your team quickly or find specialized talent that's hard to source locally? We match you with developers from Europe and Latin America who integrate seamlessly into your workflow—without the long hiring cycles or commitment of long-term contracts.

Unlike other platforms, we don't just check résumés—we put developers through a rigorous multi-step vetting process that assesses technical skills, problem-solving abilities, and communication.

Start building faster with lemon.io

I use Linear and have been following the company for quite some time.

They folks there are building a great product in a crowded space, and I've often found their opinionated views on software development inspiring. I have profound respect for their work and the competence of their employees.

That is why I listened to a recent episode of Lenny's Podcast by Lenny Rachitsky while driving down from the mountains on Sunday.

In it, Nan Yu, Linear's Head of Product, would unveil the secrets to building beloved B2B products¹.

I was intrigued right from the start.

Lenny follows the common approach of offering audio clips from the interview as an intro, highlighting the key topics with impactful quotes. The first one touched on a subject I'm pretty sensible to: tradeoffs between speed and quality in software development.

The episode opens with this nugget:

Lenny: "[…] I think you see in the team at Linear that a lot of people don't see that there is not actually a tradeoff between speed and quality. […]"

Nan: "People talk about this as if there were a tradeoff […] because when they think about speed, the thing they over-index on is rushing or being sloppy; what they should be indexing on is being really competent."

I was 20 seconds into the podcast episode and wondering if there had been some editing issues.

However, as the saying goes, you should not judge a book by its cover, and I decided to keep it for two reasons.

First, I wanted to understand better that bold and seemingly shallow statement.

Secondly, I was driving and didn't want to take any silly risks on the road just because I felt strongly about the first few sentences I heard coming out of the loudspeakers.

So I held on to the steering wheel and told myself I should listen to it with a critical yet open mind.

By the time the episode ended, I had already started mentally writing this article.

The main problem I see in how Nan approaches the issue of Quality vs Speed is that he focuses on the individual dimension. He argues that to look at someone's work, especially those who are at the pinnacle of their success, you can judge how good the output of their work will be by looking at how fast they are going.

I disagree with that being a general principle. Plenty of examples in history show that great masterpieces often result from obsessing on quality over a long period of time².

Even if that were true, the explanation for achieving speed is so narrowly focused on that single dimension that it forgets the reality of building digital products: it's a team's sport, not an individual endeavor.

Having more experienced players on your team should help you do better; there is little doubt about that.

Such experience, though, usually comes with a price tag, so you're already making an implicit tradeoff in the "good, cheap, fast" triad. Another of the many tradeoffs possible in the space of product development.

If we want to continue with the sports analogy, there have been plenty of examples of teams that failed to deliver up to expectation despite counting the best talents in their ranks³.

So, what does it take to get speed — or preferably the desired outcome — out of a team?

Interestingly, once Nan gets over the initial bold statements around the importance of individual skills, he starts offering more insightful details about how Linear achieves to move fast.

In a word, they iterate. But that's also a bit too simplistic, so let me elaborate.

They try to develop a working implementation as quickly as possible so they can start testing internally. To do so, Nan admits they don't make it pixel-perfect and accept some minor bugs.

A few minutes after stating there's no tradeoff between speed and quality, he admits they do just the opposite: they trade off the quality of the product — in its first iteration — to go as fast as possible to test it internally and then with real users.

This isn't a novel tradeoff, though.

We've known for decades, since the inception of the original Agile Manifesto, that working in small batches, iterating quickly, testing hypotheses, and giving yourself the time to perfect features incrementally is the most optimal tradeoff between limiting waste and maximizing outcomes.

Yes, having expert engineers (and designers, PMs, and CEOs, for god's sake) helps, but it's not a sufficient condition for success.

How you work, how deliberate you are with the tradeoffs you make, and how you accept to trust the system instead of letting emotion and rush drive your decision have a much more significant impact on what too many people in the industry still obsessively call speed.

The biggest hurdle in this exercise is not the implementation. It's the discipline to accept that something will not be perfect until you present it to users and collect feedback. It's figuring out the smallest increment you can meaningfully test.

That's hard because ego, opinions, and emotions often get in the way.

Our job is an almost infinite sequence of tradeoffs, many of which interplay with each other, creating a messy, complex system that lacks a single magic lever you can pull to make it work better.

Picking more experienced employees over less experienced ones is a tradeoff between cost and quality of the output generated. It's a tradeoff, not a silver bullet.

Cutting scope to meet a deadline (something Nan refers to towards the end of the episode) is trading quality — from the perspective of the user or the person requesting the feature — for speed — meeting the deadline.

Building a prototype quickly to validate the hypothesis rather than creating a full-fledged and scalable feature is another tradeoff between speed, quality, and/or cost.

These choices relate more to how you work and operate as a company than to each team member's individual skills and traits.

Given the space Linear works in — project management — how opinionated they are about how product development teams should work and how much they believe their tool leads to better practices, I was genuinely surprised by the excessive emphasis put on the individual — which opens the door to finger pointing and scapegoating — as opposed to the culture, processes, and practices of the organizations surrounding them.

At this point, you might wonder if I'm ignoring a fact: Linear, as an organization, seems to be unquestionably fast at shipping product improvements. But I'm not.

Although speed is largely a matter of perception, and its definition is relative to the speed of your competitors or whoever you're comparing with, I won't argue with the fact that Linear, from the outside, seems to be doing just that: shipping increments at high speed.

How do they do it?

Of course, they have talented engineers, designers, PMs, etc. But is that a unique advantage they have?

Do we believe Atlassian hires the worst engineers on the market? Or are the guys at TargetProcess fixated on interns and junior engineers to keep costs down? I don't think so.

A more significant differentiator is, indeed, the way Linear seems to organize work internally.

When reading between the lines of what Nan said in the interview, I couldn't help but think of the Forest & Desert metaphor Kent Beck and his daughter Beth Andres-Beck came up with in recent months⁴.

Linear seems to operate in a Forest-type environment, and I believe that's one of its key advantages.

Most companies aren't.

I've seen plenty of Deserts where teams must constantly work against the hostile surrounding environment. Where control dominates over trust and where there is no time to think about how to turn the Desert into a Forest, as you're too busy just trying to survive.

Learning about how Linear succeeded in creating such an environment would be way more insightful and educational for the industry than the obvious yet only partly accurate statement that experienced software engineers move fast.

I hope there will be a follow-up episode covering that part more in-depth.

In support of Nan's statements, during the podcast, Lenny quotes the following tweet from Patrick Collison, Stripe's CEO:

The problem with such statements is that they oversimplify a complex reality. They offer the comfort of something easier to understand, making many people believe them. Yet, their lack of nuance makes it almost impossible to engage with them constructively.

To use Khaneman's terminology, such statements engage with our System 1 brain while keeping System 2 dormant⁵.

The most annoying side effect is that CEOs and leaders around the globe see an influential person spitting out binary statements lacking depth and take them at face value without investing the time to understand what they really mean and how they would apply to their case.

For instance, in Collison's borderline populist tweet, you could argue that he is omitting the scope variable, which is an essential part of the definition of good or quality. I wouldn't go so far as to accuse him of spreading devious misinformation, as I have no evidence about his secret agenda.

If such statements are good candidates for a viral tweet, I'd be wary of anyone referencing them to prove a point—context matters. Ignoring it is just another way of applying outdated Newtonian principles of stimulus and reaction to a complex reality that is more accurately described through the lenses of system thinking.

Now, let's leave for a moment the oh-so-popular world of short sentences on social media platforms and turn our attention to people whose job is to try and make sense of the complex discipline of software development and delivery.

We can turn our attention to the work of the DORA Institute⁶.

Through years of research, its members consistently found that highly successful companies show a direct correlation between speed and quality. High-performing teams can ship frequently and with very high quality. How do they do that? Do they just hire the best engineers?

Funnily enough, I don't remember a yearly DORA report even mentioning the seniority or expertise of individuals as a contributing factor.

The absence of evidence is not evidence of absence, though. This factor may be included in the coming years.

What's more interesting is that the factors reported to have the highest correlation with positive outcomes have to do with the company's culture, the team's working processes and methodologies, tooling, and architectural decisions.

That's why when I talk with business leaders who are worried about their speed of delivery — or rather obsess over it — I start by reminding them of the following:

You don't ask for speed; you build for it.

Beyond that short statement, aimed at shifting the focus from the judgemental space of "you must go faster to prove to me you're good" to the more constructive space of "we need to build together our ability to move faster," hides a long journey.

You might let your System 1 indulge with the tweet-style aphorism or engage your System 2 in such a journey with your entire team and company.

There is no quick fix, though; patience is of the essence.

It takes time to turn the Desert into a Forest.

Something I like about this metaphor is how some system's dynamics seem to operate similarly both in the real world and in its metaphorical analog.

It's evident that, in the context of the climate crisis, in which we are literally turning forests into deserts, many individual actions that feel convenient at the moment are contributing to making the problem worse. There are little to no short-term incentives to drive behaviors that would reverse the global warming trend.

Similarly, in the metaphorical Desert, I often observe the same behavior. Individuals are so focused on their short-term convenience that it becomes detrimental to the well-functioning of the entire system.

Focusing too much on the speed of an individual engineer might paradoxically give you just that at the expense of the speed of the whole system.

Therefore, I believe the first question for any leader willing to engage in the journey from a Desert to a Forest should be the following.

what are you willing to sacrifice to get there?

If your answer is nothing, don't expect a different answer from your team members. You'd be disappointed.

I just hope you have enough water reserves to survive for a long time in the desert.

1

You can find the episode here. I recommend it as it touches on many interesting points besides the one covered here.

Lenny's Newsletter

Linear’s secret to building beloved B2B products | Nan Yu (Head of Product)

Listen now on Apple, Spotify, and YouTube…

Listen now

6 days ago · 77 likes