What does it mean to be an Anchor?
If you have been exposed to EXtreme Programming (XP) for any length of time you have probably heard of the term, “Anchor,” but you may not know exactly what it meant. In this article, I will be going over what an Anchor is, isn’t, and how it’s different from a typical “tech-lead.” If you’re ready, let’s dive in.
What is an “Anchor“?
Photo by Rostyslav Kondrat on Unsplash
Much like on a ship, an anchor keeps a ship where it is supposed to be and keeps it stable despite changing external conditions. In the same way, on an engineering team an anchor keeps the team stable, and (where the metaphor breaks down) moving in the right direction at a sustainable, predictable pace.
Another way to think about the role of anchor is that they are the second part of the bridge between Product/Business and the engineering team – the first part being the TPM (technical product/project manager). Together, they bridge the gap between technical expertise and business insights. Bridging customer needs and creating a viable product.
Before we dive into what an anchor is, let’s first clear up some things an anchor is not.
What an anchor isn’t!
An anchor is not necessarily a dedicated person on a team, instead it consists of a number of roles/responsibilities that are often shouldered by one or more people on a team. Many times, the “anchor” of your team will be obvious and explicitly recognized (by the company) as such but this is not always the case. If people from other teams come to you for questions about your product, if you are consistently driving technical implementations, vouching for tech-debt and helping the team grow — you might be an anchor!
An anchor is not, necessarily, the smartest, brightest, most-well researched or technically savvy member of a team, they do need to be excellent but don’t need to be the best. Instead, they need to be able to listen, facilitate and lead the team well to make the best decisions as a group. In this way, the anchor needs to be humble enough to listen and knowledgeable enough that people listen to them.
An anchor is, surprisingly, not a god. They are another person just like you. They are growing, they are maturing and – to quote John Mulaney – they are trying their best! So my advice is treat them as such, give them grace if they don’t read your mind, communicate perfectly etc. Which, if you want to be an anchor some day, is quite reassuring.
All that said, let’s dive into what an anchor is. At its core an anchor has four main roles/responsibilities: ambassador, arbiter, funnel and mentor.
An anchor is an Ambassador
Photo by Sam Goodgame on Unsplash
I have broken “ambassador” in two, much like an ambassador has two parts. They represent the interests of a company, country or brand to the outer world and they also present those interests back to the country to be able to move forward. For ease, I will discuss these sections separately but discuss them as the single role, “ambassador”.
For the team
First, anchors are ambassadors for the team to the product/business stakeholders. Much like any ambassador they need to advocate for the team. This includes attending important planning, strategy, roadmapping and design sessions and ensuring that the team’s needs are understood and accounted for. These needs include but are not limited to: morale, velocity, outstanding technical debt, platform migrations and compliance needs.
Further, they will act as an initial sounding board for new requests, both about feasibility and (in tandem with TPM) discussing priority and potential estimates. To do this well, the anchor needs to have an excellent understanding of the product and the system in which it resides.
Lastly, a good ambassador needs to have a good pulse on the team in order to communicate clearly. They need to be involved enough in the day-to-day with the team to know what they are looking at and feeling like to accurately portray this externally.
For the business
The converse-side of being an ambassador for the team is that the anchor needs to understand the requests and relay this information back to the team and help the whole organization reach the best possible end state-and deliver an excellent product.
They should be adept at articulating value, the roadmap and the prioritization behind the roadmap. They help the TPM to ensure the team is motivated, aligned and delivering the most valuable stories. It is essential that a good anchor understands and is able to articulate the value (or value-chain) that a product provides.
The anchor works as an inside-man with the TPM, to bubble up any issues in the team to ensure that the team is working well, effectively, cohesively and no issues are being overlooked.
To be a good ambassador they need to be able to stand-up and explain clearly the trade-offs in decisions and, when appropriate, say no this should not be done now for the best health of the team, product, design (importantly, sometimes they need to say no the business in lieu of tech-debt and sometimes they need to defer tech-debt in lieu of a big release).
An anchor is an Arbiter
Photo by Tingey Injury Law Firm on Unsplash
An anchor is also the arbiter of team discussions and ultimately responsible for ensuring that features continue to be developed and decisions are made. Unlike (most) tech-leads, an anchor does not need to be the most technically talented person on a team but they do need to have the respect of the team.
It is important that the anchor is active and intentional, in partnership with the TPM, in generating buy-in for all decisions made. This is important to avoid “doubling back” or people questioning/reversing decisions made weeks or months later (without new information). Agile teams should aim to defer design decisions until the last responsible moment (a whole other blog post), but when technical decisions need to be made as a team (where it’s small enough you may not need an architect or not have one; but important enough to require alignment) the anchor should take the lead in facilitating those conversations, driving consensus and ultimately helping the team to be on board and collectively own the final decision.
An anchor is a Funnel
An anchor should understand the system extremely well and be a spokesman for it. They should be the point of contact for incoming requests, random questions, basic support requests and crucially for the TPM (to write / accept stories, epics, roadmap, etc). They act as a funnel, they are able to protect the rest of the team from most of these ad-hoc requests. The goal of this is not to prevent other team members from being exposed but to allow them to stay focussed and deliver work. Depending on your team size, maturity and customers you may have dedicated members to fielding support requests, the “funnel” role of anchor is partially covered but is more broad as it may also cover architecture discussions, internal team conversations and more but the line is gray.
An anchor is a Mentor
An anchor should also be mentoring the team, aiming to nurture more anchors proper design thinking, technical excellence as well as good communication. A good anchor will help lead a great team and a successful product. An excellent anchor will lead a great team, a successful product and watch as the team grows, multiplies and many engineers turn into their own anchors; leading great teams (and the cycle repeats). This is an under-rated but high-opportunity activity for anchors especially as they pair or work with team-mates every day. They can take every opportunity to teach the skills, mindset and patterns needed to be a great architect.
So, what is an anchor?
To wrap up, an anchor bridges the gap between product/business and the technical team by being an excellent ambassador. They help arbitrate and make team decisions, act as a funnel for incoming requests and they mentor team members to become anchors. They are technically excellent and socially adept. Of course there is so much more that an anchor does but that is not what an anchor is. And to close I want to share a non-exhaustive list of what an anchor may do on a given day/week/etc:
- Pair with the team to write tests & code (daily)
- Pair with the TPM to write stories / epics or accept these (weekly)
- Help facilitate standups / IPMs / Sprint kickoff (or planning) / retrospectives (weekly)
- Discuss implementation details of epics/stories with TPM, Architect, and the team (weekly / ad-hoc)
- Attend discovery & framing, inception, kick-off and other technical meetings that involve understanding and articulating value + ensuring technical limitations are known (ad-hoc)
- Discuss roadmapping and plans with Business/Product (bi-weekly)
- Push back to the TPM (and stakeholders) about unreasonable timelines, technical debt that needs to be addressed and short-sighted design decisions (as-needed, sometimes daily)
- Shield the team by responding to questions, requests and other interruptions (ad-hoc)
- Escalate blockers, issues and answers needed (as needed)
That said, I hope that helps you understand a little more about what an anchor is, isn’t, what they do and how you might be one. Let me know, what did you think, what did I miss? You can email me at ajw@enfuse.io or comment below. I’d love to chat!