5 ms·
Can't say I found this article all that enlightening. Having been an employee at several startups that have transitioned past the 30-40 headcount mark, there do
by depsypher 9y ago
Can't say I found this article all that enlightening. Having been an employee at several startups that have transitioned past the 30-40 headcount mark, there does seem to be a breakdown at that stage. What is the cause, and how do you deal with it?
This article doesn't really address the causes or offer any true solutions though. Focus on culture? You need to do that from the start. Get new board members? So your advice is to get new advisors? Okay, but what steps can you actually implement to solve the problem?
In my view the real problem is that good management is difficult and not well understood. Once your company grows to the point where a flat structure starts to have problems, the usual shift is to a hierarchical structure; not only a difficult transition, but also ends up trading your old problems for new ones. I wish the startup world did a better job of tackling these issues.
- sharemywin 9y agoThe problem is the "plan" would be for the company to grow 10x in the next 3-4 years. So, for every person on the team add 9 more people. now, keep your culture. Also, most of the people you hired were experts in the jobs not management.
- DannyBee 9y ago"Can't say I found this article all that enlightening. Having been an employee at several startups that have transitioned past the 30-40 headcount mark, there does seem to be a breakdown at that stage. What is the cause, and how do you deal with it? " I'll at least attempt to give you something that may be a little more enlightening. I suspect a bunch of it will come off as stupid babble to people who have smaller teams, and less so to people who have managed or transitioned larger organizations. I claim credit for none of it. There is no single cause of course. The unsatisfying answer is that "for the complex system that makes up a lot of these organizations, 30-40 is the number at which a lot of these systems become noticeably more unstable". There are a lot of possible reasons for this (not everyone has the same mind anymore, same incentives, etc, and over time, are gravitating towards certain things) The main reason for failure though, i believe, is that startups are very used to dealing with complicated problems (difficult but amenable to having an end state and answers, even though they involve tradeoffs) and not complex systems (things that don't stay still, there is no right answer, and there is no end state) , and so try to solve "the system" as if it was a complicated problem. People want to put in place "an answer" and have it work for a while. This rarely, if ever, works You give an example of this: The flat organizational system tend to not work as well at that size. People see this as a set of problems. So they try to solve them. Often, as you mention, by moving to hierarchical management. As you've aptly described, that just ends up trading one set of problems for another. That's because there is no actual solution to the problem. It's not a problem to be solved, in the same way "culture" is not a problem that can just be solved. It is an ever changing thing. You need a very different approach. Instead of trying to solve "the problem" (which is usually, in this case, something like "people running in too many directions", etc), one needs to try to step back, and try to understand all the attractors, variables, and factors that are currently causing your system to behave in a certain way. People often think they know the answer why ahead of time, but they are often wrong :P. Figure out where you can have influence in this system by nudging variables, and try to nudge things towards a certain direction and see what happens (IE choose something you want to see more of or less of, experiment, learn from what happens, try again). Incentivize the right things to happen, instead of directing the right things to happen. This is all a pretty general description (and there are actually very good books and courses and such on the above, even if not specifically written about startups). There are also certainly times where the system is failing bad enough you need to completely replace it, but that is due to a failure of leadership. There are also times where "hierarchical management" may be a valid experiment to try (it's just an example above). But i believe most startups just go directly into problem solving mode when they hit these kinds of issues, and that, again, rarely accomplishes much except frustration and failure. It really requires a mindset shift of not just trying to solve complicated problems and seeing everything as fitting into this mold. Even you mention "Okay, but what steps can you actually implement to solve the problem?". The steps you can take are to realize it's not a single problem, or even a collection of problems. These are just emergent properties of your system. Your goal is to nudge it into different emergent properties that are closer to what you want, not just try to solve the set of problems those properties produce. It's important to also realize you will never stop having to push the system in various directions. You are never going to reach this end state where everything is always going awesome with no work on anyone's part ever again. Systems may become meta-stable, and the timeframes on which it stays meta-stable may be long, but usually the only systems that are stable are dead ones ;)
- btilly 9y agoHaving been an employee at several startups that have transitioned past the 30-40 headcount mark, there does seem to be a breakdown at that stage. What is the cause, and how do you deal with it? Oversimplifying the cause is that you go from having to manage people and problems relatively directly to managing through layers of indirection. You deal with it by knowing what effective layers of indirection are available to you, and learning how to make best use of them. There is no concrete recipe because each company is different, and nobody has really abstracted out commonalities to make the subject easier to learn. The article does give a list of important indirection tools, and a list of books that give insights on the key principles. And also stresses how, in the absence of general theory, you need to get personal assistance from someone who has concrete experience with the transition. So this seems to me to be very useful advice, even if none of it is directly actionable.
- erikpukinskis 9y ago> Oversimplifying the cause is that you go from having to manage people and problems relatively directly to managing through layers of indirection. So, that's the self-similar model where you're a manager of managers... But isn't there another model—the partnership model—where at the top is just multiple partners, each of whom manage their own part of the business and report directly to the board? Like, at a law firm there's not a CEO right? Or the CEO role isn't about delegating tasks to the partners, it's more literally an operations role, and partners have reports that are largely outside of the CEO's delegation? I'm kind of obsessed with partnerships lately, or as I like to call them: "Worker Owned Co-ops for Republicans".
- deleted 9y ago[deleted]
- sbierwagen 9y ago>Having been an employee at several startups that have transitioned past the 30-40 headcount mark, there does seem to be a breakdown at that stage. What is the cause, and how do you deal with it? https://en.wikipedia.org/wiki/Dunbar%27s_number https://en.wikipedia.org/wiki/Dunbar%27s_number 40 is about the point where the CEO can't possibly manage everyone one-on-one, and has to start delegating real management tasks.
- evincarofautumn 9y agoYup, in my experience, 40–50 is also about when a classroom changes from “small class” to “lecture hall” or needs a TA, for similar reasons. Plus the number of edges in a fully connected graph of relationships would exceed 1000 at this point, so the graph starts to partition itself: employees stop working directly with most of their colleagues and start dividing into more isolated “tribes”. And this goes on to affect the structure of their projects, e.g., software architecture[1]. [1]: https://en.wikipedia.org/wiki/Conway%27s_law https://en.wikipedia.org/wiki/Conway%27s_law