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

Team Development Framework for new managers

26 June

Individual Contributors are familiar with a technical development framework that helps them with building products. Managers, especially new managers can leverage a parallel framework to help them build their teams while drawing analogies from an already familiar framework.

Building A Team
Team Processes
New Manager
Viswa Mani Kiran Peddinti

Viswa Mani Kiran Peddinti

Sr Engineering Manager at Instacart

Promoting Interdepartmental Teamwork for More Efficient Problem-Solving

13 June

Roland Fiala, Senior Vice President of Engineering at Productsup, raises an interesting issue about autonomy in teams: does it hinder collaboration opportunities that lead to better problem-solving? He shares his system for promoting teamwork in engineering departments.

Internal Communication
Collaboration
Roadmap
Team Processes
Cross-Functional Collaboration
Roland Fiala

Roland Fiala

Senior Vice President of Engineering at Usergems

How to Motivate Your Engineers to Grow in Their Careers

13 June

Roland Fiala, Senior Vice President of Engineering at Productsup, highlights the importance of soft skills and shares how he motivates his engineers to further their careers by focusing on personal growth.

Goal Setting
Different Skillsets
Handling Promotion
Personal Growth
Coaching / Training / Mentorship
Motivation
Team Processes
Career Path
Performance
Roland Fiala

Roland Fiala

Senior Vice President of Engineering at Usergems

Streamlining Product Processes After a Reorganization

16 May

Snehal Shaha, Lead Technical Program Manager at Momentive (fka SurveyMonkey), details her short-term technical strategy to unify processes among teams following an acquisition.

Acquisition / Integration
Product Team
Product
Building A Team
Leadership
Internal Communication
Collaboration
Reorganization
Strategy
Team Processes
Cross-Functional Collaboration
Snehal Shaha

Snehal Shaha

Technical Program Management at Apple Inc.

The Optimization and Organization of Large Scale Demand

4 May

Kamal Qadri, Senior Manager at FICO, drives the importance of setting expectations when optimizing large-scale requirements.

Managing Expectations
Delegate
Team Processes
Prioritization
Kamal Qadri

Kamal Qadri

Head of Software Quality Assurance at FICO