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
Is it possible to be too empathetic? If you overdo it, it can be an energy sucker.
Delivery & Operations / Digital Transformation / Innovation at Marais Consulting Inc
3 ways leaders can cultivate relationships that lead to better products.
SVP Global Customer Experience at Salesforce
Oftentimes Engineers work in silos, developing products to specified requirements, while they remain disconnected from the most important of questions - "WHY are we building this?" We'll explore the consequences of this mindset, as well as how to connect your Engineers to the larger Company Vision.
VP of Engineering at ExecThread
Passing for promotion happens to everyone in their career lifespan. If someone does not had to go through the situation, consider them they are unique and blessed. Managing disappointment and handling situations in professional setting when things don’t pan out, is an important life skill.
Senior Software Engineering Manager at Anaplan
Recruiting and retaining good staff is amongst the top challenges for every business. There is a world where it's not always expensive, doesn't take an age, reduces lead times and actively contributes to the in-situ teams growth.
Chief Technology and Product Officer at Hive Learning