login


Google Sign inLinkedIn Sign in

Don't have an account? 

Organizing Engineering To Optimize Performance

Cross-functional collaboration
Different Skillsets
Dev Processes
Collaboration
Reorganization

11 May, 2020

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.


Related stories

Some Ideas for Breaking Down Silos In Your Organization
30 June

Jeff Foster, Head of Product Engineering, shares how he managed to break down silos in his organization by encouraging their employees to choose their own team.

Team reaction
Managing Expectations
Company Culture
Internal Communication
Collaboration
Productivity
Reorganization
Jeff Foster

Jeff Foster

Head of Product Engineering at Redgate

Recruitment and Interview Rotas: the Engineers’ Way
30 June

Jeff Foster, Head of Product Engineering, explains how engineers at his organization self-managed their taking part in the interviewing process.

Hiring
Collaboration
Jeff Foster

Jeff Foster

Head of Product Engineering at Redgate

Some Useful Tips for Decoupling Releases and Deployments
30 June

Pierre Bergamin, VP of Engineering at Assignar, outlines some useful tips for decoupling releases from deployment and increasing deployments by a huge factor, speeding up reverts and planning releases in a better way.

Agile / Scrum
Dev Processes
Pierre Bergamin

Pierre Bergamin

VP of Engineering at Assignar

Prioritizing Tech Work vs. Product Work: The Incomplete Story
30 June

Jose Pettoruti, Director of Engineering at CurrencyCloud, shares some tips on how to prioritize and balance tech work with ever-emerging new features by working closely with the product team.

Collaboration
Internal Communication
Jose Pettoruti

Jose Pettoruti

Director of Engineering at CurrencyCloud

When Shared Ownership Means No Ownership
30 June

Jose Pettoruti, Director of Engineering at CurrencyCloud, elaborates on his claim that shared ownership of services means no ownership at all and shares some tips on how to overcome shared ownership problems.

Collaboration
Ownership
Jose Pettoruti

Jose Pettoruti

Director of Engineering at CurrencyCloud

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.