Introducing Engineering Design
27 February, 2021
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.
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.
- 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.
Scale your coaching effort for your engineering and product teams
Develop yourself to become a stronger engineering / product leader
Ben Picolo, Engineering Manager at PolicyGenius Inc., uncovers some of the most critical aspects of preparing interviews for engineering positions.
Engineering Manager at PolicyGenius Inc.
Ben Picolo, Engineering Manager at PolicyGenius Inc., shares how together with his team, they gamified the whole technical debt solving process.
Engineering Manager at PolicyGenius Inc.
Arpan Dalal, Sr. Director Engineering at RepairPal, explains how to make the delivery faster by improving critical processes.
Sr. Director Engineering at RepairPal
Michael Scotto, Director of Quality Assurance at Niche, shares how he established a new functional role by formally separating automated and manual testing, and the benefit provided by giving his team the space to specialize as the company scaled.
Director of Quality Assurance at Niche.com
Gaurav Sharma, Engineering Manager at GlobalLogic, shares how he increased time on coordination activities and meetings to alleviate the pressure of remote work.
Engineering Manager at GlobalLogic
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.