Plato

Login to Plato


This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Don't have an account? 

Introducing Engineering Design

Design
Team processes

27 February, 2021

Wissam Abirached, Senior Engineering Manager at GitHub, shares how he introduced engineering design and what were its most immediate benefits.

Problem

I was managing a team that was churning a lot to push features out. Engineers would work hard to write their code and send it for review at the pull request stage of the development cycle. Following that, engineers would get feedback that would require them to go back and spend a lot of time making changes.
 

The problem was that they were getting feedback too late in the process to incorporate it, and going back to work on changes was undoubtedly hurting us immensely. Getting feedback that late is the most costly spot in the development cycle -- after engineers had finished writing code -- to make big changes. Engineers giving the feedback did not enjoy putting the team in this difficult spot. Engineers receiving the feedback were frustrated at how late it was coming. We were slow and not able to meet our goals.
 

Actions taken

After having a series of conversations with engineers on the team, I decided to introduce a new step in our development cycle -- engineering design. It was one of the first steps in the process; once they would grab a ticket, they would have to go through engineering design. Engineers would have to write down the approach they would take or schedule a call in some instances. If they would be working on something more complex, they would schedule a 30-minute call with other engineers on the team. The team was able to provide feedback before a single line of code was written. Feedback received during that phase in the process wouldn’t be disruptive and wouldn’t require them to change their entire approach.
 

I presented the new process to the team. I created a document with screenshots of our current sprint process (picking a ticket, writing a code, and doing a code review). I edited that by adding and highlighting a new column -- engineering design. I also outlined all the benefits I thought the new process would provide.
 

I was expecting a lot of pushback from the team for adding a new process. I tried to frame the benefits and to highlight that, although they would have one more process to go through, ultimately the whole cycle time would be shorter, and they would be spending less time on a ticket.
 

I also compiled a document on what a good engineering design should look like and what different formats it could take. They could either write down their approach in a ticket, describing different solutions and explaining why they decided to go with a specific solution. If it is a more complex problem, they should book a 30-minute meeting to which they should come prepared and not use it as an occasion to brainstorm with others. I instructed them to think about a problem in advance, write their solution down and present it in the meeting.
 

Also, my guidelines highlighted that this was a time-boxed effort and that no one should spend more than a certain amount of time on it because our goal was to be more efficient, not to add one more process. I also clarified which tickets or work items could skip engineering design, like a bug reported by a customer that would take an hour to fix.
 

The team was initially fairly skeptical. It was a new process they never heard of or tried before. But more importantly, they were skeptical if the feedback received so early in the process would be valuable at all. I did some convincing in one-on-ones, reassuring them that I tried this in the past and it was immensely beneficial. I also told them that my proposal was still on trial; we would try it out for two or three months and check-in during a team’s retrospective to identify the benefits and see if we would continue implementing it. That helped alleviate most of their concerns, but some skepticism remained.
 

As a result of introducing engineering design, we increased our original velocity, were shipping much faster, our code was of better quality, morale and happiness on the team went up, and collaboration culture improved.
 

Lessons learned

  • Be attentive to your team. Listen to the complaints and frustration your engineers are living through. I heard some of their complaints in one-on-ones, and though I was not heavily involved in the PR process, I could see how it was impacting our velocity. Piece together their concerns, seek patterns, and then act.
  • Try to approach problems creatively or look at different companies that were troubled by the same problems. Don’t be afraid of introducing new things. Many people are wary of introducing new processes because engineers tend to oppose any new process as such, but if you are confident about the results, do your best to get them on board.

Discover Plato

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


Related stories

Acting Quickly To Resolve an Incident
9 April

Leo Torres, Engineering Manager at Carta, speaks of his prompt response to a recent incident and how acting quickly allowed him to make a customer happy.

Team processes
Collaboration
Leadership
Leo Torres

Leo Torres

Engineering Manager at Carta

Pausing for Innovation
31 March

Arjita Ghosh, Director of Engineering at Quizlet, shares how intentional pausing can instigate innovation and boost productivity.

Team processes
Productivity
Arjita Ghosh

Arjita Ghosh

Director of Engineering at Quizlet

Shipping Products Faster with Confidence
26 March

Ian Logan, VP of Engineering at Rose Rocket, explains why the speed of execution is critical for finding a product-market fit and highlights how to build confidence when shipping fast.

Dev Processes
Team processes
Ian Logan

Ian Logan

VP Engineering at Rose Rocket

Leading Post-Acquisition
26 March

Ian Logan, VP of Engineering at Rose Rocket, shares what it takes to make a successful acquisition of engineering organizations.

Leadership
Changing company
Team processes
Ian Logan

Ian Logan

VP Engineering at Rose Rocket

How to Balance the Continual Proliferation of Ideas With Limited Resources
26 March

Jérôme Basdevant, CTO and Co-founder of Datamaran, talks of his efforts to balance his continual proliferation of new ideas with his startup’s limited resources.

Team processes
Jérôme Basdevant

Jérôme Basdevant

CTO and Cofounder at Datamaran

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.