Back to resources

Organizing Engineering To Optimize Performance

Different Skillsets
Dev Processes
Collaboration
Reorganization
Cross-Functional Collaboration

11 May, 2020

Peter Maddison
Peter Maddison

Founder at Xodiac Inc.

Peter Maddison, founder at Xodiac, tells the story about how he orchestrated a major organizational change within engineering. The goal of the change was to improve the way they received incoming work while creating some other beneficial changes in the process. He learned about DevOps in his journey and how it would be a powerful way to change his organization.

Problem

We were having a problem that required a major organizational change. The department had about 70 people, half of whom worked for me. We had tickets come in and bounce around the department until they eventually found their way to the right person to get it done. Our customers, other parts of the organization primarily, were not happy with the response time.

I realized it would be ideal to find a better way to organize around the work, starting with the way we sorted the tickets. I created a new org chart based on the services we provided.

Before proceeding with such a radical change, I did some research and ensured we had the right backing and an understanding of whether the proposal would work. This introduced me to a number of other concepts that led us down a path to success.

Actions taken

I attended a conference and ended up having breakfast with George Spafford, one of the authors of The Phoenix Project, a book about DevOps that talked to a lot of the problems I was looking to solve. The recommendation to read this book was more or less my introduction to DevOps, although it turned out to be a label for my approach to work and a lot of my career. I now had a name to put to what I was looking to do within my organization.

The Phoenix Project is more or less the de facto book on DevOps. Ironically, it does not tell you how to implement DevOps. It is an extraordinary story that does not give you a systematic approach to implementing DevOps. The book talks about the pains of being in infrastructure and operations and the agony we have to deal with at times.

This gave me the impetus and backing to implement the practices described into our organization. We did this through two major activities, described below.

One was adopting the Kanban as a methodology for organizing and identifying what the different classes of service were within the department.

I ordered some massive whiteboards that we put all across one side of the walls. We started to map out the necessary components. It was helpful to have something visible to look at so we could see what we were doing. We asked questions like, "What other services people are coming to ask us for?"

Two was going back to my org chart to create a better flow for incoming work through the different areas. We took the department, split it up into different areas. We focused on the delivery of the particular capability out of that area versus focusing on the individual discipline. We decided to create project teams that had the capability of delivering across functions for incoming tickets.

I spent about six to nine months setting everything up, communicating it, and getting all of the teams on board with what was to happen. We ran planning meetings to co-create the target state and change plan with the teams.

The reorganization went live, and we started to reap some of the benefits of the new structure. I could start to measure and collect metrics to analyze. We could ask questions like:

  • How long is it taking us to get these done?
  • Are we improving?
  • How is that going over time?

These metrics and questions helped us build out and get a better understanding of the types of work assigned to us, which allowed us to make some incremental improvements.

Lessons learned

  • Part of my role was going out and talking to the other areas of the organization, making sure they knew how to engage with us. Overall, it helped us start to move many of these pieces forward and start to create capabilities that would then enable the rest of the organization to move fast.

  • Leading up to the go-live date, we had this sense of urgency to create the changes within the organization, but you also have to follow through to sustain the change. We did not do what was necessary to do that. We had to come back together and solve the problems caused by some of the potholes we hit after we thought everything was set and good to go. Despite this, we got it running again, but it may have been a smoother process if we had been aware of the potential problems of not monitoring after we launched.

  • Another piece was learning the importance of looking after the people and involving them in the change. I learned a lot about organizational dynamics, how teams form and how teams work together. Creating a safe space for specialists to voice their concerns was critical. Getting those specialists to work together differently requires a lot of involvement, and making sure that they have a space that they feel comfortable.

Discover Plato

Scale your coaching effort for your engineering and product teams
Develop yourself to become a stronger engineering / product leader


Related stories

From Big Tech to Startup: Adding Value From Day 1

19 January

Angel Jamie, Chief Product Officer at Yayzy, recalls his transition from a well-established tech company to a sustainability startup, and the major differences he experienced.

Dev Processes
Company Culture
Impact
Team Processes
Cross-Functional Collaboration
Changing Company
Career Path
Performance
Angel Jaime

Angel Jaime

CPO at yayzy

Should You Stay Up to Date with Technical Skills As a Product Manager?

19 January

Nani Nitinavakorn, the Sr Product Owner at Revolut, describes how she keeps learning hard skills to increase motivation and respect her team.

Alignment
Innovation / Experiment
Different Skillsets
Personal Growth
Ownership
Coaching / Training / Mentorship
New PM
New Manager
Nani Nitinavakorn

Nani Nitinavakorn

Sr Product Owner at Revolut

Change Management in Engineering Organization

18 January

Joëlle Gernez, Vice President, Engineering at Pinger, shares how she collaborated her engineering team with the designers to bring about a change in the processes.

Architecture
Deadlines
Collaboration
Cross-Functional Collaboration
Joëlle Gernez

Joëlle Gernez

Vice President, Engineering at Pinger

The Role of Testing in the Engineering Product Development Process

18 January

Joëlle Gernez, Vice President, Engineering at Pinger, shares how diligently she made the existing developers a part of the testing process instead of bringing in new hires.

QA Team
Collaboration
Cross-Functional Collaboration
Joëlle Gernez

Joëlle Gernez

Vice President, Engineering at Pinger

Navigating Unexpected Cultural Differences

18 January

Markus Aeugle, VP Engineering at Doctolib, shares how he succeeded as an inclusive leader by helping his team navigate through the various cultural differences.

Building A Team
Company Culture
Diversity
Collaboration
Cultural Differences
Markus Aeugle

Markus Aeugle

VP Engineering at Doctolib

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.