Organizing Engineering To Optimize Performance

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.