Over the past few years, people I've worked with have heard me talk at length about my two pillars for building and maintaining high-performing teams. This framework is simple, repetitive, easy to measure, and applicable to almost any type of team producing work.

The two pillars of my framework are predictability and accountability. By combining these pillars with honest communication and promoting ownership, I’ve noticed an increase in the quality, velocity, and overall satisfaction of our work. Below, I'll break down each of these components in detail, with the hope that you can incorporate some of these concepts into your own management frameworks.

Predictability

One of the foundational pillars of a successful team is predictability. Achieving predictability requires some up front work on the manager's part. The goal is to be confident in your team's ability to complete work within a given time period. This confidence allows you to provide accurate timelines and estimates when planning new features or products. If you haven't used the PERT method of estimating work, it's a great exercise to explore the relationship between estimates and confidence levels.

In most of the software teams I've worked with, we've used a two-week sprint cadence. To determine how much work can be done in a sprint, you'll need to calibrate by gathering input from the team and adjusting the number of tickets on the sprint board accordingly.

Burn down charts

Jira and many other project management tools offer a report that displays the number of completed, pulled-in, and remaining tickets. This report provides a guideline for each day to show where your work completion should be. While this is a great tool, it doesn't provide a complete story about the work your team is doing. I use this as a "heartbeat monitor," a way to check how we're doing at a high level throughout the sprint. It's even a part of our daily stand-up expectations to view the report and discuss any anomalies, such as if we've pulled in a lot of new work or if two high-pointed tickets are still sitting in the TODO column in the later part of the sprint.

Data

One of the most valuable data points I collect is personal velocity numbers. However, I do not use this information to nudge individuals to increase their numbers, as this can easily become gamified. Instead, I use it to provide some flexibility when it comes to predicting our team's velocity when someone takes a week off or is doing some other task outside of the team's project board. We can expect a decrease in velocity of n this sprint.

As a manager of a group of engineers across three disciplines (iOS, Android, and Backend), I use a spreadsheet to group each platform together and track the individual velocities of each team member. These individual velocities are then rolled up to the platform totals for each sprint. The total is averaged across three sprints to determine the target number of points we can confidently pull in and complete per sprint.

For example, the iOS team's average velocity for the last three sprints is 15 points, as shown in the spreadsheet. With this data, I am very confident we can complete 15 points next sprint or plan a new feature. As time goes on, we will increase this number by stretching and refining requirements and building up our knowledge of the codebase.

Completing the burn down chart every sprint, especially on long projects, can be a simple reward and a signal to the team that their effort is amounting to something and that the project is incrementally getting finished. There is a psychological feeling that comes with finishing something, and small things like the burn down chart can improve our attitudes about the work and our feelings of accomplishment.

Accountability

In their book "Rethinking Productivity in Software Engineering," authors Caitlin Sadowski and Thomas Zimmerman provide insights into measuring productivity in software and changing our mindsets on what productivity really means. One quote I particularly liked from the book is:

Regardless of how accurately or elaborately one can measure productivity, the ultimate bottleneck in realizing productivity improvements is behavior change.

While the data we collect can help us understand our productivity and plan our work more confidently, there is still a bottleneck preventing teams from becoming high-performing. This is where the second pillar of my framework comes in: Accountability.

The framework becomes successful when team members hold themselves accountable for their own work and the work of their peers. One of the things I include in each of our team charters is the expectation that we all want each other to succeed in our jobs, and this pillar exemplifies that idea by tying it to the data we can see in velocity. We all want to finish the work and complete the sprint with 100% accuracy, so we all help our teammates succeed with their tickets.

When we hold ourselves accountable for our team's work, we care more about the tickets we are working on, the requirements, and the designs. We start looking at the quality of the code and the product we deliver to end users and strive to make it better. We feel more ownership over the work because we are attaching our name to all of it, not just our small piece of the puzzle.

Collaboration

Teams that hold themselves accountable at a high level tend to find solutions together, speak more openly about blockers, and collaborate and pair with each other to build better things. This solidifies working relationships and improves trust among team members.

It's important for a team to build trust with one another to achieve this level of collaboration. Being able to ask questions or open up about the challenges you see or have faced in a retro can help us all grow as a team by learning from every experience. As a manager, your job is to encourage and protect this type of collaboration.

During our planning or refinement sessions, improved communication can help us discover that tickets lack sufficient information or requirements. We can discuss known or unknown technical challenges with an area of the app or new technology. Talking openly about these things up front saves a lot of time during the implementation phase of a project.