Discoverable Organisations
Discoverable organisations through explicit curated team & product indexes / catalogues, charters, visions, strategies, roadmaps.
Navigating large enterprises can be notoriously difficult. You might know something about your organisation and it’s history through public-facing content. You may have an induction that gives some context (you may not). Once you’re in the belly of the beast you will get some feel for things through various resources and interactions. You will get to know a lot about the team you work in and you will start to understand things about the wider department and about your own key stakeholders. Everything else, well..?
We hobble about as in some fantasy tale discovering different things as we roam. Important things are sprung upon us now and then by different characters and events. But just as in the fantasy tales, major important contextual information about the world we’re in could have and should have been made available to us up front and prior to setting out on our journeys.
The lack of organisational visibility and frankly the apparent lack of leaders concern around this state of affairs can lead to the feeling that it’s all none of our business. We should just stay in our lane and do our bit. It’s all need to know. What you need to know will be shared with you via an e-mail or a point-in-time announcement in a meeting. For anything else ask your manager.
The piecemeal information leads to piecemeal context. On a team / unit level this can lead to misalignments in terms of gaps that aren’t apparent, working on projects which aren’t right and overlap in capability with other teams that you can’t see but will become all too apparent in time.
Individually this makes us feel somewhat disconnected and demotivated and leads to some perpetual doubt in alignment of our day-to-day decisions. It can make it hard to get things from internal teams (particularly cross-department) because it’s not clear where to start. Once you finally initiate some process if there is anything that requires true collaboration or one party to make changes this can be incredibly difficult to organise due to lack of clear communication pathways and general resistance. Even when a collaboration eventually goes quite smoothly in the happiest case there was still a great deal of inefficiency in finding the right stakeholders to begin with.
In this post we’re going to look at a simple set of artefacts and actions that can imbue an organisation with visibility and discoverability. Visibility meaning to be able to generally understand who is doing what and why at a high level via explicit information. Discoverability being the ability to do this naturally and asynchronously without help or special knowledge.
These features help alleviate all of the negatives mentioned above. Enabling general contextualisation which helps every interaction in a small way. From the departmental collaboration problems to surfacing the different types of misalignment. These can be painful to address but it’s better if you do. They help discourage weird information hoarding that is surprisingly common. Fundamentally they massively help with efficiency for a very small time investment.
Note the use of helps. There are no silver bullets. But there are better and worse ways to do things.
Adding visibility and discoverability is the difference between walking around trying to find a place and asking people you come across who all have varying degrees of knowledge and confidence Vs. being able to use those nice maps which provide a top down view and say “you are here”. You’re immediately contextualised. Theme park maps provide a particularly good experience in this vein.
Teams are groups of people that work closely together on things.
Products (for lack of a better word) are the things that teams do. The product or service that the team provide to solve problems for specific users. It is a logically coherent grouping of things that deliver value to a user. It can be really clear like “the product is the app” or part of the app. Or it can be a bit more abstract. For example a product could be a set of processes, tools and analysis that provide a view into a complex area e.g Developer Experience that can then be used to help make decisions and perhaps develop more products.
Teams have a logical purpose and are responsible for one or more products that help achieve that purpose.
I am proposing that for every team and for every product in the organisation that a set of fairly minimal living documents is continually maintained by the owning team. These documents really help quickly give context by making it clear who is doing what; why and how!
The beauty of this is that the you already know the information for the docs. Going through the exercise can force you to clarify your thinking in a positive way. In all cases the docs are not meant to be super long and detailed — there are other times and places for that. They are meant to summarise and present your ideas as clearly and concisely as possible to your own team and your colleagues so everyone knows what you’re up to.
I am not being prescriptive in exactly how the information should be conveyed. Some of the documents could be combined for example. The most important thing is the key content is intuitive to find if someone is looking for it.
Of course there are all sorts of other documentation that teams and products need which could be user-facing, org-facing or internal. Processes, guides, designs etc. The specifics all depend on what they need to do.
Visibility
Team Charter
What is the teams overarching purpose? How does it achieve this? Link to the Product Charters of the products that the team owns. Where does the team live organisationally? What is the teams history? Who exactly is in the team? What are their roles and responsibilities? How do you contact the team for product support? How can you otherwise initiate a collaboration? What publishing channels does the team use for announcements?
Every team should have a Team Charter. This also goes for teams-of-teams. The executive team is a team. The technology organisation is a team. The principle is that of making the organisation easier to understand and operate within. Where do the executive team communicate outwardly? How does feedback make it’s way to the executive team? How is the company structured?
The Team Charter concept is very similar to that of a Team Topologies Team API:
Product Charter
The Product Charter can cover the main purpose and objectives of the product. What problem is being solved? Who are the target users? Who are the current users? How will it help them? How is it built at a high level? What other products does your product depend on? What is it’s current state? Plus any additional information you judge to be relevant. The Product Charter would also link back to it’s current owning Team Charter for forwards-backwards traceability.
Product Vision
The Product Vision is what you want for the product in the longer term. Perhaps the next 2 to 5 years. What do you want to move towards from where you currently are now? What are some pain points you want to solve for the user? Where might you go technically? How might current scope change? You can afford to be a bit ambitious and aspirational here.
Product Strategy
The Product Strategy is the general approach you will use to move towards your Product Vision.
Will Larson, current CTO at FinTech Carta (previously Calm, Stripe, Uber) has a great resource on writing engineering strategy at the executive level:
Product Roadmap
The Product Roadmap is likely a term you will be familiar with. This is the actual plan of actual activities that will be moving you toward your Product Vision. There are different interpretations of what exactly the roadmap is and should be. Here I mean something that provides a good forward indication of the significant technical and user work you intend to be doing over the next few months / quarters that make your priorities clear.
Discoverability
Team Index / Catalogue
Lightweight central place that lists all teams with a link to their Team Charter, a brief description and keywords.
Product Index / Catalogue
Lightweight central place that lists all products with a link to the Product Charter, a brief description and keywords.
For both of these discoverability and searchability tools they could be in one single space and formatted in some logical way or each department / domain could maintain their own indexes with another meta-index on top of them.
The key to discoverability is creating a pattern for learning about areas of the organisation which is intuitive and generally works without the need for instruction.
Consider that I want a refund using the website of some modern e-commerce brand. I go to the site via link, searchbar autofill or I type the brand name in to a browser and expect the website to be one of the top links. I log in. Then I look in either the top right or the bottom of the page for something that looks like ‘Support’. I might instead need to go to ‘My Account’ first and then look. Through this page in some clear tab I should find my options and be able to initiate the process.
The UX is conventional and consistent and so I can easily navigate it quickly and do what I need to do. This is just a single function of a single product. But there’s no reason our organisations can’t be discoverable and visible in the same way. Following on from the customer support analogy think of the effective model our key visibility docs and indexes create and what they enable.
I am doing my work and somehow find out my team has a problem with flurbs . We have a sense that there is a standard way of doing this in the business but no one has prior experience or confidence. I go to the Product Index and search for flurbs . It turns out flurbs are handled by wizbang . I click in to the wizbang Product Charter and learn more about it. I read the product user docs which are close by and feel confident that this is the right thing and get started. Somewhere along the line I get stuck. I check the support guides that are near the user docs but can’t quite find what I’m after. Using the wizbang Product Charter again I follow the link to the froghopper Team Charter. This tells me exactly where to go for support questions so I follow that. It also tells me exactly who is in the team and their roles and responsibilities so I have a clear escalation path if I end up needing it.
All of the above involves no confusion on where to start. No interruptions of peoples work. No contacting the wrong people and getting passed along. No premature meetings. No middle-man coordinator. No frustration when I find myself on an unhappy path. It’s extremely efficient compared to an alternative.
Why create and maintain specific indexes? Can’t you just search?
Where available search is very useful. But I find an overdependence on a search function can lead to the false belief that structure and composition are not important. Everything can be dumped in to the abyss and we can just search for it. Ultimately we end up with a confused landscape and bad experience. If we’re presenting an important report where we want to convey a message we don’t just dump all of the facts in along with various other half-baked ideas and tell the audience to search for things. We refine, we curate. We try different methods to present as coherent and convincing view as possible. We care for the work and the form matters when we are being intentional and explicit.
What about small organisations?
This is a good practise for organisations of all sizes and will help you scale up and think with clarity about your domain. The focus is on the benefit in larger organisations because they are the most confusing to operate in and where some basic visibility can have the most impact. In smaller orgs everyone is more aligned as there is simply less stuff going on.
How to do this?
If you like this then start with your own team and try to influence your wider group. I strongly believe in the benefits this can bring across the whole organisation for such low effort.
What about organisational charts?
Organisational charts and tools which implement them are great. They do immediately help to provide context and you should absolutely use them. This approach provides more information which is useful and also a truer picture of the organisation because the organisational chart doesn’t fully present a teams-eye-view of what is happening as people in different reporting lines can be working together.
Can this scale though?
If one person or one team needed to do this then it couldn’t work as they would find it so difficult to learn about all of the different teams and products and then impossible to continually update as things change. This is not the proposal though. Every team does their own. They are well placed to do this stuff with ease and there is no good reason each team shouldn’t wish to be explicit about what they do considering the benefits in terms of context-giving and operational function. The trouble is setting the expectation as a standard so leadership buy-in is important.
