%20(1).png)
It can be hard to imagine any team, let alone an engineering team operating without team leads, but it can be done. By moving away from traditional leadership hierarchies and towards a more collaborative environment, teams can uncover their full potential and develop innovative solutions.
In a traditional leadership model, the team lead assigns tasks, and everyone works on their tasks. But here at PandaDoc, we’re a team of lifelong learners. We believe it’s important to cultivate a culture of curiosity and creativity. That’s where our engineering rotation program comes into play.
Our engineers rotate through different technical areas of the product and perform tasks such as demos, customer calls, releases, code reviews, and more to understand the customer experience better and become better developers. Our goal is to build a self-organized, adaptive system where each team member can be successful and feel empowered.
We partner with the product owner to define the direction and priorities for the team. Once priorities are established, our developers use their expertise to make decisions that align with the business goals. This promotes a sense of team responsibility and facilitates an environment for growth and development. Eliminating team leads has enabled us to remove bottlenecks from the decision-making process.
We still have engineering managers to maintain a formal hierarchy; however, their main focus is coaching individual developers and assessing technical quality. Leadership establishes guidelines for the company, including task prioritization, incident management, and other rules, that empower the team to make independent decisions.
Scrum Masters support leaderless teams.
Scrum Masters are like coaches. They tell the team how to be more effective during the sprint. They promote an environment of knowledge sharing, ownership, and accountability. They also monitor the value that’s being delivered and system failures. They are the main ambassadors of the large-scale scrum framework (LeSS). You can learn more about our Scrum Masters in our Building Agility on Scale article.
There are now over 800 employees at PandaDoc, but we still have a flatter organizational structure than most tech companies.
We’re also preparing for a multi-product scale. For example, we'd like to create a billing service that can integrate with PandaDoc, PandaDoc Forms, PandaDoc Notary, and other products. For that, the company needs to add platformization and standardization to the core product capabilities. In other words, create shared core services and practices everyone can use. We have two subsystem teams, one for content service and one for core service, to help reduce the cognitive load from the teams.
This year, we've introduced the Application Platform Track, with an optimization goal focused on lead time. We provide adaptiveness in the Growth and Customer value tracks while developing high-quality building blocks to help them save time. We’re creating systems to facilitate better experiments, idea generation, and rule creation so our team can quickly create products.
The Go and See practice, commonly used for managers in Large-Scale Scrum (LeSS), helps us see what is going on with the team during the sprint and make further decisions. Those observations allow us to find pipeline issues, observability, testing, etc., and include improvements to the Engineering Strategy for 2023.
We collect feedback in short iterations to get an idea of what to do next. After each two-week sprint, we decide if we should continue with a new idea or if it's time to stop. Small iterations let you quickly seize the market, reduce the distance between the end-user and the developer and make the product successful.
In addition, we monitor various indicators, such as the value stream that shows the team’s ability to plan a sprint quickly - some teams need a whole day; others can plan everything in an hour. Regarding team productivity, we measure how much we delivered vs. planned in the sprint review. This information helps us understand what worked and didn’t work to improve team efficiency on the Sprint Retrospective, which runs after each sprint.
We analyze different indicators of product quality, application performance, and reliability to ensure our customers have a seamless experience while using our product.
We also look at how teams manage code reviews and share knowledge. For example, some teams use Mob programming, where the team members work together in real-time on one laptop, changing positions every 30 to 60 minutes. Thus, everyone understands how the team approaches the backend, frontend, and testing. This method allows them to share insights and experience all parts of the development process.
Furthermore, we consider if a team can bring incremental value to customers every sprint. Right now, our highest-performing teams can do this every sprint, while others can do this every other sprint.
In 2023, PandaDoc is focusing on improvements to engineering levels and efficiency. We’re now investing 30-40% of our capacity into technical quality and creating a system that prevents degradation. As a result, we’ve built a staff engineer community, made technology improvements, integrated engineering strategy into product OKRs, established Error budgets, and improved observability, among other things.
PandaDoc also hosts training sessions and invites different experts to share their knowledge. For example, one of our teams recently presented at a sprint review, and they discussed a service covered by the test pyramid without manual testing. The test pyramid ensures the quality of their service without human factors. After that, several teams asked for help with their services. Training courses help our developers become strong engineers.
Our application performance metrics let us see how long it takes for a person to interact with a document. For example, our "time to interact with editor" metric fell from 20 seconds to five seconds, four times better than the previous day. We also noticed that the “time to interact with the public view” decreased from 23 seconds to eight seconds. This metric shows us that the document recipient can open and fully use a document in eight seconds.
We evaluate our platform on a five-point system, and over the past few months, performance has exceeded four, and it continues to grow. These metrics show us that our end-users are becoming more and more satisfied with the speed of our platform and allow us to see where engineering is heading.
“Failure-rate” shows us the quality of the releases. This metric provides insights into the number of rollbacks necessary to avoid customer dissatisfaction, and our quality strategy is crucial in improving this metric.
The Net Promoter Score (NPS) and Customer Satisfaction Score Speed (CSAT) help us indicate the likelihood of customer retention. If CSAT is above four and the NPS is over 40, we can conclude that customers are satisfied with the quality of our products and will likely remain customers.
For instance, an NPS of 70 is associated with Apple because people have extreme loyalty to Apple and its products. We have ambitions to reach 50+.
We also consider sales metrics like monthly recurring revenue (MRR), which show our growth. Despite the economic crisis, our MRR increased strongly at the beginning of the year. In addition, we closely monitor the Net Revenue Retention (NRR) Rate and Churn, which show how many customers remain and depart, respectively. Most notably, our total number of accounts has reached an impressive 50,000!
Not everything is perfect in a flatter structure, as the lack of team leads brings some challenges regarding speed, ownership, and specialization. We counterbalance these issues by continuously observing teams through the eyes of scrum masters and engineering managers and acting preemptively.
Accountability problem. Holding individuals or teams accountable for their actions or results can be hard without clear roles and responsibilities. The lack of a single decision-maker makes everyone accountable, which means no one is accountable. Consequently, we have to rely more on the maturity and professionalism of our teams.
Lack of specialization and expertise. In a cross-functional team, all participants do a wide range of different tasks. While this can be beneficial in terms of flexibility, it can also result in a lack of specialization and expertise in certain areas.
Increased workload. Often, employees may have to take on more responsibilities and have a heavier workload or a wider attention span. In some cases, this can lead to inefficiencies, such as losing focus or reduced productivity due to higher stress.
%20(1)%20(1)%20(1).jpg)
%20(2).png)
Quality is an essential component of product development that can have a significant impact on both product success and user satisfaction. At PandaDoc, we’ve seen our team’s size and complexity expand rapidly in the last few years, and very quickly in this time, we’ve added over 50 microservices. It hasn’t always been easy to manage technical quality at such a rapid scale, but we’ve overcome some big challenges. Here’s how we’ve done it.
%20(2).png){kind=spacer}
PandaDoc serves more than 50,000 customers each day, and we bear a huge responsibility to provide every one of our users with reliable service. Our application consists of more than 100 services, plus dozens of front-ends developed throughout the last ten years. When working with a system this complex, an engineer can't track every component manually — this is simply beyond any human's limit.
%20(2).png)
This article will give you a glimpse into how PandaDoc manages reliability and how we improve it continuously.
In a large-scale distributed application, infrastructure is hosted in the cloud. Multiple programming languages are involved, databases, message brokers, cache servers and other open-source or vendor third-party systems, and many services interacting in complex chains of logic. Minor disruptions in one service can be magnified and have serious side effects on the whole platform.