What is the ultimate structure for technical teams? This is a question that many of today’s business leaders are asking.
There is a significant cost involved with running a Research and Development (R&D) department — not only in salaries but also in the outcome of the product itself. Ineffective organizational structure can lead to slow releases, bugs, and organizational drag, ultimately hurting company ROI and even customer trust.
For this reason, WalkMe’s R&D department made the leap last year from team structure to pod structure. As a pod owner who has been with the company throughout this process, I can confidently say: Pods raise the overall level of quality within technical teams and create a ripple effect throughout the entire company.
Today I will break down the difference between teams and pods, the benefits pod structure can have on your organization and best practices for making the transition.
Teams vs. Pods
In order to describe how a pod functions, let’s first define a traditional R&D team structure.
Traditional teams use the top-down hierarchy most people are familiar with. Management prioritizes tasks, supervises deadlines and maintains optimal workflow within the team.
Teams consist of members with similar expertise. For example, front-end developers might be grouped into one team, while each works on a different aspect of the product.
Pods are more than a structure, they are a mental switch
The key differentiator is that pods are autonomous and self-governed, each operating as an independent unit.
Pods have no formal manager, instead, there is a pod owner — we will cover the difference this makes for management later in this post. Each member of a pod is also individually autonomous in the sense that they are responsible for coordinating their own workflow from task prioritization to deadlines.
This kind of operation requires teams to adopt a new mindset, one that can take time to get used to — but will ultimately result in a more productive, effective and engaged department.
How do pods work?
- Pods are comprised of a small group of individuals with complementary skills (from full-stacks to QA).
- Pod members are clustered together around a shared purpose. Each pod is responsible for a certain aspect of the product. They own all tasks involved, from development to performance to bugs.
- Each pod member is also a “domain owner.” Domains represent a specific area of expertise for which they are not only responsible but also the most knowledgeable. A developer’s daily tasks will not necessarily be within their domain. Instead, they will work on external projects and serve as a consultant for the developer working within their domain.
- For every domain owner, there is a domain sub-owner — someone who can pick up the slack if a domain owner gets sick or goes on vacation.
- For each task that arises, a feature owner is defined. While domain ownership stays static, feature owners are constantly being changed and defined. Domain owner A will always be responsible for domain A. However, it is feasible that he/she will be a feature owner within domain B.
How does the pod decide how to prioritize tasks?
This is a complicated and technical process, but to put it simply — the pod is a democracy.
Tasks come from all different sources — suggestions from pod members, product managers, from customers or cut from cross-company KPIs. All tasks are thrown in a virtual bucket.
The next stage is the brainstorm session: the pod sits together every 4 weeks and we handpick the most important tasks and prioritize them in the queue. Each pod member has a voice and can vote on the tasks they see as a priority.
As a pod owner, I decide who the feature owner will be for each task in the queue. My goal is not only to give tasks to individuals whose experience is relevant but also to give pod members the opportunity to do something new. I constantly mix up who works on what, while being mindful to pair experienced individuals with less experienced ones to facilitate learning within the pod.
Of course, problems can arise unexpectedly — there are technical fixes and time-sensitive customer solutions. When something of this kind comes up, the product manager will work closely with the feature owner, receiving progress updates directly from him/her.
I am also able to play around with the structure of who works on what, moving developers from one task to another. If need be, I can reassign a developer to serve as backup in order to deliver a task on time. This flexibility allows us to be more agile, offer quicker solutions and better quality control.
I could talk all day about the benefits of pods, so here are just a few
The pod structure has long been used by tech giants like Google and Hubspot, companies who know a thing or two about innovation. It is used primarily to drive efficiency and flexibility, but it doesn’t end there.
My personal experience with pods has been phenomenal. If before I felt like our work consisted of constantly “putting out fires,” now we are able to tackle our goals proactively. As a department, we are thriving rather than just surviving.
1. The employee experience was enriched
One of the lesser talked about pod benefits, but nonetheless, one with a huge impact, is how this shift affects the day-to-day experience of employees.
The switch to pods gave my team the ability to contribute to business goals in a way they had not felt as acutely before. The increased responsibility built self-confidence when it came to making key business decisions. The ownership and freedom of operating autonomously boosted job satisfaction.
2. Minimum dependency on external resources
The pod structure is built in a way that each project can be tackled in-pod. Gone are the days of waiting around for third party involvement. My pod is able to tackle all their projects from beginning to end, a concept that was previously inconceivable.
3. Opportunity for knowledge sharing and skill development within the pod
The way pods are set up allows individuals to try their hand at different kinds of projects. While the domain owner always remains in the same domain, he mostly acts as a consultant or does fine tuning within his/her domain. The rest of his/her time is spent branching out into new areas. Feature owners are redefined every few weeks, meaning there is always something new.
In the team structure, developers tend to get stuck in a rut, become bored or even quit. On the other hand, in pods, employees are regularly challenged by new and exciting projects. They are able to grow their skills and learn from their peers while also breaking the monotony of their role. This has huge ramifications, from motivation to retention.
4. Hyper-flexibility: Pods can be rearranged inside the pod
Another huge benefit of the pod structure is how easy it is to conduct temporary restructuring within the pods. If one feature owner needs a little extra help, this can happen easily and quickly without causing too much disruption to the overall workflow.
5. There was a jump in the quality of the product
Once the pod structure was up and running, something amazing started happening. Small, seemly insignificant inefficiencies that had been ignored for years suddenly disappeared. This happened organically without any top-down management requests. Once employees were accountable for certain aspects of the product, they had a vested interested in perfecting them.
6. We saw better workflows and maturity within pods
For the same reason that we saw improvements in the product quality, we also started seeing better workflows within the team. The structure of pods encourages teamwork, and the reality within my pod reflected that.
Because everyone is involved from beginning to end, there is a huge improvement in communication and alignment. Pod members worked together more fluently, there was less siloing of information, and the interactions between developers, QA, and product were nothing short of inspirational.
7. Management is free to tackle the big business challenges
When I was a team leader, my phone would ring off the hook. This dependence is not unique — most organizational structures experience some kind of a bottleneck when it comes to the time demands on management. I used to spend my time checking up on open projects, arranging schedules, and rushing in and out of meetings.
The pod structure freed my time to focus on training new members and creating long-term strategy. As a pod owner, I am not involved in the daily work of my pod but I am able to bring in backup for priority tasks that will drive our end goals. Only my mom calls me now.
Teams to pods: Best practices for making the leap
Try to avoid any interference with pod members’ work
It is easy to fall into old habits of a team-based hierarchy. Resist the urge to micromanage, or even just “manage.” Your new role is to make sure no big obstacles or problems arise that could delay important projects.
Instead of taking charge, try to take a place on the sidelines. A pod owner should be the one to instruct and direct the pod members when they need help with a critical decision rather than getting involved in each task.
Let your pod members make mistakes
It will take a while to fully transfer responsibility to your pod, and this is an important stage in the metamorphosis. Let your pod members test out their new role and freedom without fear of failure. Instead of reprimanding or stepping in, use mistakes as a learning opportunity for everyone in the pod.
When the inevitable slip-up does occur: Track the actions that were taken, conduct a case study about what happened, and share insights with the entire pod. The mistake might cause a setback, but ultimately everyone will learn to do their job a little bit better in the future.
Pay attention to seating arrangements
In order for the pod to work together, it is necessary for them to also sit in close proximity. I took this theory one step further.
Some people in the department thought I had lost my marbles when I started arranging and rearranging where my pod members sit. I created more than 12 variations of seating arrangements inside the cluster.
The devil is in the details, and this was no exception. The seating structure we ended up with had a huge impact on productivity. It drove cooperation across the pod and helped smooth the transition.
Communicate the big picture strategy
It is impossible to stress the importance of communication. Communicate with your team about the transition, but most importantly, make them aware of the end-goals so that their decisions and priorities can accurately reflect that.
In the past, it was sufficient for upper management to understand company goals and translate them into tasks that their team would then perform. However, with the pod structure, individuals form their own tasks and goals. To do so and do so well they must have a robust understanding of the end goals of the entire project.
Be patient, pods don’t happen overnight!
As we have stressed, this is a huge transition, not just for technical teams but for the whole company. Change can be scary, especially for big companies. Obstacles and challenges will arise, but with a little bit of patience and practice — your team will be a functioning pod in no time!
