← Back to blog
From Meaning to Impact

From Meaning to Impact

Author avatar
Pawel Kubiak
8 min read
  • #Team Management
  • #Leadership
  • #Productivity
  • #Tech Lead

This is the final article in the series exploring Project Aristotle - Google's research on what really makes teams effective.

So far, we have looked at four of the five factors:

A team can feel safe. It can deliver reliably. It can have clear roles and goals. People can even find personal meaning in their work.

And yet there is one more question that quietly determines whether the team will keep performing over months and years:

Does the work actually matter?

Not "does it feel important to me personally" - that was meaning.

But: does it make a real difference in the world outside this team?

This is impact - the fifth and final factor identified by Project Aristotle.

What Impact Really Means

In the context of Project Aristotle, impact is the team's belief that their work creates real change - for users, for the business, or for the wider organization.

In practice:

  • the team can see the consequences of what it ships,
  • decisions are connected to outcomes, not just outputs,
  • success is measured beyond "we delivered the ticket",
  • people understand who benefits from their work and how.

Impact is not the same as productivity. A team can be extremely productive and still wonder whether any of it matters.

Impact answers a different question:

"If we did not exist, would anyone notice?"

Effective teams can answer that question with confidence.

What Impact Is Not

This distinction matters, especially in engineering organizations.

Impact is not:

  • shipping more features,
  • closing more tickets,
  • working on visible projects,
  • being praised in all-hands meetings,
  • delivering whatever leadership requests next.

A team can be busy, visible, and well-regarded internally - and still have low impact.

Output is what the team produces. Impact is what changes because of it.

The two are not the same. And confusing them is one of the most common reasons teams quietly burn out.

Why Teams Struggle With Impact

Most teams do not lack impact because they do not care. They struggle because impact is harder to see than output.

Common causes include:

1. Distance From the Outcome

Engineers ship features. Then someone else measures, reports, and decides what is next. The team rarely sees what actually happened with their work.

2. Output as a Proxy for Value

When velocity, story points, or number of releases become the main signal, teams optimize for what is measured - even when it stops correlating with real value.

3. Roadmaps Without Reasons

A backlog full of "the next thing" without a clear theory of why it matters drains a team faster than any technical problem.

4. Success Measured Internally

If success means "the project was delivered on time" rather than "users behave differently now", the team never closes the loop on whether it was worth doing.

5. Constant Reprioritization

When priorities change every few weeks, nothing has time to produce visible impact - so the team learns that impact is somebody else's concern.

Impact is rarely missing because of laziness. It is missing because the system around the team makes it invisible.

What Impact Feels Like for a Team Member

For an individual contributor, strong impact means:

  • I can point to something that is different in the world because of my work,
  • I see numbers, stories, or feedback that show what changed,
  • I understand how my work connects to a larger goal,
  • I trust that what I do is not going to be silently dropped,
  • I feel proud of more than just the act of shipping.

In teams with impact, "what did we accomplish this quarter?" is an easy question. In teams without it, the same question gets uncomfortable answers about velocity and ceremonies.

The difference is not effort - it is consequence.

The Cost of Low Impact

When impact is missing, the consequences are often slow and subtle:

  • people stop arguing about priorities, because nothing feels worth arguing for,
  • senior engineers quietly disengage,
  • ambitious teammates leave first,
  • the team turns into a feature factory,
  • delivery continues, but the spark is gone.

This is the most dangerous failure mode in mature organizations. Nothing is broken. Everything is "fine". And yet the best people are already mentally somewhere else.

Low impact is rarely the reason given in exit interviews. But it is often the real one.

The Role of the Tech Lead in Building Impact

A Tech Lead cannot single-handedly decide what the company values. But they have far more influence over impact than they usually realize.

A Tech Lead supports impact by:

  • pushing back on work that has no clear "why",
  • connecting technical decisions to business and user outcomes,
  • making the team's results visible beyond the team,
  • celebrating outcomes, not just deliveries,
  • protecting the team from work that is busy but not meaningful.

Perhaps most importantly, Tech Leads close the loop. They make sure that after work is shipped, the team learns what happened next - what improved, what did not, and what to do about it.

A team that never hears what happened after release slowly stops caring what happens after release.

Practical Ways to Strengthen Impact

Impact is built through small, repeated practices:

1. Define Outcomes Before Outputs

Before starting significant work, agree on what should be different in the world if it succeeds. Numbers are nice. Even a clear story is enough.

2. Bring User and Business Context Into Engineering Discussions

Refinement and design reviews should not only ask "how do we build this?" but also "why are we building this, and for whom?"

3. Share Results, Not Just Releases

Release notes are not enough. Share metrics, user feedback, support data, business outcomes - whatever shows whether the work mattered.

4. Kill Work That Is Not Working

One of the strongest signals of an impact-driven team is its willingness to stop doing things. Teams that only add but never remove eventually drown in low-value work.

5. Connect People to Real Users

Even occasionally. A single user interview, support call, or production incident often does more for engagement than months of dashboards.

These practices do not require permission from above. Most of them can be started inside the team.

Tech Lead Anti-Patterns That Undermine Impact

Some behaviors quietly erode impact, even when intentions are good:

  • treating the roadmap as untouchable,
  • protecting low-value work because "we already started",
  • celebrating launches without ever revisiting outcomes,
  • defining success as "we shipped on time",
  • accepting every incoming request without questioning its value.

The result? A team that delivers a lot, complains a little, and slowly stops believing that their work changes anything.

How the Five Factors Fit Together

Project Aristotle did not present five independent ingredients. It described a system.

  • Psychological safety lets people speak honestly.
  • Dependability turns honesty into reliable delivery.
  • Structure and clarity make sure that delivery is aimed at the right thing.
  • Meaning makes the work matter to the people doing it.
  • Impact makes the work matter to the world around them.

Each factor reinforces the others.

A team without psychological safety cannot honestly discuss what is and is not working. Without dependability, even meaningful work never reaches users. Without structure, energy is wasted. Without meaning, performance does not last. Without impact, even the most engaged team eventually starts to drift.

The factors are not a checklist. They are a feedback loop.

That is why teams rarely fix effectiveness by tackling one of them in isolation.

Closing the Series

When I started writing this series, I expected the technical reader in me to disagree with parts of Project Aristotle. After all, the research talks much more about people than about systems, code, or architecture.

What I found instead is that the five factors describe, in non-technical language, almost everything that quietly determines whether engineering teams succeed or stall.

The strongest teams I have worked with were not always the most technically advanced. But they were:

  • safe enough to disagree,
  • reliable enough to be trusted,
  • clear enough to move without constant alignment,
  • connected enough to care,
  • and close enough to outcomes to know it mattered.

And the teams that struggled most were rarely failing at code. They were failing at one - or several - of these five things.

So if I had to leave one takeaway from the entire series, it would be this:

Team effectiveness is not a soft topic. It is a technical leadership topic.

The earlier we treat it that way, the better the systems - and the products - we build together.

Sources

Comments

Comments are disabled until analytics consent is granted.