Back to resources

Introducing Engineering Design

Design
Team Processes

27 February, 2021

Wissam Abirached
Wissam Abirached

Senior Engineering Manager at GitHub

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

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 Productsup

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 Productsup

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

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.