Unlike PG's half-baked founder mode essay, this article is more complete in describing what behaviors are successful during scaling. It also matches my experience when Netflix was scaling up the streaming business in the 2010-2016 era.
> 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.
Creo (based in Vancouver, BC) used to be a company that tried to address this. The concept that was used was called "unit presidency". Each employee was empowered, expected, and trained, to make decisions as if they are the president of the company. The principles behind making decisions were called "economic thinking" which the CEO used to say was everything he learnt in a Harvard (EDIT: or maybe it was Stanford) MBA distilled into the core principles. Basically looking at the ROI (Return on Investment) of the decision. Decisions were generally made by consensus though depending on the nature of the decision sometimes other methods were used. This extended to decisions that involved spending money, not just should you pick language X or language Y for your next software project.
I think it worked pretty well for quite a few years. It gradually stopped working when the company acquired a large company with a different culture and also hired people (well, managers mostly) who weren't aligned with the culture. Eventually this basically disappeared when the company was acquired by Kodak.
I've seen flavors of this in other places. Famously Andy Grove of Intel also preached that decisions need to be made by those closest to the decision and empowered people to make the right decisions. More generally this can be reflected in a servant-leadership model where leadership sees itself as facilitating the growth of the people underneath them.
Another requirement for this to work well is that management (e.g. the CEO or other leaders) are able to lay down a broad strategy for the people of the company to execute on. If the leadership has no strategy then tactical decisions can not be made properly. They also need to make sure there's coordination and structure.
Hey, author here, I think you ask a good question and I think you frame it well. I agree that, at least for some major decisions - including this one, "it is fundamentally difficult for organizations of this scale to identify and reason about valuable work."
At its core we are a platform teams building tools, often for other platform teams, that are building tools that support the developers at Figma creating the actual product experience. It is often harder to reason about what the right decisions are when you are further removed from the end user, although it also gives you great leverage. If we do our jobs right the multiplier effect of getting this platform right impacts the ability of every other engineer to do their job efficiently and effectively (many indirectly!).
You bring up good examples of why this is hard. It was certainly an alternative to say sorry we can't support etcd and helm and you will need to find other ways to work around this limitation. This was simply two more data points helping push us toward the conclusion that we were running our Compute platform on the wrong base building blocks.
While difficult to reason about, I do think its still very worth trying to do this reasoning well. It's how as a platform team we ensure we are tackling the right work to get to the best platform we can. Thats why we spent so much time making the decision to go ahead with this and part of why I thought it was an interesting topic to write about.
You're right that the input from other technical teams is hard to verify. On the other hand, that's fundamental table stakes, especially for a platform team that has a broad impact on an organization. The purpose of the platform is to delight the paying customer, and every change should have a clear and well documented and narrated line of sight to either increasing that delight or decreasing the frustration.
The canonical way to do that is to ensure that the incoming demand comes with both the ask and also the solid justification. Even at top tier organizations, frequently asks are good ideas, sensible ideas, nice ideas, probably correct ideas -- but none of that is good enough/acceptable enough. The proportion of good/sensible/nice/probably correct ideas that are justifiable is about 5% in my lived experience of 38 years in the industry. The onus is on the asking team to provide that full true and complete justification with sufficiently detailed data and in the manner and form that convinces the platform team's leadership. The bar needs to be high and again, has to provide a clear line of sight to improving the life of the paying customer. The platform team has the authority and agency necessary to defend the customer, operations and their time, and can (and often should) say no. It is not the responsibility of the platform team to try to prove or disprove something that someone wants, and it's not 'pushing back' or 'bureaucracy', it's basic sober purpose-of-the-company fundamentals. Time and money are not unlimited. Nothing is free.
Frequently the process of trying to put together the justification reveals to the asking team that they do not in fact have the justification, and they stop there and a disaster is correctly averted.
Sometimes, the asking team is probably right but doesn't have the data to justify the ask. Things like 'Let's move to K8s because it'll be better' are possibly true but also possibly not. Vibes/hacker news/reddit/etc are beguiling to juniors but do not necessarily delight paying customers. The platform team has a bunch of options if they receive something of that form. "No" is valid, but also so is "Maybe" along with a pilot test to perform A/B testing measurements and to try to get the missing data; or even "Yes, but" with a plan to revert the situation if it turns out to be too expensive or ineffective after an incrementally structured phase 1. A lot depends on the judgement of the management and the available bandwidth, opportunity cost, how one-way-door the decision is, etc.
At the end of the day, though, if you are not making a data-driven decision (or the very closest you can get to one) and doing it off naked/unsupported asks/vibes/resume enhancement/reddit/hn/etc, you're putting your paying customer at risk. At best you'll be accidentally correct. Being accidentally correct is the absolute worst kind of correct, because inevitably there will come a time when your luck runs out and you just killed your team/organization/company because you made a wrong choice, your paying customers got a worse/slower-to-improve/etc experience, and they deserted you for a more soberly run competitor.
Want to second the two parent comments to this. Small freelance / contract team of very very senior very experienced people. 3 to 4 max.
I was fortunate in that I, for the first part of my career, joined teams that were structured like this.
Some additional thoughts:
- keep things small at the start - task your team with at least two goals for the first 90 to 180 days
i ) to define a small but critical piece of work (actually designing and coding something related to what you need to do). Cannot be part of your core platform but will need to eventually be in the platform. Picking the right piece of work here is critical.
ii ) to define a design, roadmap and project plan for completing everything you want done with cost, staffing, tech and effort estimates
Then use the 90 to 120 days and the two tasks above to evaluate:
i) if the folks and team you have put together works:
a) as a team and
b) with your existing business ( can they do the work, can they work effectively with the rest of your business, is the design the come up with solid and does it give you confidence that they can tackle the real core work you need done)
ii) if you can get a sense of what it will cost (what did the 90 day project cost and was it delivered on time and budget per the team's estimate )
iii) if the team can put together a road map with support of the business for the broader objective in parallel to executing the piece of work chosen
iv ) if the solution if palatable from a cost perspective ( money, people, tech, disruption )
v) if the staffing model , architecture and integration proposed for the project by your new team could work (get feedback from the rest of the business about what is proposed by your new team )
vi) if your business can work with this new tech team ( feedback from your existing staff about the folks doing the work and their product for the small piece of work they tackled )
- It is really critical that they be 'senior' people - 'senior' here meaning they have done and seen a lot. The title will not tell you if they are. You have to actually look at what they have done. Look for senior free-lancers with a variety of (longish 4 to 5 years) experience using a variety of technologies (C / Java / PL-SQL / Perl / Rust / C++ whatever etc etc - but boring old tech is better, you will eliminate another variable from your project complexity ) in variety of industries / verticals ( 3 to 5 industries. This is a signal of effectiveness at learning new things and delivering effectively in new fields with new people in new environments.
- it is critical that your freelancers not just be developers: they have to be "business-goal oriented". Consider asking for references who are not developers and consider filtering your freelancer hires through their networks in LinkedIn - do they have a good mix of senior and non-senior people in their network who are NOT developers? That is a good indicator they worked effectively enough with other non-software parts of the business that the people on that side of the fence (marketing, ops, finance etc etc ) are comfortable being associated with them. Pick the areas that matter to you.
- Consider filtering for delivered results when you talk to candidates and in resumes: look for achievements / projects / work delivered rather than work done as this 'could' be a signal that the person is focused on actually 'owning' projects (not work ) and closing out on projects / goals (could also be a signal that the person did not not consider put delivered work in their resume so there is that - so, if you don't see it, just ask something like "what projects have you owned start to finish and how did you architect, design and execute on them" and interpret the response ).
- Key skills to look for in free lancers:
- systems integration (making systems 'talk' to each other - you will have to make your existing system talk to your new system + you will eventually have to get your data off wherever it is now to your new environment and you will have to make the new system work with all the other tech systems you have now)
- system architecture: designing software solutions
- database architecture & design
- project & program management
- lean six sigma / green belt ( means they have may have worked with ops people to optimize operations )
All the difficult stuff is going to happen in the background (batch processing, integration etc etc) so don't bother with front end development skills at the start - that is actually relatively easy to hire for.
You will definitely find folks who have the right profile who will work with you - the key is decent (not crazy) pay, benefits and elements of stability attached (contracted duration with pay guarantees for performance, performance bonuses if possible etc etc).
- Plan on developing a bench from the freelancers so hire some mid-level junior folks to work alongside them for when the freelancers inevitably move on. You will have to hire from outside (try and get mid-level people in the industry, not senior folks, so that it is clear that your senior freelancers are the leaders / owners of work ) but try really hard to source at least a few of these folks from existing staff if possible ( people in other job functions - and are good at those jobs - who are programming inclined ) as they are a good source of how things work to integrate into the team or as new hires. They do not have to be as as senior but they have to be able to keep up. These people start as grunts for your freelancers and learn the system as it is built - they are your future tech staffing.
- Plan ahead for what WILL go wrong.
I strongly strongly strongly recommend reading two books
- The Phoenix Project - https://www.amazon.ca/dp/0988262592
- The Unicorn Project - https://www.amazon.ca/dp/1942788762
They deals with how executives and staff tackled a situation very similar to what you are dealing with and explains how to tackle some of the key structural problems you WILL run into. It is also a great resource for understanding how to run a project like this and understand how things could go right and more important, how things can go wrong and what to do WHEN they do go wrong (because they WILL ). The books will give you a very strong set of foundational thoughts about how to think about running this project if you decide to commit to doing it.
> 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.