7 ms·

Self-Organizing Teams

88 points by bndr 5y ago

pid-1 5y ago
I too work at a 50-something ppl business and that's pretty much how we do things. 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.
MaxMoney 5y ago
I've always thought that the closer the engineer is to the end user the better.
- g051051 5y ago
  Ooof...not in my view. The last thing I need as a developer is to deal with non-technical people.
  - MaxMoney 5y ago
    I suppose it depends on what product you have
    - pugworthy 5y ago
      Or what you do. UI/UX? Close as possible.
      - g051051 5y ago
        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.
CoastalCoder 5y ago
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.
Ozzie_osman 5y ago
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.
- hn_throwaway_99 5y ago
  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.
  - marcus_holmes 5y ago
    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.
deleted 5y ago
[deleted]
cortesoft 5y ago
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?
- beaconstudios 5y ago
  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.
  - cortesoft 5y ago
    If you are electing leaders, it doesn’t sound like a flat structure… you are just changing the selection process, not the ending structure.
    - Nevermark 5y ago
      So a self-organizing hierarchy? 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.
      - mountainriver 5y ago
        It does scale very well in open source, the biggest contributors become the leaders, this can be formalized or not
    - SkyPuncher 5y ago
      IMO flat doesn't mean no leaders. It just means few as possible, long-term dedicated leaders. Individual initiatives and projects still have leaders. However, that's leader isn't necessarily a pre-defined role.
- stocktech 5y ago
bedobi 5y ago
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.
- madeofpalk 5y ago
  This is why I have such a fond appreciation of Good Product Managers. For me, they are the make-or-break factor for a dev job.
  - bedobi 5y ago
    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.
  - andruby 5y ago
    Absolutely. 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.
- mountainriver 5y ago
  Yup they are great at adding more friction to your job and terrible at knowing what actually needs to happen
mountainriver 5y ago
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. It’s dead simple and it works really really well
- BigRedDog1669 5y ago
  > Developers are simply judged based on the scope of their contributions. How would you do that? Lines of code?
  - prmoustache 5y ago
    Some metrics always have to be implemented to make sure the teams fulfill their role. Metrics depend on the kind of role. As a sys admin team we were relying on uptime of the services we were managing.
- fhd2 5y ago
  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
bg24 5y ago
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.
twobitshifter 5y ago
Issues: * Who’s paying who for what? 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.
black_13 5y ago
siva7 5y ago
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.
fjfaase 5y ago
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.
usgroup 5y ago
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.
- prmoustache 5y ago
  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.
gatvol 5y ago
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.
marcus_holmes 5y ago
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.
denton-scratch 5y ago
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.
lifeisstillgood 5y ago
Its all about transparency and democracy. 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?

88 points by bndr 5y ago

I too work at a 50-something ppl business and that's pretty much how we do things. 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.

MaxMoney 5y ago

I've always thought that the closer the engineer is to the end user the better.

g051051 5y ago
Ooof...not in my view. The last thing I need as a developer is to deal with non-technical people.
- MaxMoney 5y ago
  I suppose it depends on what product you have
  - pugworthy 5y ago
    Or what you do. UI/UX? Close as possible.
    - g051051 5y ago
      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.

CoastalCoder 5y ago

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.

Ozzie_osman 5y ago

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.

hn_throwaway_99 5y ago
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.
- marcus_holmes 5y ago
  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.

deleted 5y ago

[deleted]

cortesoft 5y ago

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?

beaconstudios 5y ago
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.
- cortesoft 5y ago
  If you are electing leaders, it doesn’t sound like a flat structure… you are just changing the selection process, not the ending structure.
  - Nevermark 5y ago
    So a self-organizing hierarchy? 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.
    - mountainriver 5y ago
      It does scale very well in open source, the biggest contributors become the leaders, this can be formalized or not
  - SkyPuncher 5y ago
    IMO flat doesn't mean no leaders. It just means few as possible, long-term dedicated leaders. Individual initiatives and projects still have leaders. However, that's leader isn't necessarily a pre-defined role.
stocktech 5y ago

bedobi 5y ago

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.

madeofpalk 5y ago
This is why I have such a fond appreciation of Good Product Managers. For me, they are the make-or-break factor for a dev job.
- bedobi 5y ago
  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.
- andruby 5y ago
  Absolutely. 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.
mountainriver 5y ago
Yup they are great at adding more friction to your job and terrible at knowing what actually needs to happen

mountainriver 5y ago

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. It’s dead simple and it works really really well

BigRedDog1669 5y ago
> Developers are simply judged based on the scope of their contributions. How would you do that? Lines of code?
- prmoustache 5y ago
  Some metrics always have to be implemented to make sure the teams fulfill their role. Metrics depend on the kind of role. As a sys admin team we were relying on uptime of the services we were managing.
fhd2 5y ago
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

bg24 5y ago

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.

twobitshifter 5y ago

Issues: * Who’s paying who for what? 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.

black_13 5y ago

siva7 5y ago

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.

fjfaase 5y ago

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.

usgroup 5y ago

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.

prmoustache 5y ago
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.

gatvol 5y ago

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.

marcus_holmes 5y ago

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.

denton-scratch 5y ago

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.

lifeisstillgood 5y ago

Its all about transparency and democracy. 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?