The situation: Sandra builds polished, awe-inspiring features but she’s terrible at demoing them. Each Sprint Review meeting, she stumbles over her demo and speaks like she’s half asleep. She makes exciting new features feel boring and uncomfortable. What do you do?
- The “project smoothness” option: have someone else demo her work for her.
- The “employee growth” option: let her keep doing it for experience and give her lots of feedback.
Sometimes, employee growth is bad for the project.
The classic example is the battle between velocity and learning. Say George wants to learn React, and Sheryl has lots of React experience. Do you let George build the React-based feature to learn it? Or do you let Sheryl get it done in half the time?
If you’re up against a tight deadline, of course you’d let Sheryl take it. But I find that many companies would want Sheryl to take it regardless. “Faster is better, right?” Better than what? Better than people growing and learning?
It’s short term vs. long term thinking. Project smoothness leads to short term success. Employee growth leads to long term success. Long term success can be painful in the short term. If it wasn’t painful, then everyone would eat a perfect diet and exercise every day.
It’s hard to choose awkward Sprint Review demos now so that Sandra can be great at them later. But the alternative is that she stays bad at them forever. Is that a tradeoff you’re willing to make for a little short term success?
Think of it like a spectrum. Companies on one end value employee growth at the cost of everything else. Companies on the other end want each project to cruise at the cost of everything else. We could call the metric the “growth-pain-threshold”.
Where would you like your company to be on that spectrum? And where is it right now?
Mike Crittenden 