We spend so much energy trying to figure out how to motivate people, often doing the exact things that push them away. I was reading David Yeager’s 10 to 25: The Science of Motivating Young People the other day, and his research really nails why so many of our usual tactics fail. He points out that between ages 10 and 25, the human brain is hyper-sensitive to status and respect. He says when we try traditional motivation, young people just hear adults talking down to them, which instantly makes them defensive (2024, pp. 39-42). They don’t want to be managed; they want to be noticed for their potential.
It’s a subtle shift: young people want autonomy to prove what they can do, while more experienced adults want it as a sign of respect for what they’ve already done. But the bottom line is the same. Nobody likes a micromanager; we all do our best work when we’re trusted to figure things out. Daniel Pink (2009) reinforces this in Drive, arguing that for high-level professionals, motivation isn’t about external rewards but the pursuit of autonomy, mastery, and purpose. When we step back, we aren’t just delegating tasks; we are honoring their intrinsic need to direct their own craft and contribute to something meaningful.
A few weeks back, I had a conversation with a highly respected leader in the IT community. One phrase they shared reinforced something I had always felt but never articulated clearly: “Motivation is an ongoing process.”
And honestly? It hits different hearing someone else say it out loud.
Because in tech, many love to treat motivation like a big software release. One massive kickoff. A rah-rah all-hands. Then they expect it to carry the team all the way to the finish line. But if you’ve ever managed a complex system, you know that “set it and forget it” doesn’t work. Motivation isn’t something you deploy once. It needs continuous integration.
That idea took me right back to my own team, where leadership continuously fuels our momentum by connecting our day-to-day work to the product’s bigger purpose. Managers and peers actively celebrate the small wins along the way, and everyone is empowered to focus on the work they do best.
Sustaining that kind of energy across a cross-functional agile team means killing the “motivation monolith.” You have to operationalize your drive. Because when you look at the momentum that actually lasts — the kind that prevents burnout and keeps engineers locked in — it really comes down to three things:
1. Beyond the Ticket: The Architecture of Purpose
Developers need to understand the “why” behind the code they write, not just what the ticket says. In my experience, this is where true leadership begins. As Gupta (2024, pp. 4-5) points out, an engineering manager (EM) adds their greatest value by actively bridging this gap—aligning the team’s daily output with broader business objectives.
Imagine an engineer staring at a Jira ticket that simply reads: “Refactor legacy authentication module and decouple from the main database.” To the engineer, this is just another slog through technical debt. It’s a sterile task, disconnected from the real world.
Now, imagine the manager steps in during backlog refinement. Instead of discussing story points, the manager draws a straight line from that ticket to the end user. They say, “This monolith is currently bottlenecking our entire system during peak hours. By decoupling this module, you aren’t just refactoring code; you are directly reducing login latency by two seconds. For our users—who rely on this platform for their daily workflow—that means less friction, less frustration, and a vastly better experience. You are building the foundation that allows this entire product to scale.” Suddenly, the engineer isn’t just closing a ticket. They are an architect of the user experience. They understand that the source files they are writing today are the bedrock of the company’s future capabilities.
2. The Power of the Micro-Win: Sustaining the Loop
Gostick and Elton (2020, pp. 125–127) interviewed several company leaders and kept hearing the same thing: gratitude isn’t a soft skill — it’s a performance driver. The ongoing, cumulative effect of recognizing small outcomes shifts how people feel and how they perform. Not the big awards or the end-of-year speeches. The daily stuff. Great leaders don’t wait for the big moment to celebrate. They actively look for small wins along the way—because those are the moments that keep a team from burning out before the finish line. And in engineering, this plays out every single day. Imagine it’s the middle of a gruelling, months-long push to migrate a massive legacy application. The team is tired, and the final deployment date feels impossibly far away. If the team only waits for the final “go-live” to celebrate, morale will dry up weeks before the finish line.
I remember a morning during standup when a mid-level developer casually mentions they finally fixed a flaky CI/CD pipeline test that had been throwing false negatives for a month. It’s a minor fix—a few lines of configuration—but the manager stops the meeting.
“I want to pause and highlight what Sarah just did,” the manager says. “That flaky test has been a silent tax on everyone’s momentum. By fixing it, Sarah just gave every single one of us five minutes of our focus back every single day. That is a massive win for our operational health.” The recognition is immediate, public, and highly specific. The marginal win is treated as a strategic victory. The developer feels seen, and the entire team gets a sudden injection of momentum, proving that every small optimization matters.
3. The Tailored Vector: Engineering Human Potential
Every team has hidden geniuses. Managers need to continuously look for them. Andy Ellis (2023, pp. 104–107) doesn’t sugarcoat it: “Performance development should be applied to every person on your team”—not just the ones struggling, but your top performers too. Here’s what that looks like in practice.
During a regular 1-on-1, an engineering manager notices that one of their reliable full-stack developers always lights up when the conversation shifts to data processing but seems disengaged when talking about UI components. The developer is fulfilling their current role, but their trajectory is flat.
Instead of keeping the developer in their current swimlane for the sake of short-term delivery, the manager makes a strategic pivot. “I’ve noticed how dialed in you get when we discuss data models,” the manager observes. “We have a new initiative coming up involving predictive analytics. It’s outside your usual scope, but I think your mind is perfectly wired for it. I want you to take point on the initial research.”
The manager actively aligns the project’s delivery needs with the developer’s latent interests. Six months later, that developer isn’t just writing standard code; they have become the team’s resident expert in that specific domain. By paying attention to where the engineer’s natural energy flowed, the manager didn’t just get the project delivered—they built a stronger, more specialized engineer in the process.
The Takeaway
Whether you are leading a cross-functional agile team or scaling your own career, treat team motivation like a critical production environment. It requires a clear architecture of purpose, continuous feedback loops of recognition, and strategic alignment with individual human potential.
Motivation isn’t something you have. It’s a system you run.
References
Ellis, A. (2023). 1% leadership: Master the small, daily improvements that set great leaders apart. Wiley.
Gostick, A., & Elton, C. (2020). Leading with gratitude: Eight leadership practices for extraordinary business results. Harper Business.
Gupta, A. (2024). Think like a software engineering manager. Manning Publications.
Pink, D. H. (2009). Drive: The surprising truth about what motivates us. Riverhead Books.
Yeager, D. S. (2024). 10 to 25: The science of motivating young people. Simon & Schuster.
Allan Mangune 