If you run an engineering team, no matter how busy you are, you can save money by wasting time. I’ll walk you through how. Before you dive in, here’s the overview:
- Developers are curious people - keep them happy by feeding that curiosity
- Happy people stay longer 🤯
I’m a technical lead of an engineering team at a large organization (>1000 engineers). I work with resource strapped teams across the org struggling through common problems. We know them well - throughput, efficiency, and developer retention.
In many of these teams, I see the same issues. They start small and strong. As they develop chemistry and achieve success, they attract attention. That attention and success lead to ambitious roadmaps.
To deliver, they focus on throughput above all else. They hire more engineers. They lose the identity and connection that made them successful in the first place. They work more and more on maintenance rather than new features.
Talented engineers get bored or frustrated (or both) and leave. All that systems knowledge and skill walks out the door and the team is worse off because of it.
There is no way to avoid some of that. Teams have to grow. Roadmaps have to scale. Greenfield work must always convert to maintenance.
It’s that loss of connection and boredom we can work on.
2-3 times a quarter we give each engineer an entire day to research any engineering topic they want. The only catch is that they have to present what they learned back to the group in some way.
Here’s how it works.
- Create a “Learn and Teach” ticket for every engineer and assign it 1 point (8 hours of engineering work).
- The acceptance criteria: you must present something back to the group. That could be a proof of concept, a slide deck, a toy app, anything.
- During sprint planning: prompt engineers to start thinking about their topics.
- Schedule two lunch meetings at the end of the sprint for presentations.
- Engineers let the group know what topic they will be investigating during standup.
- We all meet and present what we learned to each other. Each engineer gets 10-15 minutes to present and another 5-10 minutes for Q&A.
I would wager most engineers are curious by nature. As our roadmaps reach maturity, a lot of day to day work can focus on bug fixes and marginal feature improvements. In short, it gets boring.
Bored developers leave.
The Learn and Teach program gives engineers the chance to research and investigate something they find interesting, but never had the time to look into. In short - it gives them permission to play.
Some of our recent Learn and Teaches were:
- CSS Art. The presentation was a slide deck followed by an awesome coding challenge to draw a turtle with only css
- Docker Containers. The presentation was an interactive game where docker containers were “characters” that we each controlled to fight a common enemy.
Neither of these things translated to our work. But both developers were engaged and invested with their research projects. The rest of the team was inspired.
By the end of each of our Learn and Teach sprints, our developers always express how refreshing it is to take a break from the monotony. We all stay connected through the presentations. We keep the “research” muscle warm. We delight each other. When asked if they want to do it again, the answer is unanimously “yes”.
It may seem like an impossible luxury to throw away so much engineering time.
It is. So is taking developer happiness and retention for granted.
When you have a good team, do everything in your power to keep it together and to keep your engineers happy. Good teams build good products, happy teams stay together. If this learn and teach keeps even one engineer on board for longer, it’s worth it.
Why not give it a shot? Go save some money by wasting time.