login


Google Sign inLinkedIn Sign in

Don't have an account? 

Handling a Mistake - Adopting a New Workflow

Team processes
Agile / Scrum
Collaboration

6 July, 2020

Shridharan Muthu, VP of Engineering at Zoosk, describes how he quickly agreed to adopt new workflows, a mistake he later regretted, and how he handled the situation by spending the time to course correct and taking a stab at making things easier for his team.

Problem

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.
 

Actions taken

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.
 

Lessons learned

  • 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.

Related stories

The Power of Documentation Seen Through the Lens of a Manager
2 August

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.

Onboarding
Internal Communication
Collaboration
Lloyd Holman

Lloyd Holman

Head Of Engineering at By Miles

Building an Efficient Data Science Team While Still Being Agile
28 July

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.

Agile / Scrum
Data team
Arun Krishnaswamy

Arun Krishnaswamy

Director at Workday

Use Design Sprints to Improve Your Product
17 July

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.

Agile / Scrum
Productivity
Shyam Prabhakar

Shyam Prabhakar

Engineering Manager at Stitch Fix

How to Spark Innovation in Your Team
17 July

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.

Collaboration
Motivation
Shyam Prabhakar

Shyam Prabhakar

Engineering Manager at Stitch Fix

Improving Collaboration Between Engineering and Product Across Time Zones
6 July

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.

Collaboration
Internal Communication
Reorganization
Remote
Shridharan Muthu

Shridharan Muthu

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.