Team Infrastructure: A New Way to Think about What “Those” People Do
A black and white illustration of a complex plumbing system, with a funnel input on the left flowing through various pipes, gauges, and valves to produce a diamond on the right, representing how raw information is transformed into valuable outputs.
When a team or project has Business Analysts or other middle-person-type roles and those people are doing their work well, then things just work better. People often can’t tell you what exactly is making it work — they might say it is We’ve got a great team
or I have space to do my work
or This is a fun project
. Or something else entirely.
And yes, it could be all those things, but I think that it’s likely that you’ve also got your team infrastructure set up well. And further, thinking about those middle-person-type roles as providing team infrastructure is a really awesome way to understand (and extend) the value they bring to your crew.
Introducing the concept of team infrastructure: a new way to think about the value those middle people bring to your team.
Introducing team infrastructure
I’ve had a brainwave. Well actually my partner did, but it was based on something I said — and what do we care about him anyway? Editor: Ahem!
I’ve written previously about some of the odd parts of working as a Business Analyst. You can easily become the piggy-in-the-middle, or regarded as a master of none. It is a fate fairly common to all those middle-person-roles on a project or a team. But when done well, those middle people seem to be doing something really important that shouldn’t be discounted: they provide team infrastructure.
Let me explain.
But first, TL;DR:
- Teams run on information
- Middle-person-type roles deal with information
- In practice, those roles involve lots of infrastructure-like activities
- These include caching, routing, logging, and more
- Thinking of middle-person-type roles in this way is helpful!
What is team infrastructure?
Infrastructure is the underlying foundation or basic framework that makes everything work: plumbing, roads, traffic lights, etc. Commonly, these are considered mundane, maybe even boring … until they’re unavailable.
And what do modern teams — a group of people working together to create some outcome — run on? Candy? Petrol? Story points? Nope, they run on information.
Information is a tricky thing, especially when humans are involved — Agile
ceremonies and other team events can only do so much to address the complexity. The more people you have involved, the more complicated it gets! Each new person adds new information flows to your team. The two pizza rule actually makes a lot of sense:
Arguably, the vast majority of team ceremonies and practices are, at core, trying to facilitate the flow of information.
Stand-ups? That’s how team members know what everyone else is doing. Demos? That’s how people outside the team know what the team has done. Refinement? That’s how to make sure a problem is understood by everyone.
I could go on …
Going with the (information) flow!
And yet, despite the importance of information flow in a team, most people downplay the parts of their role that focus on facilitating it — except of course for Agile folk — and focus on the flow of information to us.
We’re analysts/designers/researchers for heaven’s sake — we analyse, design, and research!
We don’t do admin.
But I suspect that this is actually limiting the value we can bring to a team. We’re already dealing in information. By reframing our work, or seeing it through the lens of team infrastructure, we can radically increase the value we’re adding to our teams, projects, and organisations — and with little additional effort.
Now I’m not saying the middle-person roles are the only roles on the team contributing to team infrastructure: everyone needs to contribute for the team to function. However, the nature of being in the middle and being the connector between different perspectives makes us uniquely placed to contribute to the solution.
And by conceptualising our work this way, we can serve the team (not just ourselves or our outputs) better. And serving the team is especially important as it is the mechanism through which we deliver value to our customers.
So, how are we infrastructure?
Easy. Let’s start with caching.
I collect information about everything. But I’m especially interested in information relevant to my team. It’s because, like most middle folk from a Business Analyst background, I’m nosey AF. I love knowing what the dev is focusing on for the day, what the product manager is mulling, and what the exec’s next priority might be.
And while the primary benefit of this is that my team members get a heads-up on goings on (and are the first to hear the gossip from the board meeting), another, arguably more helpful way of looking at it is that I’m building a team information cache.
A cache is a high-speed data storage layer which stores a subset of data, typically transient in nature, so that future requests for that data are served up faster than is possible by accessing the data’s primary storage location. Caching allows you to efficiently reuse previously retrieved or computed data.
Reconceptualising it as a cache totally changes the value proposition. Instead of gossip and backchannel information, it has value. We can use the information we’re already collecting to protect our team (and others) from unnecessary interruptions, context switching, and repeating themselves.
As I’m going to say frequently throughout this article, you are probably already doing this, and by doing it consciously and deliberately, you can do it better with little additional effort.
But it isn’t quite a free lunch as there are some things to keep in mind.
Caching mindfully
Unlike gossip, team information — especially when being used by other people as reference material — should be as complete and as accurate as possible. Some information (such as team members names) are slow to change, other info is volatile (such as what a team member might be working on right now).
When presenting your info-cache as an accurate source, you need to be aware of when your information is getting stale, and when you should refresh your cache.
Happily, no one expects this kind of information to be 100% accurate all the time. You are better off considering yourself an eventually consistent source. But even eventually consistent information requires effort to collect. To do this really well you should be having regular catch-ups and chats with other information nodes in your network.
And finally, remember that some things simply aren’t suitable for caching (the no-cache
header scenario). In this situation, you’re better off routing the request to the appropriate authority or expert.
Which is a perfect segue to …
Are you a router?
Simply put, routing is the process of getting information from where it is now to the place it should be next.
Like actual network routers, a person-as-a-router has three key functions:
- Path determination: Deciding where the information should go. You’re doing this when you decide what information should be included in requirements, that design, or that email.
- Data forwarding: Actually getting the information to that place. You’re doing this every time you forward an email or send an
FYI
message to your crew. - Load balancing and redundancy: Ensuring information flow is effective. You’re doing this when you redirect information to the least busy team member, or when you tell multiple people of that feedback from your exec to ensure it is really heard and understood by your team.
Again, you are no doubt already doing this when you think about it. But thinking of the information flow as a function in and of itself has two powerful impacts:
- It stops us from focusing on the the outputs of our work (acceptance criteria, user stories, wire-frames, reports, requirements, etc.) in isolation in favour of focusing on the information flow process itself.
- It enables us to focus on what aids the flow of information to, from, and within the team.
Don’t get me wrong: the outputs are important. But not as important or as valuable to the team as getting information to the right place — where it can be put to use as soon as possible.
Avoid the scenic route
However, this is not to say that you should stop producing artefacts and outputs in favour of being the go-to information junkie. We’re trying to get shit done after all.
Oftentimes, those outputs and documents are the means by which the person-as-infrastructure is providing information persistence and permanent reference points for the team — another key value-add.
Logging
For the record (heh!), I’ve always hated taking meeting notes. So much blah blah blah to get down in a short space of time, and juggling between engaging with the topic of conversation and how best to summarise that point is exhausting. Not to mention that it often seems pointless — how often are meeting notes ever referred back to?
Well, with approximately the same frequency that we look at log files. And aren’t they sort of doing the same thing? Logging — whether technical logs or meeting logs — is a form of risk mitigation. You hope you won’t have to trawl your way through them in the future, but if you do need to, it’s usually a case of boy, you really need to.
Persistent data in the field of data processing denotes information that is infrequently accessed and not likely to be modified.
A funny thing happens when you reframe this sort of admin into the creation of persistent team information. Suddenly, the focus of the meeting notes changes from what was said to what needs to be on the record and what could help someone to troubleshoot later.
Longer term storage
Truthfully, a lot of what we do is to document things formally. What are requirements if not a form of persistent record keeping of what needs to happen to meet a business objective? What are designs if not a form of persistent record of the expected outcome?
We document requirements so that there is a central source of truth for what was agreed. This way the team understands what is being attempted and why. And we store our documents in a format that is best suited for longer term storage and reference.
Format? Lawdy, that feels like a whole topic in and of itself!
Not yet convinced?
Caching, routing, and logging aren’t the only infrastructure concepts that can help frame (and extend) the role of operating in the middle
. I think I could make a solid argument for many if not all the different types of network infrastructure.
Here are some additional examples:
- Filtering: You do this when you’re selecting what information should be passed on and with what degree of detail. For example, not sharing with the team a suggested enhancement to a feature until it has been validated. This protects the team from unnecessary action in response.
- Queuing, ordering, and sorting: You do this all the time. But especially when you’re selecting what issues to escalate to your product management, or which things can be parked until later. You can’t do everything at once, so you have to prioritise the important stuff first. Sometimes that email will simply stay unread for a while and that’s okay.
- Mapping, parsing, and conversion: You do this when you translate information across mental models. For example, when you convert the PO’s feedback into dev language, or when you translate what the dev said into constraints for the PO.
And I’m pretty sure there are both more ways to reframe the our role and more concepts that we could use to discuss how what we do supports the team. but I suspect I’m belabouring the point now (I can see my partner’s eyes glazing over 😂), Editor: how did you know? so I’ll leave it there.
Disclaimer: This article was originally written from my perspective and from my experiences of working as a BA in an agile environment. While I’m sure there’s value in applying the idea to non-agile settings, I’ve not done so, nor have I thought that out!
In other words, as with everything in life, apply mindfully to your context!
Final thoughts
While I was mulling the idea behind this writing this article, I found myself more aware of the parts of my role that are focused on information flow. Suddenly everything was caching, data persistence, flow efficiency, and more. I began to lean into opportunities to enhance the flow, rather than to reject them as boring admin
, and saw first hand the value it was creating.
In other words, I was seeing the information system.
I suspect we often think our artefacts are the value we’re delivering rather than thinking about the impact of our work on the system. We expend effort on making our artefacts and processes better — we practice how to write better user stories — but we don’t consciously work to create better teams.
But maybe we should.