Handling a Mistake - Adopting a New Workflow
6 July, 2020
My company was acquired and our business was going to move over to Berlin by the middle of the year. After the acquisition the new business asked us to adopt a new workflow. I (and another engineering leader) verbally agreed, not quite understanding what exactly we were signing up for. I didn’t think much of it, knowing that we only had three months left before our positions were dissolved, so I went along with it. I simply agreed to adapt to the new process without reflecting on what the consequences might be. Besides, we thought, how hard could it be? This was obviously a mistake on my part.
When asked to switch processes we were working with global Sprints - one Sprint across multiple organizations placed in different time zones. Given these circumstances it was hard to do Sprint planning, kickoff activities, and Sprint closure due to the time differences. All of the organizations were working on different things.
Another issue with the Sprints was that the new workflow was designed for commitment and a delivery for each Sprint. The contractors we were working with would take five tasks, commit to those five, give them priority, and have them done by the end of the Sprint. On the other hand, our organization would pick up as much as we possibly could to deliver in a Sprint, even if that meant having incomplete development by the end of the Sprint. Therefore, we had two contrasting opinions about conservative delivery commitment based.
The solution to these differing global Sprint processes was to create collocated based Sprints. Each location had its own Sprint and method for Sprint processes and all activities in that Sprint would happen within an organization, within a single time zone. All of a sudden there was no overlap and everybody was happy.
A second consequence due to the adaption of a new workflow was that the workflow itself was very difficult. It contained 14 steps including planning, backlog, commitment, spec, and more. Hence, even if you wanted to reject a ticket you had to click 10 times to get it through. This resulted in a lot of noise and chaos in our existing seamless Sprint activities. Needless to say productivity and morale suffered as well. As a leader, it's important to listen to feedback, especially when you make org-wide changes.
So we went back to the whiteboard and condensed the 14 steps down to 7 - backlog, committed, in progress, blocked, under review, ready to release, and closed. Simple, to the point, and everything else was only one or two steps away, instead of 10. It was an easy transition for the team because it was more familiar, since it's similar to what we had before, resulting in a boost in morale and productivity.
- As a VP of Engineering there is the notion that I am thorough and don’t make mistakes. However, I’m only human and I actually make mistakes all the time. I’m not perfect nor do I pretend to be. Once I’ve realized I made a mistake, I will own up to it and take the necessary steps to course correct. Ignoring mistakes is not an option.
- No matter how tired you are, even if you know that your job is going to end in a few months, don’t take anything for granted and always try to make time to vet new adaptations. Trying “to deal” with something will only make matters worse, impacting the morale and productivity of the team.
Lloyd Holman, Head of Engineering at By Miles, explains why documentation is essential for any company to achieve excellence, particularly underlining its importance in onboarding new engineers.
Head Of Engineering at By Miles
Arun Krishnaswamy, Director of Data Science at Workday, describes how to build a data science team emphasizing the difference between software development lifecycle and data science methodology.
Director at Workday
Shyam Prabhakar, Engineering Manager at Stitch Fix, explains how design sprints helped him fix problems caused by the lack of sufficient research and overall improve his company’s products.
Engineering Manager at Stitch Fix
Shyam Prabhakar, Engineering Manager at Stitch Fix, recalls how only one experience sharing a session with peers from another company profoundly transformed his team and led them to the path of innovation.
Engineering Manager at Stitch Fix
Shridharan Muthu, VP of Engineering at Zoosk, describes how to make communication effective between PMs and engineers when they are located in different time zones and have very little overlap.
VP of Engineering, Backend Applications at Zoosk
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.