Teams and structures that create themselves

Agile Expat by Denis Salnikov
4 min readDec 18, 2022

Over the last two years, the number of teams in PandaDoc has grown from 12 to 47, split into 8 LeSS Huge Requirement Areas (RAs). Most teams and areas were formed on a self-design basis.

Earlier this year, I shared my first-hand experience with self-design at several European conferences. My talk, which can be found at the end of the article, focused on the benefits of self-design for employee engagement and strategies for using it. Today we will discuss the preparation and facilitation of a workshop that allows such teams to come true.

“Self… what?!?”

The Hackman’s Authority Model will help me to answer this question. Richard Hackman, a professor at Harvard, has devoted his life to researching the topic of team and organization effectiveness.

The Model, based on his book Leading Teams: Setting the Stage for Great Performances, presents “self-designing teams” as the next stage of development of “self-managed” (or “self-organizing”) teams. The ones whose maturation and growth many Scrum Masters and Agile Coaches support on a day-to-day basis.

The Hackman’s Authority Model, source:

In the words of Professor Hackman, moving to this level requires “giving teams the right to change the structure of the team, or aspects of the organizational context in which it operates, or both.” This becomes a reality only if there is a mandate from the company or department management.

Helping teams build themselves

The formation of such teams can occur in different ways, but I prefer to assist them with a facilitated meeting.

As an example of its structure and timing, I’ll take one of the self-designing workshops I ran at PandaDoc. The workshop aimed to form an experimental Requirement Area with specific tech stack and domain expertise requirements.

Usually, we strive for stable and long-lived teams. But since most volunteers who expressed a desire to join the Area came to the company recently, we decided to form four teams from scratch.

The workshop structure

The workshop lasted 2.5 hours and took place online using Zoom and Miro. Besides the Facilitator and Developers, it was attended by Product and Engineering Directors of the Area and Product Managers.

🗺️ After the icebreaker, the Directors presented the RA’s Vision and Strategy for the upcoming year. Next, the Product Managers pitched the upcoming work from the top of the Product Backlog. The initial plan was to “invest” two teams in two significant features over the first several Sprints. Together with the Q&A, this part took 20 minutes.

📐 Next 15 minutes were dedicated to presenting the Ideal Team’s Vision formatted as a Skill Matrix with some restrictions. For example, each team had to possess expertise in our API and experience with the new pipeline. The team size had to fit the limit “from 4 to 6 people”.

📝 Next, all participants were given 5 minutes to fill out a Profile template in Miro. It aimed to visualize their level of expertise in each of the technologies and business domains on a “traffic light” scale.

🏃‍♂️ Each team had a dedicated Miro frame, serving as the Team Station. Participants were given 15 minutes to choose their new team. Once all Profiles got distributed across Stations, the teams went to the prepared breakout rooms to fill in the Matrix and discuss the nuances.

🔎 Back in the main room, the whole group had 20 minutes to go through all the stations, one at a time. All participants had a chance to share their observations, challenge the resulting composition, highlight possible problems and give feedback.

☕The 10-minute break followed. Then the group had another round of self-design to revise the teams’ structure, considering the received feedback. That was followed by another feedback round. The meeting design included time for the third round, which was not required this time.

Skill Matrix example, source:

The teams dedicated the rest of the timebox to the initial initiatives refinement. At this stage, two newly formed teams asked to be given a day to research the existing code base. The next day, they proposed to revise the final composition for a more efficient distribution of expertise.

Summing up

In the provided example, it took us 2.5 hours to form four self-designed teams, shape a shared context and agree on further steps. Starting the RA this way strongly motivated the teams. Their involvement also enables this wise crowd to notice the hitches that the management could not see in advance.

Have you participated in the self-design? How did it feel? Share in the comments!

P.S. As you’ve done through the article, I am finally sharing the promised conference talk.

P.P.S. Feel free to share your questions or comment under this article too! ;)



Agile Expat by Denis Salnikov

Org Design & Agility Coach @ Agile Expat | Trainer @ Co-Actors | Professional Scrum Master | Kanban Coach