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

How to improve engagement and retention in remote engineering teams?

25 October

Mrunal Kapade, an Engineering leader, based in Silicon Valley, shares tips that helped reduce attrition in the remote engineering teams while leading multiple teams from startups to Fortune 500 companies.

Remote
Company Culture
Collaboration
Motivation
Team Processes
Mrunal Kapade

Mrunal Kapade

Director of Engineering at Inspire Energy

Assessing the Performance of Your Team

20 August

Parallels between Work and Sport.

Goal Setting
Different Skillsets
Coaching / Training / Mentorship
Performance
Ron Pragides

Ron Pragides

SVP Engineering at Trustly Group AB

How to Organize, Manage, and Grow Your Team

12 July

Vineet Puranik, Senior Engineering Manager at DocuSign, discusses the impact of roadmaps, organization, and proper management for your teams to procure growth.

Managing Expectations
Delegate
Collaboration
Roadmap
Strategy
Vineet Puranik

Vineet Puranik

Senior Engineering Manager at DocuSign

(Re)Organizing Your Teams Using Domain-Driven Design

12 July

A proposal for how to create an org structure that will deliver software systems that you want, not ones you get stuck with.

Alignment
Architecture
Scaling Team
Building A Team
Internal Communication
Reorganization
Ram Singh

Ram Singh

CTO at REAL Engagement & Loyalty

Building Up Your Technical Skills in a Fast-Paced Industry

8 July

Otavio Santana, Distinguished Software Engineer at Zup Innovation, shares his best practices for upskilling without stretching yourself too thin.

Different Skillsets
Personal Growth
Prioritization
Otavio Santana

Otavio Santana

Java champion, software engineer, architect, and open-source Contributor at Independent Technical Advisor