In this article, we'll share some tips and best practices to successfully get buy-in from your team. At Haystack, we've helped countless companies adopt delivery metrics and have seen the good, bad, and ugly.
First Step: Getting Buy-In
The first hurdle is always getting buy-in from our team. Getting team buy-in is dependent on how well they understand the purpose of measuring - and how much they trust you.
Unfortunately, metrics like Lines of Code have been used in the past to judge individuals and erode trust so it's normal to be met with a bit of skepticism.
Don't let that deter you. We've come a long way from the days of lines of code and with clear intentions and a solid plan - we can introduce metrics and strengthen team trust and culture.
To successfully convince your team, you must have:
- An Obvious Purpose For The Metrics
- Solid Reasoning For The Outcomes You Seek
Be prepared to answer the following questions:
- Why do we need metrics?
- What are we going to measure?
- Who will have access to these metrics?
- Why did we pick these metrics, and which others could we have chosen?
- What is our plan to move these metrics forward?
- How will these metrics impact individuals?
The primary thing to keep in mind is trust.
Your team should understand your use cases and intent. They should trust they will not be judged by these metrics or evaluated on an individual basis in any way. Metrics should be used to empower the team, make the change, and ultimately improve the developer experience.
Data should always be used to help the team, not hurt it. This should be made completely and utterly clear to each and every member of the team.
You don't need to know all the answers just yet. It's okay if you don't.
For metrics to be successful, you just need the team to trust your intentions and embrace the strategy presented to them.
Need Some Inspiration?
If you need some inspiration on how to present your use cases and intent to your team, then here is an excellent example.
Juan Pablo Buriticá (VP of Engineering, Splice) wrote a proposal for his team that outlined his thinking in the form of an RFC. From there, his team helped iron out the details that weren't clear and make it more robust through their questions.