Besides being fairly short, and having a lot of general good advice, such as, to use my own wording, making sure every essential hat is worn by someone, e.g. you probably won't start out with a CFO, but make sure one of the founders or earliest employees wears it, it goes into a thesis that you should write up a manual of how your business runs as if you were going to franchise it.
Plenty of good justification for writing this up at some level of detail can be found in the other comments in this topic, although I'll admit the book is not oriented toward high tech businesses.
But they're still businesses, and for that focus I highly recommend, probably after one or more books on customer development, which refine many of the ideas in it, Walking the High-Tech High Wire: The Technical Entrepreneur's Guide to Running a Successful Enterprise (https://www.amazon.com/Walking-High-Tech-High-Wire-Entrepren...). It's a story about a company that made and sold novel at the time discrete semiconductor devices, how they did their customer development, how they realized doing custom work for various customers was a loser, etc. It'll help reify what you'll read in good customer development books.
Bureaucratic process-driven de-skilling probably made sense when you were GE and had six-figure worth of boomers to coordinate physical goods manufacturing. But today, for a company with 1 to even 4 figures worth of people paid to think and decide, it doesn't even make sense let alone work. The whole point of software, and computers, is that if something is that systematizable then have the systems do it. Process that is not code is a sloppy half assed anachronism. People are not machines, if the following the process actually matters then don't leave it to a human error rate.
... just don't be surprised if you suddenly no longer understand how your systems work, and cannot change them. It's important to relate the advice to the size of the company and the type of the market you're operating in.
- Should startups with two-digit employee counts start doing this? Not necessarily. Will the lack of documented policies, processes and procedures stop them from growing at some point in time? Definitely.
- Will this help you in a boutique business delivering highly individual solutions? Possibly, bot not necessarily. Will it help serve a massive customer base and use efficiencies of scale? Definitely.
There's definitely a difference between bureaucratic waste and establishing a minimal set of meaningful policies, processes and procedures. Let's not dismiss the idea based on this confusion.
it's easy to bark orders at everyone below you to create a bunch of documentation and then kick up your feet, light a cigar, thinking you've achieved "systemization" of your company, or some other operational/bureaucratic aspiration which might or might not have a firm grounding in reality.
the harder, narrower road: hire smart people, feed into your team, and do your best to stay out of their way. this is by no means easy -- it's a lot of work putting together a team and leading a team and running interference so they can shine. but it's totally worth it.
In some regards this reflects how I experienced many managers. Understanding that a management task needs to be done (e.g., define a business process), then go to an employee below and charge them with doing it.
However, a good manager also adds value. If you work as engineer you are exhausted after a programming task and don't really want to write notes down. But you yourself already know that you actually really should do it. Having a manager to motivate you and help you improve your documentation and formatting skills can go a long way to find out what happened in that task 6 months ago.
and the other bit about the harder, narrower road: you don't get to really find out how good the team is, and their plans that you let them run with, until a year or two or more later.
But I don't think there is any better solution. I agree that a bunch of documentation without substance is a waste of time, and just corporate smoke and mirrors.
Actually not totally true. There was some content in there. But since it wasn't structured that well it's hard to see. Putting everything in a process is like putting your code in a class. It's not absolutely necessary but helps structuring stuff.
A process is a regular activity that solves a certain problem for a certain consumer group (the consumer may be an employee of your company, e.g. when the process is mail hosting for your company). Writing down the usual steps to take helps people to not forget stuff when doing the job, and helps managers/QA make sure everything is there to close a task.
Also each process has typical roles, e.g. someone who is responsible for the process adding value to the big picture (process owner), someone who is responsible for getting the day to day problems out of the way (process manager), and someone who actually does the steps involved in the process (process practicioner). With this structure it is easier to see when something is missing. E.g. in corp life one can often find a process with more than one owner, more than one manager, but zero practicioners, which results in nothing getting done at the end of the day.
Also you can think about how all that may relate to Scrum and co. There you also have these roles like board owner, scrum master and engineers.
All this stuff is somewhere in the article, but it's not layed out very well. Probably written by a person who works on a daily basis with people who already know all that, which of course makes the tutorial nature of the article worhtless. One may guess there was a blog post practicioner, but no (real) manager.
[+] [-] hga|9 years ago|reply
Besides being fairly short, and having a lot of general good advice, such as, to use my own wording, making sure every essential hat is worn by someone, e.g. you probably won't start out with a CFO, but make sure one of the founders or earliest employees wears it, it goes into a thesis that you should write up a manual of how your business runs as if you were going to franchise it.
Plenty of good justification for writing this up at some level of detail can be found in the other comments in this topic, although I'll admit the book is not oriented toward high tech businesses.
But they're still businesses, and for that focus I highly recommend, probably after one or more books on customer development, which refine many of the ideas in it, Walking the High-Tech High Wire: The Technical Entrepreneur's Guide to Running a Successful Enterprise (https://www.amazon.com/Walking-High-Tech-High-Wire-Entrepren...). It's a story about a company that made and sold novel at the time discrete semiconductor devices, how they did their customer development, how they realized doing custom work for various customers was a loser, etc. It'll help reify what you'll read in good customer development books.
[+] [-] cagenut|9 years ago|reply
[+] [-] tzmudzin|9 years ago|reply
- Should startups with two-digit employee counts start doing this? Not necessarily. Will the lack of documented policies, processes and procedures stop them from growing at some point in time? Definitely.
- Will this help you in a boutique business delivering highly individual solutions? Possibly, bot not necessarily. Will it help serve a massive customer base and use efficiencies of scale? Definitely.
There's definitely a difference between bureaucratic waste and establishing a minimal set of meaningful policies, processes and procedures. Let's not dismiss the idea based on this confusion.
[+] [-] thefastlane|9 years ago|reply
the harder, narrower road: hire smart people, feed into your team, and do your best to stay out of their way. this is by no means easy -- it's a lot of work putting together a team and leading a team and running interference so they can shine. but it's totally worth it.
(edited for tone and clarity)
[+] [-] erikb|9 years ago|reply
However, a good manager also adds value. If you work as engineer you are exhausted after a programming task and don't really want to write notes down. But you yourself already know that you actually really should do it. Having a manager to motivate you and help you improve your documentation and formatting skills can go a long way to find out what happened in that task 6 months ago.
[+] [-] gregpilling|9 years ago|reply
But I don't think there is any better solution. I agree that a bunch of documentation without substance is a waste of time, and just corporate smoke and mirrors.
[+] [-] untilHellbanned|9 years ago|reply
[+] [-] erikb|9 years ago|reply
A process is a regular activity that solves a certain problem for a certain consumer group (the consumer may be an employee of your company, e.g. when the process is mail hosting for your company). Writing down the usual steps to take helps people to not forget stuff when doing the job, and helps managers/QA make sure everything is there to close a task.
Also each process has typical roles, e.g. someone who is responsible for the process adding value to the big picture (process owner), someone who is responsible for getting the day to day problems out of the way (process manager), and someone who actually does the steps involved in the process (process practicioner). With this structure it is easier to see when something is missing. E.g. in corp life one can often find a process with more than one owner, more than one manager, but zero practicioners, which results in nothing getting done at the end of the day.
Also you can think about how all that may relate to Scrum and co. There you also have these roles like board owner, scrum master and engineers.
All this stuff is somewhere in the article, but it's not layed out very well. Probably written by a person who works on a daily basis with people who already know all that, which of course makes the tutorial nature of the article worhtless. One may guess there was a blog post practicioner, but no (real) manager.
[+] [-] geomark|9 years ago|reply
[+] [-] samuelbrin|9 years ago|reply
[+] [-] Avernar|9 years ago|reply