Inclusivity and debates in Engineering

Painting of sun rising behind cacti as a metaphor for thorny issues facing emerging startups

In its infancy (seed stage), a startup builds out API, Tools, and systems in a very nimble way with minimal-to-no overhead of processes. The need of the hour is speed of delivery and getting a working Proof-of-Concept out; so the emphasis is ‘getting things done quickly’ as opposed to elegantly. At this stage, elegance in software design/architecture is mostly accidental.

The startup then moves in to a Series A/B/C stage. To get to this state(s), the company needs to grow its customers and employees. A growth in the engineering organization organically leads to a process where decisions are thoughtfully made, with scale, performance, and maintainability in mind. New employees bring with them a diversity of experience. With diversity of experience comes difference of opinions. Important technical decisions which used to be made in cubicles and/or coffee shops now move on to whiteboards and conference rooms. Nuanced (and not so nuanced) debates start happening before design and architecture decisions are made and implemented.

As debates get heated, individuals with the loudest voices tend to win out and others end up being collateral damage. Disgruntlement seeps in and manifests itself in cliques, grumbles and in extreme cases, attrition. What an engineering organization does to effectively address such issues is a reflection on the company culture.

A few questions to ponder

  1. What can an organization do to provide an environment that is inclusive and voices do not get suppressed? At the same time encourage healthy debate on the merits of a technical issue?
  2. Conversely how does an organization go about implementing such a structure without falling into the ‘decision by popularity’ trap?
  3. Solving (1) & (2) would require structure and process(es). How does an organization do that without getting mired in a process bog?

What follows below is a reasonably successful strategy adopted at a company I worked at.

Architecture Team

Charter: To provide a fostering environment where engineers debate design & architecture, and arrive at decisions in a timely fashion

Principles

  1. Everyone is welcome to present
  2. Every idea is fallible, can and will be questioned
  3. Everyone has a say in the debate
  4. Debates are on the merits of the idea, not the ideator

Minutiae

  1. The architecture team met weekly to discuss and decide on proposals
  2. Teams/individuals came to the meeting to present their design/architecture proposals
  3. Anybody in the engineering organization could attend the meetings, ask questions and/or provide feedback
  4. There is a facilitator who runs these meetings and there are a select few who would vote on decisions
  5. Decisions once made are not revisited unless circumstances change drastically or there are new use-cases where some older decisions need to be re-litigated.
  6. After a decision, one of the ‘voting’ members works with the team to implement the proposal. The voting member’s role in this case is to act as a facilitator and also close the feedback loop back to the Architecture Team by providing update(s) on implementation

To prevent the discussion from ratholing, the meetings followed a structure which consisted of 6 rounds. We adapted the Holacracy approach to run these meetings

  1. Presentation round: The design/architecture proposal would be presented at the meeting with no interruptions from anyone present
  2. Clarifying round: At the end of the presentation, each member in the room (or on the phone) can ask clarifying questions on the proposal. These questions were intended to add clarity to some salient points which could be unclear or ambiguous. The presenter would respond to the questions. This round is NOT meant for back-and-forth banter or to provide opinion on the proposal.
  3. Reactions: In this round, all engineers in the room except the presenter provide their reaction to the proposal. Reactions include concerns, highlighting benefits or drawbacks. The presenter takes notes as needed acts acts as a recipient of the feedback with no response.
  4. Amend and Clarify: In this round the presenter takes the feedback into consideration and clarifies any open questions or concerns. Depending on the feedback, the presenter may amend the original proposal.
  5. Objection round: The facilitator goes around the room asking each person to answer the following question ““Do you see any reason why adopting this proposal causes harm; objection or no objection? If so please state your objections” The objection(s) leads to a discussion between the objector(s) and presenter until a logical conclusion is reached.
  6. Decision round: The facilitator then goes around the room and asks each person who has a vote to say ‘Yes’ or ‘No’ to the proposal. The votes are tallied and a ‘winner’ is declared.

Benefits of this approach

  1. There exists a structure and environment where technical proposals are debated before a decision is made.
  2. The structure minimizes the incidence of analysis-paralysis.
  3. The decision vote is not by popularity, but by select few team members.
  4. Decision Makers Panel: The decision makers are a group of 7–9 engineers who work at the company. Experience in the industry and tenure in the company varied. e.g. members of the panel were engineers 3–5 years out of college as well as folks with 10+ years of industry experience. The members are not necessarily from the ‘echelons’ of the engineering hierarchy. There was a mix of engineers from the engineering organization, professional services and Devops.
  5. Managers are not part of the decision making process. If they do turn up, they are not part of the decision makers. Their presence in the room is just for their edification and they do not have a say in the final decision.

How did we attain the goal of inclusivity?

  • Everyone has a say in the review and feedback process
  • Decision makers span across the org and not just core engineering.
  • While everyone has a say, not everyone has a vote. This ensures that the most ‘valid’ ideas are approved. We avoided the ‘popularity’ trap, and also ensured that the loudest voice did not override the other voices.
  • Each team had a representative on the decision makers’ panel. This gave uniform representation and a lower chance of bias.
  • We had a policy in place where we rotated engineers on the decision makers’ panel. This gave us diversity of opinions over a large swath of time.

This approach was not a silver bullet and did have its shortcomings

Many engineers disliked the idea of limited voters. They wanted a more democratic process, which was an antithesis to the purpose of the Architecture team’s formation. Given time and the rotation policy, this resistance could have been overcome.

The idea of a structured meeting was unpalatable to some because it stifled free flowing discussion. The purpose of the structure was to avoid the infinite discussion without decisions. This was, and is a challenging hurdle to overcome.

Engineers did not like the overhead of an approval process, partly because of the implicit accountability and partly because the process seemingly slowed down the pace of innovation

We ran out of time to fine-tune the process

Inclusivity and healthy technical debates for engineers are at the heart of company’s culture of innovation. Abandon the diversity of voices and the resulting homogeneity could end up stifling innovation.

--

--

--

Views expressed on this blog are solely mine and not those of employers, past or present.

Love podcasts or audiobooks? Learn on the go with our new app.

Recommended from Medium

Big Brother by Undefined Variables — eMAG Hackathon 2017 Best Hack Award

Why do you suck at hacking? (Underrated)

How to send a blank message.

Serverless framework — Building Web App using AWS Lambda, Amazon API Gateway, S3, DynamoDB and…

Introducing Flutter Text Helpers

Designing to Patterns: A Pythonic Example

Unity: Implementing Dark mode

Asset Protection Law

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Kartik Lakshminarayanan

Kartik Lakshminarayanan

Views expressed on this blog are solely mine and not those of employers, past or present.

More from Medium

Aviation in Software Engineering: Aviate, Navigate, Communicate

Cross-team Product Development & Delivery Process: Discovery Phase.(Part 4)

How Use Cases Help You Define Software Requirements

The Elephant in the Room