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
Kirk Gray, VP of Engineering at McGraw-Hill, recalls his experiences performing major reorganizations of departments, including successful techniques to ensure a smooth transition.
VP Engineering at McGraw Hill
James Andrew (Andy) Vaughn, Principal Technical Product Manager at AppFolio, speaks on the mutually beneficial partnership between product managers and engineering leadership and its relation to a harmonious product development organization.
James (Andy) Vaughn
Principal Technical Product Manager at AppFolio
Andrew Tsui, Product Leader at Sailthru, recalls his opportunity to navigate a tricky user-and-business problem by leveraging a new platform to simultaneously optimize SEO content and sustain advertising inventory for a media business.
Director of Product at Startup
Mu Qiao, Senior Engineering Manager at Teladoc Health, was able to provide other departments with context from his engineers by dividing their efforts and conquering with a cross-functional model of collaboration.
Sr Engineering Manager at Teladoc Health
Jennifer Agerton, VP of Product at letgo, reflects on her efforts to scale up a product team and set it up for success through a threefold action of introducing a new structure, new roles, and new ways of working.
Chief Product Officer at AirHelp
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.