Shape of Work vs Shape of Organization

In software engineering organizations, the shape of the work rarely fits the shape of the organization. The successful organizations I have worked at have been tree-hierarchical or hub-spoke. The shape of work can be forced into hierarchical or hub-spoke, but this is not a natural fit and causes a lot of inequity in work distribution.

Autonomous teams are often touted as a solution to this problem. But what exactly does autonomy mean? I thought it was the combination of capability and empowerment. I was talking to a friend who defined it as "permission." The recent trend of embedding product managers (and other resources like design/UX) into teams has been a big win for productivity. I think this addresses the capability aspect of autonomy. However, it does not really address the shape of work or empowerment ("permission"). I think there is a tension between a focus on specific metrics/outcomes and autonomy. I would define autonomy as not just "permission," but also the expectation to pursue outcomes without micro-approvals at each decision point.

Agency for teams or individuals is more a question of trust. Acquiring agency can be seen as an exercise in building trust. A common antipattern is agency that is not merit-based, but nepotistic, reputation-based, or just without data or method.

During a conversation about self-organizing teams, a former coworker pointed out that product managers don’t take kindly to engineering resources being constrained temporarily or otherwise based on a self-organizing principle. I think it depends on the problems the self-organizing team solves. A resource loss for one product manager should mean that another product is unblocked. In organizations where business priorities are clearly and transparently articulated, engineering resource fights should be minimized. Without clear priorities, self-organizing teams will impact many roles, including but not limited to: program managers, project managers, principal engineering (architect, staff/support), and design (UX). There is an explicit trade-off between being able to solve critical blockers and impacting existing products.

"The best architectures, requirements, and designs emerge from self-organizing teams." - Agile Manifesto Principles

In my experience, self-organizing teams allow for short-term and medium-term alignment around the work that needs to be done, instead of what the management structure is. I find the "self-organizing" principle from the Agile Manifesto to be a reasonable approach to flexing teams so they better fit the work. The obvious issue is that if the shape is not a temporary change, then it will be time to reorganize the teams that are involved.

For example, an "Autonomous Team" may change and no longer have a product manager, UX, and engineers on a single team. The work is now shaped so that there is a data and query team with an engineering manager and a subset of engineers that focus on data integrations (with the same manager). Both new self-organized teams share a product manager. The entire configuration and user interface team is split out and is tightly coupled with another product group.

If done right, a self-organized team is an effective experiment in a small reorganization. It is a minimally disruptive iteration in an organization that pays down the accumulation of organizational debt. If we think of self-organized teams that start as experiments which will, after a preset time, return to the original team structure, it makes them much more palatable. Since the individual contributors on the team will continue to report to the same management, it requires very little shifting of politics.

Keizan Gus Shaffer for the feedback and discussion.

Jonathan Pearlin for 10 years ago discussing the origins of this post.