To Win Big, Dream Big

How team vision drives continuous improvement

The outcomes you get are capped by the level of ambition you set for yourself.

If you aim for good enough, you might reach exactly that. Now what?

If you aim to be the best, you have a good chance of playing in the same league with the best.

Teams are no different

The same applies to teams.

In my experience the first mistake that managers and leaders make is not articulating clearly the level of ambition, or going with a weak version that does not inspire anyone.

Compare:

• “We are a team that does a great job” vs “We are a world-class team”

• “We provide great user experience” vs “Our product provides unmatched premium user experience”

• “We reliably deliver features” vs “We build products that define the category”

Most of the teams I was a part of as an engineer didn’t have an articulated vision of what they are for and where they are going. I missed that without understanding what was missing — no movement or sense of progression, just the next feature to deliver.

I believe people want to be inspired by what they are doing, not only earn a paycheck. It is true for my sample of one at least.

Beyond slogans: The Corporate Poster Trap

Everyone who has been working in the industry long enough has seen empty slogans. “World-class team” on a poster in the office kitchen while the codebase is on fire and people are burning out. In most cases, the “vision” is at best a set of values on a website shown during onboarding — it is never actually used for anything.

It does not need to be that way. Even if you cannot influence the whole organization, it is still possible to make your team a pocket of excellence in the organization. To do that you need a vision, a definition, and an action plan that moves the vision from a slide deck into a functional tool.

Define what your vision actually means

Let’s say your vision is “World-class engineering team.” It could be anything that reflects your ambition.

Whatever you choose, to turn the vision into reality you need to make it tangible.

You have to define dimensions for you vision, for example:

• Engineering quality — how reliable is what we build?

• Delivery speed — how quickly can we go from idea to production?

• Developer experience — do engineers fight tooling or do meaningful work?

The point is to make the abstract concrete. “World-class” on its own is a poster. Defined dimensions with clear expectations turn it into a target.

A vision only becomes real when it is used to break a tie between several choices. If your vision of “quality” doesn’t occasionally force you to delay a feature, it’s still just a poster.

You don’t have to invent dimensions from scratch. Industry benchmarks like the DORA State of DevOps report, DX developer experience surveys, and similar research can help you understand how your vision looks like in measurable terms — and where your team stands relative to the industry.

Assess the gap

For each dimension, define where you are today and what world-class looks like. Be honest.

If today you deploy every two weeks after a stressful manual regression, and world-class means deploying multiple times a day with automated gates, you have a gap.

Improve with a system

This is where most teams fail. They do the vision exercise, maybe even the gap analysis, and then nothing changes.

To move forward towards your vision, pick one or two dimensions that you will be working on, define a concrete change, run with it, reassess after a set period of time — for example a quarter. Rinse and repeat.

The key here is to keep going. Some of the changes will not stick, some will be marginally successful, and some will change the game.

An example from my own practice

We set a goal of creating a world-class engineering team. One of the gaps we identified was delivery. After benchmarking against the DORA report we found that the best teams release on demand — with bi-weekly releases we fell in the middle cohort. It wasn’t good enough. We set a target of moving to releases on demand, increased our automated test coverage to the appropriate level, and then conducted an experiment dropping the manual regression.

The experiment was successful.

Not only did we match our ambition on delivery speed, but product quality also increased — QA engineers had their hands free for doing in-depth exploratory testing that prevented more complex issues from entering production.

We set an ambitious goal, we created a plan, we implemented it, observed the results and reached our goal, partially reaching our vision.

Keep the message alive

A vision announced once and never mentioned again will not do anything. For ambitious framing to shape behavior, it needs to stay in focus. This means repeating the message in team meetings, one-on-ones, and planning sessions. Not as a slogan but as a lens:

• When reviewing a technical decision: “Does this meet the standard we set for ourselves?”

• When celebrating a win: “This is exactly what world-class looks like.”

We always need to remember, the team needs to see their leader model the behavior — the team will follow what we do, not what we say.

My personal experience

When people started talking in one-on-ones about the vision and what ideas they have to make it happen — that is when I felt a big milestone was achieved. A poster on the wall turned into something tangible that both sets the standards and drives decisions. The job is never done, but it is not an uphill battle anymore.

My experience is that if you are consistent with your vision — you repeat it often, model it yourself, and use it for decision making — people will internalize it and be inspired by it instead of being dismissive and skeptical. At the end of the day, most people want to be a part of something bigger than themselves. Big vision, when executed as a living system rather than being a corporate poster, turns ordinary teams into exceptional.

So the question is: what level of ambition have you set — and is it a tool you actually use, or just a poster on the wall?

Thank you for reading and see you next week,

Roman

P.S. Scaling an engineering org is hard — especially without a sounding board who’s been through it. I’ve spent 20 years building software and then scaled a startup’s engineering department into a top leadership role. I learned management in the trenches, made the mistakes, and figured out what actually works. Today, I help engineering leaders and startup founders stress-test their strategy and scale their teams without repeating those same mistakes.

If you’re facing a challenge — whether it’s org design, technical leadership, or figuring out how to grow from here — reply to this email or DM me on Substack. Tell me what you’re working through, and we’ll see if I can help.