How to Develop an Engineering Working Agreement

Problem

At my previous job, I experienced a growing frustration due to misalignment of how things were done. Everything was implicit and undocumented, with assumptions dictating the course of action. There were de facto solutions that were in the heads of the veteran members of the team. That particularly affected new engineers who were perplexed by the implied ways of doing things. The confusion served neither business nor the team well.

Through one-on-ones I was having with my team, I learned how distressed they were by the existing situation. They were either receiving mixed messages on how to do things depending on who they would ask or left without an answer on how to handle some situations. I felt that developing an engineering working agreement would be a good solution to level set on the expectations for how we wanted the team to operate and perform as a great engineering team.

Actions taken

I kicked off the process by serious deliberation on how I could get people to commit to a nascent engineering working agreement. I started compiling the document. I did an outline and then started to add answers with my own expectations. As I was doing it, I was becoming increasingly aware that my initial approach was not going to work. I couldn’t dictate to people how they should operate. Especially not by imposing on them a document I drafted based on my own expectations. For the agreement to accomplish the desired result, we all had to commit together.

I retained the outline and removed all of my answers. I had that same outline serve as talking points for a team-wide discussion. Though I was fleshing out the document aside, it was only to make recommendations to the team. I shared the outline with the team and scheduled a time to meet together and walk them through the document. Everyone was granted access to make changes as they saw fit. We had five 90 minute sessions over a couple of months and we talked through each of the topics in the document -- how we operate, what our development workflow should look like, what is the expected behavior, how we communicate, etc. Another important topic was team values that we should align on, which would help us steer in the right direction.

After we established and committed the first version of our agreement, we met quarterly to review and iterate on the document. Before every upcoming round of discussion, I would re-share the link for the document encouraging people to prepare for the discussion on specific topics and have their input ready. During those quarterly meetings, people would open the document, switch to the suggesting mode, and add their input for the first 30 minutes. Then for the next 60 minutes, we would talk through each of those suggestions, and I was proud of how it became incredibly collaborative and truly democratic: everyone had a voice, and everyone spoke up.

As a result, people felt much more engaged with the team and more comfortable with what the expectations were. The whole process also made sure their voices were heard, and the document became a place where frustrations or friction could be handled constructively, manifesting camaraderie instead of resentment. They would hold each other to the same standards, which also enhanced team cohesion. The fact that the whole process was participative and that we did it as a team (as opposed to me imposing my proposal) strengthened their ownership of the process. That also mattered a great deal to me as I perceived myself as a fellow engineer surrounded by other engineers, primus inter pares. I had responsibility as their leader for the health and success of the team, but in engineering matters, I considered myself their peer.

Lessons learned

• Don’t dictate to people what and how they should commit. Being directive and imposing your ideas seldom results in commitment and willingness to embrace the imposed proposal. To ensure commitment, rather than telling people what to do, show them how things could be done. Help them find what great looks like and see why commitment is critical to success.
• Encouraging people to take ownership over processes, or more precisely, to take ownership over how the team operates is essential. We, as managers, can’t be present at every conversation taking place or at every decision-making process. We have to empower people on the team to take ownership, but as managers, we are responsible for providing them with guidelines and context that help them make sound judgments.