Self-Organizing Teams
vadimkravcenko.com
vadimkravcenko.com
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 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.
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.
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.
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.
Ask any engineer whether Marketing or Accounting should have product ownership.
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.
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.
Marketing should sell your product, not tell you what to build. Same for accounting. They should tell you what is selling or what is not profitable.
Feynman said the same thing about NASA, in his report on the causes of the Challenger disaster.
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.
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.
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.
* YCombinator?
* Edit for clarity
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.
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.
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.
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.
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.
It’s dead simple and it works really really well
How would you do that? Lines of code?
Metrics depend on the kind of role. As a sys admin team we were relying on uptime of the services we were managing.
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?
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.
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.
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.
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.
Individual initiatives and projects still have leaders. However, that's leader isn't necessarily a pre-defined role.
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.
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.
As we grew, it honestly never occurred us we needed managers or PMs.
Just pay people well, give them freedom and good incentives (read: bonuses instead of fixed pay) and they will find the best way to get shit done.
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.