Did you know that in 1904, the John E. Hurst & Company building in Baltimore Maryland broke out in flames? It consumed the entire building and began to spread to others causing what is now known as “The Great Baltimore Fire.”
Firefighters from the DC, New York, and Philadelphia areas responded to the fire but were unable to control it. This is because the fire took place before city safety standards had been created. There were no fire hydrants in the area. So despite the extra help, with no water, they were all but useless.
The fire burned for 30 hours and destroyed over 2,500 office buildings and homes before it was finally put out. Not long after, cities started creating safety standards that prevented this type of destruction in the future. Standards are important because they can sometimes save us in a fire. Both the physical and metaphorical ones.
This segues nicely into my main topic, creating team standards to avoid the metaphorical “office fires.”
I recently went through a team exercise to build out a set of standards. I wanted everyone to create the standard together but not fall into the trap of design by committee, which admittedly was a difficult balance to find. Below is the process I came up with to manage this dilemma.
The creation of team standards was actually something that the team wanted. At the beginning of the year, I worked with my group to determine three themed goals. It was an exercise facilitated by me but lead entirely by my team. Dozens of ideas were discussed, and it was discovered that a unified standard was unanimously voted on as a high enough priority to include into our year plan.
Now that my team decided on the direction, it was now up to me to make sure they were put in a position to be successful. I needed to make sure that Standards Creation was a priority by gaving time, focus, and guidance through the process. I wanted to create a recipe for success that we could use while developing standards into the future.
I did this by doing a couple of things:
- They chose the goal, so I made it official – I wanted to reinforce that everyone needs to be involved in the creation of standards. I assured them that for this to work, we would need to come together and form something that we could all get behind. I explicitly created a goal for every team member and included it on their annual HR forms. The goal described in detail my expectations for participation and development. I wanted it to be official to make sure it didn’t slip through the cracks or get reprioritized, as so many internal efforts do.
- I made everyone responsible but one person accountable – Because I wanted this to be a group effort, I made everyone on my team responsible for the success of these standards. But to make progress, there needed to be someone moving us along the path to success, and it shouldn’t be me. As I said, I look at my position as one of tapping into someone’s ability to be successful, not doing it for them. Therefore, I assigned someone to be accountable for the creation of a particular standard. They were responsible for organizing meetings, keeping track of questions that needed to be answered, and delegating writing duties (even to me) when they saw fit. I too was responsible for the success.
- I made myself clear on the arguments I wanted – When a meeting was set up, the person accountable for the project would send out topics ahead of time. I just required the team to come prepared to discuss. I asked that language be used in an objective manner. I explained that phrases like “I like doing it this way” or “this is how we have always done it” should only be used as a single bullet point and not the main argument. Because of this, each conversation was meaningful and near emotion free.
- This is not a democracy; I made the final call – I was walking a fine line with this tactic. Design by committee can be unproductive. Sometimes the best advice can be overlooked due to the group trying to compromise with one another. That’s where I came in. If there was a compelling argument to be made, even if it wasn’t the majority, it was always an option. I made sure to keep perspective on what’s best for the company when the team may be overlooking some key facts. This was not a frequent occurrence, but there were a few decisions that had to be made when it wasn’t part of the majority.
As a team, we were able to achieve success with this method with very few lessons learned moments. We created a recipe for success that we will be able to rinse and reuse. The one thing I would prepare you for is when a developer says “I want to have better team standards,” that they really mean “I want the team to standardize around how I do things.” This is a conflict area that you may have to navigate through, and it also may come as a morale hit when pushing through the process. However, if you prepare yourself for this eventuality, and make sure you are clear with the “why” of every decision, you should navigate it just fine.
I hope you enjoyed the read and good luck with implementing this yourself. If you have any questions for me or if you have your process you would like to share, please leave a comment below (or connect with me).