Manage Work not People

Lean / Kanban was always about managing work instead of managing people. Often mention as Manage the flow. Organizations are about organizing people, but they should be about organizing work instead. As organizations grow, it's harder to make an impact and easier to get benefits. Safi Bahcall, the Loonshots book, says that as organizations are growing, the perks become much easier to get rather than impact(outcomes). That's why politics and empire-building strike. Leaders need to be explicit about managing flow. Otherwise, organizations tend to focus on local hierarchies and produce local optimization(classical Lean issue).  If we should manage work/flow instead of people(Some coachs also called it to manage the system). Should we have teams? Are teams silos? Are silos always bad and wrong? When should we create a team? When should we decommission a team? Work often happens on teams, people leave and join companies because of teams, but would teams get into the way sometimes? How to properly handle cross-team coordination? 

What's, is the goal?

In his classical book The Goal, Goldratt tells a tale about a factory about to bankrupt. Which is a classical Lean book, by the way. Where in this book be basically say that Lean does not work in 2 scenarios:

1. There is no Demand for your product

2. You dont want to change

I would argue that most of the companies fall under #2 rather than #1. In this amazing classical book, he says that you need to work on 3 key metrics(Throughput, Inventory, operational expenses):

• Throughput = Rate of the system generates money through sales
• Inventory = All money system has invested purchases in things that intend to sell
• Operational Expense = All money system money spend to turn inventory in throughput 

However, in the book, he does not state this formula right away. He tells and interesting tale about friends trying to save a factory and learning Lean principles, and discovering important principles.

Back to The principles

Lean comes from manufacturing, where we had factories. We often consider the word Factory as a bad thing within the technology industry, such as Software Factories, Feature Factories, etc... Often, the factory is a bad word because it is associated with Top-down, high hierarchy, low feedback, and waterfall-ish processes. However, a factory is all about flow and working to optimize flow rather than manage people. In some funny sense, we need to have more factory thinking towards flow, not towards rigidity; software requires high adaptation, high flexibility. Sometimes, this flexibility is called Agile. The industry turned agile in the thing agile fight so hard, which is: a rigid process. 

Lean has many principles, and one of them is called See the Whole. See the whole factory. In order words, you need to understand the complexity and embrace it, embrace the fact that there are no simple answers, and stop local optimization.  So are teams just silos? Do teams get into the way? 

Aron Dignan has a fresh perspective on that. In his amazing book Brave new Work. Where he sees an organization as an Operational System and focuses on work dynamics to tune key aspects such as Purpose, Authority, Structure, Strategy, Resources, Innovation, Meetings, Compensation, and much more. IMHO this is Lean for 2021. Is so cool to see this new manifestation.,

Teams: Friend or Foe?

Teams could be considered silos easily. Teams are where the work happens. Silos allow you to reduce communication and maximize re-use. Teams allow focus. Focus is a double edge sword. Simultaneously, teams allow work distribution(look at team topologies book), but they also have blind spots. In what ways can we handle teamwork better? A team like a company; in other words, the team strength is the team's weakness. Simply put: A company can do what team and process can do.  

There are several ways we can organize teams: Platform, Stream Aligned, Subsystem, Enabling team (According to team topologies). Platform and Subsystem teams tend to work as facilitators providing services, tools, and abstractions. Subsystem Teams and Enabling teams work on as a Service model, and Stream Aligned teams are towards collaboration.  

Platform teams often are technology teams and structure by function or tech layers. . i.e., Postgresql Platform Team, CI/CD Team, Security Team, Linux Team, Application Stack Team, etc... Platforms are not limited to tech functions and could and should be used as part of the business domains such as Payments Teams, Growth Team, Accounting Team, etc... Platform teams can be good or bad depends how you organize them and govern them.

Most orgs dont apply DDD to teams in tech organizations, and other teams are either technology or function-driven or even both. What's the issue with the Postgress Big Data Ingestion team? Well, that hyper-specialization often has lacked flexibility and will require coordination with other teams. Data Meshes specifically pushes for Domains(DDD) and Non-Hyper-Specialized Teams. 

From time to time, as time passes, Function / Technology driven teams have issues. What happens when we run out of MySQL work? Or what happens if we need to deal with Cassandra now? It's common to have to borrow resources from other teams. So when thats is fine and when it's not? There are different ways to deal if that. One possible way is the classical PMO approach. You have an external entity looking up to teams and doing cross coordination and evaluating when creating teams and when shutdown teams. 

There are other solutions in self-management, such as the Swarming and Swarm Board approach, by the  Tim Ottinger(Modern Agile). 

There also plenty of Team Charters to allow teams to figure out their purpose and execution dynamics. Aaron Dignan(Brave new Work) also mentions Team charter in his book. Here is one cool format to create a team charter.

As much as you can push to the edge teams, the better. That's also a concept quoted many times in the Byond Budget Book where they go on and on why radical decentralization is needed and actually better. IMHO teams alone are not the problem, but whatever else you do or dont. IMHO specialization is fine and desirable to some extent - however, often, you might not want hyperspecialization. 

The author of the book Range asked - what's best, a Frog or a Bird? One sees deep, the other see breath, so what's best? Both! We need a booth. IMHO there are different needs in product and technology organizations. However, I'm sure that you should treat people as grown-ups and manage the work, not people. 

Change is about Learning

It's so easy to enter the auto-pilot and just do tasks every day. It's so easy to do the same business as usual as all companies do. There is no change without Skin in the Game; there is no Change without learning. There is no learning without curiosity and seek for understanding. Learning is a continuous activity, a team that makes sense today might not make sense tomorrow. Retrospectives are important, review process for continuous improvement. Managing people is not the point. What matters are what the company learns and unlearns as a whole and how effective it can learn or not. 

Cheers,

Diego Pacheco