Giving engineers more direct customer access is interesting. Curious how you prevent chaos where engineers prioritise noisy customer complaints over other priorities
Velocity itself means nothing *unless* you can (and want to) adjust the direction when you learn new facts.
And you actively seek new information.
I agree with many specific arguments here, but I would still argue that, without understanding details on how a team operates, I still recommend going slow in the right direction rather than fast, well, somewhere.
Going in the wrong direction (and fast) leaves a costly trail behind. A complicated code base. Emotions related to realizations that we worked on useless stuff. Cost of hustle when none was needed. Yes, these are mostly intangibles. But they stack up.
And then there's the question of where the next pit stop is and whether we can make it there (to stick with a metaphor of a race car wandering around semi-randomly). The most common reason for failed startups is "ran out of money." These are all those race cars that ran out of fuel before they managed to find a gas station.
They sure went fast.
Still, I argue with a meta framing more than any detail here.
I think a much better concept to describe what we're looking for is maneuverability.
Maneuverability includes both the ability to change direction and to move swiftly. Ideally, we want both, but it compounds mutually exclusive factors. The more we optimize for rapid change of direction, the slower we have to move (and vice versa). So we seek a reasonable optimum within context.
A drag racing car is all speed and no directional control. A walking person is all directional control and no speed. You want neither.
"I still recommend going slow in the right direction rather than fast, well, somewhere."
This is the tricky part - you don't really know it's the right direction anyway.
I think that the optimizing here is not for the speed of output, but the speed of learning - and if you do it right, part of deal is to also have faster experiemenets. When done right, it can be without leaving a trail (being prepared to throw code away, fully deleting features, and so on).
I come from the context of early-stage product development.
Across that cohort, going fast from the outset is:
a) very typical
b) most commonly a mistake
c) and a costly one
When you start with a product idea, a high pace of learning almost implies a slow pace of development.
There are only that many experiments where you can get the validation instantaneously.
On the other hand, there are oh so many experiments you can run with very little or no code whatsoever.
The default attitude, however, is to build everything as if we knew where we were going. It's not the pace of learning. It's the pace of building. A sad outcome is that the founders run out of money before they find out what the right direction is.
If they listen to our advice and start slower, the difference is that by the time of the first validation, they have spent much less of their resources. Since the first validation is almost always invalidation ( https://pawelbrodzinski.substack.com/p/90-of-times-validation-means-invalidation ), they still have runway to react and change course.
I agree, it's different if you have semi-infinite coffers, or you start with an idea that's already been validated (like you automate an existing business process). Most startups do neither.
Meta’s most misunderstood value has always been Move Fast. If I had to describe the vibe I got from hearing Mark’s talk about it in one sentence,it would be:
“With a constant sense of urgency, optimize for the shortest feedback cycles.”
The wording for this value changed over time, from “Move Fast and don’t be afraid to break things” to “Move Fast with stable infra.” Love to see a similar process in this post.
Loved the architectural review habit. Pure intention made auditable by other brains.
Also loving the human PR review part - it is a lot of pressure to remove it due to the perceived slowness of "everybody being busy with their own thing". If we do the process and habituation right, it solves tough slip-ups, particularly with the adoption of the AI that injects all kinds of weird stuff along with the great stuff.
Last but not least, adding fresh perspective regularly – this makes the team a pipeline of greatness and change. There is the overlooked perspective on the senior career – staying too long at one organisation without a change tempts stagnation. The senior must have a growth plan, and an ambitious one, basically planning for their next focus, whether own business or another challenge. Naturally, get some new perspective with a talented, high-energy apprentice, and the team pipeline roars ahead, churning out more high-quality builders and problem solvers.
Fantastic article and account of your ways, thank you!
Teams that learn fast, win fast, simple as that.
Giving engineers more direct customer access is interesting. Curious how you prevent chaos where engineers prioritise noisy customer complaints over other priorities
I would question framing here.
Velocity itself means nothing *unless* you can (and want to) adjust the direction when you learn new facts.
And you actively seek new information.
I agree with many specific arguments here, but I would still argue that, without understanding details on how a team operates, I still recommend going slow in the right direction rather than fast, well, somewhere.
Going in the wrong direction (and fast) leaves a costly trail behind. A complicated code base. Emotions related to realizations that we worked on useless stuff. Cost of hustle when none was needed. Yes, these are mostly intangibles. But they stack up.
And then there's the question of where the next pit stop is and whether we can make it there (to stick with a metaphor of a race car wandering around semi-randomly). The most common reason for failed startups is "ran out of money." These are all those race cars that ran out of fuel before they managed to find a gas station.
They sure went fast.
Still, I argue with a meta framing more than any detail here.
I think a much better concept to describe what we're looking for is maneuverability.
Maneuverability includes both the ability to change direction and to move swiftly. Ideally, we want both, but it compounds mutually exclusive factors. The more we optimize for rapid change of direction, the slower we have to move (and vice versa). So we seek a reasonable optimum within context.
A drag racing car is all speed and no directional control. A walking person is all directional control and no speed. You want neither.
"I still recommend going slow in the right direction rather than fast, well, somewhere."
This is the tricky part - you don't really know it's the right direction anyway.
I think that the optimizing here is not for the speed of output, but the speed of learning - and if you do it right, part of deal is to also have faster experiemenets. When done right, it can be without leaving a trail (being prepared to throw code away, fully deleting features, and so on).
I come from the context of early-stage product development.
Across that cohort, going fast from the outset is:
a) very typical
b) most commonly a mistake
c) and a costly one
When you start with a product idea, a high pace of learning almost implies a slow pace of development.
There are only that many experiments where you can get the validation instantaneously.
On the other hand, there are oh so many experiments you can run with very little or no code whatsoever.
The default attitude, however, is to build everything as if we knew where we were going. It's not the pace of learning. It's the pace of building. A sad outcome is that the founders run out of money before they find out what the right direction is.
If they listen to our advice and start slower, the difference is that by the time of the first validation, they have spent much less of their resources. Since the first validation is almost always invalidation ( https://pawelbrodzinski.substack.com/p/90-of-times-validation-means-invalidation ), they still have runway to react and change course.
I agree, it's different if you have semi-infinite coffers, or you start with an idea that's already been validated (like you automate an existing business process). Most startups do neither.
I think we agree on most of it :)
Meta’s most misunderstood value has always been Move Fast. If I had to describe the vibe I got from hearing Mark’s talk about it in one sentence,it would be:
“With a constant sense of urgency, optimize for the shortest feedback cycles.”
The wording for this value changed over time, from “Move Fast and don’t be afraid to break things” to “Move Fast with stable infra.” Love to see a similar process in this post.
Loved the architectural review habit. Pure intention made auditable by other brains.
Also loving the human PR review part - it is a lot of pressure to remove it due to the perceived slowness of "everybody being busy with their own thing". If we do the process and habituation right, it solves tough slip-ups, particularly with the adoption of the AI that injects all kinds of weird stuff along with the great stuff.
Last but not least, adding fresh perspective regularly – this makes the team a pipeline of greatness and change. There is the overlooked perspective on the senior career – staying too long at one organisation without a change tempts stagnation. The senior must have a growth plan, and an ambitious one, basically planning for their next focus, whether own business or another challenge. Naturally, get some new perspective with a talented, high-energy apprentice, and the team pipeline roars ahead, churning out more high-quality builders and problem solvers.
Fantastic article and account of your ways, thank you!
Fully agree about the new perspective. There is a limit to the ideas you can break from the brains of people already in the company.