Plato Elevate Winter Summit has been announced (Dec 7th-8th)

🔥

Back to resources

How to Develop an Engineering Working Agreement

Team Processes

5 May, 2021

Alex Khadiwala
Alex Khadiwala

Head of Engineering at InsurGrid

Alex Khadiwala, Head of Engineering at InsurGrid, speaks of his efforts to develop an engineering working agreement and how the participative nature of the process can ensure commitment.

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.

Discover Plato

Scale your coaching effort for your engineering and product teams
Develop yourself to become a stronger engineering / product leader


Related stories

Building a New Team in a Foreign Country

23 November

Adam Hawkins, Site Reliability Engineer at Skillshare, went all the way across the world to build a brand new team who worked very differently than he was used to.

Team Processes
Adam Hawkins

Adam Hawkins

Site Reliability Engineer at Skillshare

What It Takes to Understand Other’s Perspective

23 November

Nicholas Cheever, Divisional Vice President, Global Supply Chain Technology at Trimble Transportation, shares how to really understand someone else’s point of view.

Team Processes
Nicholas Cheever

Nicholas Cheever

Divisional Vice President, Global Supply Chain Technology at Trimble Transportation

How to Handle Team Collaboration After a Merger?

23 November

Nicholas Cheever, Divisional Vice President, Global Supply Chain Technology at Trimble Transportation, shares how he helped the acquired company’s team members understand the business mission and give them focus.

Acquisition / Integration
Team Processes
Nicholas Cheever

Nicholas Cheever

Divisional Vice President, Global Supply Chain Technology at Trimble Transportation

Surefire Ways to Boost Team Morale

11 November

Rajesh Agarwal, VP & Head of Engineering at Syncro, talks about effective ways to boost team morale when stepping in as a new manager in the team.

Motivation
Team Processes
Rajesh Agarwal

Rajesh Agarwal

VP and Head of Engineering at Syncro

How an Empathetic Approach Can Solve Problems

10 November

Han Wang, Director of Engineering at Sonder Inc., shares how he changed a manager’s viewpoint for achieving better results and improved team coordination.

Goal Setting
Personal Growth
Leadership
Coaching / Training / Mentorship
Team Processes
Han Wang

Han Wang

Director of Engineering at Sonder Inc

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.