Startup Envy

A few months ago a friend of mine who had recently started his own biomedical engineering company came by our office and looking at our space, exclaimed, “wow, I totally have startup envy right now.”  This sparked two conflicting reactions:

First, amusement.  Our office is a spartan, frigid basement that screams “we care more about what’s on our screens than what’s in our surroundings.”  It’s a space that has never crossed my mind as the envy of someone else’s eye.

It’s always cold in our office.

Second, disappointment.  Pathos Ethos has been around for eight years now and while we’ve had our share of opportunities and successes, I am always looking around at the other entrepreneurs on the playground, bemused: “How did that guy get so high on the rope ladder? What makes that gal so special that all the cool investors gave her cookies?”  

Sadly, even with a decade of entrepreneurship under my belt, my startup envy was no different than my friend who had started just a few months ago.  And what did I do with this unusual moment of self-awareness?  I did what everyone does when faced with overwhelming evidence of their own stagnation: I put my head in the sand and blamed others.

Putting my head in the sand and blaming others.

Thankfully, I have an uncompromisingly objective business partner who has the uncanny ability to point the finger right back at me.  Moreover, Pathos Ethos works with enough startups for me to know that even in the best of cases, a startup’s identity and its founder’s identity are so closely intertwined that they are nearly the same thing.  

This, friends, is our inciting discovery: Pathos Ethos’s biggest problems over the years were actually reflections of my own personal shortcomings.

Pathos Ethos’s biggest problems over the years were actually reflections of my own personal shortcomings

In an effort to pass on this invaluable information to the future generations of startup founders, here are three of my own shortcomings that stunted Pathos Ethos’ growth:

Control Disorder

I would never consider myself someone who needs to be in control, but the symptoms that helped me self-diagnose this barrier to growth might be visibly familiar to you, either in a founder you work for, or in yourself:

  1. I often discovered myself extremely stressed because I felt like I had too many disparate tasks on my plate. Project management, customer satisfaction emails, sales calls, blogging, system administration, wireframing, and content insertion on the same day = a cranky founder.
  2. I found my employees always seemed to be waiting on me to make a decision in order to move forward.  After 4 emails, 3 shoulder taps, and 7 slack mentions, they either give up or go rogue.
  3. I would empower my employees to make tactical decisions and then overrule them if they didn’t make my preferred choice.  If you work for me, never, ever make a decision I don’t want you to make, even if I told you I didn’t care.  Also, never, ever not make a decision. Sucks to be you.
  4. I was working longer hours to do the things that I didn’t want to pay someone else to do.  Why hire a devops engineer when I have AWS documentation available for free? It can’t possibly be that hard to learn.

At it’s core, control disorder means you end up artificially constraining the most important resource your company will ever have: your time.  And if you’re a firm believer in throughput optimization, you’ll know that even if you’re the best at every single thing your company will ever do, context switching is a total killer for productivity and being involved in everything means your entire company’s growth will bottleneck on your personal availability.  This, then, is what I’m calling the first axiom of Founder Problem: a company will never grow above its founder’s ability to let go.

The first axiom of Founder Problem: a company will never grow above its founder’s ability to let go.

For Pathos Ethos, we ended up treating control disorder in two major ways: delegation and automation – the latter of which is simply delegation to robots.  But at least you get to control the rules for your robots, so I suppose that’s more palatable to the acute sufferers of this malady.

Yes, a robot butler.

There’s all kinds of resources out there that will help you be a more effective delegator, but we’ve found the RACI framework to be extremely helpful, especially when combined with a use-of-resources exercise that our friends over at Humble shared with us.  Be disciplined in sticking to your RACI assignment; question whether you’re crossing an appropriate boundary when you intervene; turn delegated failures into learning moments, not chastisements.

Secondly, we invested in a slew of online tools that automated a large portion of our back-office needs: Proposify for proposal writing, Freshbooks for invoicing, Toggle for budgeting time, Bench for bookkeeping, IFTTT for integrations, Unito for board syncing and the list goes on.  Take a moment to think through what you spend your time doing that isn’t something only you can do and see if there’s a tool (or human) out there that does it for you.

Now admittedly these control disorder symptoms don’t always mean that you’re a sufferer of this founder condition, (you could just be a “pursuer of excellence”) but let’s be honest, it never hurts to check yourself and observe if control disorder is limiting the growth of the company you founded.

Solution Syndrome

I’ll be the first to admit that this one hits me pretty badly, especially during those moments of life where I might be stubbornly preparing a ribeye dinner masterpiece (because, well, sou vide and a torch) while someone is trying to tell me our guests tonight are actually vegetarian.  Here are some ways I notice I’m languishing in solution syndrome:

  1. I passive-aggressively complicate everyone else’s ideas during brainstorming meetings.  Yeah, that salad would just take too long to prepare.  We wouldn’t hit market fast enough and well, radish is out of season, it would all be cost-prohibitive.  We’ve already prepped our wagyu.  Let’s just stick with that.
  2. I use my preferences to defend my solution.  I don’t think those colors, that logo, and I guess the whole design really work for me.  It just doesn’t represent me.  And if I don’t like it, other people won’t like it either.
  3. I start dismissing discovered data about my target audience.  I don’t care if Han and Leia had a problem at the event with him.  Palpatine’s my man.  If they can’t deal with him being at the Rebel rally, they can go somewhere else.
  4. I find myself believing in the software version of the Fields of Dreams.  If I build it, they will come.  If I build it bigger, more will come.  If I charge a small subscription, it will definitely be worth it to them.

Solution syndrome is one of my favorite issues to deal with in startup founders, not just because as a product guy, I struggle with it incessantly myself, but because it scratches a secret itch of mine to examine people’s most stalwart assumptions about their user base.  Don’t get me wrong, assumptions, like most parts of human intuition, are usually good things and help us save precious neural calories by skipping large investment into critical analysis, but they can also get us entrepreneurs into real trouble if we never realize we’re getting emotionally attached to our solutions – the biggest issue of which is an inflexibility that calcifies out of a commitment to a particular solution.

And herein lies the key point: even seasoned entrepreneurs forget that their first attempt at solving a real problem will always be (at least somewhat) wrong.  This, therefore, yields the second axiom of Founder Problem: a company will never grow beyond its founder’s willingness to validate their own assumptions.  Once you stop testing your assumptions, you introduce more risk and inevitably stall your company’s growth.

This, therefore, yields the second axiom of Founder Problem: a company will never grow beyond its founder’s willingness to validate their own assumptions.

To combat this tendency to blindly trust our gut, we direct all of our product clients to consistently practice what we lovingly call the Problem and Solution Kata.  Whenever faced with an opportunity to make a priority decision about product development, our kata directs us to pause and spend a best effort amount of time constructing a single concise sentence describing the problem you’re trying to solve with your feature/initiative/organization.

This forces entrepreneurs to take their intuited ideas and willingly place them on the altar of validation before they commit more resources to building it.  I mean, wouldn’t you rather know (or at least have an educated idea) if your $200,000 wagyu-grilling mobile app is going to solve a real problem before you actually go and build it?

Our $250,000 seed round is still open.

Never have I ever been more convinced that a single discipline could make or break a founder (and their startup) than the distillation of problem and solution, and at Pathos Ethos, we have adopted several sets of exercises that help our clients navigate this issue.  The two that we use most often are modified versions of the Fishbone Diagram and the Five Why’s, but just googling it will get you a ton of exercises that you can adapt to your own tastes.

As with control disorder, I’m sure there are founders out there who might actually just have perfect intuition, but alas, I know from experience I am not one of them, and to be blunt, you probably aren’t either.

Domain Myopia

I remember a few years back during a particularly tight financial time for Pathos Ethos, I was complaining to an employee about how I thought our developers were to blame for our poor cash flow.  I stubbornly pointed my finger at my beautiful spreadsheet saying, “I look at our metrics every sprint, and it’s right here. Our developer productivity needs to be better.” A very smart Ryan then looked me in the eye and said, “Nope. The problem isn’t with our developers.  It’s further upstream.”  And what he meant by that was that I was too quick to lay blame on the things I look at frequently without deeper and broader examination of our business.

Here are some other things I caught myself doing that confirmed my domain myopia:

  1. I repeatedly found myself attributing the most minor of issues to the same primary cause.  To a man with a hammer, everything looks like a nail.
  2. I discovered a pattern where the business functions I was personally executing were always faultless, while everything else constantly needed correcting.  That Salesforce integration I sold is keeping our pipeline healthy.  It’s not my fault we can’t produce code fast enough.
  3. I started dismissing context when it came to process improvement.  I don’t care where these leads come from, we need to figure out how to double the emails our sales team contacts this quarter.
  4. I never really knew how well the rest of my business was doing.  Really? You started a business?

At the time, I had no understanding of process flow, and so of course, when faced with a crisis, I was looking for cause and effect relationships within my own optical field, never realizing that things beyond my peripheral vision (both before and after the execution chain) were having huge effects on our overall business.  I was seeing problems in my developers, and it never occurred to me that the sources for those problems might not have originated there.

As advocates of flow efficiency optimization, I wish I could go back in time and tell myself that no matter how much I tried to improve my developers, it wouldn’t solve our problems.  I wish I could tell my younger self to look beyond the things that I considered to be within my professional domain, and that to unlock my company’s growth potential, I had to understand more than just what I was comfortable with.  In this, is our third axiom of Founder Problem: A company will never grow bigger than their founder’s capacity to understand their entire business flow.  Because by definition, unseen problems are the ones that live in places you never examine.

The third axiom of Founder Problem: A company will never grow bigger than their founder’s capacity to understand their entire business flow.

At Pathos Ethos, we train everyone we work with, both our team members and clients, to begin addressing domain myopia by adopting process visualization.  Our favorite tool for this is the value stream map because if done right, it will force you to consider the bounds of where your client flow begins and ends (tip: there’s usually a step before and after you haven’t thought of) but in general, any framework out there to get you to visualize your business process holistically will rescue you from over analyzing the pieces of your business that you’re most familiar with.

Admittedly, this is only the first step; visualization isn’t everything.  Thinking so will only lead you down the path to the dark side: to an overdependence on metrics.  Metrics in isolation of analysis can only tell you what’s happening not why (for that, you could use people like us to discover what’s wrong), and on the other side of the spectrum, too much focus on your visualization could give you a serious case of analysis paralysis.

Too much Data.

Additionally, if you have an expert or a partner that oversees some other parts of the business, don’t make the mistake I did by ignoring their domain altogether.  Even if you trust them (and you should, otherwise something is already wrong), not understanding their territory means a breakdown in communicating how your different pieces of the business affect one another, opening the door to both missed opportunities and mistakes in the future.

And if you happened to have grown your company beyond that point without at least being aware of every piece of your business, I’ll be frank: that’s probably just an accident.  And whether good or bad, accidents don’t last forever.

Founder Problem

You may have realized by now that all three of these axioms of Founder Problem orbit a common principle:  Founders are their own worst enemies.

Founder Problem: Founders are their own worst enemies

While I suppose I could have started out by describing this common principle, my suspicion is that a lot of founders who exhibit these symptoms would never have gotten as far down the post as this to even read this summation; I know I wouldn’t have.  People who can’t get over themselves don’t usually do so well when you level criticism to their faces (I am still super sensitive to criticism about everything).

And I certainly wouldn’t have had as much fun writing yet another article about startup success.

At Pathos Ethos, we’ve found the ability to overcome Founder Problem to be such an important attribute that it has become a critical component to how we qualify startups we enter into relationships with.  We’re not alone either.  Several of our accelerator friends judge startup applications by qualitatively testing for Founder Problem (they don’t call it this): Is this founder a teachable leader? Can they overcome their own assumptions about their product?  Do they have the capacity to see beyond what they are comfortable with?

All this to say, being a founder is not easy, and I can certainly relate to the voices in your head: “Why am I not doing better?  What can I do to help me take my organization to the next level?”  I definitely still ask these questions to myself and I guess also to really anyone who will listen to me whine.  But if you’re interested in figuring out how to overcome your own founder problems or just need a kick in the butt to get you motivated again, give us a call – it’s easy and it’s free.  At the very least, maybe you’ll get a chance to have a laugh at our office.