Philosophically I love a lot of the ideas of self-organizing teams. In reality, they are very difficult to implement. Hierarchies work because they allow someone close to the work to take a very deep, detail-oriented view, while allowing others to operate at broader, higher layer of abstraction. Someone can think about the why, while others think about the what and how.
That said, hierarchies can be soul-crushing for a lot of reasons. Still, I've found hierarchies work best when infused with a lot of the ideas behind self-organizing teams (ie as much end-to-end ownership as possible, as much autonomy as possible, etc). This only works if you have a high-functioning group of team players who all trust each other, and managers who don't act like pointy-haired bosses.
I actually think this is a false dichotomy, and a common misunderstanding. You do get a hierarchy in a self-organising team. The self-organisation will re-produce itself, and produce a hierarchy with components from within the system itself.
This is how we view it in my company. The difference between self-organizing and traditional methods of organizing is the following:
In traditional methods of organizing, the hierarchy is fixed, and embedded within a specific role. i.e a Product Owner. Usually it is also imposed from outside.
With self-organization power is "fluid" , in that it shifts based on the circumstance and context. The system itself will internally produce the hierarchy. This hierarchy is emergent based on the specific context, in order to deal with the specific situation.
To put it simply, a self-organising system is much more adaptable. The hierarchy and structure is emergent. Organisation is not imposed from outside, but from within. The hierarchy itself can shift from moment to moment.
Very much agree. As someone who has been involved in something similar to "self-organizing teams" in the past, I'll take a hard pass. The primary issue is that there are usually hard external constraints on the business (e.g. client deadlines) that make self-organizing teams a recipe for chaos and inefficiency.
I find a culturally-ingrained model of "servant leadership" works much better. For example, most programmers I know are happiest when they are programming. An ideal management chain would take care of all the other (often shitty) work so that the product team and programmers can just focus on building the product, and they are given the freedom to build that product in the best manner they see fit.
I have found that devs really only work well in a team using servant leadership style. Especially if the leader can't code and doesn't understand how software development is actually done.
There is an interesting anti-pattern that happens where the "alpha geek"[0] is actually leading the team and the designated manager isn't in charge at all. This can go well, or it can lead to disaster, depending on the personalities involved. I suspect that a lot of success stories from "self-organising teams" are actually succeeding by removing the designated manager and allowing the "alpha geek" to lead without having to fight about it.
[0] not a derogatory term, just a metaphorical take on the relatively common occurrence of developer teams creating ad-hoc hierarchies based on experience and personality.
> Hierarchies work because they allow someone close to the work to take a very deep, detail-oriented view, while allowing others to operate at broader, higher layer of abstraction.
I almost never see this happen in real life. Maybe for a little while when a team first starts to establish hierarchies. But it always degrades, in my experience, until there exists an middle layer of management that only serves to slow down productivity. If you want to find out what's going wrong in any large corporate minded software studio, the managers will never give you the correct answer. Go ask the thought workers in the trenches as they typically understand why productivity drops off a cliff. When you have a brilliant visionary at the "broader, higher layer of abstraction" with the productive members of the team reporting directly, magic CAN happen. But largely, "managers" and similar roles are useless bloat. Same goes for the PM/producer type roles. I have a friend who started a game development studio a few years ago and committed to NEVER hiring a producer. It was bold. It's going really well and I think he's totally on to something. IMO, you can build better teams without those roles involved at all.
I’ve been reading the Mythical Man Month and I think that book has a lot of good ideas.
The issue I find is that often leadership of hierarchical organizations is given to nontechnical glue person.
These people eventually bubble up and become “middle management,” as they amass visibility and receive credit for the products their technical team built.
There is no vampire of workplace productivity like a nontechnical skip manager directing project priorities.
I want instead all the nontechnical support personnel to be relegated to being assistants like in Mythical Man Month.
Ultimate leadership and ultimate responsibility for delivering a software project must be embedded in a technical leader.
Nontechnical product owners are a true blight on society.
Perhaps I am misunderstanding you, but wouldn’t those two non-technical roles have pretty significant reason to have ownership/input into a product?
I could see extreme positions on every end I guess.
The Marketer has no idea what is technically realistic and makes promises to customers that are not technically feasible.
The Accountant paralyzes decision making and reduces expenses via a variety of counterproductive means to protect the bottom line.
The Engineer just wants to build cool things and does not really care if it makes money or customers actually want it/might find it cool. So long as curiosity is piqued and we can give it away for free to other engineers.
I think they all have a role to play in the process, given that at the end of the day, you can’t have a product without money, customers won’t buy a product if it is not appealing/meets their requirements/something usable, and you can’t have money or a marketable product without people building it under mostly realistic expectations.
Of course they should have a role to play and input. They should be part of the discussion.
It's a question of responsibility for delivery. People in those positions shouldn't be the owner, who is accountable to the business for features being delivered.
The person responsible for features being delivered should be technical.
> If you want to find out what's going wrong in any large corporate minded software studio, the managers will never give you the correct answer. Go ask the thought workers in the trenches as they typically understand why productivity drops off a cliff
Feynman said the same thing about NASA, in his report on the causes of the Challenger disaster.
> Someone can think about the why, while others think about the what and how.
I've found it's really important everyone understands the why as well as the what and how, as knowing the reasons drives much of the decision making even at a low level.
One of the best combinations I have seen was with hierarchies that allowed for two people at the “top” of the local hierarchy. One who is more of a generalist and people manager, with the other being an experienced technical SME.
I do not like arrangements I have seen with how that division works with EMs and PMs.
EMs, from my experience, become too far removed from the technical work and too involved with people management.
PMs many times are not necessarily good people leaders OR technical leaders.
Not to say I have not met some truly great PMs and EMs, as well as teams where both people in those roles just clicked. But it was not as a matter of organization, and more because they were exceptional people who would excel in any organizational structure.
There needs to be some executive decision making to make this work whether or not to follow up on a goal or new project. Without this there’s no cohesive nature to the organization. The OP article is in client services which gives the advantage of the client serving as executive and making many decisions, however you could imagine what would happen without this clear external reference. In the client services they are each acting as independent contractors on a team which isn’t an uncommon thing in consulting.
* How are bad behavior and bad teammates dealt with?
I could see some people I’ve worked with running this system into a ground.
A common counter to this is something along the lines of "<bureaucrats with title t> are necessary because someone has to think about <something> blabla" where something is usually strategy, business, concept, product, whatever.
It's true someone has to think about those things! But in my experience, most of the people who do it are terrible at it and just come up with endless important sounding grand initiatives that are really just bullshit. But they are very good at making them seem important and portraying them as successes by perverting data etc etc.
So even if you're in an org where implementation is very efficient (cross functional teams etc), at the end of the day, you're just being very efficient in implementing bullshit.
To me it seems like the best orgs are those that have efficient implementation combined with a very simple goal that everyone can appreciate and so there is little need for such bullshit.
Me too! I know it probably sounds like my comment belittles everyone with those titles, but I'm not. I guess what I am saying, in my experience, Good Product Managers are extremely, extremely rare, and ones that peddle bullshit are extremely common, and unfortunately, it's probably all but impossible to tell which is which during a hiring process, because they will all portray everything they've ever done as a massive success.
I often say that "doing the right thing wrong" is more important than "doing the wrong thing right". In other words: the choice of which problem to solve is more important than how you solve it.
It's nice to hear that they've found a net-gain by using self-organizing teams.
The article posted plenty of benefits, but I didn't notice any mention of downsides. My personal experience with self-organizing teams has been quite the opposite.
I'd love to hear back from them in a few years regarding how it played out for them. It would be great to have more data to predict when self-organizing teams will work and when they won't.
It would be excellent to get there (self-organizing teams) eventually. In fact, it should be the norm in startups. For everybody else, the teams need to have very mature decision making skills to get there. It does not happen in reality. I have seen numerous screw-ups (eg. team making a decision to change a product functionality without analyzing the impact on the rest of the organization, making a decision to release something without realizing the legal issues, getting the product strategy misaligned). IMHO, all these can be solved in ideal situation and right people. Self-organizing teams will continue to be an ever evolving journey in non-startups.
I think this is a great step and something that needs to be talked about more. To me breaking the strict hierarchy is the new remote work.
What I’ve seen work really well is treat all products like open source projects. Some people call this “inner source” but that term is a bit muddled.
Work is organized around projects and functionality, not dumb middle management. The group around the project keeps an open backlog, anyone is welcome to participate in meetings or pickup tickets.
Those that contribute the most get the most say, a true meritocracy.
Developers are simply judged based on the scope of their contributions.
FWIW, I did that for years quite successfully in an organisation with about 80 engineers! At that scale, it works, in my experience, not worse than an org with lots of managers - they're gonna do infighting amongst each other at a certain size anyway :P
Self-organising fails horribly in the presence of malice. Bad actors at any level break the communication and spirit.
Having a hierarchy allows for leadership to spot bad actors and take action. It does not of course eliminate bad leaders - but there is reasonable chance that you can select for good actors in leadership more easily than selecting for everyone to be good actor.
However, if we introduce transparency - allowing everyone to see the output of, and decisions of, everyone else and democracy, allowing all those (stakeholders) to vote on projects / allocations, we might have coherent teams that have geneuine ownership.
(as opposed to teams that feel ownership over a product, right up until the Boss sacks them, equity event shows they have not voting stock etc etc)
Edit: Software changes the calculus of running an organisation. By pulling everything about a company out into code, it is possible to view and review the whole company and make explicit changes with an expectation of success based on modelling. A company will become immutable - able to run forever if nothing else changes. The problem is reduced to how to manage the organisation that changes the company. This makes a focus on people who can write code that changes the company. Why have anyone else on staff?
I think hierarchies are optimal for command and control but they work best when power is not distributed hierarchically as well. Ie some kind of bottom up feedback that keeps the upper levels of the hierarchy directly valuable to the lower levels all the way up.
Self organisation that doesn’t end up having leader nomination needs something like voting or consensus driven decision making instead : I haven’t seen that produce good decisions efficiently.
I've worked in a company working in holacracy. Some people are more active or passive than others. Some people are more vocals than others. Some people have better social and negociation skills.
In the end although there is no hierarchy per se, some natural leaders emerge, and they are usually best suited for the job than some managers who are clueless about what the team is doing because they still have to do the job and be accounted for.
In my experience, having multiple people own a thing means that no-one owns it. Usually what happens is that officially "we all own this", but unofficially "if you touch this without consulting Sharon, she'll be pissed off".
Or it gets dumped into the "no-one wants to touch that, if it goes wrong we have to coerce someone to go fix it, badly, and late" bucket.
I am always curious how self organizing teams scale when tackling huge problems that no single person or small team can fit in their head. How do you coordinate your efforts when no one has the whole picture?
This approach doesn't entirely eliminate structure. Often you still have a layer of people dedicated to identifying, prioritizing, and breaking problems down into manageable sizes. They're just not the ones dictating who solves the problems.
I simplify it as "Kanban, but for problems". Instead of a person creating a list of tasks for a team to do, they identify and define problems important to the organization. Teams then self-create around those problems to solve them.
I did self organizing teams at a startup where Engineering grew from 20 to 100. It sounds like the article had the same philosophy, but implemented it differently. We didn't eliminate roles, but the roles became more fluid along with the person that was performing them.
Before, one person would receive and coordinate work among the team - the tech lead. After, we had a rotating roster of people who were interested in solving problems that would act as a tech lead. This was in coordination with our Product org.
You create an open participation group which focuses on these problems. Anyone can contribute to that group and it meets on a regular cadence. I’ve done this many time and it works wonderfully
Through cooperation - it's not like you can't work together in a flat organisational structure, or even elect people to deal with higher order concerns for the duration of a project.
My instinct is that wouldn't scale. Self-organizing gets more complicated, and usually more political, inefficient, and disorganized, the greater the distance self-organization spans.
But I don't know any organizations that actually work that way, so have no data.
I have come to the conclusion that what happens on the lower-level of the organisation depends on the attitude of the CEO. If he is a persons-first person, this will lickly trickle down to every level. The same as with a results-first person. You basically have two types of managers: those who stand up for there team and those who want to control their team.
This may work in a startup but seems like a recipe for disaster in a traditional established corporation. We have seen many flavours of no-management, zero hierarchy engineering frameworks been sold as the ultimate solution to all problems but there lacks independent data about the efficiency compared to traditional models.
I'd love to know if there's any knowledge sharing across these self organising teams; how does the larger org ensure that the work produced is consistent to some baseline; is secure, maintainable, observable etc without having massive tool and platform fragmentation issues.
The goal of removing hierarchy is pretty challenging; it's been convincingly argued that the absence of explicit hierarchies often simply results in implicit, invisible hierarchies.
In a situation with invisible hierarchies, it takes a newbie a lot more time to learn what power they do and don't have. There are still power relationships; but they're less obvious and transparent, much harder to navigate, and much harder to modify.
My point isn't that non-hierarchical organising is impossible, but that it requires constant attention - frankly, I don't think it's possible unless removing hierarchy is a key aim of the organisation. That is rarely the case, unless the organisation is a more-or-less left-wing political organisation. A commercial organisation will hardly ever put eliminating hierarchy centre-stage.
So removing explicit hierarchies is likely to be counterproductive, in most organisations. You end up with implicit hierarchies that are harder to understand and alter, and so more rigid. If I were joining an organisation, I'd sooner it were one with clear, explicit hierarchy, or alternatively one dedicated to the removal of hierarchy.
To be clear, you can't completely remove implicit hierarchy. Dominant people tend to dominate, and an explicit hierarchy mitigates that. Dominance might derive from force of personality, having a loud deep voice (men!), knowledge, eloquence, and "who you know".
So non-hierarchical organising requires a lot of effort, and definitely slows down decision-making. It has a cost.
One of the worst, most difficult projects I ever worked on was where I was forced into direct interaction with a "customer". She was a nice enough lady in general, and knew her subject area, but she had no technical skills at all. We were paired up to improve a part of the UI and we struggled because she would ask for things that were technically impossible, and get upset when I told her we couldn't do it. It got so bad that she complained to my boss that I wasn't doing my job as her "support person". Fortunately, my boss cleared up her misconception and we finished the project. But her fundamental failure to understand the technical limitations of the hardware and software, as well as not seeing me as a partner, were a huge hurdle.
That said, hierarchies can be soul-crushing for a lot of reasons. Still, I've found hierarchies work best when infused with a lot of the ideas behind self-organizing teams (ie as much end-to-end ownership as possible, as much autonomy as possible, etc). This only works if you have a high-functioning group of team players who all trust each other, and managers who don't act like pointy-haired bosses.