I think this is a great goal and that this post furthers it. I do hope someone from a more staid institution writes a parallel document about how they work. Lightcone runs on a very chaotic/heroic model that works well for them and has accomplished great stuff, but some projects and people do better with a slower and steadier approach.
Can confirm Lightcone is very chaotic and sometimes works heroic hours, and it seems tangled up in our way of working for reasons that are not super clear to me.
So when reading your comment I was asking myself why the above template couldn’t be run by a project that wanted to work closer to 40 hours rather than 80 hours per week? One answer is that “Well, if people are importantly blocking elements, they must be available to reply on slack and unblock other people whenever”, which is mostly true for us, except that 1) we almost never wake up people who are sleeping :) and 2) if people sign-post they are taking a rest day or going on vacation others usually try fairly hard to find a way to solve problems without contacting them.
I agree that most of these rules could smoothly transition to a less intense team, and nonetheless believe a less chaotic org would write a fairly different document, which is why I think it would be useful for them to do so.
One thing I can speak to a tiny bit is a software company I worked at that had a lot of the chaotic/hero-ness in certain roles, but absolutely had to be cross-continental, and thus was also remote and heavily asynchronous. It built up really great practices for documentation and async communication to make that work. Alas it’s been too long since I worked there for me remember specifics, so I can’t say anything useful.
I don’t feel that we’re especially “chaotic” or would describe us as a chaotic org. We have lots of structure and process and principles and intentionality in how we operate. Though I suspect there’s something real you’re thinking of.
Oh fwiw I think we’re quite chaotic. Like, amount of suddenly changing priority and balls sometimes getting dropped because we took on too many things.
(Not sure we’re that chaotic for a startup, but startups are already pretty chaotic)
For me, the interesting part is the transition from a fast-growing startup to a stable enterprise. I have been in transitional companies most of my professional life, and felt the growing pains. I have looked for resources to support this transition. One book provided a useful lens: Growing Pains: Transitioning from an Entrepreneurship to a Professionally Managed Firm by Eric G. Flamholtz and Yvonne Randle (Goodreads). It describes a number of stages or challenges that a maturing company has to tackle in a particular order of priority. It is mostly based on case studies and surveys.
In my experience, all the areas have to be advanced at the same time, but some more than others. For example, the clear instructions, mentioned above are a precursor to Corporate Culture. And it also makes sense to start with Operational Systems before you need them—at least to hire people with experience in these areas that will later be able to bring them about.
I think this is a great goal and that this post furthers it. I do hope someone from a more staid institution writes a parallel document about how they work. Lightcone runs on a very chaotic/heroic model that works well for them and has accomplished great stuff, but some projects and people do better with a slower and steadier approach.
Can confirm Lightcone is very chaotic and sometimes works heroic hours, and it seems tangled up in our way of working for reasons that are not super clear to me.
So when reading your comment I was asking myself why the above template couldn’t be run by a project that wanted to work closer to 40 hours rather than 80 hours per week? One answer is that “Well, if people are importantly blocking elements, they must be available to reply on slack and unblock other people whenever”, which is mostly true for us, except that 1) we almost never wake up people who are sleeping :) and 2) if people sign-post they are taking a rest day or going on vacation others usually try fairly hard to find a way to solve problems without contacting them.
I agree that most of these rules could smoothly transition to a less intense team, and nonetheless believe a less chaotic org would write a fairly different document, which is why I think it would be useful for them to do so.
One thing I can speak to a tiny bit is a software company I worked at that had a lot of the chaotic/hero-ness in certain roles, but absolutely had to be cross-continental, and thus was also remote and heavily asynchronous. It built up really great practices for documentation and async communication to make that work. Alas it’s been too long since I worked there for me remember specifics, so I can’t say anything useful.
I don’t feel that we’re especially “chaotic” or would describe us as a chaotic org. We have lots of structure and process and principles and intentionality in how we operate. Though I suspect there’s something real you’re thinking of.
Oh fwiw I think we’re quite chaotic. Like, amount of suddenly changing priority and balls sometimes getting dropped because we took on too many things.
(Not sure we’re that chaotic for a startup, but startups are already pretty chaotic)
(Campus team seems much more chaotic than LW team tho)
high frequency?
For me, the interesting part is the transition from a fast-growing startup to a stable enterprise. I have been in transitional companies most of my professional life, and felt the growing pains. I have looked for resources to support this transition. One book provided a useful lens: Growing Pains: Transitioning from an Entrepreneurship to a Professionally Managed Firm by Eric G. Flamholtz and Yvonne Randle (Goodreads). It describes a number of stages or challenges that a maturing company has to tackle in a particular order of priority. It is mostly based on case studies and surveys.
(picture from this summary)
The Growth Stages are
New Venture—Markets and Products
Expansion—Resources and Operational Systems
Professionalization—Management Systems
Consolidation—Corporate Culture
In my experience, all the areas have to be advanced at the same time, but some more than others. For example, the clear instructions, mentioned above are a precursor to Corporate Culture. And it also makes sense to start with Operational Systems before you need them—at least to hire people with experience in these areas that will later be able to bring them about.