GitPrime is Renaming to Pluralsight Flow Learn more

What ‘Fast’ Actually Looks Like

Perspectives in Engineering

What ‘Fast’ Actually Looks Like

Operational fast vs. strategic fast

Many of us share a misconception about what ‘fast’ looks like at work. We equate ‘speed’ to being busy, frantic meetings, and the flurry at the end of each sprint.

But ‘fast’ has been lost in translation. And the more neurotic we get about our definition of working effectively and working fast, the slower we seem to go.

That isn’t to say we shouldn’t focus on delivering quickly. Without a doubt, speed to market is important. The speed of iteration is important. The fact of the matter is that there are teams that are truly ‘fast’, but they operate in a paradoxical way.

So what does ‘fast’ actually look like?


A calm, consistent flow

I had a funny conversation recently. My friend is a software developer at Tesla. He said, “we don’t really do Agile. We’re too busy to do ‘all that stuff’. We just focus on getting things done, and it gets done.” I laughed. What he was describing is as Agile as it gets—a true flow—without the various guardrails and prescriptive elements.

‘Fast’ is sustainable. It’s not fits and starts, not just one sprint, one month, or “one project.” People aren’t getting burnt out or leaving your company after some stock vests.

This isn’t to say that there aren’t ebbs and flows. There are (hopefully) new challenges that are landing on your desk, some of which will require an entirely different approach. Work gets boring if every day, and every month, is the same.

Fast teams exude ‘calm’. Work gets done but without the frenzy. These teams create value quickly and minimize risk early, but without extra process or control. They also do so in a predictable fashion.

An investment in resilience

I remember speaking with an executive who wandered down to engineering. She was immediately concerned that people weren’t at their desk. They were on the sofa reading. Horror! What kind of work ethic is this? She didn’t realize that a lot of knowledge work involves a good deal of pondering, and then a flurry of activity. The developer sitting on the sofa was researching something. They spent a couple hours there, had some coffee, and solved the problem gracefully. This is ‘fast’, but it certainly didn’t look like it.

Fast takes an investment in resilience, which often involves going slower in the short-term. It also means having “slack” baked into the system. Resilience may involve taking time to learn new skills or shuffling teams. It may involve your most experienced developers slowing down to teach. Your most experienced engineers still receive training. None of this feels “fast” in the near term, but the benefits will materialize with time.

Said differently, “slow down to speed up.” Explore early, churn early, review early. Capture lessons learned and share them with the team.

As an aside, I’ve known more junior teams to take 1-2 years to really start clicking. If they had been forced or pressured, they may have never gotten there. “Slowing down to speed up” must be supported at in leadership to allow any team to build muscle and endurance, to practice, and to ramp up.

The ability to seize opportunities

Fast is being able to seize opportunities when they emerge—and doing the least amount of work (and adding the least amount of complexity) required to exploit those opportunities. So it often involves doing, or at least permanently releasing, less workload.

Limiting work in progress has a far greater impact on “fast” then typing faster. The team juggling one project will always outperform the team juggling five. Same effort, but with five projects you’re paying a multi-tasking cost. Fast is about the flow of work. Does the whole organization reliably move important things through the system?

Imagine half of your organization starting calling out sick. Imagine what would happen! Yet we routinely do things that lower the throughput of our organizations by 50% without realizing. This is the challenge with ‘fast’. Taking care of that which is causing the 50% reduction feels out of bounds. We chase ‘fast’ framed by the situation, instead of thinking about step changes.

Validated outcomes

When most Agilists go off about “velocity”, what they are actually talking about is velocity for the sake of velocity: a blind focus on output. Truly “fast” organizations do have fast output and they make consistently smart decisions. The output is fast and minimalist. It is solving the problem with a quarter the amount of code.

Can the team go from idea to validated outcomes with customers quickly? Can they add complexity to the product such that speed is possible in the future? From an outside perspective, a lot of these activities look slow. In an operational sense (moving quickly), these activities are slow. But strategically, they are fast. ‘Fast’ != staring at screens all day.

The reality is that validating your work—getting it in front of customers—feels slow. It feels awkward. Who does it? Do you keep working while you test? Does the team sit around? What happens? If you’re really getting stuff out there in front of customers, it feels slow, and that is an uncomfortable truth. If the team is not getting surprised sometimes, changing course and pivoting, then there is no new information. You might have just as well planned this out in one big batch.

Fast requires a focus on quality, on delivering value, if you ever hope to sustain the output for the long haul. And quality requires autonomy. For short periods of time, it is possible to “force” fast—think about the big critical project where everyone pays attention. But to get sustainable ‘fast’ you need a minimal number of hops and handoffs. In many cases, it is not the actual work that is slowing you down, but all the work around the work.

Parting thoughts

Many organizations confuse operational speed with strategic speed. But when we focus on operational speed (or moving quickly), we tend to slow down. A resilient team goes fast and lives to go fast another day.

So when people talk about “going faster,” make sure to ask some questions (adapted from this post):

  1. What does faster mean for you?
  2. What are you trying to optimize for?
  3. Are you willing to go slower in the future, to go faster right now?
  4. How has “going fast” worked out? How has it helped the business? Has it hurt? What has been the impact of the added complexity?
  5. Would you be willing to go slower and build less, if it led to superior business results? Can we build less?