When an associate engineer and intern joined my team (see my previous post), one of the things I noticed had nothing to do with documentation or knowledge sharing. Something shifted in how the existing team showed up. The two new arrivals were visibly enthusiastic, curious, asking questions. And that turned out to contagious. Engineers who’d been heads down and fairly routine in their habits started engaging differently.
It got me thinking more carefully about what engagement actually is, where it comes from, and how a leader can act in deliberate ways to grow it.
What engagement actually means
Engagement is the difference between someone doing their job and someone actually thinking about it. It’s the engineer who flags a problem on a Friday afternoon because they care whether it ships correctly. It’s the code review that catches the architectural issue nobody else noticed rather than the one that approves and moves on. It’s the team member who shows up to a planning meeting with a better version of the problem than the one you came in with.
Most team leaders know who the engaged people on their team are. What they often underestimate is how much of the rest of the team is just getting through the week, and what that costs over time. Not just in output, but in the quality and inventiveness of the work.
Why it matters more than you might expect
Let me throw some stats at you. Culture Amp’s Science of Sustainable High Performance report pulled data from over 560,000 employees across 1,500 companies and found that organisations in the top quartile for engagement have 14% of their people rated as high performers, compared to 10% in the bottom quartile. The gap might not look that large on its own. However, over a team, and over time, it compounds significantly. The same study found that only 2% of employees sustain high performance across multiple review cycles, which tells you that performance isn’t really a trait you identify at hiring and then bank on. It’s a condition you either maintain or erode through the environment you create.
Disengagement in tech is also unusually hard to detect. Skilled people can produce perfectly functional work while keeping their best thinking to themselves. As long as the code compiles, sprint velocity is steady, bugs get fixed, it may look superficially as if people are showing up. What you don’t see is the solution they didn’t suggest, the risk they noticed and stayed quiet about, the refactoring they judged not worth raising. That cost stays invisible for a long time, which is part of what makes it dangerous.
How team leaders can make the difference
Culture Amp’s research identifies three main drivers of engagement: leadership quality, access to learning and development, and confidence in the organisation’s direction. As a team leader, you have limited control over the third one, but the first two are factors you can influence.
Engagement isn’t just a company culture problem or something HR owns. The biggest human factor in how people feel about their job is who they interact with on a day to day basis, and how they interact with them. In other words: engagement is a team-level outcome, and the team leader is a big factor in it. If your team isn’t engaged, the most useful place to start is not the compensation structure or the company strategy. It’s your own behaviour. How clearly are you communicating what actually matters and why? Are people growing, or just executing tickets? Do they feel like individuals with careers, or like resources with a queue?
People engage when the work feels meaningful, when they have real say in how they do it, and when they feel like they’re genuinely respected rather than just managed. They drift away quietly when the opposite is true, and usually by the time it’s obvious it’s been going on for a while.
What this looks like day to day
None of what builds engagement is particularly complicated. It’s just easy to let slide when things are busy, which they always are.
Point people at the problem, not the solution. The most common mistake I’ve seen, including from myself, is over-specifying. The moment you hand someone a fully formed answer, you’ve killed most of the autonomy that makes work engaging and closed off approaches you hadn’t thought of. Be clear about what you need to achieve. Leave the how open.
That’s not to say you can’t have opinions as a technology leader, of course. But you need to be careful to give people space to disagree, come up with their own, better, ideas.
Give people the context behind decisions. Engineers often work with a fraction of the information that shaped the thing they’re being asked to build. Sharing that context, the customer problem, the constraint, what trade-off was made and why, changes how people engage with the work. It also tends to surface assumptions early when they’re still cheap to revisit.
Absorb organisational noise so your team doesn’t have to. A significant part of my job is filtering out the turbulence from above and around, shifting priorities, stakeholder anxiety, process overhead, so the people who need sustained focus can actually have it. This is invisible when it’s working well, which is partly why it tends to be the first thing that slips. It’s also a hard one to balance against the need to provide context, sometimes.
Treat psychological safety like it’s infrastructure. Yeah I know, “psychological safety” is a bit of a buzz term. That doesn’t mean it’s not important though. People won’t raise problems, challenge decisions, or share half-formed ideas unless they feel genuinely safe doing so. That safety gets built through consistent behaviour over time, especially when things are difficult. How you respond to bad news tells your team more about what’s actually safe to say than any values statement you could write.
Get to know your people as individuals. Quite apart from being a basically decent thing to do (and to make your own job more enjoyable), the engineer who wants to become a deep technical specialist and the one who wants to eventually lead a team need fundamentally different things from you. Understanding what each person values, where they want to go, what’s getting in their way, is both decent management and the most direct path to their engagement.
Have real conversations rather than scheduled ones. This one goes hand in hand with the previous point: what works is regular, honest, two-way conversation. The goal is knowing what’s frustrating someone before it turns into a resignation, or understanding what someone is trying to grow into before they start looking for it somewhere else.
Be curious out loud, and be wrong sometimes. The thing that stuck with me from watching our new team members was how their open curiosity seemed to give the rest of the team “permission” to not always know everything. If you model genuine curiosity and acknowledge when you’re wrong, people stop pretending to certainty they don’t actually have. That changes the quality of the conversations you have, and the quality of the work that comes out of them.
The point
Being a technology leader isn’t about being the best technologist on the team. It’s about building conditions in which people with genuinely different experiences and perspectives can bring their full capability to the work and actually care about what they’re building.
When that works, it builds on itself. A team that feels valued brings more of its thinking to the work. A team with diverse experience makes fewer of the mistakes that come from everyone’s blind spots pointing the same way. A team that performs well develops the kind of trust that makes real challenge and honest disagreement possible. Each thing feeds the others.
The loop is surprisingly easy to break. Disengagement builds gradually. Hiring drifts towards people who think like you. Leadership slides from developing into managing. Often you won’t notice until it’s been happening for a while.
Building it, on the other hand, just takes consistent attention. It’s also where the real leverage is. Get it right and an awful lot of the other stuff gets easier.
This is the final post in a three-part series. Part 1: How diversity, engagement, and performance all strengthen each other. Part 2: Why experience diversity is a technical asset