Discover more from Wysr by Cameron Armstrong
A Simple Leadership Framework for Tech Founders
1. Be responsible for everything that happens or FAILS to happen. 2. Facilitate your team's ability to win 3. Protect your team.
If you don’t have a leadership philosophy as a Tech Founder, you should probably figure one out…because you just admitted you’re leading people without a deliberate framework.
There’s a lot to say about leadership in startups, but most of the advice sounds basically the same.
Be emotionally intelligent. Hire people smarter than you. Don’t micromanage. Keep learning. Listen to your team. and so on.
All good advice, but these are just things you should do as a leader, not philosophical approaches to each and every day you’ll spend as a founder leading your organization. Good frameworks help you fill in the gaps when there’s not a clear answer to the question you’re dealing with. These activities don’t help you structure an unstructured situation as a leader, but maybe after today you’ll be able to deal with your leadership challenges in a better (or at least more structured) way.
Tbh, thinking about leadership is sometimes not really a focus for founders until it’s far too late (imo) and to a degree this makes sense. Product Market Fit is obviously critical for the survival of the company and at the earliest stages of your startup, there’s too much to do to spare any time thinking about non-core tasks.
You are continuously making decision after decision to gain and maintain small bits of momentum and you basically just accept as a fact of life that you’ll sometimes make bad calls. I certainly did in my time as a cofounder of my e-commerce startup. Bad calls are natural and part of the chaos in the primordial soup of startupland.
However, the one thing you can’t afford to screw up is your interactions with your team. This, potentially more than anything else, shapes your organization’s future. Good interactions bring you closer together through honest debates & discussion and bad interactions create distance internally via politicking or avoidance behaviors. The way your team sees you & how your leadership style makes them feel directly influences what will get done (and how well!) on any given day.
My philosophy on leadership is shaped by my experiences, as yours and every founders’ will be over time (if not already). As an Army Officer, I led units from 5 to 50 Soldiers in uh...high-stress environments for 4 years.
To be honest, the military wasn’t that dissimilar to the environments to startups in which I’ve led, advised, or invested. Change was the only constant, most of our problems were novel (at least for us), and we had to use our baseline knowledge and experience to figure out how to move things forward every day . While the stakes might have been slightly different, my private sector teams’ emotions, thoughts, and concerns were largely the same as my military teams’ while we traversed our startup journeys.
I thought it would be different. I did my research to find really deliberate and practical thought around leadership in the private sector (especially when it came to early stage startups), but man I was disappointed. There was a lot of words, but not a lot of meat about how to no joke run a tech organization. Frustrated with this dearth of information, I decided that my best course of action was to apply the things I had already made work in the military to my approach to leadership at my startup.
I focused on primitives to guide my decision making in the ambiguous situations in which we typically found ourselves and it actually turned out pretty well.
This is my (nested) Leadership Framework that I still use today.
I’m responsible for what my organization does or fails to do
It’s my job to facilitate my team’s ability to do their job
It’s my job to protect my team from the external chaos waiting in the wings
Principle 1 - I’m responsible for what my organization does or fails to do
This is lifted directly from the Army FM (Field Manual) on Platoon leadership. The key here is that it emphatically does NOT mean that you need to do everything in your company yourself. It all rolls up to you, but can’t only start with you. Another way to think about this is that “not everything is your fault, but it’s all your responsibility”. The balance between acknowledging the limits of your personal control and the obligation to still deal with things beyond these limits is one of the most challenging things for high performing founders to realize, accept, and embrace.
What does this actually mean? Take this example:
In the Army, the Platoon Leader’s highest casualty producing weapon is her radio.
That radio is the link between her organization and the awesome firepower that the rest of the military can bring to bear (jets, helicopters, artillery, oh my) as well as typically being the only method of coordination between her geographically separated units. The shared understanding of the initial intent of the operation (ie. Attack this hill at noon) between her and her team is the foundation of the plan. This foundation is supplemented by continuous, course-correcting adjustments via the radio. These two components working together are the only thing that keeps a mission on track especially when something (literally) blows up and the plan goes to hell.
This course correcting responsibility cannot be overstated.
It should be front and center in your mind every day as you think about where to focus your team. It’s the implementation incarnate of the extreme ownership that total responsibility requires. The founder’s role as the “Keeper of the Focus” is crucial to compounding success over time.
You, as the founder, are typically the only person in the organization that has the breadth of exposure to understand the disparate connections across activities that need to be made in order to achieve the startup’s goals. Maybe you’re the only person in the room that has critical information from your last advisor call to share with the team closest to the problem. Maybe you’re the only one that is thinking past the next capital raise and can push to get that core feature started today so you’ll hit your milestone in 3 months rather than 3 quarters.
Good founders reduce friction and the best way to do that is to proactively communicate key knowledge early, often, and consistently. If it’s not happening, it’s on you and owning that responsibility that is unbelievably powerful.
Conversely, when the team actively messes up you also need to own it. Not to let people off the hook for not hitting their metrics, but because your ownership let’s them forgive themselves in a productive way. Did they build the wrong thing? You didn’t translate your vision well enough. Did something not get built that should have? You didn’t implement the proper checks. Of course, consistently underperforming team members need to be either improved or removed as evidence mounts, but ultimately you’re the one that promised all this stuff to your customers and your investors.
You can’t pass this buck...well. You can, it just won’t work out well for anyone involved.
Principle 2 - It’s my job to facilitate my team’s ability to do their job
These principles are nested which helps me prioritize and focus at the right level of abstraction for the situation at hand. Accordingly, Principle 2 is the most important Specific Case that Principle 1’s General Case implies.
Bluntly, even the most capable team will fail without the proper resources.
This sometimes means actual material resources (servers, marketing budget, more brainpower, more interns, etc), but more often means creating the psychological conditions for your team to win. I think of this as developing my organizational resources (AKA people). Getting really good at building organizational resource capacity requires thoughtful practice, experimentation, and a lifelong dedication to the study of people. I know that’s not a helpful sentence, but getting better at this basically involves two steps:
Get good data on what your team needs
Give it to them!
Honestly, step 1 is tough to effectively do (at least at first) because most people have been treated so terribly in their careers or been so improperly led/mismanaged that even the most self-actualized members of your team probably have a near mortal fear of asking for help. Plain and simple, you can’t facilitate if you don’t know what their blockers are and straight asking won’t necessarily solve this.
Counterintuitively, Smart and Capable People are often the worst offenders here because their conception of self is usually wrapped up in their ability to solve problems (myself emphatically included). This is a huge, core problem at a startup because when someone on the core team (or important sub-team) keeps their (very real) problems or blockers to themselves, they can limit the growth of the entire startup until it’s unblocked.
This is bad because every extra minute wasted in Q1 turns into days wasted in Q4.
Sometimes there are parallel paths that mitigate this problem, but in the early days everyone is probably working on the same things so you need to be laser focused on spotting these hidden blockers.
You shouldn’t hold this against your team (it’s a rational response to poor leadership), yet it immediately turns into your responsibility when you onboard people to your organization. Fixing this is a long term effort that never really finishes, but generally involves 2 things. The first is setting a standard of pragmatically supporting each other in your organization and the second is aggressively embodying that standard.
As a leader, you must communicate to your team in a public forum that asking for help when they need it is critical to your startups success. This sets a visible precedent for everyone to see (I call it Setting a Support Standard). Then, over time, you then have to consistently ask for help yourself from your team in a public way.
Write an info request in a joint slack channel. Ask a junior team member’s opinion during your standup. Get perspective around the table to clarify a point that is being discussed while on an external/customer facing webinar with team members. Do the things that show people that asking for help is how the Boss does his best work (I call Embodying the Support Standard).
So restated, one of the best ways to get a good data stream about what your team needs (aka Step 1) is to:
Set a Support Standard
Embody that Support Standard
The point is not to project confidence as a leader (although thoughtfully asking for help does this in spades). The point is that it will lead to better and faster solutions because your team will see and intuitively understand that asking for help is a force multiplier, not a weakness.
When you start doing this, your team will eventually try it out. Keep a sharp eye out for this. When you see that someone who is brave enough to ask for help on something publicly praise them for doing so. Call out how they probably saved days of work by getting the answer and not trying to reinvent the wheel.
Look for tangential examples of your team embodying this. Mentorship, code review pairing, and apprenticeship style training are all in this spirit. Celebrate the senior member’s teaching contributions to the good of the team and support the newly educated person’s embracing of your standard. Finally, consistently ask your team what they need both generally (“Need anything to unblock you today?”) and specifically (“How many more intern hours will you need to proofread that presentation?”) based on their part of the business.
This isn’t a fuzzy, feel good technique.
It’s a foundational part of the facilitation required to build a high performance team and you should overcommunicate that. Great teams make each other better by the org pushing individuals to improve and by individuals pulling the org for self-improvement opportunities and leaders making sure that both of those things are happening.
At the end of the day, you can’t facilitate anything if you’re not getting good data from your team on what their bottlenecks are. Once you get a good data stream for this first step, Step 2 is generally as simple as listen to it and unblock.
Principle 3 - It’s my job to protect my team from the external chaos waiting in the wings
This is the hardest one to pin down and the easiest one to screw up, but it’s also potentially the most impactful to your company’s trajectory. There are a ton of amazing teams that have been torn apart by FUD (fear, uncertainty, and doubt) that could have been avoided if a stalwart leader had been there to hold them together.
Critically, this does not mean lying to your team.
Nor does it mean coddling them. Many (often smart) people think it does and they’re wrong. Your team is made of grown, thinking adults with agency and they deserve to be treated as such.
Protecting your team means Building the World that gets them to see The Vision of where you’re going together and how you’re going to get there, come what may. This perspective may feel a bit normative (because it is), but your (early stage) team is following you because of your conviction and ideas (almost by definition because your venture hasn’t achieved anything yet) so having a strong opinion about how to have hard conversations with the people on your team is a must. You’re going to hit some rough times eventually and they deserve the effort of your preparation for how you’re going to handle that.
I’m not a diehard fan of Radical Transparency a la Ray Dalio, but I do firmly believe that most people are mature enough to handle their reality and, more importantly, they deserve clarity about events which will affect their lives in a material way (both good and bad). If someone is not mature enough to handle the news that it might be a rough few months while you try to secure that next round of funding, that person probably wasn’t a good fit for your startup team (or startupland in general) anyway.
Does this mean the ultra direct approach with bad news a la Moneyball? Partially.
But it also means focusing on what’s next and where you’re going and how you’re going to get there.
I’ve found the best way to handle sharing tough news is by framing as follows:
Start with a clear and honest explanation of the problems you’re facing
Transition to your ultimate Vision for your team and how these problems change that (if at all)
Explain how you’re going to make the Vision a reality. Sometimes you just need the first step and sometimes you need to explain more thoroughly the way.
Doing this sucks, but it’s how you protect your team. The counterintuitive trick is to realize that most of the time the best way to protect your team is by fortifying their internal strength rather than actually blocking/safeguarding them from some external thing like budget cuts or politics (although this definitely also happens, especially if you’re a small team in a large organization).
Check out Winston Churchill’s first speech to the House of Commons (text here) in May 1940 as Hitler had just invaded Belgium, Luxembourg and the Netherland and the Fall of France (a British ally) seemed a likely outcome. It has all these elements and is staggering to listen to in the context of an existential threat to their country. Delivering bad news sucks, but we’ll probably never have to deliver news as bad as this so that’s something to think about!
Telling the truth is a way to strengthen your team’s resolve because each crisis (or victory for that matter) is actually another opportunity to re-inspire your team about The Vision. Framed correctly, you’ll improve your team’s cohesion and willingness to build together in ways that founders that lie or avoiding sharing crucial information in the name of “protection” can’t compete with because, much like time, legitimacy is one of the few finite resources. Lies and lies by omission undermine and erode legitimacy. Plain and simple.
Interestingly, this approach works for communicating good news as well! It’s a lot easier to share positive news to your team, but what’s less common is for that positive news to be used as another chance to focus the team on the goal. Remember your “Keeper of the Focus” role!
You’re not gonna always nail this one, but a 10% improvement over today could help retain some key team members during a rough time and reduce the ambient stress level of your team, which frankly pays for itself pretty quickly.
When it comes down to it, your team is all that stands between you and liquidation.
No amount of think piece writing, workplace perks, and quippy tweets will save a team that loses confidence in the leadership of their organization. Actions that demonstrate responsibility, facilitation, and honesty keep that confidence going strong well into the toughest days of your startup journey.
I think this gets overlooked in tech because allocating time to deliberate leadership thinking is commonly dismissed as one of those “squishier” things that you can’t observe with a number. This dismissiveness is straight avoidance of the tough reality that, at least for now, we work in organizations with other people. It’s a mistake that is actually pretty detrimental to the long term potential of your startup because without at least some thought you’ll end up trying to scale inefficient or bad leadership and organizational systems once you nail that Product Market Fit you’re working so hard at finding.
For better or worse though, people will put up with a lot...until they don’t.
But let’s be real - they shouldn’t have to! You have the sum of all humanity’s knowledge and a written historical record about building effective teams of various sizes, makeups, and distributions at your fingertips! You don’t need to invent it.
Somebody else has almost certainly tried, failed, and improved whatever team technique or leadership style you’re thinking about doing. I recognize it might not seem immediately obvious where to look for good examples of these trials (hint - startup focused books usually index more on tech and less on people), but fortunately this means that it really doesn’t take that much time to get much closer to the right answer for you and your team - it’s just an issue of finding better data sources to learn from.
Classics are often classics for a reason. If you haven’t read “How to Win Friends and Influence People”, “The Effective Executive”, “Leaders Eat Last” please do so for the sake of everyone on your team.
Take it all in, let go of the stuff that doesn’t resonate with you, but read it so you can consciously construct your organizational process and approach to people rather than just letting it happen to you.
I hope this added value to your day.
Please share this with someone who might find this interesting!
If you have any thoughts or questions about this essay - Let’s Chat
and, of course, please subscribe to Wysr