I think the key difference is that a founder has a much better understanding of the company as a complex system. This understanding includes not just how people think it works at a certain point. It includes all the previous attempts, reasoning behind those attemps, the context of past failures and successes, the personal dynamics behind those choices.

Complex systems are notoriously hard to understand. Seeing the system develop from zero to complexity is an experience and perspective that is impossible to replace. Even most early employees don't have a comparable understanding.

Of course not all founders know everything about all the key components of their businesses, but the founding team does have a much much better understanding than other person. I think that's why founders get frustrated with ineffective things. While most others have to account for unknown unknowns and give others benefit of doubt, the founders have a much better and robust understanding of why things happen the way they happen.

The difference between management and leadership may be more about where you focus and how you engage others. Being a founder and being a leader is different in how well you understand the system.

https://www.wallstreetzen.com/stock-screener/founder-led-com...

Not everyone can be a leader.

But in my experience a good founder doesn’t necessarily make a good leader. Not a CEO anyway, but it depends on the role of the CEO. If the the CEO is “chief strategy and opportunity officer” then some founders are often quite well suited to it.

But we should bear in mind that all founders do not have the same skill set. Woz was also a founder of Apple and a great engineer but not a CEO.

At this moment, you can decide that you are starting a company. You are now a founder.

(This is why Founder is historically an unprestigious job that smells a lot like Unemployed, though the startup hype cycle of the last 15 years changed that.)

It is perhaps possible to interpret these articles as saying anything whatsoever, but they don't seem to specifically say what Paul's article says.

As with any complex system, you have to be careful about degrees of freedom, too many and it can break down and too little and it can get seized.

I think the founder not only motivates people to work on the correct thing by doing this, but the founder also directly experiences feedback from working with people lower on the org chart, enabling them to steer the company with more accurate information.

To my mind the CEO job at scale is 4 things - Keeping the fight fair-- The leadership and executive management should argue viciously, The CEO should make sure these conflicts remain constructive and aligned with company goals

Holding the vision true-- There's a risk of mission drift, continually reinforce and refine the company's vision, make sure all leaders remain aligned with longterm goals

Enforcing strategic adherence-- A strategy is only as good as its execution. ensure the leadership team not only understands the strategy but implements it across all levels of the organization. Manager of Leaders

Deal with the real world-- Q-calls, investor relations, supply chains/vendors/etc.

This is often the problem I have with business advice, it's general but not generally applicable. Scale matters probably most in the context, followed by the type of business.

I imagine from what I read about Steve Jobs, Elon Musk and Jensen Huang is that all three of them have/had unconventional management style in the sense that they're often amongst the IC's. Obviously you can't do that with all of your 30.000 employees, but I think they're just picking the teams that are most crucial at a certain point.

For example if Steve Jobs is managing Apple while launching the iPhone, I imagine he's talking to the VP of Sales in the management meetings, but he's not on the sales floor, nor is he sitting with MacOS dev teams or making sure motivations are high in the customer service department. But I bet you could find him in weekly iPhone design team meetings, and maybe he'd be shown progress on iOS every month and have a 3-hour brainstorm with a core team of senior devs on that team. Maybe they'd pull him into procurement meetings to make sure the capacitative touch screens would be made in the quantity they needed.

You'd have your VP's, directors and senior management making sure the ship sails, but you'd have the founder CEO present where they can have most impact, which just isn't in those top level meetings.

http://timesofindia.indiatimes.com/articleshow/111457691.cms...

This is a great talk by Brian on why he is CEO, he has a bit of a chip on his shoulder about designers not being CEOs from what I gathered: https://www.youtube.com/watch?v=V6h_EDcj12k

At the least, they said you need to hear directly from the people on the ground to know what they’re experiencing. The people on top could talk to them about what they learned.

Additionally, companies like IBM and FedEx used to give rewards to employees for ideas to improve the company. It was often a percentage of what those ideas made or saved up to a certain cap. A bunch of people would usually collect the max reward whenever this way implemented.

Those are a few examples that I saw show up in many places.

There’s a saying (which I’m sure has an English equivalent) where I live that goes something like “It’s the owner’s gaze which fattens the cow”.

Owner vs manager is the original “AI alignment problem”, usually taught as the principal-agent problem in business schools, and is very real. SV-type founders are, by and large, meaningful owners in their enterprises and thus heavily invested (literally) in the company’s performance. Professional managers, leaders or not, are just selling their labor. There is a whole field of management science about designing proper compensation structures to make CEOs better aligned with shareholders, but you get that quicker by making them the same person.

Of course there’s a whole other world of majority shareholders leveraging their position to extract value from minority shareholders, which is just another version of the same problem.

All this to say, you’re right that there’s prior art about what he’s writing, but its the principal-agent problem, not leaders vs managers, and in general business literature does not equate the issue of founder ownership with the PA-problem (obviously any undergrad can link the two issues, but that’s not how they’re usually approached)

A recent science fiction series explores this exact concept against a tableau of post-democracy communism, socialism, fascism, and libertarianism:

The Owner Trilogy, by Neal Asher: https://www.goodreads.com/book/show/24087399-the-complete-ow...

(The read of it is something like Altered Carbon meets The Expanse.)

I'm not sure it is.

Let's look at those three links:

1. The first of these dovetails -- not the same, but on the same hunt -- with Graham's piece, and is an excellent read.

- Unconventional wisdom

2. The second is formulaic anecdata consultjunk, the same method incurious journalists use covering politics through "focus groups".

- Conventional wisdom

3. The third uses the same formula, and while more effort (think "polling" or "survey" instead of "focus group") in an attempt to elevate from anecdata to study, seems not to have read or understood the first.

This third one is also contrary to the (often rejected while not yet disproven) theories* of Elliot Jacques, that people have sweet spot time horizons, and most can only flex +/- 2 horizons. As this article bullet lists (because of course) how to "shift from a leader/manager mindset to a lead/manage one and balance the two skillsets" it applies solely the manager rubric to action, through the lens of a manager that doesn't understand Graham's piece or the first article, almost irreconcilable with Graham's stance or the first HBR piece.

- Conventional wisdom (orthodoxy, even)

PG article and first link are not conventional wisdom, though it might sound that way to Taylorist thinking.

- - -

Perhaps the lack of awareness Graham keeps noting is to be expected.

Seems unusual for serial startup entrepreneurs who have built firms from $0 to $B to have also individually joined and worked up to C-level in "institutions" (50+ years old, and 5K - 100K+ employees, not just other tech unicorns still bearing Founder imprints) after learning the startup experience that lets them see management practice through a "it doesn't have to be like this" lens, making it rare to find the perspective necessary to delve into Graham's take or the difference between these three HBR articles.

Perhaps it's not only that management culture is a distorted bubble (PG: "VCs who haven't been founders themselves don't know how founders should run companies, and C-level execs, as a class, include some of the most skillful liars in the world").

Perhaps it's that founders with institutional perspective are themselves unicorns.

---

Footnote:

* Elliott Jaques' "Stratified Systems Theory of Requisite Organization" suggests that individuals have a natural "sweet spot" time horizon for decision-making at work (which should align with the time horizon of the decisions' scope and impact), and most can only communicate up or manage down within a range of one or two levels above or below their own optimal horizon. — https://en.wikipedia.org/wiki/Requisite_organization

Both PG's post and your point about his experience creating a rare perspective is spot on. While I think PG's "Founder Mode" concept needs further exploration, he's on to something I never saw in the typical HBR-type literature. It mirrors my experience being a startup founder acquired into a decades-old F500 tech company. It took me quite a while to figure out how this huge, well run company really worked and I always felt my understanding of the important ways it was different from my startup was unique and distinct from the standard business writing.

I'd be very interested to compare notes. I'm username at alphabet's service.

Founders have to lead themselves and other while going from 0 to 1.

I’m not sure what you are saying is accurate.

Even if Paul was rewriting a topic… more than one writer writes about a topic for their readers, no?

The MBA form of management using people as process .. is increasingly less applicable and in need of updating .. where software increasingly can push papers and connect people and processes.

We don’t see this much in management consulting or MBAs very much. Maybe there’s a benefit to leaving how the world was.

> There are as far as I know no books specifically about founder mode. Business schools don't know it exists.

> …what they were being told was how to run a company you hadn't founded — how to run a company if you're merely a professional manager. But this m.o. is so much less effective that to founders it feels broken. There are things founders can do that managers can't, and not doing them feels wrong to founders, because it is.

It’s so conventional that he de-listed the article but keeps it published and available by URL

> By promoting themselves from data to code, hijackers on September 11th promoted box-cutters into 400,000 lb. incendiary bombs

Published September 2001

i want to give pg a lot of credit for clear thinking here, but of course if he'd suggested locking cockpit doors in august 02001 instead of september, that would have been significantly more impressive

your original summary of https://paulgraham.com/hijack.html was not correct

The code/data rhetoric is not exclusively an earmark of Lisp. A primary concern in security are situations in which what is intended to be data allows for a surprising malicious use whereby it effectively becomes a way to program behaviors into the software which processes the data.

For instance, Winamp being exploited by loading a specially crafted MP3 playlist file is an instance of data becoming code; no Lisp in sight. Code being a flipside of data, in the context of security, is simply the consequence of the Von Neumann model.

Graham is arguing for compartments; exactly why we use containers and such. The main idea is that the passenger cabin should be sandboxed away from the cockpit, which isn't earth-shattering.

Where he mentions Lisp is this:

> The defense that does work is to keep code and data in separate places. Then there is no way to compromise code by playing tricks with data. Garbage-collected languages like Perl and Lisp do this, and as a result are immune from buffer overflow attacks.

This point seems bungled. Garbage collection is no panacea. Bugs in a garbage collected run-time can expose applications to exploitable attacks. The advantage in Perl and Lisp is that the application programmer is not writing low-level buffer manipulation routines from scratch. That stuff is in the language run time, where we debug the low-level implementation code once, and have thousands of applications use the debugged thing. If a hole is found, we fix it once, and close the issue in thousands of apps once they upgrade to the new run-time.

Garbage collected languages do not necessarily keep code and data in separate places. Moreover, non-garbage-collected languages do that. The C language can easily be implemented in a conforming manner such that the data areas (automatic storage (a.k.a. stack) and dynamic (malloc) are not executable. C keeps code and data separate. Functions are not objects. In some C implementations, like certain DSP chips, functions are in a separate space; you cannot cast a function pointer to char * and access the function image, because the resulting pointer will be interpreted in a different memory area. Of course, C data can contain pointers to functions, which can be redirected if overwritten.

Lisp data can also contain function pointers: e.g. a closure object with a pointer to code and to an environment. If that is stored in a heap somewhere where an array is also stored, and the run-time has a bug which allows array overrun, it could perhaps be exploited.

as you know, though, there is a connection between this kind of security and garbage collection. specifically, if you're using a language that bounds-checks all array accesses, so array overruns are impossible, but relies on that same application programmer to free pointers manually, you can have a use-after-free bug, where a function pointer is written into heap space previously occupied by an array (or other data structure) to which a pointer still exists. if the attacker can cause writes to happen via that pointer, they can still break your security

garbage collection is a perfect guarantee against use-after-free bugs, unless of course the garbage collector is buggy. it's not the only possible solution; alternative solutions include statically allocating everything (abjuring dynamic allocation completely, like cobol), linear typing, never deallocating anything, and mlkit's region-based memory allocation are some alternatives which have been used. garbage collection is the most popular and probably the most practical

so it's not just that we have thousands of applications use the same debugged low-level buffer manipulation routines. it's also that we have thousands of applications use the same debugged garbage collector

i want to point out that even without having code and data in the same memory space, there are a variety of things an attacker may be able to do. when non-executable stacks, aslr, and w^x protections started being implemented, attackers started returning into libc; function pointers that point into the middle of libc would work just as well. (return-oriented programming might be more difficult, unless the thing being used-after-freeing was a large stack-allocated variable, which would be unusual.) and of course if there are shell commands, sql commands, java bytecode, or the like in data memory, overwriting them with malicious data may be just as good as uploading malicious machine code