Apps + Coffee Connection: Engineering team structures worth po(n)dering
This blog is part of a series that delivers insights from the monthly meetups of Bugsnag’s Apps + Coffee Connection (ACC) community.
In November 2019, we launched the inaugural Bugsnag Engineering Leadership Forum. Designed to share best practices and learnings, this event was our first foray into building an engineering leadership community. The forum ended up being a huge success, and participants provided resounding feedback that they wanted more: Bugsnag was delivering a much-needed place to meet peers in the mobile space.
And that was the plan! Then 2020 happened. With the onset of the pandemic, in-person events were scrapped. However, we decided not to let the virus stop us (we are in the business of thwarting bugs, after all), and the stage was set to build a virtual community that we call the Apps + Coffee Connection (ACC) network.
Each month, ACC members meet up online for a roundtable discussion around a specific topic. The first four conversations have been so insightful that we’ve decided to share the highlights in this new blog series, starting with the ACC from May. Expertly led by our first guest facilitator, Peter Yiap, Technical Director at Supersocial, the discussion focused on team structures.
Want to increase organizational efficiency? Check out “pods”
If efficiency is on the brain, then you may want to consider “pods.” This new organization structure is rapidly becoming a popular way to address the challenges associated with horizontal teams. Pods are cross-functional and embody a vertical structure, which is designed to reduce friction in handoffs, enable collaboration and coordination, and promote ownership.
“Rather than tossing things over the wall and hoping for the best, pods provide a lot of efficiency gains and a lot of coordination,” one participant shared. “Pods go hand-in-hand with how deep into scrum philosophy you are and how you are sharing information.”
Of course, challenges exist with introducing new org structures, and the biggest one is often found in the form of employee resistance. Change is hard, and pushback is inevitable. Another participant shared his experience with the transition to pods: “By far, the biggest challenge was to convince people and get buy-in. Engineers were probably the hardest to convince. We had to help them overcome their fears that work will be harder, they’ll have to learn new things, and they’ll have more responsibilities. But the reality is, pods are easier, and work is much clearer.”
Since apprehensions can vary, it’s important to find influencers on each team and to inject a sense of ownership by emphasizing how everyone will be involved in iterating pods. Not surprisingly, engineers are more likely to get excited about pods if you can show off the benefits, such as increased development velocity and code reaching production faster.
Pods are designed to evolve and become unique
Pod teams should have autonomy and the ability to adapt to find out what works best. That means every company will end up with its own agile pod structure. “We’re going to put a first iteration of the process in place, and then it will evolve,” a participant said. “Tell the team that you are going to evolve it and help adapt it to what works best for our company.”
One participant shared her pro tip for getting started: Give each pod team a succinct one-sentence mission that pod members can rally around (and maybe even tie the mission to company OKRs!).
And always remember that patience is a virtue: the pod process can take months, or even a year or more, to stabilize. “Once you define an iteration for the process, stick to it so you can test how it works and then iterate,” a participant shared who has transitioned to pods at several companies. “It will be slow. For me, it’s always been slower than I thought, and perhaps a bit painful, but pods are totally worth it.”
Who’s in charge around here?
Leadership within pods can be tricky, and every company will find what works best. To get started, most participants recommended starting out with pods that rely on two people:
- Pod scrum master, who manages the development process and distributes tasks; and
- Pod product manager, who drives the business side, represents stakeholders, and decides what ultimately gets into the product.
One PM per pod is considered ideal for providing a single point of contact and removing ambiguity; multiple PMs in one pod team can lead to confusion for QA and developers. At smaller companies, one PM may be part of multiple feature pods. Because pods develop over time and evolve to suit each company’s needs, these general rules of thumb may or may not apply, but they provide a good starting point.
A natural question to ask is, how do performance reviews work with pods? Some organizations conduct two reviews for engineers: a pod performance review to evaluate the “what” (value created) and a regular engineering performance review to evaluate the “how” (code). An alternative is the dotted line approach where each person within a pod continues to have a functional manager who conducts performance reviews, hiring, etc.
When’s the right time to transition to pods?
There’s no easy answer, but take note of when:
- Lead time to production starts to increase;
- Delivery is slowing down or quality is being sacrificed to get products out the door; and
- Engineers are complaining about speed to production, how difficult it is to talk to PMs, and how long it takes to get work done.
Any of these pain points can trigger the consideration of pods. As one participant shared, “It’s important to listen to developers and managers to hear if they are fed up.”
Of course, it’s also important to recognize that pods aren’t always the right answer. If pods are deeply reliant on each other and blocking each other’s progress, ask yourself: What are we gaining? The pod structure should deliver speed and autonomy, and individual pods should be able to produce something of value. If they aren’t, then pods may not be the best structure for your organization.
Pods can attract prospective employees
Do job seekers find pods attractive? Most likely, yes! Time will continue to demonstrate, but most participants believe pods are considered a big plus. As one stated, “While I don’t know the full impact, pods help us better sell what we do and what it’s like to work with us. And I think that pods are appealing rather than traditional, older structures.”
To show off your organizational structure and ensure it’s a good fit with a prospective employee, one idea is to conduct interviews within a pod so candidates can see the value in the way the pod structure works and understand with whom and how they’ll be working if they join the team.
What about value stream management teams?
Similar to pods, value stream teams are generally stood up to build a particular product from start to finish and tend to involve shared resources across teams with more of a hierarchy structure.
There’s overlap with structures and multiple ways to build out teams, which is why the final recommendation of the day was to check out the book Team Topologies: Organizing Business and Technology Teams for Fast Flow as a way to help figure out what might work for your company and team.
Curious to learn more about the ACC community? Register here to join our vibrant community and monthly discussions.
