Lessons scaling from 10 to 20 people(josephwalla.com)
josephwalla.com
Lessons scaling from 10 to 20 people
http://josephwalla.com/lessons-scaling-from-10-to-20-people
22 comments
I understand the appeal of this, but the hardest thing in the very beginning is keeping a laser focus on the critical task of building and validating something people want. Resources are so precious at that stage, and the green field is so wide open, that you have to be obsessive about keeping an eye on the ball. It's extremely easy to drink your own koolaid and start believing the narrative in your pitch deck before you are anywhere near traction.
Mulling over an org chart is one of the easiest of the thousands of nice-sounding things you need to brutally cull from your todo list in the early days.
Mulling over an org chart is one of the easiest of the thousands of nice-sounding things you need to brutally cull from your todo list in the early days.
I think you've misunderstood the parent. By making explicit that the founder does all these things, it makes the urgency of hiring and delegating clear.
It's only helpful if it adds something to the feedback loop. That's what an organization and its projects need at every stage: healthy feedback. If it's too far into fantasy, it gets forgotten and replaced with something more expedient; if it goes completely unaddressed, the absence manifests as some other failure.
So, early org chart is only useful if it doesn't jump too far ahead of what the business is: If you discover you need a different organization to execute on the plan, there's no point in planning for scaling the existing one out. But if what's being followed is a "hire a great team and great things will happen" kind of plan, then there's no conflict since it just means you've considered both near and long-term aspects of building a great team.
So, early org chart is only useful if it doesn't jump too far ahead of what the business is: If you discover you need a different organization to execute on the plan, there's no point in planning for scaling the existing one out. But if what's being followed is a "hire a great team and great things will happen" kind of plan, then there's no conflict since it just means you've considered both near and long-term aspects of building a great team.
I think you should read the GP again.
Sorry, what do you think I'm misunderstanding?
The GP is clearly suggesting thinking about role definition from day one rather than waiting until the 10-20 employee phase. I'm stating unequivocally that I think that is a mistake.
The "urgency of hiring and delegating" only kicks in once you have a level of certainty of what needs to be done. Every employee you bring on adds not only burn rate, but also communication overhead. The only thing that gets a startup from the garage phase to actually being able to series A and credibly hire more than 10 people is for every founder and early employee to ruthlessly identify things that need to be done and execute on them. This idea of documenting what exactly founders are doing and thinking about delegating them is what YC has dubbed "playing house"*.
[0] http://www.paulgraham.com/before.html
The GP is clearly suggesting thinking about role definition from day one rather than waiting until the 10-20 employee phase. I'm stating unequivocally that I think that is a mistake.
The "urgency of hiring and delegating" only kicks in once you have a level of certainty of what needs to be done. Every employee you bring on adds not only burn rate, but also communication overhead. The only thing that gets a startup from the garage phase to actually being able to series A and credibly hire more than 10 people is for every founder and early employee to ruthlessly identify things that need to be done and execute on them. This idea of documenting what exactly founders are doing and thinking about delegating them is what YC has dubbed "playing house"*.
[0] http://www.paulgraham.com/before.html
The trouble is that it may make the urgency of hiring and delegating seem more than it is. Plenty of businesses won't need separate people to take on each responsibility for a while, if ever. Other than the really obvious ones, a new business probably won't even know which responsibilities might become large enough to need dedicated people looking after them yet. Hiring is always a fine balancing act, and hiring the wrong people and/or to fill the wrong positions is just as toxic to a new business as not hiring and delegating when the right time comes.
This is a central point of Michael Gerber's book The E-Myth (E stands for entrepreneur). You must work on your business as much as you work in it from day 1.
Forget about scaling, tell me what are all/most of the possible worker roles (part-time or full-time) that a startup needs in its: first month, 2nd-6th month, rest of 1st year, and so on.
This kind of knowledge "beforehand" is a valuable startup insight that is not disseminated well enough IMO.
This kind of knowledge "beforehand" is a valuable startup insight that is not disseminated well enough IMO.
Impossible to tell cause the trajectory of each company is different. You need to hire the people you need in your situation (time/budget/workload/opportunities/etc) not in the "general case".
See this is where I disagree. We need to get over the idea that every startup is a special snowflake with its own unique set of needs and requirements.
I'm not even talking about hard-tech, or some non-tech law firm startup, or a new hospital or something.
For the software startup (all types, online/offline, web/desktop/mobile, etc, etc), I believe in the 80-20 rule. 80% of the worker roles of all startups are very similar and can be enumerated and contemplated in advance. If entrepreneurs fail to take that into account, they're simply raising the risk bar and setting themselves up for a more likely failure.
I'm not even talking about hard-tech, or some non-tech law firm startup, or a new hospital or something.
For the software startup (all types, online/offline, web/desktop/mobile, etc, etc), I believe in the 80-20 rule. 80% of the worker roles of all startups are very similar and can be enumerated and contemplated in advance. If entrepreneurs fail to take that into account, they're simply raising the risk bar and setting themselves up for a more likely failure.
Any thoughts on what people who want to be generalists should be doing?
The implication of some of that post would seem to be "leave".
The implication of some of that post would seem to be "leave".
Or stay at a place that is engineered/choosing to stay small/right-sized so they can be a generalist.
There's no (or no obvious) way to stay a fully cross-cutting generalist in a company of 10K people.
There's no (or no obvious) way to stay a fully cross-cutting generalist in a company of 10K people.
Interesting read, though I'm a little wary of the turning generalists into specialists point being taken too far. There are a lot of unwritten assumptions behind that idea.
For example, let's consider a business that does something many of us here are familiar with: making a web app. There's a trend in web development world these days to put every little thing into its own silo. We separate front-end and back-end people. We separate back-end developers from DBAs and operations people. We separate designers and front-end developers. We invent whole new job titles using trendy terms like "user experience", as if making a good UI hasn't always involved doing the same things.
The real world does not work like this. In the real world, all of these things are related, and what matters is the overall result. In the real world, there are many different skill sets, but almost no-one is an expert at one thing and has little if any knowledge of the others. And crucially, in the real world someone can often do one part of a job much better if they also have substantial knowledge of some of the related parts.
So I think generalist vs. specialist is almost always a false dichotomy once you get beyond the crude "Yes, the CEO probably shouldn't also be the guy spending all day debugging a tricky rendering glitch" level. One "generalist" with skills/knowledge in more than one area can easily be more productive than multiple "specialists" who each know their own area but don't really understand the relationships to adjacent areas, and thus need significant process and management to work effectively at all and still probably incur significant overheads. IME, the principle of keeping a level of generalism scales up just fine as well: those with the broader knowledge and skills often become good candidates for technical leadership roles in growing organisations.
For example, let's consider a business that does something many of us here are familiar with: making a web app. There's a trend in web development world these days to put every little thing into its own silo. We separate front-end and back-end people. We separate back-end developers from DBAs and operations people. We separate designers and front-end developers. We invent whole new job titles using trendy terms like "user experience", as if making a good UI hasn't always involved doing the same things.
The real world does not work like this. In the real world, all of these things are related, and what matters is the overall result. In the real world, there are many different skill sets, but almost no-one is an expert at one thing and has little if any knowledge of the others. And crucially, in the real world someone can often do one part of a job much better if they also have substantial knowledge of some of the related parts.
So I think generalist vs. specialist is almost always a false dichotomy once you get beyond the crude "Yes, the CEO probably shouldn't also be the guy spending all day debugging a tricky rendering glitch" level. One "generalist" with skills/knowledge in more than one area can easily be more productive than multiple "specialists" who each know their own area but don't really understand the relationships to adjacent areas, and thus need significant process and management to work effectively at all and still probably incur significant overheads. IME, the principle of keeping a level of generalism scales up just fine as well: those with the broader knowledge and skills often become good candidates for technical leadership roles in growing organisations.
If you want to stay a generalist at a bigger company, convince the bosses that they need to worry about the Truck Number of each of the competencies in the company, and then participate in improving it.
The problem I've always had with being a generalist is defending your existence. If there are constant fires to put out, people will see you fighting them. But if you prefer to prevent fires instead, you have to work all the harder to be seen.
It's easier to be recognized if you let or encourage management to label everybody and you carve out a nice niche for yourself. It's easier to make something more complicated so people leave it to you to work on. Managers who know how to run an effective team know and push back against this, the ones that are just trying to look good often don't.
The problem I've always had with being a generalist is defending your existence. If there are constant fires to put out, people will see you fighting them. But if you prefer to prevent fires instead, you have to work all the harder to be seen.
It's easier to be recognized if you let or encourage management to label everybody and you carve out a nice niche for yourself. It's easier to make something more complicated so people leave it to you to work on. Managers who know how to run an effective team know and push back against this, the ones that are just trying to look good often don't.
What you describe is often true in larger companies, but IME not in the kinds of 10-20 person outfits we're talking about here, or even quite a bit bigger.
At that level, one experienced "generalist" person who can do a whole job end-to-end can still get the same visible results as a small team of less experienced "specialist" people, and if we're talking about salaried staff then that single more experienced person is probably costing far less to hire than all of the other team put together because good senior people are disproportionately cheap to hire as employees.
The overheads of running a team mean it takes a surprisingly large project before it's necessary/advantageous to hire a much larger team of junior people rather than a much smaller number of senior people, assuming you have the choice.
At that level, one experienced "generalist" person who can do a whole job end-to-end can still get the same visible results as a small team of less experienced "specialist" people, and if we're talking about salaried staff then that single more experienced person is probably costing far less to hire than all of the other team put together because good senior people are disproportionately cheap to hire as employees.
The overheads of running a team mean it takes a surprisingly large project before it's necessary/advantageous to hire a much larger team of junior people rather than a much smaller number of senior people, assuming you have the choice.
Agree with all of this. But there seems to be active distrust of coders working solo, both from managers and from other coders. There's a surprisingly strong perception the "a team" is the safe option.
But there seems to be active distrust of coders working solo, both from managers and from other coders. There's a surprisingly strong perception the "a team" is the safe option.
It's been my experience that capable developers tend to appreciate other capable developers. It's also been my experience that capable developers appreciate managers who are actually doing a useful job, and vice versa, and that both of those groups are also quite willing to support those who are currently less experienced but are interested and trying to learn and grow.
I suspect the kinds of objections you're thinking of most often come from managers or developers whose own positions are threatened as soon as someone competent enters the picture. A capable one-person development group has no need of a micro-manager to take the credit on their behalf, nor of a developer who has just enough knowledge and skill to be dangerous and/or in the way but no inclination to get any better.
At some point obviously you need more than one developer for scalability and resilience, but even then you can still do a lot with a few good developers and a useful manager co-ordinating them compared to a large group of mediocre developers and a whole management hierarchy above them.
It's been my experience that capable developers tend to appreciate other capable developers. It's also been my experience that capable developers appreciate managers who are actually doing a useful job, and vice versa, and that both of those groups are also quite willing to support those who are currently less experienced but are interested and trying to learn and grow.
I suspect the kinds of objections you're thinking of most often come from managers or developers whose own positions are threatened as soon as someone competent enters the picture. A capable one-person development group has no need of a micro-manager to take the credit on their behalf, nor of a developer who has just enough knowledge and skill to be dangerous and/or in the way but no inclination to get any better.
At some point obviously you need more than one developer for scalability and resilience, but even then you can still do a lot with a few good developers and a useful manager co-ordinating them compared to a large group of mediocre developers and a whole management hierarchy above them.
can somebody explain why posthaven is so widespread? i don't see any reason to use it over medium etc
It's affiliated with YC (created by alumni), promises to stick around and even keep your content online. Whereas Medium is still looking for a sustainable business model.
It offers immortality (of your texts). And people are afraid of death, beeing forgotten and leaving no mark behind.
Posthaven was started by Garry Tan, a YC alum & founder of Posterous. When Posterous, a blogging-ish platform, was acquired and later shutdown...
http://techcrunch.com/2013/02/15/posterous-will-shut-down-on...
...Garry started Posthaven. Posthaven got press as the "never gonna sellout and/or shutdown" blogging platform. I still remember Posthaven whenever I think about starting a blog that I'd like to be around forever. It's a good pitch for people who value the longevity of things they write. I'm not confident Medium will be around forever, and major content sites do go bye bye: Posterous, Geocities, Vine.
http://techcrunch.com/2013/02/15/posterous-will-shut-down-on...
...Garry started Posthaven. Posthaven got press as the "never gonna sellout and/or shutdown" blogging platform. I still remember Posthaven whenever I think about starting a blog that I'd like to be around forever. It's a good pitch for people who value the longevity of things they write. I'm not confident Medium will be around forever, and major content sites do go bye bye: Posterous, Geocities, Vine.
On day 1 every position from CEO, CFO, to mail delivery messenger is filed with one or 2 names: the founder(s). As the company grows, you hire people and start delegating the work so that they can fill the positions on the organization chart.