What is "founder mode"?

I wonder if 'founder mode' is the antithesis to Agile as getting shit done is against the manifesto (in practice).

Not to mention, PG is taking the dangerous route and only looking at a few data points (let's be honest, just one - Brian Chesky, not even Joe or Nate) and trying to extrapolate that over the rest of the domain.

According to PG, Sam was one of his favorite founder types a decade earlier. How did that founder mode work out, except for a failed startup, then having to kick him out of YC, and now heading a startup where all the core team members left for greener pastures? If Loopt did pan out, I'm sure PG would be raving over Sam instead.

At this point, it's about time PG steps out of his inner circle shell and actually meet some successful founders in the YC community on the regular.

> how do good leaders stay in the detail and run great companies at scale?

It's a relevant question not just for founders but for leaders at every level.

IMO, one test for a "good leader" is whether they are capable of doing the work 1 to 2 levels down into their teams. The more familiarity they have, the more they are able to hire, fire, and evaluate those people. After all, it's pretty hard to evaluate work in an unfamiliar domain. Paradoxically, though, good leaders do not contribute to that work directly. So how do they maintain their skills if they don't do the work?

Consider the case of a front-line engineering manager with IC engineer reports. A good one will know their team's codebase, know where it could be easily extended and have good intuition for the time required for any given feature idea. They know the difference between good and bad code. But they NEVER submit PRs, mostly because the maker schedule/manager schedule problem [1] forces a choice of doing only one type of work well. (Every new manager I've seen who wants to "spend 10-30% of their time writing code" will either fail to support that code or fail to support their team as a manager, when in a fast growing team or company.)

The solution for eng. managers is to have the codebase on their machine, be able to build and run it, and occasionally implement their own experiments or POCs. These things NEVER go to production. It's meant purely to maintain the manager's familiarity with the codebase and staying current with their team's output. (Hat tip to CW).

Note that we still don't have good labels for these behaviors. "Hands on" and "hands off" confuses the issue-- is the example above "hands on" or "hands off?" It's both and neither, because those aren't useful labels.

There are other solutions for leaders higher up the org chart. The article mentions skip level 1:1s and niche area deep dives both with the purpose of evaluating leadership effectiveness. When I did these, I'd always start with setting the same context: I have two goals for this meeting and one non-goal. I want to hear about what you're working on, what's going well and where the challenges are. I also want to answer any questions you have about what's going on elsewhere in the company. My non-goal is giving you specific direction, since that's always between you and your manager. I'm just here to gather and share information.

The role of a leader is to set goals, share context and ensure the right team is in place, hiring and firing as needed. They need to know what's going on from top to bottom in the teams they lead, and in order to hire effectively, they need to be capable of doing the work 1-2 levels below them. But they never actually contribute 1-2 levels down, because that would severely undermine the people they've delegated to.

I think this is why so many had a knee-jerk reaction to in PG's founder mode essay, where he implied that founders have a special ability to bypass management layers and contribute directly (in the Steve Jobs example). I've seen it happen, and it failed 100% of the time. 100%. After establishing some amount of managerial structure -- wild guess would be after 50+ total employees -- contributing directly several layers down into your team is a recipe for disaster. The puzzle is how to lead effectively without making that mistake.

[1] maker schedule/manager schedule https://www.paulgraham.com/makersschedule.html * Bonus behavior: good managers are sensitive to booking meetings with any of their team members who are on the maker schedule.

On the basketball court, when someone's got a hot hand: Damn, he's going founder mode.

At dinner, when someone devours a meal: I went founder mode on that shit dude.