One of the responsibilities of a great execution team is to make sure they will deliver in great speed and great quality, over time. “It’s a marathon, not a sprint” might be a confusing statement if you’re actually using Sprints in your development process ;)
What do I mean by “confidence building” and how does it affect you? Well, I believe that you need to earn others confidence over time, making sure your customers, internal and external, are happy with your results. For that you’ll need to make sure you understand what’s expected from you, to reach deadlines on time, to raise the Red Flag early and offer alternatives, to deliver product with great quality and to produce estimation that prove themselves as meaningful. Your job is to keep the execution machine at full speed and building the confidence as you go.
My recommendation is to make sure your Sprints will contain some internal maintainability time so you could stay on track rather than “have a good Sprint once in a while”. Here are a few thoughts:
- Bugs elimination – making sure the backlog is not overwhelming. Pick wisely, based on ROI given by product and technical teams.
- Provide rough estimation on the Features in the roadmap, review previous estimations and see if you were close.
- Push small POC for risky features to come.
- Create technical design for big/risky features you plan to address next sprint.
- Eliminating technical waste – small refactoring to enhance team productivity.
You can either treat them as features, or simply buffer some availability of the team to handle this.
No matter what, do not abuse the trust people have in you. Your boss hired you because s/he trusted you to do well, it doesn’t mean you don’t have to work hard and continue to earn her/his confidence in you.
It is a marathon, after all.
p.s. check out my latest side-project, SoftwareLeadWeekly – A free weekly email, for busy people who care about people, culture and leadership.