The Anchor Playbook

Scenarios: Anchorship in Practice

Pivotal/Tanzu Labs

Common scenarios that come up frequently with recommendations for all anchortypes.

Scenario: Introducing the Anchor

A new team member has joined the project and the team is introducing roles and responsibilities, including the anchor role. The team wants to make it clear that the anchor has specific responsibilities, but they do not want to indicate that the anchor is the sole owner of those responsibilities or make it difficult to transition anchors if needed.

Recommendation

As you introduce the balanced team to the new team members, include a description of the anchor role. Be aware that preconceptions people have around leadership in engineering may color their expectations of an anchor’s responsibilities. Be prepared to counter these expectations as needed (see table below). In addition, be aware that the current team anchor may need to transition into another role at some point for a variety of reasons, including possibly transitioning a mentoring anchor to the primary anchor role. Do not imply that the anchor is the sole keeper of project lore: on the contrary, the team will function best when everyone has full context and any engineer is equally capable of helping to onboard new team members.

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

Scenario: Program or Portfolio Onboarding

In a portfolio with multiple teams and projects, it is often true that one team — for instance, the initial team in an expanding portfolio — holds more context than a newer team. In these cases the team or teams closer to a core group of business or technical stakeholders are responsible to ensure this context is shared across the program.

Recommendation

Dedicate time for the program sponsors and a versed anchor to onboard new anchors as they join the portfolio.

1. Working with the program sponsors, the appropriate team’s anchor schedules some one-on-one time with the incoming anchor to provide the lay of the land and make sure that valuable context is shared.
2. The onboarding anchor is responsible to ask questions, make sure they are on the same page, and possibly raise areas of inquiry for both teams. Fresh eyes are generally valuable.
3. The anchors may decide that a more frequent cadence of anchor planning meetings (APMs) would be a useful way to carry on the conversation.

Scenario: Anchors Away!

It is not always possible to keep a much loved anchor on a project. The anchor’s departure can cause stress for the team, who has come to trust and rely on the anchor. However, it’s not always possible or desirable for an anchor to see a project through to its conclusion.

Recommendation

Managers, project sponsors, and stakeholders should feel free to rotate the anchor to another project, either to support a new team or to provide opportunities for the employee that they might otherwise miss. In order to do this safely:

1. Avoid setting the expectation that anchors always remain with a project until the end.
2. Either provide time for a new team member to work with the outgoing anchor until they fully understand the context and issues (see the Learner), or socialize that a trusted and experienced engineer will be taking over as the anchor.
3. Try to avoid transitioning multiple members of the balanced team at the same time.
4. Encourage teams to maintain lightweight architecture decision records (ADRs) to support continuity during a transition.

Scenario: Cross-Team Neural Network

Projects are more likely than ever to require multiple teams, which may spin up in any number of locations and time zones. Teams are using Slack or MS Teams channels, but communication is light, asynchronous, irregular and targeted (e.g., Slack is used to pose and answer specific questions, but it’s not a good venue for exploratory conversation). Teams need a way to communicate cross-cutting concerns, vet technical decisions, and align on shared direction in real time.

Recommendation

For programs or project portfolios that have more than one parallel effort, use anchor planning meetings (APMs) to surface issues relevant to all portfolio teams.

1. Anchors are responsible for recognizing and initiating topics relevant to the portfolio.
2. If you are working for a consulting company, be sure to keep your company’s portfolio managers informed about what is happening across projects so they can make recommendations and adjustments to stakeholders as needed.

Scenario: Learning Anchorship

Anchors use a variety of skills depending on the context they are operating in and the problems they are trying to address. The different modes in which the anchor operates (the modalities described in the previous sections) can be difficult to see and learn in the course of one project. Learning the many facets of anchorship over the course of several projects can contribute to role confusion and overall stress.

Recommendation

Identify prospective anchors and create an opportunity to learn from an experienced anchor as both work together on the same project. If the mentoring anchor is introduced as such to the team, it may be easier to switch anchors in the course of the project, thus making it easier to transition the senior anchor to a new project if needed. This practice is good for both the “shadow”, who has the opportunity to learn anchorship from an experienced team member, and the mentoring anchor who will be reminded to keep anchor responsibilities top of mind.

1. The prospective shadowing anchor’s manager informs the team anchor that their report is particularly interested in learning anchorship during the course of the project.
2. When they begin working together, the current anchor and their shadow anchor should discuss their goals for the project. After this, they can continue a dialogue with regular 1:1’s.
3. Additionally, the current anchor should identify which Anchortype they are following from this Anchor Playbook, and the nuances thereof.
4. Both anchors should participate in Anchor Planning Meetings and stakeholder update calls.
5. The current anchor can help find other opportunities for the shadowing anchor to practice anchor skills (e.g., tee up a stakeholder conversation), provide back up as needed, and offer feedback.
6. Both anchors look for an opportunity to swap roles, with the original anchor “stepping back” but providing support while the shadowing anchor officially steps into the anchor role. The former anchor might depart the team over time.