This newsletter is sponsored by Honeycomb.
Prepare for the Multi-Agent World
Every engineer has a coding agent. Every vendor is selling one. The hard part is knowing how agents and humans work together. Watch Honeycomb’s Innovation Week to learn what’s shaping the next era of software.
Learn what makes agents good teammates, not just fast ones.
See how to get visibility across an entire fleet of agents.
Hear from industry experts at AWS, RedMonk, and Checkly.
Thanks to Honeycomb for sponsoring this newsletter. Let’s get back to today’s thought!
Intro
Communicating well with stakeholders can make the difference between a successful project and a failure. This is what I like to say:
You can create the best code in the world, write the best tests, and create the best documentation, but if you don’t manage stakeholders’ expectations and perceptions properly, your work won’t come across as the best.
In this article, I am sharing a practical approach to stakeholder communication, from identifying the right people and understanding their expectations to creating a communication plan and keeping everyone aligned throughout the project.
The advice in this article primarily applies to tech leads, but a lot of it applies more broadly. It applies if you’re part of an engineering team working on a project, managing such a team, or even working on freelance or consulting projects.
This is an article for paid subscribers, and here is the full index:
- Understand your stakeholders’ needs and expectations
- Conduct a RACI analysis
- Use the RACI analysis to start shaping your communication plan
- Develop a plan
- It can be short and to the point
🔒 Present your plan to the right people
🔒 Give the right information to each RACI role
🔒 Tailor your information and share it interactively
🔒 Share updates consistently
🔒 Have regular meetings
🔒 Be transparent
🔒 Make information always available
🔒 Create a release plan and communicate it to the stakeholders
🔒 What the plan should cover
🔒 How to communicate the plan
🔒 Last words
Let’s start!
“The Multiplier Mindset” published by O’Reilly is now available!
This article is an adapted version of one of the chapters of my book called “The Multiplier Mindset”. The e-book (Kindle) and the print version of the book is now available in most Amazon stores.
Understand your stakeholders’ needs and expectations
To communicate effectively, it’s really important to identify the people who have a “stake” in the project. Stakeholders are the people affected by the outcome of your project. Some people will be affected just a little, while others have a great deal to gain or lose.
And you can’t build the right thing if you don’t know what you’re expected to build and why. You need to understand the why behind the ask.
What is the motivation behind the project? Ask as many questions as you need to at the beginning of a project. Never neglect this.
I highly recommend asking business and product-oriented questions at this stage. You can find a list of product/business and technical questions in this template:
Notion Template: List of questions to ask before making a technical decision
You can get the template here: 🎁 Premium products.
A good engineer thinks like a product manager, and it’s really important that you think like one.
Conduct a RACI analysis
Second important thing is to conduct a responsibility assignment analysis, which is a concept based on the Project Management Institute’s book PMBOK® Guide: A Guide to the Project Management Body of Knowledge.
This is often called a RACI analysis. The acronym RACI refers to four different roles who participate in a project:
Responsible (R): The people who perform the work to complete the project
Accountable (A): The person or people who are ultimately answerable for the project’s completion
Consulted (C): The people whose opinions are sought for input or feedback
Informed (I): The people who are kept updated on the project’s progress
The purpose of a RACI analysis is to clarify who is involved in the project, in what roles, and how they should be engaged throughout its lifecycle.
Completing a RACI analysis early helps you avoid confusion, reduce communication gaps, and create a communication plan that keeps the right people informed.
Ideally, the tech lead or engineering manager creates the initial RACI matrix during project planning, together with the product manager and other key stakeholders.
As the project evolves, they can update the matrix if responsibilities change. The image below shows an example RACI matrix for a fictional tech project.
To help you with making your own RACI matrix, you can use this template:
Notion Template: RACI Chart for a Tech Project
You can get the template here: 🎁 Premium products.
Use the RACI analysis to start shaping your communication plan
Once you’ve identified these roles, use them to shape your communication plan.
For example, schedule regular check-ins with people who are consulted, send milestone updates to those who should be informed, and make sure the accountable person is aware of key decisions and risks before they become surprises.
Keep in mind that responsibilities often change as a project progresses. Someone who is only informed during planning may become consulted during implementation or accountable during the rollout.
Revisiting your RACI matrix at major project milestones helps ensure your communication stays aligned with the project’s needs.
If you are part of a small team or company, creating a RACI matrix may be an overkill, so make sure to only use it when it makes sense for your case. The point is that you should completely understand who all the people involved in the project are and what their level of involvement is.
Develop a plan
Once you’ve aligned with stakeholders on the project’s goals, it’s time to plan how you’ll deliver results. There are several key reasons why I highly recommend creating a technical specification that serves as the project plan:
It creates alignment within the team
If everyone understands what the plan is and how to approach the project, then everyone can also provide their input before starting the project. That will make it easier for them to detect unforeseen problems even before the project starts.
It creates alignment across teams
Especially in bigger companies, teams can’t always see what other teams are doing. Creating a plan ensures that everyone can get up to speed on a certain project anytime.
It creates alignment across departments
Being transparent with your work and your plans is the best way to achieve alignment. Departments like Customer Success and Product Management benefit a lot from that.
They can take a look at the plan anytime and ensure that their discussions with stakeholders or customers are aligned with the plan.
It allows for easier onboarding
Having a clear plan makes onboarding a lot easier, because each new person can easily read it to get up to speed on specific functionalities and approaches.
There is no need to dig through the code to find out how certain things are built and what approaches have been taken.
It can be short and to the point
A plan doesn’t need to be tens of pages long. Depending on the project’s complexity, it typically includes the following:
The problem being solved
Goals and nongoals
Functional requirements
Proposed architecture or system design
Important technical decisions and trade-offs
Risks and assumptions
Dependencies on other teams or systems
Rollout and migration strategy, if applicable
Many engineering organizations today practice spec-driven development (SDD), in which engineers write and review the technical specification and then create the implementation plan, which should be detailed enough that AI can use it to implement the changes in code.
Full article on how to do SDD here:
