Lost and Founder: A Painfully Honest Field Guide to the Startup World

by Rand Fishkin

Managing Is a Skill, Not a Prize

The Peter Principle, a 1969 book by Laurence Peter and Raymond Hull, which popularized the quote at this chapter’s start. The theory behind it is that each employee is judged for their next promotion based on their performance at the current one, rather than their potential aptitude for the new work required in that higher-up role. Hence, people advance at an organization until they are no longer competent in their positions, and the company is left with more and more incompetence at senior levels. It’s inevitable that this ugly scenario will occur if employees stop being promoted only after they can no longer perform effectively.

Underlying this problem is a belief that anyone can be a people manager, and that unlike any other specialized role (e.g., accounting, marketing, engineering, design, or sales), all it takes is the will to manage and an understanding of the problem space. This is bullshit.

One of the hardest, most frustrating conversations I consistently have with team members is the one about what managers do versus what individual contributors (ICs) do. Many ICs believe that management is just telling people what to do and making sure they do it. They assume (falsely, in my experience) that only managers who’ve previously done the work themselves can be effective. They make an inherent assumption, often based on real, personal experiences (which are impossibly hard to argue against), that the best managers are the people who used to be the best ICs, thus proving their worthiness as leaders. A mediocre engineer will make for a poor engineering manager. A great customer service manager could never be an effective engineering manager. These myths are so easy to believe and so tied up in standard business protocols that unraveling them is like pulling teeth every time.

Thankfully, I’ve got the evidence, after a decade of growing teams and shrinking them, of observing great people doing awful work and seeing previously poor performers excel to say that the line between being great at the work yourself and being a great manager of the people doing that work is largely disconnected. I will absolutely concede that much of the time, great people managers were good at, or at least performed, the jobs of their reports at one time or another. But that, my friends, is correlation, not causation. Just because most managers apply for and are ...

Google started from a novel premise: assume managers don’t make teams better. They attempted to prove this hypothesis by identifying high- versus low-performing teams and looking for any correlation with the managing individual. Was it the case that “great” or “terrible” managers could be identified—folks who moved from team to team and consistently brought up (or down) the performance of their groups? Indeed it was. Unsurprisingly, Google found that managers did make a difference after all, and that teams with great managers were happier and more productive.

What might be surprising, though, is what Google found to be the eight behaviors consistent across strong people managers. Here they are, in order: Is a good coach Empowers team and does not micromanage Expresses interest/concern for team members’ success and well-being Is productive and results oriented Is a good communicator Helps with career development Has a clear vision/strategy for the team Has important technical skills that help him/her advise the team

On the great teams I’ve observed in which the manager did not possess technical skills, there was often a surprising benefit: the team members themselves upgraded one another’s skills, mentored one another, and more often, took greater responsibility for the output of the work. I suspect that’s because in teams with managers who possess their own strong technical skills, the work gets done their way, and the improvement in skills tends to be clustered around the managers’ specific strengths. It also strikes me that because of the reliance on these highly skilled managers, there’s less individual effort given by the team’s members to explore and expand on their own. This isn’t always the case—sometimes a great IC will make for a great people manager who encourages broader education from the team and who encourages dissent on how to do things rather than enforcing his own tried-and-true methods. But both my own lived experiences and the research suggest that people management and IC work are two fundamentally different things whose overlap is neither obvious nor consistent.

Don’t Make Management the Only Ladder Employees Can Climb

There is a deeply held misconception in business culture that people management is (a) the only way to lead and (b) the only way to advance one’s career. If we address both of those, dismantle them, and create clear, obvious paths to prove that this isn’t true in our organizations, we can build better teams composed of the right people properly suited to the work (management and IC). At Moz, we addressed this by creating a new, dual-tracked career pathing system.

a junior engineer starts out as a lower-level individual contributor, but as they gain skills and prove their effectiveness, they can move up the ladder of promotions, salaries, benefits, stock options, and influence *without* ever becoming a people manager. Those progressions enable these firms to retain high-quality talent, groom them to serve in consultative roles involving important technical projects and discussions, and benefit from their expertise without demanding that they get good at people-management skills, which may not interest them or fit with their talents.

We realized the following: We had to do more to recognize and reward ICs (or it would never be perceived as a viable, prestigious path). We had to formalize the influence of ICs (or else their contributions would be interpreted differently by different people and create hot spots in the organization where ICs were more versus less respected/influential/involved). We had to expand the IC path from purely engineering to every role and team.

Thus, we made this chart:

Moz’s dual-track career progression operates on a simple principle: individual contributors should be able to grow their skills, their influence, their titles, and their paychecks just like people managers.

Those pillars included: Prominent role models along that IC track had to be regularly called out by leadership during all-hands meetings, strategic presentations, external public communications (like blog posts), and in status report emails. Regular interfacing needed to happen between high-level ICs and the rest of the Moz staff, so every employee had facetime and access to them. Influence had to be granted to ICs to guide initiatives, to advise on process, to be included in key decision making, and to have final say over project areas.

You must choose how equal you really want the two paths to be, and where to assign accountability. Be wary—accountability without the means to control it is a recipe for frustration and disaster. Those who are held to account must also be given the freedom to own (as much as possible) the inputs that can affect their success. That’s harder with ICs than managers because ICs are usually not perceived as having final accountability, nor are they able to hire and fire, which many believe (falsely, in my opinion) to be where the power comes from in a project.

“Product Architect.” It’s a role Moz gave me a few months into my post-CEO tenure, and one I think can be very successful if done right. The idea is to have an individual who is responsible for a project’s or product’s success, has a team to work with, and is given the means to direct that work, meaning they determine what’s to be created, have final say over product design decisions, and work with a people manager to evaluate the work and contributions of the ICs building it.

Forcing management to be the only way up will cost you talent in places you need it, and worse, install the wrong people in those roles, harming everyone on the team.

Emotional comfort with one’s colleagues was a better predictor than IQ, than years of experience, than the strength of previous work, than literally any and everything else researchers had hypothesized about.

Project Aristotle, an internal Google research project, looked at thousands of teams at the company with years of empirical data on performance and concluded that empathy between team members and a group norm of emotional support was the best, most consistent predictor of a team’s success. A 2012 North Dakota State University study found that social sensitivity, “the ability to perceive, understand, and respect the feelings and viewpoints of others,” was strongly correlated with high-performing teams. A 2008 Carnegie Mellon University study uncovered much the same in their analysis of 699 individuals broken into small groups for five-hour-long projects. The New York Times wrote about its results: What interested the researchers most, however, was that teams that did well on one assignment usually did well on all the others. Conversely, teams that failed at one thing seemed to fail at everything. The researchers eventually concluded that what distinguished the “good” teams from the dysfunctional groups was how teammates treated one another. The right norms, in other words, could raise a group’s collective intelligence, whereas the wrong norms could hobble a team, even if, individually, all the members were exceptionally bright.

The common threads I’ve seen separating successful teams and projects from unsuccessful ones generally have the following elements: Clarity and shared understanding of goals (i.e., everyone gives the same answer to the question “Why are we building this and what do we hope to achieve with it?”). Unity around the specific work required and how each person will contribute to it (i.e., everyone can give an answer to the question “What am I supposed to be doing and how does that fit with what each other person on the team is doing?”). Confidence in the people around them to contribute equitably (i.e., everyone believes the statement “If I contribute my portion, everyone else will contribute theirs and we’ll be successful”). Belief that should things go wrong, they/we will have the ability to catch it, fix it, and survive it (i.e., everyone agrees with the statement “If this doesn’t work, it won’t mean the end for my project/team/company/career”). A powerful sense of camaraderie and kinship, such that everyone on the team/project cares about the people around them and takes joy in the shared experience of working together (i.e., everyone would say “I want good things for all of the people on my team, and I’d be happy to make sacrifices for them and believe they’d do the same for me”).

Nine times out of ten when I or another project/team leader has had to pull the “we’re doing this because I’m in charge” card, it’s a signal that the project (or the team) is doomed unless we can turn those prevailing attitudes around.

What’s interesting is the nuance of psychological safety—it’s not about being, as Edmondson put it, “unrelentingly positive,” but rather about feeling comfortable speaking up, contradicting, questioning, and expressing criticism or nervousness.

because many people and organizations reward outcomes rather than behavior. That can lead to punishing good behaviors if the outcome isn’t the desired one, even if the forces were outside our control. And it can lead to reinforcing bad behaviors simply because they led to a good outcome (again, even if the outcome was largely disconnected from the behavior).

What makes a behavior worthwhile is different for each person and each company, but almost all follow a few patterns: The behavior is, in and of itself, apart from any connected outcomes, rewarding and fulfilling. The behavior fits with your core values. The behavior can turn into a habit and (at least slowly) scales with decreasing friction (i.e., it’s easier to engage in the thirtieth time than the second). The behavior has a positive, measurable, causal impact. Even if it’s small.

There is no clear causality between the behavior and a consistently negative outcome.

When we make it about the work rather than the goal, we find that outcomes improve. The field of behavioral science has all sorts of data on what happens when rewards are connected to outcomes rather than behaviors (namely, people cheat, break rules, game systems, and ignore the safety of themselves and those around them).

In my estimation, there were five key principles driving the growth-rate deceleration. If I had understood each of them in 2012, I believe I’d have been a much better CEO, board member, and contributor.

#1: Subscriber Retention versus Customer Acquisition

In 2011, the average Moz Pro customer subscribed to our product for 8.5 months. In 2016, the average Moz Pro customer subscribed for 11 months.

In 2011, we signed up approximately 1,000 new free trials each month. In 2016, we signed up about 4,500 new free trials each month.

I’d argue we invested foolishly in marketing and reach when we should have been investing in product and retention. Why? Because of how subscription-based businesses work. You’re basically filling a leaky bucket, and eventually, if you grow enough, you’ll churn through your entire pot...

We knew that millions of organizations and marketers were interested in using SEO software, but we’d never done enough to make our product into a long-term habit and an essential part of those organizations’ operations. Compare, for example, Moz’s average eleven-month subscription tenure with a company with Salesforce, perhaps the best-known and most-respected company in the...

This means that Salesforce has to acquire only 10 percent of its current customer base each year to maintain the same revenue. Any additional new customers, or any up-sell on current customers, means growth. At Moz, we need to add thousands of new customers each month just to keep up our existing revenue. Here’s where focus comes into play. Because we’re so dependent on new customer acquisition in order to stave off shrinking revenue, we have to substantially split the company’s priorities between product development that can attract new customers versus investments that improve retention of existing customers. Now multiply that by four different products and you can see how the organization struggled just to keep its head above water. Customer retention versus customer acquisition is a long-running debate in ...

Ironically, that path was something we finally discovered in 2016. We tested a customer success program, whereby trained Moz staff members held phone calls with subscribers in their first month of use, walked them through the features of the product, proactively answered questions, and helped people learn how to solve their problems and goals using the tools. The effect was dramatic. Subscribers who talked to a customer success representative for thirty to forty-five minutes stayed with the product for 30 percent longer than those who...

Customer success surely isn’t the only way we can improve retention, but with the business so dependent on new customer acquisition, and the leadership team spread so thin worrying about multiple products, we were a combination of unwilling and una...

#2: Multiple Products Dilute...

It’s not just the potential for negative experiences that carry over from product to product, though. The mere existence of multiple products from a brand causes cognitive strain and a weakening of memory and relevant associations.

Plenty of companies buck this model with multiple products, but the successful ones do so only when their initial products have enough momentum, viability, and traction to stand alone.

At Moz, we tried to expand into multiple products, selling to audiences outside our core, long before we had the momentum, viability, or traction on our initial product, Moz Pro. Our churn rates were the clearest indication of a still-immature product, but we foolishly took our focus and investments off that product to buy, build, launch, and support others, hoping the brand association and reach would enable faster growth with new products.

#3: The Inherent Complexity of Numerous Priorities

David Strayer, professor at the University of Utah and coauthor of “Who Multi-Tasks and Why?,” puts it nicely: The people who multitask the most tend to be impulsive, sensation-seeking, overconfident of their multitasking abilities, and they tend to be less capable of multitasking. I’d apply that same statement to organizations, especially in the startup stage.

The great strength startups usually have is that they can uniquely focus all their energy on just one thing, whereas their incumbent competitors have diverse efforts and responsibilities that impede progress.

Losing focus and asking your small team(s) to take on more tasks rather than do one thing better costs you this critical advantage. Doing just one thing means you can: try more experiments in pursuit of success, meaning you learn and iterate faster; keep communications overhead lean by hiring fewer people and keeping the task list short; get your most senior leaders personally involved in projects, reducing power distance and minimizing the time required to make crucial decisions; recruit, train, and hone the skills of the best people for the tasks needed; identify and reduce waste (of time, materials, people, or investments) fast, because it’s easier to see said waste when you have less to concentrate on; and budget time, expenses, and people more accurately with less variation.

Each new product and priority cost vastly more resources and created more time dilution than the previous one. When we removed these products and priorities, and simplified, the results spoke for themselves. Fewer people, more focused on just a few things, could do more than a much larger team pulled in myriad directions.

Silicon Valley startup culture embeds founders with the false belief that because growth is what matters most, we should pursue any and all strategies that could lead us there. Far wiser, and much more difficult because of the discipline and patience required, is ignoring those potential off-course avenues in favor of applying the experimentation, learning, and iteration process to the one thing in which you can be best at in the world, and letting those other strategies for growth wait until you’ve got truly massive scale.

Are you looking for complete control, profitability, and 100 percent ownership with slower growth? Bootstrapping on nights and weekends while you’re at a day job (or consulting, or living with a very supportive partner) may be the right match.

What Won’t Change in Our Field over the Next Ten Years—I’m stealing this directly from Amazon’s Jeff Bezos, who applied it thusly: In our retail business, we know that customers want low prices, and I know that’s going to be true ten years from now. They want fast delivery; they want vast selection. It’s impossible to imagine a future ten years from now where a customer comes up and says, “Jeff, I love Amazon; I just wish the prices were a little higher,” [or] “I love Amazon; I just wish you’d deliver a little more slowly.” Impossible. And so the effort we put into those things, spinning those things up, we know the energy we put into it today will still be paying off dividends for our customers ten years from now. When you have something that you know is true, even over the long term, you can afford to put a lot of energy into it.