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? 

Back to resources

Introducing Engineering Design

Team processes
Design

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

Collaborating With a Cross-Functional Expert
17 June

Rafal Leszczynski, Engineering Manager at Auth0, relied on the help of an assigned expert from the security team to provide context to them as developments emerged and problems arose.

Cross-functional collaboration
Dev Processes
Internal Communication
Team processes
Rafal Leszczynski

Rafal Leszczynski

Engineering Manager at Auth0

Promoting With a Career Ladder
17 June

Heiko Reintsch, Head of Product at GetYourGuide, uses his company’s career ladder to model the behavior of the ideal candidate for promotion.

Handling Promotion
Coaching / Training / Mentorship
Team processes
Career Path
Heiko Reintsch

Heiko Reintsch

Head of Product at GetYourGuide

How Context Evolves as You Advance as a Manager
17 June

Heiko Reintsch, Head of Product at GetYourGuide, bears witness to the unifying power that a comprehensive, company-wide vision has over a large team of individual contributors.

Product Team
Collaboration
Sharing the vision
Team processes
Heiko Reintsch

Heiko Reintsch

Head of Product at GetYourGuide

Testing, Learning, and Improving: Building a Successful System Progressively
17 June

Rohan Kulkarni, Engineering Manager at Expedia, shares his first significant triumph implementing a new system of cross-functional cooperation across an entire organization, testing, learning, and improving over the course of three quarters.

Collaboration
Team processes
Rohan Kulkarni

Rohan Kulkarni

Sr Engineering Manager at Expedia

The Benefits of an Agile Working Environment
2 June

Anupam Singhal, Director of Data Science at Workday, witnessed the transition between past and future first-hand as his company adopted a policy of Agility, just as the trend began to take off in Silicon Valley.

Company Culture
Team processes
Agile / Scrum
Anupam Singhal

Anupam Singhal

Engineering Manager at Snapdocs

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.