BA 40/52: Growth, Scale, Communication Anti-Patterns and Observations
This piece is part of an ongoing stream of thought on Systems of Work. Together, these individual pieces form a playbook on how TPMs can leverage their skills to help teams do the work of doing work effectively.
As teams and organizations grow, the first thing to take a hit is communication.
One imagines that the simplest of solutions is to get the teams to talk to each other more. However, over my career, I have noticed a few fascinating anti-patterns and observations. There are potential solutions to these obstacles, some easy while others that require some patience.
“We made it a requirement that every project needed to start off as a design doc. Yet, we still struggle with making sure teams remain aligned on the end goal.”
At Google, often times discussions would conclude with the following statement “I will write a doc on that.” Documents are a powerful tool for communication especially an ever increasing async world. Alas, it isn’t always that simple.
The effectiveness of design documents relies on a few things: template, lifecycle, source of truth.
Template — Amazon’s famous 6-pager is a great example of standardizing the way to collaborate on ideas, solutions, and projects. But, just adopting a 6-pager for your organization will not always work. At Nike, the Digital Product team mandated that the 6-pager approach as a way to better communicate ideas. It was a disaster. Why? Culture. Nike accountability structure and culture of collaboration were not compatible with the 6-pager. Nike’s creativity and ideas flow better when visualized in slides decks. Forcing them to suddenly get better at writing, at length, about ideas… was unnatural.
If you decide on a templated design doc to improve your communication then make sure the template reflects the way your team works and discusses ideas. Give them enough structure but leave room for their own creativity to flow.
Lifecycle — All systems operate on a lifecycle, whether it is in nature or software engineering. Clearly outline when a document is ready for discussion, when it is ready for implementation, when it is ready for deprecation. Part of effective communication is clarity and if the there is no clarity of what stage the written word is at present, it becomes difficult to debate the merits of the words contained within any design doc.
Source of truth — when you have numerous ideas in numerous docs floating around, it is very easy to get lost about which document is the one to follow or the truth. When teams have agreed upon a concept or idea, it is important that all other documents are either marked archived or reference back to the single source of truth. Like all truths - there can only be one.
“We elaborate, bottom up, roadmaps, we have tools to track the work and progress, exec leadership does offsite to craft robust strategies, we do all hands weekly, yet we continue to suffer from misalignment and miscommunication across teams.”
Always remember this — process can only do so much.
If the process is not giving the outcome you desire, dig deeper before you blame the system as the fault and bring upon another system to replace it. At Nike, we followed SAFe and as you can imagine, multitude of tools and processes to make planning and product decisions. Yet, at the end of it all, we always had confusion and misalignment between what teams needed to do and what the priorities were. Problem wasn’t the process (although, in my opinion, it was unnecessarily elaborate) it was something more.. simpler. There was an absence of an overarching clear strategy, vision, and goal for the teams to align towards.
To build better effective communication across a growing organization, make sure the high-level strategy and goals are clear and well understood. If you don’t have clarity, the communication will be spent figuring out what exactly is it that all tactical actions are supposed to be leading to.
“We write lengthy weekly status, we have daily stand-ups, steering committees, working sessions, yet we still get blind sided by risks and roadblocks"
This is a common pattern. As organizations grow, leadership has less proximity to the work as they previously did. As it should be, they built middle management structure to move tactical decision making more to the front line teams. Hope is that a continuous flow of information will keep them aware of the risks lurking, big decisions to be made. Yet, again, all of these processes rely on something far more basic and essential to be effective — proper accountability.
What made Apple special was not the tools we used, the A+ talent we managed to hire, or even the way we did work, no, what made Apple Apple was the DRI philosophy. The right people (experts) in charge of work can make hellva difference. When you clearly identify an owner, set the expectation with them that they own the end to end success of any project or feature, whether or not they write the most amount of code for said project or feature, they are the expert who can best guide the cross-functional team to success, communication becomes effective by this single simple system.
Why? When it is not clear who is leading the charge, keeping things aligned, looking at the whole picture, who leadership looks to to clarify progress, people wait around for others to surface risks and issues. “Someone is clearly seeing this as I am, why should I rock the boat, someone else will of course surface this.” No amount status writing, design doc, exec reviews, will ever punch past this mindset.
Communication only works when the right accountability structure is in place. Give every action, project, effort an owner. Give them the powers to make tactical decisions and give them time and energy to listen when strategic roadblocks appear. Go directly to them for answers and instead of operating through the org structure — this the greatest acknowledgement of decentralized decision making.
The larger the organization becomes, the greater the resistance to enact any process to improve communication.
This is one of the most fascinating patterns I have seen as a TPM. Time and time again, efforts to improve communication whether in written or other form, is met with a common pattern of words “we have too many meetings”, “we write too much status”, “code ships products, not docs”, resistance. I believe that this resistance is rooted in the belief that more communication is driven from a place of accountability and performance evaluation rather than one of alignment and focus. But yes, sometimes, there can be too many meetings.
At every step, it is important that any effort to improve communication comes with a disclaimer and reminder that this not about accountability or perf evaluation. A necessary consequence of growth is more opportunities for misalignment, more opportunities for missing things and the only way to improve that is better communication.
I am curious, for those of you who have seen your teams and organizations grow, what observations did you see, or anti-patterns that made communication harder and how did you deal with it?
Until next time 👋!
-Aadil
How was this week’s newsletter?
This is a timely piece. My company's business growth is limited by the scalability of our products, and we have new CTO and lots of new leadership individuals. We have quite a lot misalignments and chaotic communications. I certainly believe this is the opportunity for TPMs to shine. To better align teams, I talk with different leaders regularly to understand their thoughts on how we are doing with the program(s), then update and publish the roadmap/issues/progress; In terms of communication for status update, I'm going to CTO to expose the issues and propose to him that we need to have neutral and objective status update with same format(s) but by one role(program managers) with same cadence. Let's see whether any improvement there. Thanks for the insights!