When an associate engineer and intern joined my team (see my previous post), one of the things I noticed was that something shifted in how the entire team showed up. The two new arrivals were visibly enthusiastic, curious, asking questions, and that turned out to be 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 and caring about it, which shows up in all sorts of ways: flagging a problem on a Friday afternoon instead of clocking off for the weekend early; specific and constructive code reviews rather than a lazy approval box tick; passionate disagreement with a chosen solution and coming with better alternatives instead of just “doing what we’re told”.
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 and 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 (hopefully) 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.
One example of a concrete thing we’ve started doing is “normalizing incidents”: when something breaks in our systems, instead of agonizing over questions like “how much customer impact does this have?” and “is it really serious enough?”, we just default straight to escalating it as an incident. On a practical level this creates a dedicated/centralized conversation channel to loop in everyone on the problem, which in turn creates a great “log” of the issue as input for a post-incident review. But on a psychological level it takes some of the “blame/shame” out of incidents. I know we often state in incident reviews that we are doing a “blameless” retro, but just saying that isn’t enough, and it certainly doesn’t help while fixing the problem. Making incidents less of a “heavy” thing helps avoid having an on-call engineer who is frantic because they are worried they are the cause.
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. People who feel valued bring more of their thinking to the work. Diverse experiences mean that you catch mistakes that homogeneous teams miss, and good performance builds the trust that makes people feel valued, and lets people challenge each other honestly. This loop is surprisingly easy to break. Disengagement creeps in slowly. Before you know it, you’re hiring clones of yourself, and leadership becomes more about managing than developing. 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 as a techonology leader you can make the biggest difference. 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