Team organization is a process that needs constant reevaluation, Mark Sost, VP of engineering at cannabis wholesale platform LeafLink, said. When restructuring his engineering team, leadership started the process with honest and open communication.
“We began by talking through the pain points, including concerns we’d seen with the larger team, as well as issues arising from those concerns,” Sost said. Out of those meetings, leadership proposed a gradual shift to the company’s current pod structure.
Once a restructuring is complete, delegation and follow-up are key to its success. Matt Bowman, software engineering director at Yext, doesn’t allow teams to be larger than eight engineers so that roles and responsibilities are clear. Small team size encourages better communication between team leaders and direct reports.
When productivity gets stale, it’s time for restructuring, Sost said. The first step? Reevaluating team goals and objectives. From there, breaking out teams into smaller pods so there’s little separation between the work being discussed and the work being produced keeps productivity at a healthy pace at LeafLink.
When did you know it was time to reevaluate the structure of your engineering team?
For any team, the time to reevaluate structure is when something that normally feeds productivity — planning process, work check-ins and overall meeting cadence — gets impeded. This is also a good time to reevaluate current team goals and objectives.
At LeafLink, we started to break out into smaller pods after there was too much separation between the work being discussed and the work the team was focused on. That’s a great indicator that there’s enough “work space” between team members that you should be reevaluating the structure of your organization.
The most important part of this process was making sure our team members felt heard.”
How did you determine the right structure for your team, knowing that team would see rapid growth in the coming months?
Like all software, I don’t think there’s a one-size-fits-all approach to team organization. Similarly, I don’t believe that what works one quarter is guaranteed to work the next. Team organization is a constant process, and should become more efficient the more you learn about the work being performed and the abilities of team members.
At LeafLink, we have six or seven pods at any given time, each focusing on a specific product offering. Some pods focus on developing and iterating on our marketplace tools, some on building systems that enable rapid international expansion, some on emerging product offerings like LeafLink Financial and LeafLink Logistics, and some that work on more technical areas like our APIs, integrations and the overall stability of our platform and infrastructure.
Pods are also cross-functional, meaning they have a mix of product, product design, front-end, back-end and DevOps resources. The general structure of these groups is dictated by the work they own.
What steps did you take to try to ensure a smooth transition to the new team structure?
Moving from one functional structure to another can be tricky, but a smooth process starts with communication.
We began by talking through the pain points, including concerns we’d seen with the larger team and issues arising from those concerns. Out of those meetings, we proposed a gradual shift to the current pod structure.
The most important part of this process was making sure our team members felt heard. We incorporated many of their thoughts and opinions, which really helped accelerate the transition to a new structure.
Finally, being able to chart progress from an initial proposal to its final state was helpful when it came time to present our work to the rest of the executive team.
Bowman said he uses critical thinking and communication to determine the structure of his team. At Yext, each engineering team operates on a complete project from front end to back end. The vertical structure allows for clear ownership and roles within each team.
When did you know it was time to reevaluate the structure of your engineering team?
Yext realized that it was time to reevaluate the structure of our engineering team when the growth of our product engineering team was approaching 600 percent over a period of just two years. Since our consulting wing sits near Washington D.C., we decided to capitalize on our competitive advantage and aggressively grow our team there. We took a different approach to team organization that included adding another layer of management to keep people operating efficiently, improving and formalizing our onboarding processes and developing our individual contributor engineers into leaders. We also gave our junior and mid-level engineers additional responsibilities to help speed their development.
How did you determine the right structure for your team, knowing that team would see rapid growth in the coming months?
Critical thinking at all levels is vital for an organization to execute effectively and leverage each team member’s talents. To keep communication simple, we kept the number of layers as low as possible between the people making strategic decisions and those executing them. Distance between strategy and tactics is important, but too much distance can create a situation where feedback is rare, the strategy is out of touch, and employees don’t think critically. Instead, they just do what they’re told.
Whenever one of our teams grew to seven or eight people, we would break it into two smaller teams. We’d then separate the responsibilities between them in obvious ways to create clear team ownership, which helped us maintain organizational efficiency. While separating teams has advantages, we generally don’t split teams into front end and back end. Instead, we try to make logical vertical slices, so that teams own a product or feature from top to bottom.
Meeting ahead of time with team leaders was key to a smooth transition.”
What steps did you take to try to ensure a smooth transition to the new team structure?
Meeting ahead of time with team leaders to discuss what we’re doing and why we’re doing it was key to a smooth transition. Ensuring the success of the teams is of paramount importance, so we evaluated existing teams prior to reallocating resources and sought buy-in from experienced engineers prior to transitioning them to a new team. There were times when an engineer preferred to stay where they were, while other times they were excited by the prospect of a new challenge. After the reorganization, we followed-up and solicited feedback to ensure teams were effectively working together toward the organization’s goals.
Vora Vor, CTO of Pico, uses a modified cross-functional pod model, called dynamic pods, for its engineering structure. These pods have a distinct advantage for early-stage startups like Pico: Leveraging the range and experience of each engineer exposes the team to a broad range of business problems and solutions.
When did you know it was time to reevaluate the structure of your engineering team? What were the biggest indicators?
The Pico product team consisted of 3.5 people in September 2019 when I joined. The founders’ mandate was for me to evaluate and reform the engineering practice for the imminent scale of the company, given a very ambitious product roadmap.
Although amazingly dynamic and successful, the small team showed urgent indicators for reform. The agile implementation was inconsistent. Measuring engineering effort was anecdotal and lacked methodology. Finally, the absence of an organizational chart created friction and ambiguity in ownership, technical direction, task assignment and individual career paths.
How did you determine the right structure for your team, knowing that team would see rapid growth in the coming months?
Pico utilizes a modified cross-functional pod structure, which we call dynamic pods. This approach leverages the range and experience of each creative engineer. Dynamic pods offer a key opportunity of working at an early-stage startup: exposure to a broad context of stories, business problems and solutions. They also nicely accommodate existing culture and practice in a way that is impactful to reform. In short, people can grow across our end-to-end JavaScript stack including front end, back end, DevOps, Node.js, React and CSS, yielding overlapping compasses of expertise.
As Pico grows, we will add informal articulation and light specialization to our dynamic pods, but only where this will enhance velocity of releasing features. True specialization will await the exponential scale of our operation in 2021, but will likely retain this dynamism.
Weekly retro or full-team huddles surface tech challenges.”
What steps did you take to try to ensure a smooth transition to the new team structure?
First, we produced an organizational chart situating each individual contributor, lead and candidate not only within Pico, but also within the industry and the narrative of their career. We surfaced heuristic and specific milestones and tied those back to the chart. We defined measurable KPIs for coding days, pull request throughput, and rework at both IC and team levels. Professional development and learning plans were offered to any engineer that wanted them, backed by a regular one-on-one cadence with me and also with each other.
The second step was to fill our product manager role to spearhead our agile flavor and bring coherence to our roadmap and sprinting tempo.
Third, we engaged offshore resources for engineering backfill capacity and to inculcate a “follow the sun” modality, bringing true constant delivery. Every engineer has a voice in the evolution of our practice from scrappy startup to rugged software shop. Every engineer actively participates in every recruitment, ensuring our culture and values remain forefront.
Weekly retro or full-team huddles surface tech challenges, interests, findings, hot topics and rotational demos. We have added to the number of meetings, but gently suggest that meetings be 30 minutes or shorter.
