
Lessons scaling from 10 to 20 people - gkop
http://josephwalla.com/lessons-scaling-from-10-to-20-people
======
vmarsy
I don't remember where I read it (probably on a HN post or comment) but there
was a great suggestion regarding organization chart. Instead of doing one only
when you scale from 10 to 20 people like this article suggests, the idea was
to do one on day 1.

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.

~~~
dasil003
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.

~~~
dilemma
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.

~~~
buzzybee
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.

~~~
dilemma
I think you should read the GP again.

------
fizixer
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.

~~~
ido
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".

~~~
fizixer
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.

------
dasmoth
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".

~~~
sokoloff
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.

------
Silhouette
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.

~~~
hinkley
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.

~~~
Silhouette
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.

~~~
dasmoth
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.

~~~
Silhouette
_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.

------
dodorex
can somebody explain why posthaven is so widespread? i don't see any reason to
use it over medium etc

~~~
blfr
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.

~~~
anotheryou
It offers immortality (of your texts). And people are afraid of death, beeing
forgotten and leaving no mark behind.

