Scaling Teams to Make Better Decentralised Decisions via Documents and Tenets

Problem

Anyone who has been inside a growing team or responsible for growing a team, knows the headaches related to these scaling changes. One sunny day, you may have a small tightly-knit team that knows each other well, working purposefully to goals, and the next day, everything is larger but ‘on-fire’ and somehow also falling apart. This may sound like an exaggeration but it is what it feels like at that moment, for those involved.

At one of the firms I worked at, I was PM for a machine learning product, built and used by an expanding, global team. This product enriched shopping catalogues with key data, to help shoppers find the right products, when browsing or searching. However sigh a few of the decisions in the early product version were now hurting quality, as it tried to scale up. Hence, scaling was stalled as the output was investigated. At this point, I took over the product and decided to sit down and listen to the original team, the newly scaled team, and the stakeholders, all around the world. Together by talking, we found the source of the problems and I made decisions to improve quality, in the next version. Soon, we were back to scaling, and rolling out to more global shopping sites. However, there was an unexpected side-effect from these talks - I was being looped in, to do more and more ‘scaling’ reviews for tech products. Plus my team and stakeholders were now expanding so much (21 countries in the end) that I was in so many 1:1s, I could barely find time to buy, let alone eat my lunch!

It was great to be scaling, it was just happening faster than we were ready for. I needed to find ways to connect our stakeholders, so they could trust each other more, and make great product scaling decisions themselves, without needing me in the room. I was clueless how to fix this. So I reached out to my mentors, who gave me great suggestions. And I’d like to share the actions here that made the biggest improvements for me and the teams involved.

Actions taken

FAQs and asynchronous documents

One of the things I tried was creating written FAQs (frequently asked question documents), with answers, for the most commonly asked questions and reviews. This asynchronous document meant stakeholders could get the standard answers, at any time of day, in any time zone - without needing to find an overlapping 1:1 time with me. This was one of the key actions that helped us scale. I could also update these FAQs at a central site, whenever the answers evolved. And while this required a lot of time, to write in an approachable way (so it was self-explanatory) and to keep current, it was worth it. It even served as training materials, for people new to collaborating with our team.

Open Office Hours

Next, instead of queuing up endless 1:1 meetings in my calendar - I started to group related asks, into fixed group meeting times. Together we set up fortnightly ‘open office hours’ on the most common topics, with sessions compatible for each of the standard team time zones. This also helped bring focus to our meetings. It freed up my calendar and that of my key stakeholders. And it meant whenever an issue, or innovative new idea came up, everyone knew it was only a few more days until we would be at the fixed forum to discuss it. It also helped hugely to connect stakeholders to each other. Some stakeholders (even though they worked in the same city and office) actually met each other for the first time at these forums and were soon collaborating on their own product prototypes locally!

Tenets

By this point, we had the bulk of asks, being handled in a scalable fashion. However, there were still a lot of unexpected escalations, where I didn’t feel after the session, I had added any unique value. So based on a mentor’s suggestion, I set up a ‘Tenets’ workshop with my team, to document my decision making. Looking back, I wish I had tried this first - as it probably helped the most to bring the team and stakeholders together. At this workshop, we discussed the principles I used to make a decision. We discussed the principles each team member used. And we discussed what everyone needed or wanted, to do their best work. We consolidated this into a set of trade-off default positions (tenets) for the common types of decisions e.g. when a support ask, could override proactive work etc. This became a written list of team tenets, that we shared and updated as we progressed.

And this tenets document really changed things. Just telling people I trusted them, so they should trust each other, wasn’t enough. However, collaborating to co-produce our decision framework (tenets), that we then shared with stakeholders, hugely built trust. In fact some of the sub-teams, without prompting, even took their stakeholders through the tenets, in their own follow-up deep-dive workshops. And soon, most of the ad-hoc reactive topics were just ‘answered via tenets’ and we were all freed up, to focus together on the more meaningful and impactful, collaborative teamwork.

Lessons learned

• Decentralised decision making with open frameworks, is hugely beneficial in scaling product teams. I found such mechanisms are useful to help people understand why and how decisions are being made. And this helps them feel safer, to try to make more decisions themselves, without having to escalate so much. Plus the existence of a framework that everyone can see and contribute to, helps structure conversations and evolve decision making, as the team learns and scales together.
• Also building shared artefacts like FAQs and team ‘tenets’, takes a lot of time and effort, from everyone involved, if you do it properly. Even so, this very significant investment in time is worth it. As the process of openly creating and sharing such artefacts, helps build trust between everyone involved - which pays back even more, in the long-run.