From Chaos to Structure on the Operations Team
13 March, 2021
At my previous job, I was assigned a team that was malfunctioning and had a reputation of not being able to do much work. Nothing would ever come out of it, and when it did, it was incomplete. Engineers were rarely available to answer questions, documentation was poor and it was hard to figure out what the team was working on. It didn’t come as a surprise when my CEO asked me if I could help them improve their operations.
I started off by jumping into their Scrum calls and participating in their discussions and planning meetings, just to get the feel of what they were going through the day-to-day. It didn’t take me much to discover that the team was using different ticketing systems, which meant that they didn’t have a single pane of operations. Thus the team could not see the progress of their tickets or catch up on the tickets that might fall through the cracks.
I also noticed a lot of frustration and burnout nearing exhaustion. Most of the work went to a small group of people while others waited for them to finish it up. A number of people didn’t have the skills needed to tackle the problems the team had to deal with and didn’t have the time to be trained to improve their skills. I also identified the overlap of responsibilities and where cross-training was required for different team members. I made sure that each individual would have an opportunity to follow a training program and enhance their cross-functional competencies. This reflected a lack of guidance, and the team’s primary leaders were profoundly embroiled in the problems the team found itself in.
I decided to isolate the support and project work on the team so that people who did support didn’t have to do projects and could remain in the reactive mode, while people who worked on the projects were not distracted by the support work. I set up a rotation for those individuals who were on the support team, and instead of being on support all the time, I set up a weekly rotation. The same person who did support was also on PagerDuty calls in case that something would go wrong.
Furthermore, I identified roles and responsibilities for each and every individual on the team and discerned what we needed as a team in terms of skills and competencies. Anyone who was on support was responsible for resolving short tickets immediately and assigning more complex tickets to people working on projects. We also started creating runbooks for anything we needed to do, from providing access to resolving quick permission issues. That allowed us to automate most processes and enable juniors who recently joined to follow the procedures with ease.
As things started to roll more smoothly, we started to organize things from the prioritization perspective. We initiated weekly conversations with external stakeholders to learn more and adjust their expectations. When they needed something from us -- depending on the scope of a task, current resource allocation, and the company goals -- we would do prioritization and communicate what possible timeline for the execution could look like and what kind of their participation would be necessary for us to deliver on time. We would also explain how they could check-in and track the progress, which quieted some of the noise coming from the outside.
Following up on that, we established standard SLAs for our support tasks. More complex projects were negotiable, but with smaller tasks (for example, access or permissions), we set short timelines, and the team was clearly instructed how to hit them.
Finally, I established healthy hours for operations. Some people were doing 14 or 16 hours shifts, and that reflected on their well-being. We had to communicate our decision to external stakeholders and make sure they were aware of our availability of resources. Most were quite flexible to adjust their working hours to support the well-being of our engineers.
- Take time to assess the situation before rushing to take any actions.
- Spend at least an hour with each member of the team before the first draft of the situation analysis is completed.
- Communicate to the outside world that the change is coming and ask for patience.
- Align team celebrations with meaningful milestone deliveries.
Scale your coaching effort for your engineering and product teams
Develop yourself to become a stronger engineering / product leader
Snehal Shaha, Lead Technical Program Manager at Momentive (fka SurveyMonkey), details her short-term technical strategy to unify processes among teams following an acquisition.
Senior EPM/TPM at Apple Inc.
Christophe Broult, Director of Test Engineering at diconium, focuses on how he scaled his team while building organization and management teams in place.
Director Test Engineering at diconium
Sangeeta Wakhale, Senior Manager Engineering at athenahealth, talks about the space she had created between her work and family life, balancing time between the two that enabled her to pursue her dreams.
Senior Manager Engineering at athenahealth
We doubled the Engineering team from 54 to 109 full-time employees. We expanded our team footprint to include: Brazil, Portugal, and the US. We evolved our road mapping and planning processes from two Product squads to eight Product squads, in alignment with PM areas of ownership.
SVP Engineering at Trustly Group AB
Jason De Oliveira, CTO for more than 10 years, shares his experience completing a reorganization, implementing agile, and collaborating with multiple teams.
Jason De Oliveira
CTO at Vialink
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.