The best technical innovations rarely come from formal training programs or enforced skill development initiatives. They emerge from engineers who are genuinely excited about solving problems.
This observation contradicts conventional wisdom in engineering management, but it reveals an important truth: enthusiasm is the real driver of technical excellence.
Technical breakthroughs don’t magically appear after training sessions. They come from engineers who can’t stop thinking about problems. The kind who wake up with solutions in their head because they’ve been puzzling over challenges in their sleep.
The most powerful way to generate enthusiasm is through demonstrated behavior, not directives. Engineers are particularly attuned to this distinction—they quickly distinguish between leaders who “walk the talk” and those who merely issue instructions.
This means getting your hands dirty with work that many consider “beneath them”. By diving into the trenches, you send a powerful signal about what matters. Writing detailed Jira tickets shows you value clear communication and planning. Participating in tech debt reduction demonstrates commitment to code quality. Writing tests proves testing isn’t just something you talk about. Responding to customer queries shows customer problems matter at every level. Deep-diving into complex analysis proves thoroughness is valued. Trying work outside your expertise demonstrates learning is ongoing for everyone.
What’s particularly powerful about this approach is its authenticity. You can’t fake genuine interest in the unglamorous parts of building technology. When a technical leader spends time refactoring test coverage, the message about what matters is unmistakable.
This enthusiasm creates a multiplier effect. When engineers are passionate about solving problems, they dig deeper, persist longer, and explore creative avenues that training programs would never cover.
[It’s important to note that enthusiasm doesn’t have to mean working beyond normal hours.]
Generating motivation isn’t abstract—it takes deliberate, consistent actions. Engineers need to see how their work affects users. This means sharing customer stories, highlighting metrics improvements, and creating direct connections between technical work and business outcomes. When someone can trace their pull request to a customer’s success story, the impact becomes real. Abstract metrics like “improved performance by 20%” matter less than “this change helped 5,000 users complete their tasks faster.”
Nothing kills motivation faster than bureaucracy that prevents productive work. Identifying and eliminating process barriers sends a clear message that getting things done matters more than procedural compliance. Every unnecessary approval step, every redundant status meeting, every form that could be an async message—these accumulate into massive friction. The leader who removes these obstacles demonstrates they value engineers’ time and focus.
Recognition matters, especially for technical curiosity. When someone dives deep into a problem, recognize that effort regardless of outcome. The engineer who spent two weeks understanding a complex issue deserves recognition even if the ultimate fix was simple. This kind of deep work—understanding systems at a fundamental level—is what separates good engineering from great engineering. Celebrating it reinforces that superficial fixes aren’t the goal.
Carving out dedicated time for engineers to explore technical interests pays enormous dividends. The 20% time concept became famous because it works—it acknowledges that creativity requires breathing room. Engineers need space to investigate interesting problems, try new approaches, and build things that might not have immediate business value. Some of the best features and architectural improvements emerge from this exploratory work.
Leaders who openly share what they’re learning, including struggles, normalize growth. This creates psychological safety around not knowing everything. When a technical leader admits they’re learning a new framework or struggling with a concept, it sends a powerful message: expertise isn’t fixed, and continuous learning is expected at every level. This vulnerability creates an environment where engineers feel safe asking questions and admitting knowledge gaps.
Building this motivation-centered approach to technical excellence isn’t complicated, but it requires consistency. Look for engineers who demonstrate genuine interest in how things work, not just those with impressive credentials. The candidate who spent evenings building side projects out of curiosity often outperforms the one with perfect academic pedigree but no intrinsic drive. Curiosity can’t be taught, but it can be recognized and nurtured.
Continuously reinforce why the work matters and who it helps. Engineers want to build things that matter. Connecting their work to real people solving real problems makes the difference between a job and a mission. Share user feedback directly. Bring engineers into customer conversations. Make the impact tangible and immediate.
Spend time doing the “grunt work” alongside your team. The leader who writes tests, reviews pull requests in detail, and tackles unglamorous tasks sets the tone. This isn’t about micromanagement—it’s about demonstrating that no work is beneath you if it moves the team forward. Engineers respect leaders who understand the daily challenges because they’re living them too.
Identify and eliminate anything that prevents engineers from making progress. This might be slow CI/CD pipelines, unclear requirements, cross-team dependencies, or inadequate tooling. The leader who obsessively removes blockers sends a clear message: your time is valuable, and making you productive is my priority. This operational support, though often invisible, is what enables engineers to focus on complex problems rather than fighting infrastructure.
Give engineers control over how they approach problems. Autonomy isn’t just motivating—it’s essential for innovation. When engineers have ownership over technical decisions, they invest more deeply in solutions. This doesn’t mean zero oversight, but it does mean trusting engineers to choose implementations, technologies, and approaches within reasonable guardrails.
Once motivation exists, make learning resources readily available. This means budget for conferences, courses, and books. It means dedicated learning time isn’t seen as a perk but as part of the job. It means bringing in experts for workshops or lunch-and-learns. Resources alone don’t create motivation, but they amplify existing drive.
The best engineering cultures aren’t built on rigid learning paths but on contagious enthusiasm that makes learning inevitable. When engineers are genuinely excited about solving problems, technical excellence follows naturally.