Spikes Within Sprints
6 December, 2019
It is important that individuals on your team have time allocated for growth and development in addition to Sprint work. I approach this by rarely giving developers formal training and instead allow them to spend time working on Spikes. Here, I will explain what a Spike is and how you can effectively utilize them within your team.
What is a Spike?
A Spike is an investment of time, energy, and resources towards a task dedicated to disrisking or dispelling unknowns. It may also be referred to as research although I don’t like to use this term because research is unbounded and uncertain. More so, research covers a large area and tends to be self-directed. Spikes, on the other hand, are focused on a small aspect that actually needs to be understood in order for the person to be productive. Additionally, Spikes are time-limited because they are aligned with that clear objective or related to future work.
I expect engineers to be able to declare how much they understand the work that they are doing. If they need to spend extra time to reach that level of comprehension then they can request a Spike to come up to speed. We set the objective of the Spike as well as allocated time, which could range from a couple of hours to a couple of days depending on the expected value that it could bring (which is difficult to measure). At the end of that time the person reports their findings to myself or the team and the information is then used to solve a problem or increase overall productivity.
- Spikes give people time to recognize and focus on specialized topics adjunct to the work that they do. This removes the full breadth and weight of formal training or scaling the whole domain by narrowing in on issues that they are faced with day in and day out.
- Spikes work best if there is one clear question to answer. Refrain from using ambiguous statements or a bunch of questions which will result in ambiguous or multiple answers.
- The Spike should be time-limited. At the end of the designated time the person should report their findings, even if they have not come to a conclusion. In this case, the findings may result in the assignment of another Spike.
Sameer Kalburgi, VP of Engineering at Fieldwire, shares how he enhanced his public speaking skills to make his presentations more compelling and engaging for a non-technical audience.
VP of Engineering at Fieldwire
Gergely Orosz, Engineering Manager at Uber, shares how he approaches building teams of leaders that are enabling people to grow faster, have more autonomy and be more motivated.
Engineering Manager at Uber
Kevin Perko, Head of Applied Research and Data Science at Scribd, discusses how he made his employee successful by helping them transition into a more suitable and challenging role.
Head of Applied Research / Data Science at Scribd
Raghavendra Iyer, Head of Engineering at ReachStack, discusses how setting up measurable goals and providing structured learning can help your employees expand their knowledge and skills.
Head of Engineering at ReachStack
Ido Cohen, Head of Product at Permutive, explains how he approaches coaching by looking at his reports as products that he tries to build.
Head of Product at Permutive
You're a great engineer.
Become a great engineering leader.
Plato (platohq.com) is the world's biggest mentorship platform for engineering managers & product managers. We've curated a community of mentors who are the tech industry's best engineering & product leaders from companies like Facebook, Lyft, Slack, Airbnb, Gusto, and more.