The Anchor Playbook
The Anchor Role
The anchor role tends to resist easy definition. In some ways, it is more clearly described by what it is not:
| The Anchor Is Not | The Anchor Is |
|---|---|
| Is not “the tech lead” | Is Pivotal/Tanzu Labs’ answer to the “tech lead” |
| Is not “the decider” | Is a facilitator for good team decisions |
| Is not “the boss” | Is a teacher |
| Is not “the architect” | Is the initiator of architectural conversations |
| Is not “the manager” | Is an advocate for growth and empowerment |
| Is not responsible for the business stakeholder’s decisions | Is responsible for due diligence with regard to technical excellence |
At Pivotal/Tanzu Labs, while architecture and technology leadership are fundamental to our practice, we don’t have traditional, top-down architects or framework-writing tech leads. Our teams need leadership of a different flavor, so we evolved to have anchors instead. This framing raises more questions than it answers. What do we need from technical leadership and why do we do it differently?
At Pivotal/Tanzu Labs, we value empowered balanced teams. We want all members of the team to own their product, contribute ideas, and act on their ideas. The ethos of the empowered team is often incompatible with traditional hierarchical forms of leadership which risk stifling initiative and ownership. Our teams don’t execute on an inflexible, preordained plan: they own every step of the product development journey.
So what is an anchor?
An anchor is the representative of the engineering practice who can explain and model the engineering practice in the same way that Product Managers and Designers anchor their practices in a balanced team. They monitor team dynamics, encourage best practices, and ask the tough questions needed to drive success. They will not be the only engineer or the only team member doing this, but they will make sure it gets done.
Okay, that’s a little more descriptive.
But what does an anchor do? What expectations do we have for anchors on our balanced teams? For new team members and engineers new to the anchor role, it can be confusing to figure out how to anchor, especially since there are many ways to approach anchoring a project depending on the situation.
Anchortypes
Anchorship is often performed differently depending on project context. The type of product, the team structure, and the overall experience level of the team are all factors that influence which style of anchorship will be most effective. One team may find that peer leadership is most effective, while another team finds that a more authoritative leadership style is necessary. The variety of anchor styles can make it difficult to nail down what is and what isn’t anchorship, but this variety is also what makes the role multi-faceted and resilient.
Not every team member will see the full variety of anchor modalities in the course of their first or first few projects. This playbook will describe the most common “anchortypes” observed in the wild. As you take on anchorship, think about the different modes you can operate in, and consider which will be the most effective for your team and your product.
Choosing which anchortype you need for a given project can be a good conversation to have with experienced anchors as well as the project’s sponsor(s). You can use the anchortypes described here to help prioritize the set of responsibilities most needed for your team. As you have this conversation, think about the trade-offs and challenges that arise with each form of the role. We’ve listed some of them here, as food for thought, but think about the context of your project and your own unique skill set as you set expectations for the leadership style that will be most effective for you and your team.
Anchortypes describe the variety of hats the anchor may wear on different projects. These are not prescriptive descriptions; the anchor role is always evolving and requires the freedom to evolve. However, these classifications can help us describe the anchor role to teams and each other. Anchors can use these touch-points to discuss and determine the appropriate anchor modality to meet the needs of the project and the team.
History: why is called an “anchor?”
Once upon a time, the group that became Pivotal/Tanzu Labs was a small consulting company in San Francisco working with startups in our office, all using very early versions of Ruby on Rails.
Though enabling rapid productivity, Ruby on Rails at the time had many bugs and shortcomings, and the framework was changing dramatically with each release.
For this and other reasons (read: fun!) our engineers were not assigned to one specific project. Instead, they all rotated between projects frequently, even daily. This was partly necessitated by the volatile nature of Rails at the time; when an engineer manged to upgrade one project’s codebase to the latest version of Rails, or figured out a workaround for a new bug, that engineer would then rotate onto other project to help them do the same.
This arrangement was wonderful for the above reasons, but also had its shortcomings. Project stakeholders weren’t incredibly happy with this setup, rightly asking, “who’s on my team?” Furthermore, decisions on product and engineering direction were sometimes lost as every engineer rapidly rotated from project to project.
To solve this problem, we “anchored” one engineer to each project. That person didn’t rotate onto another project until their current project was finished, or until another engineer was ready to take over (see Scenarios: Anchorship in Practice later in this Playbook). This arrangement eventually evolved into the Anchortypes we describe here.