Reporting lines vs. delivery structures — fight!
There’s a lot of great content around teams and their composition (cross-functional compared to a team with the same skillset). There…
There’s a lot of great content around teams and their composition (cross-functional compared to a team with the same skillset). There doesn’t seem to be as much when it comes to working in larger complex organizations. Complex networked structures with many communication channels often held together by heroic types who somehow manage to keep the organization cajoled together to meet an impossible regulatory mandate involving hundreds of systems to change and continue to work flawlessly.
I recently read ‘A Radical Enterprise’ by Matt K Parker and it reignited my curiosity on the topic of organizations, interactions, structures, and systems. Ever since I first became an architect / CTO I realized that system and people architecture were intrinsically linked together, I later found out Conway's law and things started making sense.
There are value streams, value chains and even value networks. It can be overwhelming, and organizations can be allergic to some of these words as they can come across as buzzwords which are susceptible to parroting or worse, the same word now has a different meaning (which definition are you using) e.g. product is a common example.
There are formal organizational structures that don’t quite hit the mark but help illustrate how organizations have changed over time as they have increased in complexity and in scale, even the work has changed has well.
pre-bureaucratic — (aka entrepreneurial) centralized and typically found in smaller organizations, communication occurs one-to-one
bureaucratic — clearly defined roles and responsibilities, a hierarchical structure and merit is respected within the organization
post-bureaucratic — decisions are based on dialogue and consensus, rather than authority and command, the organization acts like a network
Other types are described in more detail in the Wikipedia article on organizational structure. It’s worth reading if you can make the time but be warned it is extremely easy to go down the rabbit hole.
There’s a whole other type of organizational structure referred to as the informal organization which I think is closer to the delivery structures I think of. e.g., cross-functional team > team of teams > team of team of teams etc.
Large complex organizations have become more network like, rather than simple top-down hierarchies we’ve all seen published in an org chart. This may be the cause of some confusion. If people are expecting a top-down view of the world, that really isn’t how work gets done and it certainly isn’t how people interact. It is often the informal networks that allow you to get work done more effectively (See the book ‘Change: How to Make Big Things Happen’ by Damon Centola).
I’m not sure the name hits the mark though as I want the information organization to be published / accessible by everyone in the organization to enable collaboration and discovery. Think a file system for finding the right teams working on a given product or service — it should also work the same in reverse too.
Too many options
With all these crayons in the box, there’s often too many options to consider. I’d like to see the topic evolve in a way that allows for transitory states and context specific heuristics that allow you to think about the problems you are trying to solve rather than copy-pasting the latest model / framework. This can be particularly dangerous the larger the organization as you are more likely to have heterogeneous groups of people with different customers. Designing and scaling a common approach for distinct types of teams and interactions, is akin to top-down solution or best practices for a complex domain.
This should be where you instinctively now think, this feels very solution focused rather than dynamic and based on context. It is great to learn from models and frameworks but simply copying them in your organization is not going to work. You need to probe and experiment, see what works and reflects. If people come to you with a solution like: Spotify, SAFe, LeSS, Nexus or Scrum@Scale as a way of addressing companywide agility — you should be sceptical and ask lots of questions. If people are talking about problems, teams, and interactions you can have a far more constructive conversation.
This is further complicated when people mix reporting line and a delivery structure. What confuses some people is that these things can be the same or different and that uncertainty is often what causes confusion. Many people in large complex organizations are used to predictable hierarchy x-levels of an organization for budgeting, financial profit and cost center reporting and other related processes.
Depending on how your company is setup you may have different skill-based departments (or you might call them chapters and guilds) - so when you work together as a cross-functional product team or organization you end up having people from more than one department in the same team. Inevitably people from different departments e.g. engineering or product have different reporting lines, even if they work together to deliver a common product.
Team Topologies is a great meditation on team level topics, products, services, and platforms. However, I feel like some language is missing above the team's level. There’s a focus on teams and team interactions but doesn’t have sufficient language to describe a tribe / team of teams sized organization (up to 150 people) that works on a common product or product family.
I’m a fan of Team Topologies language when it comes to team level topics, especially when it comes to thinking about team APIs to illustrate communication and interaction models. Some teams enable others, some deliver to a customer and others provide either a platform or a complex sub-system. If you are starting off in the large and complex, this can be daunting to think about how you continue to deliver whilst also starting to make positive inroads to become more autonomous.
Trying not to forget the blog’s title, the other aspect to consider if you have teams and the people in the teams don’t all report to the same manager, is how they get help, how they grow their professional craft with a support network in place. Having this mix of a self-organization or self-managing team can be quite foreign to many people — especially if your line manager isn’t managing the team of people you work with, but a group of people spread out over many teams. The notion of a chapter can be quite unusual for some, but it is the original intent of the department concept which is to give people career paths and progression with the specific skillset they have e.g. a finance department — it is unlikely you’ll learn to be a better accountant from your cross-functional team — however you might from your chapter / extra-dependant team. Treating all teams one way is a dangerous proposition — teams is even the wrong word to use. A chapter is your home base and your cross-functional / product team is the sports team you are part of (both can be stable) but you may find yourself playing for other teams in the future — even if you still have the same manager / coach.
It isn’t all about technology / product teams
There is some guidance around non-product teams and even a little about service / operation teams and how they can adopt new ways of working (e.g., a help desk may adopt a pull based (Kanban) approach where they have no control over the work coming in, but they can limit how many of the items they work on at any point in time. This is an oversimplification, not all work fits neatly into a help desk vs. product delivery — some work can take many months to complete.
It isn’t always clear how these teams come together, interface or collaborate. throughout the organization. You may have come across extra-dependant teams or enabling teams (from Team Topologies). If the sales department needs to reach out to the legal department or compliance department on an ad-hoc basis it isn’t always a clear path as to how that should work.
There are ways of working at a team level, there’s ways of working inside of an organization in terms of a portfolio, quite often having a straightforward way to interact with other teams or departments is challenging enough, let alone when you are using the agile banner — collaboration and flow is the goal, rather than local agility (p.s. read the Goal by Eliyahu M. Goldratt)
I think at this point, how they work is important to the team but not to the team that needs something from them, they just need the outcome and typically in as short a time as possible — ideally, they don’t even need to talk to the team and instead can rely on great documentation / tooling to help them out.
If your organization is facing a companywide Agile Transformation in a compressed period, it seems clear to me that a one size fits all, top-down model just isn’t going to work. Additionally, if your entire organization is being told to be Agile and they are all eager to get onto the band wagon, you should really think about what guide rails and guard rails you may describe to the teams or you rapidly risk people tying themselves in knots and thinking that their best people will leave because of the guidance written on paper.
Deploying an army of coaches to help roll out ways of working is also potentially risky too. Selling solutions without understanding the context of the teams, the type of work, how work arrives and how work gets done are all key aspects to consider.
This is even more fragile if you start enforcing specific minimum and maximum sizing numbers (people wise) and enforcing those numbers like the ‘agile police’. It’s OK if a cross-functional team has 10 people instead of 5–9 but the teams should be aware of the decisions and challenges they will face (e.g. Brookes law) — the more people, the more communication paths.
There’s value in aligning on purpose, values, and principles (the agile manifesto has some useful ideas, but they can be off-putting to non-tech people) to help guide people in how they collaborate and make decisions. However, telling a sales team to work in sprints or iterations just for the sake of it seems to be missing the point — what happens if new leads come in within the sprint, then what?
Summary
The jury is still out with regards to having a practical set of heuristics people can use, focusing on upstream producers and downstream consumers (or interfaces and interactions) is a useful way to understand a team's part in a wider system and avoids the whole ‘what is a product’ discussion that people can get lost in when they’ve never thought about a product before — especially if their product is actually a human service it can all go south quite quickly and start sounding theoretical — if that happens you may have lost the accounting or audit department.
Many types of teams or even departments in an organization will never be cross-functional, that doesn’t mean they won’t get something useful out of smaller batch sizes, optimizing for flow. If you combine this with regular reflection and continuous improvement you have a chance of things getting better in a sustainable way. If people think they are done and now ‘so freaking agile’ — then you have a problem.