Information Wants to be Free
There is something magical that happens when project management dashboards start to show the way to the goal. The teams become self-directing and in complex and chaotic situations, self directing teams are a super-power. But you can't get there without a correct information architecture.
Information wants to be free. But it needs to be contained.
If we liken information to water, then we have a good analogy for discussing freedom and containment. Like information, water also wants to be free, free to flow and follow the path of least resistance. But in order for water to be useful, it also needs containment. A river is useful when it is contained by its banks. When it ceases to be contained by its banks, it turns into a force for destruction.
Information is the same. When allowed to flow willy-nilly, wherever it wants to, it becomes a force of confusion. And this confusion sneaks up on the org and takes it by surprise. Conversations like "Is X done?" "Wait what? No we decided to do Y instead remember?" are typical of orgs where information is not contained well.
In the context of Product Engineering, have you had such a conversation -
— svs 🇮🇳 (@_svs_) March 9, 2023
- When will X be done?
- Wait, we decided not to work on X right?
Even in the best run orgs this is a problem because entropy and the heat-death of the universe.
We committed every kind of error possible there – errors of omission where we forgot about projects entirely, errors of commission where we worked on things that we had only decided not to, and errors of prioritisation.
And this was in a small org with 3 devs, 3 ops and a few sales people. I found it so embarrassing that I could not answer such basic questions – what are we working on?, how far have we got?, how far do we still have to go? – that I decided to fix this. This is the foundation of all Project Management. This is the foundation of 'estimation' and building trust in execution.
The three questions
The basis of all Project Management, is very simple - at any point in time you have to be able to answer these questions
- what are we as an org working on?
- how much is done?
- how much is still left to be done?
There are a few things to notice here. Notice, for example, that we're not asking 'when will it be done?'. That question leads to a lot of wasted energy, which is a topic we can discuss at length in a subsequent essay. For now, let's just agree to agree that the 'when' is not a top level question.
And yes, there are levels to this. For example the first question can lead to a bunch of follow-on questions such as 'are these the right things to be working on?', 'what is the relative priority of these tasks?' and so on. It also leads to these tricky question – 'are we working on what we think we're working on?' and 'are we agreed on what we agreed to be working on?'. Now naturally some of these questions might seem excessive to you but at a certain size of company or with certain trust dynamics they do become relevant. However, these are outside the scope of Project Management so we will park them for the moment.
When seen through the lens of Project Management then, any information flow that does not report itself in a meaningful way then will have to be duplicated in the reporting stack. ie if we keep chatting on Slack we cannot reliably tell what we agreed to be working on and so will have to maintain this information elsewhere.
*Disclaimer - Slack is fine if you're a team that sits around one table – where coordination is cheap and direction changes frequently. But where you need larger teams to be locked on to a moving target, Slack is doing more harm than good.
The whole point of information architecture then becomes – how do we do our work in such a way that the work reports itself as it happens.
A simple example might suffice to illustrate – instead of talking about an issue on Slack, what if we <gasp> discussed the issue on the ticket itself? That way a number of things happen – we maintain the whole history of the issue in one place, which becomes super important when we want to summarize and reflect on our activities. It also has the added advantage of keeping all stakeholders included in the conversation. And if we are using the issue tracker to discuss the issue it is much more likely that all our other data points on the issue such as when it was created, when it was started, when it was assigned to whom, when the PR was raised and merged (ie the MLT), all of these become correct and meaningful.
But a word of caution – there is a difference between reporting and summarization. If you believe that there is some magic data pipeline from your OKR planning sheet to your issue tracker to your stakeholder reports, then you're mistaken. Human Attention is required at every level of abstraction and yes, this is a good thing.
Why it's important.
There is something magical that happens when project management dashboards start to show the way to the goal. The teams become self-directing and in complex and chaotic situations, self directing teams are a super-power. Modern product development deals with so much information that no one level can have all the context. In this situation having teams that can correctly decide next steps on the ground means that those with the most context are driving tactical decisions.
But in order for this to happen, we need to make these dashboards first correct and then useful. And in order for this magic to happen, we need the information flows into these dashboards to be correct.
Correct information architecture is a necessary condition for building teams that can execute reliably towards their goals because at any moment everyone can answer the three main questions
- what are we working on?
- how much is done?
- how much is left to be done?
This requires a change in habit and is not trivial, but the benefits of it are well worth it.
To be continued...
I'll write more later about why Slack and Notion are not good for information architecture beyond a point. Hint ->
What state is your company Notion in?
— svs 🇮🇳 (@_svs_) March 2, 2023
I'll talk about the psychology of what makes these so attractive, what to do instead, how to change behaviours so that you get an information architecture that leads to useful project management in a virtuous loop that leads to empowered product teams.
A final note
Almost all the content on engineeringorg.com is free. However, it would be great if you could support the publication with a subscription. Ghost doesn't allow one time payments but if you get the annual sub I'll make it lifetime free (this is for everyone, including if you've already paid).
