I wonder if a certain type of software business is most amenable to this.
For instance, if you are a growing SaaS that doesn't need to pivot, but rather to scale and add features.
In that case, a certain number of your objectives are inherent and obvious. Features that exist should be stable. Features that work now, for the current number of customers, should continue to work as more customers are added.
Well, if your SaaS is doing something valuable, just meeting those criteria is likely to involve a lot of work (otherwise it seems the product wouldn't be valuable), and profitability (customers indicate that it's valuable with their wallets).
And at least for some subset of SaaS companies, up to a certain number of developers, those criteria can be met by developers looking at metrics and saying to themselves, "hmm, this or that bug exists that I can fix", or "I wonder if it would be worth it to containerize the app and write tests that work against the whole container," and do a feature branch and then a PR, and if this initiative turns out to be new or valuable enough it eventually gets written into a blog post and may become part of the nature/value of the product, or contribute to the culture of the company.
So for companies with the right circumstances, I can readily imagine that the jobs that bosses do can be replaced by IRC, Github and the obvious objectives the product itself provides.
I don't know how it would work for companies more generally.
For companies that are still trying to decide what to do? Or what to do next? That seems quite experimental. For instance, Valve software; they have had such a headwind from Steam, for so long, that we may not really know how well the "bossless" approach will work for them until it produces their Next Big Thing.
> Also, when you have a flat structure, what incentives are there for people to aspire to anything other what they're doing now??
However, I feel that this makes the mistake of believing that the only way people want to ever grow is into management. For myself, this is absolutely not the case. There really do need to be other ways to grow other than into management.
Personally I do not want to grow into "management" because I don't want the job of managing people and careers. But I do want to grow into guiding product direction and picking my own projects. At most companies those two are linked. The more tenure/respect you have the more you can influence managers, but the managers still have ultimate say on the product direction.
Because of this I keep thinking about whether it would be worth the hassle of being a manager just so I could have the control I want.
It also makes being a startup (co-)founder very appealing because I'd be much more involved in what development gets done. Except then it would add even more overhead on top of managing people, since co-founders also manage finances, legal, PR, and take on risk.
I agree there needs to be a better way for people to grow. That's why I'm interested in flat structure experiments.
>> I agree there needs to be a better way for people to grow. That's why I'm interested in flat structure experiments.
I worked at a startup who got bought by a large corporation. We had already had a flat structure:
Manager
Team Lead
Senior Developer
Developer
As soon as you moved to Senior Developer, your development ceased. Which lead to essentially a flat structure for developers since most didn't want to go into management. The only option was to quit - which happened frequently and increased turn over.
This lead to another crisis of how to give developers a role besides management to aspire to. They came up with two roles. One was a "research and development" role and the other was an "application development" role.
This lead to another crisis. When you have a large team of developers and only two roles to aspire to - you again have another flat structure. Too many people for too few spots put them right back where they started. If you didn't get an "R&D" or "App Dev" spot, developers got frustrated and left. It created more politics and backstabbing and "cliques". If you knew the manager, you got preferential treatment to get into these now prized roles. It actually created more problems than it solved.
In order to get around this, you have to build a hierarchy structure, not just new roles. This include title changes as well as increase in pay, increase in responsibilities, etc. You can give developers a non-management track, but it as to be structured, and give people a sense they are achieving their goals and not feeling like they're being marginalized or just another cog in the wheel.
This is why I'm not sure flat structures will work. When you reduce the ceiling of achievement for everybody, what else is there to look forward to?
That's not really "flat" in the sense that the OP is describing it. What he's talking about is restructuring a company to look more like an FOSS project. You have the project maintainers (c-level team) that set the goals. They sign off on all subprojects that are aligned with those goals and have enough people who want to work on them. The subprojects are run the same way, with people deciding what to hack on, in a way that is aligned with the goals, plus has support of the other team members.
The situation you described has all the crappiness of a corporate hierarchy, but none of the promises of meritocracy ("work hard and advance"). From the programmer’s perspective, he’s stuck both in rank and in skill.
Contrast this with the FOSS model, which creates the feeling that he’s working on something, versus working for someone. He can work on whatever project he’s interested in, or create a new one if it has enough traction. Since he’s not going into management, that leaves him with advancing in either depth or breadth. He can advance in depth by choosing to work on something that challenges his skill level. Or he can advance in depth by working on new technology or in a new area (e.g. frontend vs. backend).
>> He can work on whatever project he’s interested in, or create a new one if it has enough traction.
Just to play Devils Advocate here, but what happens if everybody wants to work on the same project? And this same developer doesn't have enough traction for other projects he would like to start?
If everyone works on the same project, there's only so much work to go around. If no one wants to work on something, it's probably a sign that it's not worth doing.
Sets objectives. The manager sets goals for the group, and decides what work needs to be done to meet those goals.
Also, when you have a flat structure, what incentives are there for people to aspire to anything other what they're doing now??
While I can appreciate his leap of faith, I'm not sure this will work out long term.