“founder mode” – a simple rebuttal

Paul Graham – I’m not buying what you’re selling. Why are you asking us to suspend belief that management doesn’t work and only founders can lead companies to success?

I read through the founder mode blog post, and it left me profoundly sad. Sad? Yes, because Brian Chesky, at least as Paul Graham portrays the talk (I can’t seem to find a video of the talk anywhere), is bucking conventional wisdom to avoid managing and advocating for more of a hands-on approach as a leader. The so-called ‘conventional wisdom’ they disguise is that this advice doesn’t scale and leads to worse outcomes. Propping up “founder mode” as the next great leadership style is a fool’s errand.

I’m sad because Paul seems to selectively forget success cases for non-founder run companies, e.g. Microsoft (Satya), Apple (Tim), Amazon (Andy). These are not small companies with a combined market cap of ~$8 T. That’s $8,000,000,000,000. What are these “manager mode” companies doing from which start-ups could draw inspiration? Obviously, the above companies have been successful, what is the logical basis for this argument?

The key failure in logic in the argument of “founder mode” vs “manager mode” is conflating a company being “run into the ground” that conventional management simply doesn’t work. Looking deeper, a great manager will dissect and investigate why. Is it an easy process to investigate what’s broken? No. However, building a company whose success is inextricably bound to a particular leader (founder mode) is super dangerous (especially to shareholders).

The danger of relying solely on a single leader highlights the need for robust systems that transcend any one individual. A successful way to ensure smooth operation in business is creating auditing mechanisms to roll-up status and risks in various business units. These recurring auditing events help leaders to stay informed and ask questions to tweak execution (a project is taking too long, or is going off the rails) and act as a forcing function to hold the business leaders accountable to the reporting and risks. Unfortunately, it takes courage to hold people accountable. 

A case study, when I worked at Amazon, there was great company lore around how Jeff Bezos would show up to six-page review meetings. He would allow the least senior people (after reading for 20 mins) to give comments on the doc before asking his questions. This gives oxygen for other ideas and sets an example that Jeff isn’t the most important person in the room. Jeff Bezos, at Amazon scale, couldn’t possibly dive deep into each business frequently. He was able to scale and trust leaders by establishing mechanisms which improved the successful outcomes (e.g. six pager reviews and operations / budget planning). Examples of great successes that have been driven through the six page process are Kindle, Amazon Prime, and every Amazon product which has launched since 2004. These documents because of the rigorous review process drive clarity of thought in the decision making process of what to build for the customer, how and why.

The success of Amazon’s structured approach raises a critical question: why then, should we rely on the singular vision of a founder when a well-designed management system can achieve so much more? Why am I skeptical of “founder’s mode”? Because I have worked at companies where the founder was deeply entrenched in “founder mode” philosophy. Every new product idea and innovation had to pass through this founder. Being the single decision maker and hands-on certainly didn’t improve the outcomes because the company still struggles to this day. 

A more nuanced thought around “founder mode” is whether companies are creating the right structures (and mechanisms) to succeed even in the absence of their founders.

Great Expectations: Not just a Dicken’s Tale

Disclaimer: What you don’t know, can hurt you.  

My expectation for you, as the reader, is that these guidelines will help you to take a more intentional approach to both setting and clarifying expectations.  

Clarifying expectations – What do I even need to do? 

When I was a new manager, I had an employee who was relatively new to the workforce. I will refer to them as Wally, not their real name. I had the expectation that Wally would be able to deliver on engineering tasks which another team needed done. The previous manager had not stated the person wasn’t meeting expectations as part of the transition. As the project was executing there were clear signals (to me) that this employee wasn’t meeting expectations (e.g. not giving status updates on progress made, not treating the project with urgency). This was clear to me, but not clear to Wally. What was the gap? I hadn’t set clear expectations with Wally (e.g. you need to send updates on your progress to stakeholders daily) and the other team’s lead. A couple weeks in, and I was having an expectations conversation. This is the challenge of expectations. My expectation, which was implicit is that a person should understand the importance of proactive communication and execute as quickly as possible on a project. 

Expectations – they’re everywhere! 

Expectation [ ek-spek-tey-shuhn ] – n. 1. a belief that someone will or should achieve something. 

Each job that you will hold in your life will come with expectations. Some expectations will be written down (explicit), most will not (implicit). Your job as an employee is to understand these expectations, the spirit behind them, how they apply to your role, and meet (and hopefully exceed) these expectations. 

Why are expectations so important? 

Expectations make and break relationships, this includes work relationships. Think back to the last person who consistently didn’t meet your expectations. What happened to that relationship over time when that person consistently didn’t meet expectations? 

As a manager, your role is to provide clear expectations to employees on how to be impactful and grow impact over time. Clear expectations are good, because the context in the expectation helps create enough structure for an employee to understand how to be successful.  

So, how do you hone your expectations: 

  1. Ask your manager –
    • your manager should have clear expectations for your role and level at the company. At larger companies some of these expectations are generalized for your role and level as a leveling guide or career ladder document. Whenever I have a new employee start on my team, I first ask them to read through and evaluate which areas they have demonstrated for their role and level, and identify where they are exceeding, meeting, or not demonstrating areas. This identification of not demonstrating an expectation is not punitive, but rather to illuminate which areas we can focus on demonstrating in the future (I.e. setting up goals). 
  2. Align to written current and next level role expectations
    • Expectations for a more senior engineer may have statements like the following: “autonomously deliver large-scale and ongoing business impact across a team, product capability” 
    • If they have been in their current level for a sufficient period of time, I ask them to look at the next level expectations and do the same identification (exceeding, meeting, not demonstrating). This can then feed into promotion readiness discussions. These role and level expectations merged with business needs should result in a goals-type document.  
    • A couple of clear examples:  
"In order for our team to scale successfully in the next quarter, I will interview 2 candidates a week, providing written feedback which clearly articulates where they are meeting / not meeting the rubric for the role / level" 
"I will execute the XYZ project as the technical lead and launch it by end of Q3, this will involve me working with the profile, search and detail page teams (both mobile and backend), aligning on a design, running status update meetings (to identify risks), and send stakeholder update emails"   
  1. Align to unspoken organization norms
    • observe others who are successful in your role (at your company or in your org) – the hardest expectations to meet are unspoken (unwritten) ones. A company may have a strong set of principles that define behaviors which are rewarded, e.g. Amazon LPs. 
    • These principles though can have different priorities depending on the organization or leader. So, what is defined as a principle for the company may not be the prioritized principle of the organization or leader. Let me give a specific example, as these leadership principles (LP) have some tension built into them that isn’t always apparent. The principles of deliver results and insists on the highest standards can be at tension with each other. If you are in a v1 product team where time is of the essence to launch the product, deliver results (getting it done) may be prioritized over insists on the highest standardDeliver results then will be rewarded as compared to someone who might demonstrate insisting on the highest standards (with less results delivered). If you are having difficulty these unwritten expectations or what is rewarded in an org, find one of the influencers / strong performers and ask them for what are the most rewarded behaviors. 

How are they used by your manager? 

Expectations are a tool like anything else, to facilitate alignment between your manager and yourself. When you have strong alignment on expectations (and goals) with your manager, and then you execute against those expectations well, trust is built. Notice, I didn’t say that rewards would follow, that doesn’t always happen in the immediate term as the impact of the project might not turn out to be as big as anticipated, etc. (More on that in a later blog post.) However, trust is the lifeline of employee / manager relationships. The converse of not meeting expectations doesn’t necessarily result in performance management and end in termination, but in loss of trust.  

Why is trust so important? 

Many times, as a manager, I need to assign a big project opportunity and more often than not, I give those opportunities to an employee who has earned my trust. So, by not meeting expectations, and therefore not earning my trust, the employee is losing out on the opportunity to own a critical project. A specific example: imagine there is a two week timeline to deliver a feature, should I give the project to someone who I know will own the project and unblock themselves to meet the deadline, or a person who might have equivalent experience, but makes excuses of why things aren’t able to get done (e.g. too hard to do in an unfamiliar code base)? The question seems rhetorical, but the decision making for the above situation is something which managers face all the time.  

How do I build trust in an ambiguous situation?

As a manager, I have learned through the years that my leaders can’t read my mind. So, how do I manage the situation of discerning their expectations? (this applies to most senior level folks as they need to identify the most important problems to solve)

Over communicate. When I have a new manager, I turn up my verbosity level, as I tend naturally more towards terseness. I demonstrate how I think by writing the following: context of the problem, potential solutions and trade-offs, (if I’m not solving it individually) how I am coaching someone else through solving the problem, and when we should have enough information to move forward with executing. I then share that doc with my manager.

Why do I do this? I’m not looking for approval from my new manager, I’m looking to provide my manager with enough context to show them how I am thinking through the problem in order to develop trust. By over communicating in the two to three months after joining a new manager, often I find this develops a strong amount of trust which leads to greater and greater autonomy for me and my team. Additionally, if there is some failure of logic in my thinking or some missing context, they can provide that, and I can learn about those hidden expectations from them.

I liken this approach to showing your steps for math problems in school. Two people can have the same correct answer, but the teacher may grade down one of the students’ homework or test, because they didn’t show the work. They didn’t articulate how they came to the correct answer, so it could have been luck.

What should I do? 

Think about a few of your work or personal relationships. Ponder expectations that you have of the other person, and what expectations they might have of you. If you have a close enough relationship with them, ask them if your expectations assessment is accurate (are you missing any?). The results could be unexpected, and help you grow.  

3 essential characteristics to making a great hire

You need to hire a person to help you deliver on your goals. How do you make sure that person is the right fit for the job? I have identified three characteristics (that you need) in hiring the right person for the job. By focusing on clarity, patience, and perseverance, you will have success in hiring.

Clarify what you need

Hiring can be one of the most daunting job responsibilities. At first, it can seem insurmountable, you need a person who has specific skills to help me deliver on my company or team’s vision, and you need them right away. As you focus on the immediate need, anxiety mounts, and instead of focusing on the what (skills and behaviors the candidate would bring), you start focusing on the when (you need them right away). The first major obstacle is fuzzy candidate requirements, what role and responsibilities do you need this individual to perform? You need to clearly define these roles and responsibilities. Write everything down that you can think of in terms of responsibilities. At a larger company you may have more well-defined role guidelines that define expected responsibilities. However, beyond the base role guidelines, you need to focus on what is unique. Once you have captured all of these responsibilities, prioritize these responsibilities.

An abbreviated list of responsibilities for an M1 software development manager:

  1. Responsible for hiring team and growing team member skills
  2. Capable of project management in a large organization (breaks down work into milestones, communicates risks to stakeholders, actively manages risks, understands the software development lifecycle)
  3. Understands architectural trade-offs with systems being built and can articulate reasons for decisions
  4. Capable of creating three-year vision document that captures personnel needs
  5. Has expert knowledge in running a high scale service, actively creating the correct operational metrics for service and mechanisms to monitor them

Let’s consider this abbreviated list, which is for a software development manager (M1) at Amazon. These are all expectations called out in the role guideline for an SDM. However, these expectations will be different from team to team. Consider a senior manager (the hiring manager for this role) who is working on an incubation project. She ranks the responsibility list as follow: 4, 1, 3, 2, 5. She ranks #4 as a priority because she needs an individual who is helping to shape the vision of the product. #1 is the second highest, because this manager will need to hire and grow a team from scratch. #3 is important, but there is a strong senior SDE on the team. #2 is lower because this project is more insulated from the company. #5 is less important because this is a greenfield project which has no customers at the moment.

Patience is a virtue

Great, now you have clarified what skills a successful candidate will possess. As a skilled entrepreneur, manager or individual contributor, you know you need to focus on the long-term goal of what skills this person brings, but the time pressure to hire dominates your mind. In order to give yourself peace during this process you must acknowledge that hiring the right person takes time. The time required is illustrated in the following pipeline.

1 Sourcing -> 2 Phonescreen -> 3 Onsite -> 4 Offer

Funnel
Image courtesy of my talented 12-year old daughter

I show the chart to illustrate the full lifecycle of how big companies hire. Each of these stages take time. There are standard ratios that recruiters know in terms of hiring. There is no shortcut, it is purely a numbers game, and it takes time. Let me illustrate this with some ratios; these aren’t true numbers, as these differ from company to company. For this illustration imagine that for each 10 reach-outs (cold-call), we have 1 interested candidate. For each 10 phonescreens we have 3 candidates who qualify for an onsite loop. For each 10 candidates we have 2 offers, of which one will accept.

Working back from that one candidate, you have the following math:

1 candidate requires 10 onsite loops

10 onsite loops require 30 phonescreens

30 phonescreens require 300 reachouts

Wow! That is a lot of work for a single employee. As a manager, this is where the temptation becomes strong to take short cuts. Don’t do it! Here are some shortcuts, and why you shouldn’t take them:

  1. Lower the hiring bar. For any role, you should define expectations of responsibilities. These expectations are sometimes called role guidelines, and should unambiguously define criteria for each level of that job family (a good starting place is defining how much autonomy, scope and business impact is expected). For tech positions we define the hiring bar in terms of demonstration of functional and behavioral competencies. Measuring these competencies against a role guideline for an ideal candidate gives you more objective data to determine whether you should extend an offer and at the level of role you should offer.
    1. Functional competencies are role specific needs for the candidate to be successful. An example for a software development manager at Amazon is demonstrating technical proficiency, i.e. software architecture and (service) operational excellence. We measure functional competencies to ensure that the candidate is able to perform the required job functions. Imagine hiring someone to do accounting that doesn’t understand balance sheets, quarterly reporting or who is bad at math. Hiring an unqualified (or underqualified) individual on the functional competencies will have negative consequences.
    2. Behavioral competencies. Behavioral interviewing is based in the theory that past performance indicates future results. Large companies, like Amazon, have a set of criteria for determining whether a candidate is a good fit in terms of behavioral competencies. Amazon defines the behavioral competencies as leadership principles (LPs for short). Read more here: https://www.amazon.jobs/en/principles. In each Amazon interview we ask behavioral questions for evidence and demonstration of these LPs. Think of these LPs as the codified work culture at Amazon. We look for a cultural fit by looking for strengths and/or concerns in their behavioral examples. These behavioral examples are mapped to a STAR (situation, task, action, result) narrative type format, and we ask follow-up questions to understand the individual’s autonomy, scope, business impact and personal involvement (especially important for hiring leaders). An example, to illustrate the point, when interviewing for Bias For Action LP, I want to understand how comfortable a candidate is with making a decision without all of the information.
  2. Introduce bias into the loop to change the outcome (good or bad). As part of running a fair and impartial loop, it is industry standard to avoid cross chatter about candidate performance to other interviewers on the loop. By firewalling the feedback from one interviewer to another, you reduce bias into the loop. We accomplish this at Amazon by having our feedback system (a website) disallow view access to the feedback until the interviewer has entered their feedback. After the feedback has been entered into the system, we hold a meeting, called a debrief, where we discuss the strengths and concerns for the candidate. By keeping bias to a minimum, the candidate has a fair chance of doing well in each interview. Therefore, even if the candidate performs poorly in a single interview, they can perform well in other interviews. To compare the approaches, imagine as the interviewer that I have a concern about a candidate not taking a data driven approach. If firewall rules were broken, after my interview I might mention to the next interviewer in the loop, this candidate doesn’t take a data driven approach, which would result in a biased impression for the next interviewer.  However, if I wait until the debrief, I can voice my concern about a candidate not taking a data driven approach and ask for counter examples where the candidate took a data driven approach.
  3. Ignore red (or yellow) flags. Red (or yellow) flags are indicators of poor judgment or anti-culture signals. An example of a red flag is a candidate who makes a comment that is sexist. During one interview debrief, we were discussing a candidate who was strongly technically, when another interviewer in the debrief raised a red flag (strong concern) about the candidate. The concern was around a mentoring example, where the candidate shared a story about a female engineer whom he had mentored. When asked about how he helped her, he made several statements, which the interviewer followed up to clarify, that were derogatory to females being uninterested in diving deep or inferior technically. Our debrief noticed the narrative as being sexist and decided to pass on the candidate. Can you imagine the negative impact of that candidate on a team with female engineers? 

Persevere to the end

You are patiently evaluating candidates and avoiding pitfalls as you pursue a candidate who brings the necessary skills and attitude. This is the point of hiring where you need to dig deep and persevere. Two years ago I took on a multi-disciplinary management role. With this role I needed to hire a product manager. The hiring process took three months. Fortunately, for me, the internal Amazon job board was providing qualified candidates, so the sourcing part was covered. I had “coffee chats”, informal informational-type interviews, with 32 candidates to share as much as I could with the candidates. These informal 30-minute chats resulted in 10 “screens”. For these functional competency screens, I relied upon a senior manager who had a product management background at Amazon. After he vetted the candidates, I had 3 formal loops over this three-month period. This period had many emotional ups and downs, some would disqualify themselves by dropping out after the coffee chat (because of my lack of experience managing PMs), others expressed interest and made it to the screen phase only to be disqualified for lack of technical depth, one candidate, to whom we offered a position, was disqualified for poor performance within his current group. Finally, I found a candidate who was a great fit for the role, he turned out to be one of the best employees that I have managed. The total time investment was around 20 hours. In the midst of the coffee chats, “screens” and formal loops, I started to wonder, “when will this end?”. I have other job responsibilities other than interviewing candidates. However, as a wise mentor once told me, hiring is your most important job. Don’t give up, and be encouraged to persevere.

No candidate is going to be perfect. Even though you won’t find a perfect candidate, by focusing on what you need, making data driven decisions and enduring the highs and lows of the interview process you will find successful candidates. Finding these candidates isn’t an easy job, be patient with yourself and others during this process, and don’t give up.

More about me