PandaDoc R&D from the Inside: How We Work

At PandaDoc we have more than 40 teams working together to deliver our product to market. This article explains our structure, processes, and guidelines.

Teams

A team is a minimum building block of the organization. PandaDoc has three types of teams: feature teams, complex subsystem teams, and functional teams.

Feature Teams

Most (>90%) of our teams are feature teams (see Figure 1). Feature teams have the following characteristics:

• Long-lived and stable
• 5 to 6 individuals in each team
• cross-functional, with the technical know-how to contribute to any system or component
• deliver end-to-end customer value

Figure 1. Feature team

Every feature team can deliver a potentially shippable increment alone, or for a complex feature, in concert with another team or teams.

Every feature team has a Scrum Master and an Engineering Manager, both of whom work with 2 to 3 teams.

We grow new teams by training new team members in existing teams until they become proficient. After new team members are sufficiently trained, we form a new team.

Complex Subsystem Team

The complex subsystem team has the expertise to shorten the development cycle for component they are responsible for. This team helps to streamline work by refactoring or splitting complicated components.

This team is not allowed to write business logic for other teams to avoid becoming a bottleneck and/or knowledge center.

We have just one complex subsystem team in the whole organization.

Functional Teams

These teams perform groups of functions. Examples include the security team, operations, QA automation (e.g., developing an automation framework), etc.

Tracks

Multiple teams are grouped into Tracks (see Figure 2). Each Track is an organizational building and scaling unit that focused on a specific client area or driving business metric.

Each Track has a:

• product goal represented by objectives and key results and long-term commitment
• set of teams working to achieve the Track goal
• Track backlog from which it inherits its priorities

Figure 2. Track

Tracks have the following characteristics:

• simplicity: a maximum of 6 to 8 teams per Track keep each Track with a wide focus
• flexibility: each Track is able to work within the entire company technology stack and application
• self-sufficient: each Track has members with the required expertise and knowledge to complete its goal
• ownership: each Track has full responsibility for both the technical and product quality of its service
• customer-focused: each Track prioritizes value for customers within single Track backlog

Tracks are temporary. Tracks can be reformatted, made obsolete, or updated at any time due to product changes. Because feature teams can do any work in any part of an application, it’s easy to change Track goals or the number of teams in a Track.

Specific Tracks focus on defined objectives. Examples include:

• Growth Track: helps encourage product-led growth by running experiments on growth
• Day-2-Day Track: helps users navigate and use PandaDoc the most effectively
• Document-as-an-App Track: implements document-related use cases
• Ecosystem Track: helps other companies integrate with PandaDoc
• Revenu Solutions Track: democratizes B2B sales by enabling SMBs with effective affordable tools to grow and win
• Platform Track: enable teams with a toolkit, shortening cycle time

All the Tracks, except the Platform Track, are oriented to external customers and consist only of feature teams. The platform Track contains functional teams. It does not develop business-related features, and none of the feature teams are dependent on it.

Tracks Operation Model

We use the LeSS Framework within our organization. Every Track uses Scrum and follows the main guidelines and rules of LeSS (see Figure 3).

Figure 3. A Track’s process in the LeSS framework.

All Sprints are synchronized within the organization for all Tracks, which helps with consistency.

Track Leadership
We designed Tracks to be independent and self-managed. Every Track has the following leadership:

• Product director: who plays the role of Area Product Owner (APO), who orders the Track’s backlog and decides how to achieve its goals. The APO has a product owner team, usually consisting of 3 to 5 product managers per Track.
• Engineering director: helps set up engineering and technical approaches in Track. Every Track has around 3 engineering managers who work with the teams and the Track. They report to the engineering director.
• Head of design: helps set up common design guides and processes.
• Scrum master: helps to implement LeSS and set up working inspect & adapt process; works with teams and organization.

Track Events
Every Track team follows Scrum procedures, but in scaling manner (multi-team events). Click the link below for a video example of our sprint review process:

Multi-Teams Sprint Review — How do we do it?

Sprint review is the only event we have across all Tracks. We run all other events from Scrum only on the Track level.

Scaling of R&D Organization

The main scaling unit of the organization is Track. A new Track appears when a new business needs is discovered and significant resources are required to fill the need. We launch a new Track when we have at least 3 teams working in a new area.

The current organizational structure follows LeSS Huge guidelines (see Figure 4).

Figure 4. Organizational structure according to LeSS Huge guidelines

Every Track has an Area Backlog, inherited from the Product Backlog controlled by one Product Owner (in our case, the CTO). This gives us the ability to:

• move teams between Tracks if global priorities and the current distribution of teams by Tracks needs redistributing
• change Tracks if needed, as well as start new Tracks or close Tracks no longer needed

The structure is highly adaptable and enables us to prioritize goals in our system structure. At any moment we can shift to working on the highest-value priorities.

1. At any moment of time working on highest valuable items from Backlog, meaning that we are avoiding local optimization
2. Highest adaptability: ability to change plans on the fly to the whole organization

What’s next?

We are continually experimenting and improving. Look to us for

• technical excellence — we strive to be best in class in development practices
• initiatives decomposition — we seek to get the most from the least effort

Look for more information in the upcoming articles. Feel free to ask questions.

Meanwhile, check out these related videos.

How we started our journey

Current experiments within the organization

A bit more about our culture and structure