Then there's the Bureaucracy Model.
When you think bureaucracy, you think red tape.
This is not so in the case here.
Again, this is not about just payment, the attachment still to interest in work.
That's why people want to do this job as opposed to other jobs.
And this lecture's still for the competence for the current tasks but
it's mostly improvisational nature of those engineering based teams.
In this case, there are formal procedures that tell people what to do.
So again some quotes, we're not hierarchical as much as we are procedures,
methodologies, and systems oriented.
I really like to see that everyone in the company maintains procedures rather than
just handwave and do things any way.
We don't want to be so hierarchical as to be startling, nor do we want to be so
flat that everyone's in each others business.
Or we want to make sure things are documented, have job descriptions,
project descriptions and rigorous project management techniques.
So again, this is not a bureaucracy where you're going in,
waiting at an office to see you passport get stamped.
This, instead the fact that there's actual procedures that control things,
rather than the improvisation we typically see in startup companies.
The final stable model was the Autocracy Model and
in this case, this is about the founder who runs things.
This is a default model that founders often run into
that can be very problematic.
In this case, the main goal is that you expect people to work for
you because you're paying them.
You're hiring them because they can do the job today and
you're watching everything they do, right?
So one thing we want to avoid is consensus management.
I think it lends itself to slowdowns and development schedules.
We have good communications around a core group,
but we certainly know who makes the call on things.
We don't have the resources available to spend a lot of time getting everyone warm
and fuzzy, rather than gain through a decision, or
even more directly, you work, you get paid.
So that's the autocracy model.
There are many potential models out there, but these five stable models,
star, engineering, commitment, bureaucracy, and autocracy
are the ones that seem to be dominant in the startup culture of Silicon Valley.
You could see each of them differs on attachment.
Why people are working for you, on selection, how you're hiring people and
control, how you're making sure they're doing what they're supposed to do.
The stats in Silicon Valley showed that the Engineering model was the most
prominent, had the plurality, followed by the Commitment, the Star, Bureaucracy and
Autocracy models.
You'll notice that 32% that's hybrid.
Those are the people that didn't follow one of these dominant six models.
Now, what's interesting is you'd expect there to be
many more Hybrids because there is a lot more hybrid options.
The fact that it's actually just 32% indicates
that the stable models are much more common than the hybrid approaches.
Now these models aren't just a guideline,
they actually make a difference in the kind of company you're running.
The kind of company you build will actually be influenced and
the level of success it has by the kind of model you pick.
So that star-based model where you're hiring based on potential and
you're going for the people who accomplish the most amazing things, and you
sort of stay out of their way, that works well for companies based on innovation.
So when you're hiring star scientists or star programmers.
It also works well for enhancement based models,
models where you are doing small improvements to existing things.
So maybe better design, [INAUDIBLE] innovation, so, Star works well there.
It does not work well for sales, marketing or service jobs and it doesn't work very
well for jobs where cost is the issue because hiring Star is expensive.
The commitment model on the other hand is not very good in innovation
because everyone thinks alike, that's part of why you all come in to be together.
But it works really well for sales marketing or service models.
So organizations where people are doing selling, where they do consulting work,
this is a very powerful technique.
The engineering model is rarely the best at anything but
is usually good at anything potentially.
So you can always assemble teams of people to handle a problem.
So even though you're not optimize for anything from innovation to enhancement,
to sales and marketing, to managing cost, engineering is a good default choice.