Loading...

From Chaos to Structure on the Operations Team

Vladimir Baranov

CIO/COO at SCOUT Space Inc

Loading...

Problem

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.

Actions taken

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.

Lessons learned

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

Be notified about next articles from Vladimir Baranov

Vladimir Baranov

CIO/COO at SCOUT Space Inc


Leadership DevelopmentCommunicationOrganizational StrategyEngineering ManagementPerformance MetricsFeedback TechniquesCareer GrowthSkill DevelopmentRoles & TitlesTeam & Project Management

Connect and Learn with the Best Eng Leaders

We will send you a weekly newsletter with new mentors, circles, peer groups, content, webinars,bounties and free events.


Product

HomeCircles1-on-1 MentorshipBountiesBecome a mentor

© 2024 Plato. All rights reserved

LoginSign up