When online farm sales platform Barn2Door’s engineering team had outgrown typical pod size, VP of Engineering Geoff Schwab said it was time to analyze the two distinct types of work developers were accomplishing: preparing for scale and product development. Leadership then divided the department into smaller groups based on migration priorities and market differentiation.
But before they made the switch, the team needed top-down buy in and clear-cut direction.
“After CEO Janelle Maiocco reviewed the proposed structure, engineering tech leads were appointed for each team,” Schwab said.
Public safety company Axon went about pod division using a different strategy. Leadership provided separate teams as many resources as they needed right off the bat, encouraging engineers get to work. The problem? They didn’t define workstream ownership.
“Because of the lack of clarity on what each squad was accountable for, engineers did not feel strong ownership and morale decreased,” Director of Software Engineering for Real-Time Communications Anshuman Srivastava said.
Once they identified the issue, the team was able to restructure using a horizontal model. Front-end engineers owned dispatcher and patrol officer outcomes and back-end engineers supported two experience squads.
In the end, the updated formation supported productivity and increased morale.
Barn2Door leadership structures its engineering pods for high alignment and high autonomy. Because the company is currently in a period of growth, the engineering team has reconsidered their infrastructure to sustain increasing transaction volume. Schwab said doing so requires making the deployment process more agile.
When did you know it was time to reevaluate the structure of your engineering team?
We recognized that the team had grown to a point where people were working on two disparate areas. One focused on migration from Heroku to AWS to prepare for scale and product features. The other worked on market differentiation to continuously improve the product itself. The team had grown beyond the size of a typical two-pizza team or pod. We needed to remove the overhead of having each team participate in planning for features they were not working on.
How did you determine the right structure for your business, knowing that the team would see rapid growth in the coming months?
While AWS migration and product features do have dependency collisions, they have different stakeholder inputs. So it made sense to break the team into two designated areas of investment: product and infrastructure.
Infrastructure also involves some refactoring to a stricter, services-oriented architecture (SOA) in order to independently scale components and make our deployment process more agile.
By splitting into distinct teams, we were able to more clearly make independent progress. Ultimately, the infrastructure need is a temporary one. Feature teams should own their full implementation from front end through to the back end. As such, the longer-term team structure will be focused on pods. Each team will own a logical grouping of features.
By splitting into distinct teams, we were able to more clearly make independent progress.’’
What steps did you take to try to ensure a smooth transition to the new team structure?
In order to ensure a smooth transition, we discussed the proposed structure in our weekly team meeting. After CEO Janelle Maiocco reviewed it, engineering tech leads were appointed for each team. The tech leads are responsible for driving the planning process and investigations for each team, which was key to our successful transition. While the leads don’t have any direct reports, they move the teams forward and have a backlog ample enough to keep them from being blocked.
Axon’s engineering team prides itself on its autonomous squads, but at a certain point, the squads were growing too large and their roles too amorphous. After it became clear developers were overengineering certain features and meetings began taking longer than was necessary, Srivastava said leadership reevaluated team structure. The public safety technology company shifted its focus to outcomes for their main users: dispatchers and patrol officers.
When did you know it was time to reevaluate the structure of your engineering team?
Development speed is one of the most important metrics to track. Optimizing that metric is a challenge for any engineering leader. And it becomes even harder during times of rapid growth, where there is a high degree of ambiguity, new engineers are joining the team and a vast amount of work needs to be completed.
For Axon Dispatch, our initial org structure was optimized for flexibility given the high degree of ambiguity we faced. We split the org into two vertical teams with the resources to handle any incoming workstream but without any defined ownership.
We uncovered a fundamental problem: scenario completion was taking significantly longer than we expected and team members missed internal deadlines. Because of the lack of clarity on what each squad was accountable for, engineers did not feel strong ownership and morale decreased.
How did you determine the right structure for your business, knowing the team would see rapid growth in the coming months?
Once we saw the slowdown in velocity, we restructured the team around customer outcomes for our main users: dispatchers and patrol officers.
This did end up resulting in our org structure to become more of a horizontal split. The front-end engineers were in the two squads owning the dispatcher and patrol officer outcomes, respectively. The back-end engineers were in a platform team that had two key objectives: driving the police agency administrator outcome and supporting the two experience squads.
The key benefit was that the squads became fully aligned and empowered to build the solutions they needed to solve their users’ problems. This shift had an immediate impact on our execution. The morale of the squads vastly improved since each squad had clearly defined ownership, they knew the problems they needed to solve, and they were empowered to innovate.
There is no perfect org structure, and there have been some pros as well as cons to the structure we have. But it’s important to continue monitoring the health and execution of our organization, and to make sure to listen to candid feedback from the engineers so that we can evolve our organization over time.
A key virtue of our organization is over-indexing on written documentation.’’
What steps did you take to try to ensure a smooth transition to the new team structure?
A key virtue of our organization is over-indexing on written documentation. We have strived to have in written form every aspect of our organization, from our processes to engineering architecture docs to how we should operate Zoom in our current pandemic climate. This not only ensures proper communication with all stakeholders, it also benefits the writer so that they can structure their thoughts and ideas.
Our first step was simple: write down what the new squad structure should be, the reasons why we should structure it a certain way, and the potential risks. We then shared this out in stages. We first included the managers and squad leads to review, comment and challenge, then shared it widely to the whole team. We had numerous healthy debates, such as should we switch to a more vertically-aligned squad structure.
However, we made sure that everyone was aligned on the high-level goal we wanted to achieve. Since everyone was aligned on having autonomous squads that owned customer outcomes, we were able to focus the debates and quickly get alignment on what made the most sense for us as an organization.
