How Startups can work with Big Companies and not get Killed

(Note: this post was originally published on the Wonolo blog under the title “Collaborate. Innovate. Top Tips for How Large Enterprises and Startups Can Have a Winning Partnership”)

Recently, I was invited by Unum, one of our FORTUNE 500 customers, to participate in a panel session about corporate innovation at Maine Startup and Create Week. At the heart of our discussion was how large companies like Unum can be more innovative and how startups and large companies can work together toward this goal.

It’s a topic that’s close to my heart: I spent the first part of my career in the wireless industry, and back in 1998, I was a part of the founding team of Symbian, one of the first operating system platforms for smartphones (although they weren’t yet called “smartphones” at that point).

Symbian was a joint-venture between Nokia, Ericsson, Motorola, Psion, Panasonic and, later, several others. Their rationale for investing in Symbian was a desire to have a common software platform for smartphones. However, what these companies actually had in common was that they were large, bureaucratic, and they were arch-competitors.

Getting these large companies in the Symbian joint-venture to work together was somewhere between very hard and impossible. (For the full story, see David Wood’s excellent book.) The term of art at the time was term “coopetition,” and it didn’t work. None of the participants in Symbian really had any desire to share their product plans with their competitors.

So, the irony was that, while Symbian was arguably at the spearhead of technology innovation, it was frequently stymied from actually being innovative by the inertia and culture of its participants. This left the market open to more focused, agile and independent companies like Google and Apple to dominate the smartphone market of today. In contrast, Nokia had an ignominious end – broken up and sold off, with billions of dollars in market value destroyed.

So, fast-forward to 2016 and my panel discussion at Maine Startup and Create Week…How can big companies be more innovative, and how can startups and large companies work together to the benefit of both?

Designer, Builder or Maintainer?

First, let’s take a look at the kinds of people that tend to work at startups versus larger companies: I have a simplistic but hopefully powerful model that divides people into three groups – “designers,” “builders” and “maintainers.”

Let’s use an analogy: here in San Francisco, arguably our best-known symbol is the Golden Gate Bridge – just look at any tourist tchotchke.

If we think about the Golden Gate Bridge, first there were the designers. In our culture, the designers generally have the “sexy” job – they are the visionaries.

GG_Bridge_Plans.png

Next come the “builders” who actually constructed the Golden Gate Bridge.

GG_Bridge_Maintainers.png

Last come the “maintainers.”  These are the workers who hang on ropes off the bridge, scraping off rust and continuously repainting it in International Orange.

International_Orange.png

This is the least sexy job in most people’s eyes: which would you rather be – the visionary designer of the Golden Gate Bridge or someone who hangs off it on a rope, scraping rust?

Now, in a startup, what you need for success are just a few designers – these are typically the founders.  You can’t have too many because they tend to butt heads.

What you really need for a startup is a boat-load of builders: these are the doers – people that create and Get Shit Done (GSD). Builders are the backbone of any startup.

What you don’t need in a startup is maintainers: everything in a startup is being created anew so there isn’t anything to maintain. You’re also focused on growth rather than optimization.

Contrast that to a big, established company: there, most people are maintainers. Their job is to ensure that an already successful business continues to be more successful. They are there to grease the wheels and optimize.

So What?

What this means is that there is a cultural mismatch between a large company and a startup.

At the core of the startup mindset is a willingness to fail and an acceptance of it. In a startup, failure is the norm – as the cliché goes, you fail your way to success. Since “failure” has negative connotations, I think it better to simply reframe it as “learning.”

Another important aspect of building a startup is understanding the art of the “good enough.” Because you’re bandwidth-constrained, you are forced to be very selective and very efficient in how you do things. You have to get them done quickly. You have to not let the great be the enemy of the good. You have to focus on delivering 80% of perfection for 20% of the effort.

Naively, when large companies aspire to become more innovative, they trot out clichés like “we reward risk-takers.” This is a lie. The last thing you want when you have a large company generating billions in revenue it to have some cowboy risk-taker come in and break it. What you want are maintainers to keep it working and keep it generating billions of dollars.

To take it back to the Golden Gate Bridge example, would you want a maintenance worker who said, “Let’s see what happens if we take all the bolts out”?

I think it would be better to rephrase it as, “We reward people who make small, smart bets.” Making a series of small, smart bets to test various hypotheses is the basis of iteration, and iteration is the how you build great products and great companies.

Recognizing these problems, many large companies have started to take a different approach – they have created specific initiatives intended to foster and drive innovation. Wonolo itself was created through The Coca-Cola Company’s innovation program.

Creating a Great Corporate Innovation Program

So, how can a large company create an innovation group and/or program likely to succeed? These initiatives can take various forms, but I think these are the most important elements:

  1. Set money aside – the budget for innovation can’t come out of the normal, operating budget for any existing business unit. If it does, it competes with the budget needed for maintenance of what’s already working.
  2. The innovation group must report directly into the CEO – this demonstrates genuine commitment to innovation and also helps unblock bureaucracy.
  3. Be clear with objectives – what specifically are you hoping that the innovation program does for your business? What are you looking to achieve? How does it positively impact your core business?
  4. Build the right team – a good mix is designers and builders from outside of the organization, along with some inside players who can help navigate the existing organization, as long as they carry enough weight. You will also need to reassure your best maintainers that they should stick to what they do well rather than trying to join the innovation program because it’s sexy.
  5. Accept failure – as discussed above, you must accept that failure is a vital part of the process. Not all initiatives you start or companies you fund will be successful, but you will learn something important from each.

How Can a Startup Engage with a Big Company and Win?

Big companies can kill startups. I’ve seen it happen.

Big companies can lead startups on and consume lots of their time and bandwidth with no pay-day. At the end of the process, the large company has perhaps lost a few hundred thousand dollars. Meanwhile, the startup has run out of funding and is dead.

Here’s what I’ve learned (the hard way) to avoid that outcome:

  1. Find your champion. Ted Reed is our champion at Unum. Not only is he an all-round great guy, but he also understands the need to be completely transparent with us. A great champion is your guide to the large company – its structure, how it makes decisions and the key players you’ll need to win over.
  2. Seek trust, honesty and transparency – any great relationship is built on mutual trust. Get feedback early and often (from your champion) on your likelihood to succeed.
  3. Don’t over-invest until you have clear commitment – be prepared to scale back or end the relationship if it’s not clear you are on a path to success. The opportunity cost of your time in a startup is huge. Don’t do anything for free – free means there’s no value, and it won’t be taken seriously.
  4. Ensure clarity in objectives, value and define success – if both sides are not clear on the business value that your product or service is providing to the large customer, be very cautious. Make sure both sides agree on what success means.
  5. Start with a small, well-defined trial – rather than trying to boil the ocean, it’s wise to start with a trial that demonstrates the value your product or service provides to the large company. This has less risk, requires less investment and has a higher likelihood of success. For more tips on how to best go about setting up a pilot, check out our related blog post.

How Can a Big Company Engage with a Startup and Win?

On the other side, how can big companies successfully engage with startups and win? Here’s my personal recipe:

  1. Be honest and transparent – don’t lead startups on. Be honest about chances of success and what it will take.
  2. Be respectful of bandwidth and provide funding, if possible – realize that a startup’s most precious commodities are bandwidth and funding. Do everything you can to reduce the sales cycle. Structure the deal to provide the funding and/or revenue necessary for the startup to succeed.
  3. Have realistic expectations in terms of maturity of a startup and its processes -don’t try to apply your pre-existing vendor onboarding process when engaging with a startup. For example, a 10-person startup won’t pass your 50-page IT security audit.
  4. Respect the need for independence – you may be providing a startup with revenue, funding and a great customer reference. However, a startup needs to be in control of its own destiny and own its own product roadmap. Don’t treat a startup like a consulting company or development shop, unless that’s how the startup sees themselves.

Overall, the relationship between a large company and a startup can be a marriage made in heaven. I would marry Ted Reed if I could.

Meaningful Metrics: 6 Steps to Metrics Heaven

Surely, one of the benefits of technology-based businesses is that it’s much easier to make data-based decisions – to “drive by the numbers”.

Superficially, this seems like it should be easy – just look at the data and decide what to do, right?  However, in every company I’ve seen, it’s always been painful.

Hopefully, this will help you avoid some of that pain.

Six Steps to Metrics Heaven

Six Steps to Metrics Heaven

I believe there are 6 steps to “metrics heaven”:

  1. Define
  2. Measure
  3. Present
  4. Discuss
  5. Action
  6. Iterate

Sorry, there are no short cuts; you have to get all 6 right to be successful.

Step 1 – Define

Ask the Right Questions

Your path to Metrics Heaven starts simply by asking the right questions.

Firstly, try to state the question behind each metric as unambiguously as possible.  Secondly, explain in plain English what this question means and why it’s important to your business – the context.

Example:
Question:  “Of the users that have signed up in the past 12 months, what percentage have logged in in the past 1 month?”

Context:  “This metric measures our ability to keep users coming back to our site.  This is vital to our core business model as we pay $40 on average to acquire each new user and can only make a profit on them if they keep coming back.”

Clear definition of the question is particularly important because the person responsible for actually answering the question – writing the database query, wrangling Google Analytics, etc –  is often not the person framing the question.  So, any ambiguity has the potential to result in an answer that is misleading or just plain wrong.

Fight Data Overload

If you try to measure, track, discuss and action too many metrics, you’ll lose track of what’s important.  You’ll lose sight of the forest for the trees.

Data overload is an insidious problem.  The addition of each new metric seems innocuous so it’s hard to say no.  Plus, there’s a tendency for people to want to get their group’s name “up in lights”.  But it’s vital that you do say no.  Otherwise, here’s what I’ve seen happen every time:

  • pulling and calculating all the metrics becomes a chore and takes forever
  • you end up with a big and unwieldy dashboard
  • the dashboard takes more than 30 minutes just to run through with everyone during the metrics meeting
  • people fall asleep or get distracted by their laptops/iPads/iPhones
  • you run out of time to discuss actions
  • people start to view the metrics meeting as a pain and find excuses to avoid it

Top 10 Metrics

To avoid overload, you need to identify a maximum of 10 metrics.  This “Top 10” constitutes your top-level dashboard.

By “top-level dashboard”, I mean the dashboard that is shared with the whole company, which the executive team uses to drive the business and the first – and maybe only – set of metrics you review when you meet.

Each group or department may have its own dashboard too.  There may be multiple levels of dashboards that dive deeper and deeper into the internals but don’t let those pollute your Top 10.

Your Top 10 metrics dashboard will probably be something you’ll want to work to automate so that it’s available live, displayed on a big flat-screen in your office, etc (more on that later).

To help ensure that you don’t grow beyond 10 metrics, use his rule:  if someone wants to add a metric to the top-level dashboard, they have to choose one to remove also and justify why the one they want to add is more important than the one they want to remove.

Now, let’s look at how to identify which metrics should be in your Top 10…

MAIN Metrics

I have come up with a handy-dandy acronym to help identify the metrics that you should choose, particularly your Top 10 metrics; “MAIN”:

  • Meaningful
  • Actionable
  • Isolatable
  • Not misleading

Let’s look at these 4 in more detail…

Meaningful

Is the metric a true and valid indicator of success in your core business?

A good way to ask this is to pose the following question:

“if this metric changes in the right direction, and nothing else changes, will my business be doing better?”

If the answer to this question is no, then you may have identified a useful metric to measure and try to impact, but it’s unlikely that you’ve identified a Top 10 metric.

Actionable

There’s not really much use measuring something if you can’t do anything about it.  You must be able to “move the needle”.

Metrics where you can’t move the needle are potentially interesting in terms of giving you a better understanding of what drives your business but almost certainly are not Top 10 metrics.

Isolatable

It’s vital that you choose and define metrics in such a way that they do not vary based on other, independent variables, whether those variables are in your control or not.

You need to be confident in measuring the effect of the actions you take to move the needle.  You need to avoid the age-old problem of confusing correlation with causation.

A classic example in web businesses is not insulating your metrics from the impact of fluctuations in traffic caused by other factors.  For example, you may have been measuring the number of user adds on a weekly basis and be working aggressively to drive up that number by reducing friction in your sign-up funnel.  The week after you launch a slew of sign-up funnel optimizations, you get 25% more users.  Yay for you – it worked – gold star.

Not so fast.  It turns out that what actually happened was that an article in a local style magazine that your PR agency setup some weeks back was finally published which drove 25% more traffic to your homepage.  Your conversion rate actually stayed the same.

To isolate a metric as far as possible, first frame the question in such a way that it’s not impacted by other variables.  The easiest approach to this is to always define metrics in terms of rates, not in terms of absolute numbers – e.g. “what % of users that started down the signup funnel completed it last week?” Not, “how many users signed up last week?”

Lastly, always be suspicious if it seems too good to be true.  Dig deeper to check whether your action really was the cause of the change.

Not Misleading

Lastly, even if a metric is isolatable, it may also be misleading in other ways.  It may give a false negative or false positive, or otherwise cause you to react in the wrong way.

It’s important to define metrics in such a way that they are hard to misinterpret.  Even if that’s not completely possible, it’s important to highlight the ways the metric could be misinterpreted when it is discussed.

Another classic example from the web is measuring the cost effectiveness of various CPC (cost-per-click) advertising campaigns.  You may find that certain keywords or certain channels allow you to buy traffic at a lower cost.  So, you decide to spend more money on those channels and reduce your spend on other channels.  However, not all traffic is created equally.  You may find that the users/customers brought in by the cheaper CPC rates actually generate proportionally less revenue for you so it’s worth paying more for higher quality traffic.

The danger of misleading metrics is one of the main reasons why stating the context of each metric (as discussed above) is so critical.

Step 2 – Measure

So, you’ve defined your Top-10 MAIN metrics in a precise and unambiguous way.  Now you just need to measure them.

Easy, right?

Um.  Mostly not.  Measuring is usually hard for a variety of reasons:

  • the relevant data is spread across multiple systems (your database, Google Analytics, MixPanel, AddThis, etc)
  • data is buried in the depths of your system and extracting it requires in-depth knowledge of your systems (and probably wicked SQL skills too)
  • the people with the know-how to extract the data are probably engineers who are busy with other things and consider extracting metrics beneath them
  • metrics were not really considered when the original system was built so the “instrumentation” has to be added retrospectively; this work contending with other product feature work
  • lots of manual steps are required, making it a chore

Tools

The good news is that there is a growing range of tools available to help.  The bad news is that any tool, if badly used, can be worse than no tool at all.

Let’s look at a few…

Google Analytics (aka “GA”)

I hate Google Analytics.  However, I can’t argue with the price.  And it’s incredibly powerful…if you can work out how to use it.  It’s unfortunately incredibly unintuitive.  It’s a camel (horse designed by committee).

The good news is that it’s fairly ubiquitous so you probably already have people on your team who have experience with it.

Mixpanel

I like Mixpanel.  I have no relationship with them other than as a happy customer.  Mixpanel does the 10% subset of Google Analytics that you actually need and does it well – the charts make sense, things are consistently referred to by terms that make sense.  It’s not free but it’s not expensive compared to the value it provides, in my opinion.

KissMetrics

Personally, I had a bad experience with KissMetrics but that’s just one data point.  They are probably Mixpanel’s main competitor.

SQL Queries

The data in your app is probably in a relational database.  That means you need at least one SQL ninja to write queries on that database.  SQL is a technology that is older than I am and therefore is definitely not cool but it does what it does better than anything else, if you know how to use it.

Unfortunately, modern web frameworks mostly insulate developers from having to use SQL directly.  Whilst this may be a good thing from the perspective of developer productivity and “separation of concerns”, it means that the number of engineers that can write complex SQL queries is reducing.

Microsoft Excel

There ain’t no shame in Excel, in my opinion.  Likewise, Google Sheets, although the graphs are much better in Excel.  Both have plugins to pull in data from various sources, including Google Analytics.

Hire Someone

You might want to consider hiring a “data analyst” – i.e. someone who runs the metrics process as their main job, rather than it being done badly as a part-time job by others.  I use parentheses around the job title because I’ve found that people who self-identify as Data Analysts have a tendency to be quite academic and unable to roll their sleeves up and actually grapple with Google Analytics to extract the numbers.

I would suggest you’re better off starting with a technically-minded digital marketing person.  They’re like unicorn poop in the current job market so good luck.

Step 3 – Present

Once you’ve got the actual data, you now have to present it in a clear way that can be digested by others.

Build a Dashboard

The first step in presenting metrics is to build a dashboard that quickly and clearly communicates your “Top 10” metrics.  Don’t worry about finessing the dashboard for metrics outside your Top 10;  it’s better to get the Top 10 dashboard as good as possible before you spend time elsewhere.

Excel is the most common tool used for this purpose and, to repeat myself, I believe there is no shame in Excel.  However, as discussed above, there are an increasing range of more automated options.

Use Charts

Some people are able to “see the matrix” – they can see patterns and trends in raw numbers.  But, most people can’t, including a lot of very technical people.

So, show charts in your dashboard, not numbers – they really help highlight trends over time, progress versus budget and other patterns.

“One Number” Nirvana

I already talked about limiting yourself to a maximum of 10 top-level metrics.  I’m going to go a stage further and say that every business has just ONE number that represents how successfully the business is performing.  This may seem impossible at the outset but but I bet you it’s not.

So, set yourself the stretch goal of identifying that One Number.  You’re unlikely to get to it immediately so start with your Top 10 and see if you can iterate towards your One Number.  It may be one of your Top 10 or it may be a calculation based on a number of metrics.

Simplistically, you might say that revenue or profit is the One Number for any business but absolute revenue or profit is driven as much by scale as anything else.  Before you can scale to maximize revenue or profit, you need to have a business model and product that is worth scaling and you’ll also likely need to persuade investors to give you the cash required to scale.  That’s where your One Number comes in.  So, your One Number is likely to be something like customer acquisition cost (CAC/CPGA) or profit per user add.

Build a Live Dashboard

Data junkies will argue that the ultimate nirvana is to have a live dashboard that shows your One Number and Top-10 metrics, with graphs, on a web page that anyone in the company can view at any time to see a real-time view of how the product and business is performing.

But, however easy it is to get view the metrics, that does not remove the need to meet to discuss them and to action them.  So, let’s talk about that.

Step 4 – Discuss

Having your metrics beautifully presented is no use if you don’t actually talk about them as a team.

Meeting to discuss the metrics regularly keeps them in the front of everyone’s minds, makes sure that everyone understands what actually drives your business and, most importantly, is the venue to come up with your action plan for pushing them in the right direction.

Meet Weekly

The only cadence that I have seen work when it comes to reviewing the metrics in an online business is weekly.  A month is an aeon in Internet time.  Daily is good for quota driven sales team but too much for a startup team that is trying to build and rapidly iterate a product.

So, set a fixed time to meet every week.

The most important people to have at the meeting to review metrics is the people in the company that can actually impact those metrics.  Others can attend but you don’t want too many cooks.

Manage the Time

It’s very easy for the weekly metrics meeting to turn into a mechanical run through of all the metrics.  This is especially true if you’ve let your dashboard grow beyond 10 metrics or if you spend time diving into lots of very detailed metrics below your Top 10.

Most important is that you spend at least as much time on actions as you do on reviewing the numbers.  People who attend the weekly metrics meeting should be expected to have reviewed the metrics ahead of the meeting and come to the meeting armed with questions and suggestions for actions.

Step 5 – Action

Having perfectly accurate and beautifully-presented metrics that you discuss weekly as a team is useless if you don’t actually do anything about them.

What’s surprising is how often this happens.  People come to the weekly data meeting, review the metrics, ask questions and then go back to their jobs.

If this is what’s happening, you’re wasting time preparing the metrics and might as well get a job rearranging deckchairs on a sinking cruise ship.

Set Targets

It’s way easier to move a metric in the right direction if you specify a target of where you’re trying to get to.

Frankly, any target is better than none but it’s of course better to have a target that is achievable.  It’s better to start with a small, achievable increment and then move the target as you get better and more sophisticated in impacting your metrics through action.

To learn more about this, read a good dieting book.  Trying to either “stop being fat” or “lose 40lbs” is much, much harder and more demotivating than setting an achievable target for each week.

Actions for every metric

Every metric in your Top 10 should have a corresponding list of actions aimed at moving the needle in the right direction, along with an owner for each metric.  These can be marketing efforts, new features, A-B tests, whatever.

If you repeatedly don’t come up with actions for a Top 10 metric, ask why.  It probably means you should remove that metric from your Top 10 and replace it with something you feel is more important and which you can actually impact.

Likewise, if agreed actions don’t get performed by their owners, you can keep people honest by asking whether people still think the metric is important in terms of making the business successful.  If it is, then ask what other tasks they are doing that are more important.  If it’s not, remove the metric.

Step 6 – Iterate

I would say that the chance that you’ll choose the right set of metrics, be able to extract all the data you need, present them clearly and  build an action plan to move the needle first time around is approaching zero.

Expect it to be painful initially.  Expect it to take time.  Expect that you’ll need to iterate.

Summary

If there are just 4 things I suggest you take away from this, they would be:

  • Ask the right questions
  • Fight data overload
  • Focus on action
  • Iterate and expect it to take time to get right

Agree/disagree?  Please leave a comment (link is top-right of the page).

Focus – what it really means and why it’s important

When I started my first company in the late 1990s, many people advised me on the importance of focus.

“Focus”, I’d repeat and nod sagely, not really knowing what they meant.

“Focus” seemed like an inherently Good Thing™ on the face of it – like happiness and democracy – but a pretty vague concept.

Since then, personal experience has shown me the critical importance of understanding what focus means when building a company.

Focus is absolutely essential when building a startup but it’s also important for companies at any stage so I hope this is useful and relevant to all.

Focus – a definition

So, how do we define “focus” in the context of building a company? I would define it like this:

Focus is maximizing the time spent on the essential complexity of the problem your company is trying to solve and minimizing the time spent on incidental complexity.

Every company and every product is trying to create some value for its customers and users. Without that, the company and product by definition has no value. Typically, creating that value can be thought of in terms of solving some problem for your customer.

The more time you can spend on understanding the value you are creating for your customer –  i.e. understanding the problem you are solving for them and solving it – the more you are increasing the value of your company.

Working out what the value is you are creating –  the problem you are solving for your customer and how to solve it in the best possible way – is the essential complexity of your company.

In contrast, time spent on incidental complexity does not increase the value of your company and product.  It simply takes away time and energy from working on the essential complexity.

In summary, you don’t build value by solving problems that others have already solved – you create value by solving problems not yet solved and, to a lesser extent, by solving problems in significantly better ways.

Incidental Complexities

So, what are incidental complexities?

Here are some examples of the most common ones I’ve seen (in no particular order).  I bet many readers will have seen all or most of these:

  • infighting between colleagues
  • “busy work” that could be automated easily
  • reinventing the wheel
  • failure to make decisions / trying to keep too many options open
  • early stages of recruitment – finding candidates, reviewing resumes
  • meetings with ill-defined agendas
  • waiting because of colleagues’ poor time-management
  • attending conferences without pre-scheduled meetings and clear objectives
  • over-analysis of vendor/technology selection
  • doing your own IT support
  • obsessing over your competition
  • pitching investors
  • trying to make money from things that are not part of the problem you’re solving for your Customer
  • frequently switching between multiple tasks
  • rewriting things that are good enough (see my post on Why You Should (Almost) Never Rewrite here)

Let’s look at some of these examples in more detail and try to  identify some general sources of incidental complexity.

Decisions

“We would rather suffer the visible costs of a few bad decisions than incur the many invisible costs that come from decisions made too slowly – or not at all – because of a stifling bureaucracy.” – Warren Buffett

“Commit to making decisions. Don’t wait for the perfect solution. Decide and move forward.” – 37signals

“A good decision is a made decision.” – Clayton Christensen

Many people have written about the art and importance of decision making.  I will not attempt to cover this topic in depth.

My view is simply that you don’t learn anything from a decision you don’t make.  Whereas, you learn from all decisions, especially bad ones.  Fail fast, move on.

Startups, in particular, are all about making high-risk, low-data decisions.  If you don’t have the stomach for those, you shouldn’t be running a startup.  Deferring hard decisions just creates ambiguity and saps time, morale and energy.

Choice is Bad

When it comes to moving quickly and focusing as much time and energy as possible on the essential complexity of your business, choices are a Bad Thing™.

This seems counterintuitive to many people, especially in the West where our culture is built on the importance of individualism and choice, and denial of such freedom is tantamount to treason. However, choice in areas outside of your essential complexity just slows you down.

In software development, one of the reasons that Ruby-on-Rails is so popular, and one of the reasons why we currently use it, is that it is built on the principle of “Convention over Configuration“.  This principle is about reducing the number of decisions a developer has to make – gaining simplicity without necessarily losing flexibility.

Think about every aspect of your business in these same terms.  Everyone likes to think that their business is special and unique but the reality is that, outside of the essential complexity of your business, the other challenges you face are common to 90-100% of businesses of a similar size and stage of growth. They are solved problems and therefore textbook incidental complexity.

Analyzing choices that don’t really have impact on the value you’re building isn’t time well spent.  In a typical Silicon Valley startup, these are decisions like which accounting system to use, which CRM system to use, which web development framework to use.

Of course, I’m not advocating making completely blind choices with no thought whatsoever. However, what I’ve seen is that people often err on the side of overanalysis. The return on this time diminishes very rapidly.

If it’s not core to your competitiveness or differentiation, why spend another hour or day or week analyzing to make a 5% better decision?

Outsource Everything You Can – Use Specialists and Don’t Reinvent the Wheel

Money spent taking away incidental complexity is money, time and energy saved to focus on essential complexity.

A classic case in point is recruitment – people hate recruiters.  With a few notable exceptions, I hate them too.  But, they are a necessary evil.  At the time of writing, hiring in Silicon Valley is as hard as it ever has been in my memory.

To be clear; recruitment is one of the most important things that you can do as a founder, manager or executive – controlling the quality of the people that you let in is one of the best controls you have over the quality of your company and its output.  Therefore, I would never advocate for outsourcing the process of choosing the best people.

But, that doesn’t mean you have to burn lots of hours of your own time on the front-end of the recruitment process – finding people, contacting them, reviewing resumes, screening candidates, etc is not a good use of your time – outsource it.  That’s what recruiters do. Their fees may seem outrageous but they’re not when you consider the real cost of the time you’d spend doing it yourself – not only the direct cost of your time, but the much bigger opportunity cost of not spending that time addressing your essential complexity.

Another big mistake I’ve seen is startups taking non-core parts of their customers’ business process and incorporating them into their own product – invoicing, online payments, backup, logging and monitoring, reporting, hosting, etc, etc, etc.  These aspects are peripheral to your essential complexity so they should be peripheral to your product.  They are solved problems.

Usually, what superficially seems like a simple problem to solve inevitably turns out to be more complex.  By implementing the functionality in your own product, not only have you lost that time you could be spending on essential complexity but you’ve also taken on the burden of supporting and maintaining a feature that doesn’t return anything for you in value and differentiation.  You’ve basically re-invented the wheel.

Don’t forget that the vendors of these systems understand their overall domain pretty well (it’s their essential complexity) and they are building products that cover 70%-100% of the most common requirements.  At the same time, you likely understand your own problem domain better than almost anyone so, if you happen to have unusual or unique requirements on invoicing, data backup, etc, you’ll know about it. If there is some aspect of these systems that you are differentiating on, that validly falls into your essential complexity.

These days, with SaaS companies proliferating and APIs available for more and more business systems and processes, it’s very simple to incorporate all of these important but non-core aspects into your overall offering with minimal effort.

Today, most companies wouldn’t imagine building their own data centers – most companies just use the Cloud (Amazon EC2 or similar).

Take that to it’s natural conclusion – what other aspects of your business can you out-source?

Beware False Economies

In a startup, money is always tight, and managing your cashflow is critical to success.  However, it’s easy to let this drive you into false economies.

In every business there is “busy work” that is no fun but just has to get done.  In startups, this is a bigger problem because people have to wear many hats so this busy work has to be done by someone who has many other things to do.  Some of those things are likely to be part of your essential complexity.

Every case is unique but always think through the true cost of having internal resources spend their time on busy work that could be easily automated and/or outsourced.  Again, there is a direct cost but a bigger opportunity cost.

Don’t Sweat the “Competition”

Another mistake I have seen is for early stage startups to waste time and energy worrying about their “competition”.

The reality is that, early on, most startups are in an ill-defined space and still in the Customer Discovery phase.  This means your “competition” is hard or impossible to define.  Your true competition will emerge over time, once you’re out of Customer Discovery and better understand your positioning.

In the meantime, just focus on creating value.  You’ll likely beat your “competition” simply by focusing more of your energy on the essential complexity of the problem you’re solving than others.  The faster you understand and solve the problem for your customer, the faster you create value.

Death by Meeting

So many people have written about meetings, that I will only give it a cursory discussion.

In my view, meetings are another necessary evil but are overused.  Here are my guidelines:

  • meetings should be schedule to 30 minutes by default, not 1 hour
  • only invite those people who need to be there.  The productivity of a meeting decreases with the square of the number of people in the meeting.  Those people that need to be in the loop can be updated by one of the people in the meeting afterwards.
  • every meeting has a clear objective – not a detailed agenda, necessarily – a clear objective of what is expected to have got done by the end of the meeting
  • every meeting starts on time

Beware the Cost of Context Switches

Another hidden cost of having insufficient focus, is the cost of continually having to switch between tasks.  This switching cost is often underestimated or ignored.

Paul Graham wrote a great post on the big impact of context switching to “makers” (software engineers, etc) versus managers, who are generally more used to scheduling their time in blocks.

Actually, the cost of context switch is there for  everyone, even the most adept executive with the most fastidiously managed calendar. Research shows that human brains are very poor at multi-tasking and, ironically, those that think they are best at multitasking are actually the worst.

Don’t Underestimate the Importance of Motivation and Energy

If you’re only looking at the time spent, you’re only seeing part of the picture.  You need to understand the importance of motivation, energy and morale on your own output and the output of the company as a whole.

Incidental Complexity not only takes time away from Essential Complexity but it also demotivates and saps energy and goodwill, especially when the people doing the work know they are working on Incidental Complexity.

Essential Complexity – What Should You Be Spending Your Time On?

So, what should you actually be spending your time on?  What is essential complexity?

It’s tough to give a simple, single answer to this question.

Firstly, it depends on the stage of your business.  At this point, I will pause to plug Steve Blank’s book “Four Steps to the Epiphany“.  I dont’ know Steve but if there is just one book you should read on how to build a startup, you should read this one.

Early on in a startup, the essential complexity is working out who your customer is, the problem you are solving for them, the value of that problem, what your product is and how you’re going to solve it.

Once you’ve solved that (and only once you’ve solved that), your essential complexity becomes understanding your customers’ problem in even more detail and making sure you are designing, building and deploying a product that best satisfies those customer needs.

Further down the line, the essential complexity will be to make sure you stay ahead of your competition, increase efficiency, etc.

Of course, you can’t also ignore the #1 rule of any business; don’t run out of money.  So, raising money is also essential complexity for most startups.

It also depends on your individual role in the business but this is easy to overstate.  In a startup, people always have to wear multiple hats.  The right things for you to do are the right things to do, whether  or not they are strictly speaking part of your “job description”.  People who have rigid ideas about job descriptions probably shouldn’t be working in startups.

Some Focused Suggestions

In a smaller company (i.e. a typical startup), the first step is to make sure that everyone – from the CEO down to the intern – knows what the critical success factors of the business are – i.e. what are the things that the business needs to get done in order to be successful.  This list will change over time but needs to be regularly communicated and repeated.  Achieving these critical success factors is the essential complexity for your business.

With that list in mind, every person in the company needs to get into the habit of asking the following question:

Of the things I could be doing, am I currently doing that task which most contributes towards the business achieving its critical success factors?

Of course, people won’t always get the answer right.  Also, very often, and particularly for those people lower in the organization, they may be several degrees of separation away from the overall success factor for the business.

However, don’t underestimate people too much – I think most people will answer this question correctly more often than not.  The trick is to get and keep the list of critical success factors at the front of everyone’s minds and to get people into the habit of asking the question of themselves, and of others.

The next part is about communication.  People need to communicate what they think their priorities are and why.  This helps flush out people’s dependencies on each other.

In a very small organization this can be done verbally.  Once you’re beyond about 10 people, it makes sense to write these down and communicate them – I’d recommend weekly, by email.

As the organization grows, you’ll have to get more formalized.  In a bigger organization I’ve seen large SIPOC exercises run at whole-company off-sites work very effectively.

Whatever the size of the organization, the most important thing is that you and everyone else understand the difference between essential complexity and incidental complexity and what the specific critical success factors are for your business.

Focus, focus, focus.

Agree, disagree?  Please leave a comment (link at top of article).

Why You Should (Almost) Never Rewrite Code – A Graphical Guide

I’m by no means the first person to write about the dangers of rewriting code.  The definitive work for me is “Things You Should Never Do, Part I” written by Joel Spolsky in 2000.  If you haven’t read that, you should.

A recent discussion caused me to create a series of charts to graphically illustrate the dangers of rewriting.  I tend to think graphically – blame too much time in Powerpoint creating VC pitch decks.

I hope these charts help anyone considering rewriting code or being hectored by earnest, bright, young engineers and architects advocating a rewrite.  I’ve seen this movie before and I know how it ends.

The Status Quo

Firstly, here’s the status quo:

The more time and money you spend on an existing product, generally speaking, the more functionality you get.

Let’s then overlay the competitiveness of the product in its target market.  Of course, what you want to achieve is a continual improvement in the competitiveness of the product.  Competitiveness doesn’t increase as fast as functionality.  Your competitors don’t stand still so, typically, the best you can hope for is to increase competitiveness gradually over time – even staying flat is a big challenge.

Of course, this chart is idealized – functionality will increase in a more lumpy way as you release major new chunks of functionality and competitiveness will move up and down against your market. However, they demonstrate the point.

Note:  the Y axis on all these charts represents “functionality” which, for the purposes of this discussion, can be considered a blend of features and quality.  The distinction between the two is not really important in this analysis since you always want to be advancing on one or both and they both impact overall product competitiveness.

Let’s Rewrite!

Cue your software architect.  He’s just been reading about this great new application framework and language called Ban.an.as – it’s so much better than the way you’ve been doing things previously. Hell, Ban.an.as has built-in back-hashed inline quadroople integration comprehensions. Plus, all the cool kids are using it.

If you’re a non-technical manager or executive, this can become quickly overwhelming and hard to argue against.  They’re the experts, right, so they must know what they’re talking about.

[By the way, if you’re a non-engineer, there’s no such thing as “back-hashed inline quadroople integration comprehensions” – I made that up.  Sorry.
A little secret here: there really haven’t been any new programming paradigms invented since the 1970s.  Software folks are generally in their 20s and didn’t see them the first time around – they just get “re-discovered” and given new names. Sssh – don’t tell anyone.]

Just to be clear – I’m not saying that new languages, frameworks and technologies can’t create significant improvements in developer productivity – they can.  But, their introduction into an existing product has a big price, as we’ll see.

Lastly, lest I alienate or offend my fellow geeks, I have been that very software architect advocating for the rewrite.  I learned this the hard way.

So, this is how the rewrite is supposed to work in theory:

Let’s break this down:

The rework is expected to take some amount of time.  During this time, functionality won’t increase because developers are focusing on rebuilding the foundations.
In the graph, that’s the blue area you can see peeking through.  That blue area represents the cost of the rewrite.

But, once the rewrite is done, the idea is that progress will be massively greater than it was previously because the new technology used is inherently better than the old.  Developers will be more productive with the new.  There’s no need to work with the old spaghetti code – instead, there’s a beautiful new architecture free of all the baggage that came before.

The critical point in time is the break-even point – this is the point at which the functionality of your product starts to exceed where you would have been had you stuck with the original implementation and continued working on it.

During the rewrite period, the competitiveness of your product will typically decline since your competitors are not standing still and you can’t develop new functionality.

However, the claim typically made by the rewrite advocates is that the rework will be relatively easy, take a relatively short period of time and hence achieve break-even quickly, after which it’s non-stop to the moon…

What tends to go wrong – Part 1

So, what tends to go wrong?  The most common problem is arguably the most common problem in software development generally; the rewrite takes significantly longer that expected.

There’s a discussion of why this tends to happen below but, for now, trust me that this often happens – if you’ve had any experience with software development at all, it’s highly likely that you’ve seen this happen too.

The result is that the cost of your rewrite is significantly larger than originally claimed.  (The blue area showing through on the chart is now much larger.)  This means that the break-even point is also significantly pushed back in time.

The knock-on effect is that the competitiveness of your product drops for a much longer period of time.

If you are a big company, you can probably (hopefully) absorb the pushed out break-even point – maybe other products provide revenue, maybe good channel relationships continue to deliver sales of your product even though it’s falling versus the competition or maybe you’ve simply got lots of cash reserves.  Joel Spolsky references several big company rewrites that failed but did not kill the company.

However, if you are a startup or smaller company (or even a less fortunate bigger company), this can be – some might argue, is very likely to be – fatal.

What tends to go wrong – Part 2

It gets worse.

Not only does the rewrite often take longer than expected but functionality is not even flat at the end of it – functionality is actually lost as a side-effect of the rewrite.

That’s because all of those small but important features, tweaks and bug-fixes that were in the original product don’t get reimplemented during the rewrite.  (These are the “hairs” that Joel discusses.)

Remember that the main focus of the rewrite in the developer/architect’s mind is generally to build a better architecture and these small features don’t seem important and mess up this beautiful new architecture.

Plus, however good the developers are, they will introduce new bugs that will only get exposed and fixed through usage.

The net result is that the product after the rewrite is, in the eyes of the end-user and the market, worse than the product before the rewrite, even if it’s better in the eyes of the developer.

This further pushes out the break-even point in terms of functionality and competitiveness of your product will take a long time to recover.  If you listen carefully, you can probably hear your competitors wetting themselves laughing at your folly.

What tends to go wrong – Part 3

Oh dear.

The nail in the coffin is that, not only does the rewrite take longer than expected, and functionality get lost in the process, but the benefits of the new technology/language/framework turn out to not be nearly as great as claimed.  Meanwhile, if you’d stuck with the status quo, you would have got more productive due to normal learning effects – i.e. don’t forget that while your team is climbing the learning curve with the new technology, you would have been getting better with the old one anyway.

Any one of the 3 problems above is potentially fatal but all 3 together is definitely so.  Competitiveness of your product will likely never recover.

Why does this happen?

So, the above sections discuss what can go wrong.  It might help to understand why this happens.

In Joel’s seminal post cited above, he makes the point, “It’s harder to read code than to write it.”

Very true – it’s also more fun to write new code than learn someone else’s code.

Developers like to feel smart and, intellectually, learning someone else’s code can seem like a lose-lose scenario to a lot of developers – if the code is bad, it’s painful to learn and you’re going to have to fix it.  On the other hand, if it’s better than you would have written, it’s going to make you feel stupid.

Also, bear in mind that the fundamental motivation of most (not all) engineers is to Learn New Stuff ™.  They are always going to gravitate towards new things over old problems they feel they’ve already solved.  Again, I’m not faulting developers for this – it doesn’t make them bad people but, if you’re a non-developer, it’s critical you understand this motivation.

Put it this way: would you rather be the guy that architected the Golden Gate Bridge or one of the guys hanging off it on a rope, scraping off rust and repainting it?

Another problem is that when you rewrite, you typically make rapid progress early on which gives false validation to the decision to rewrite.  It makes you feel smart – what a beautiful cathedral I’m building.

That’s because you’re writing code in a vacuum.  No one is using the code yet; certainly no actual users.  But, as you start to reach launch date, all those small features, tweaks and bug-fixes – all that learning that was encapsulated in your old product – starts to become conspicuous by its absence.

The bottom-line is that, when the case to rewrite is being made, it is not comparing apples to apples – it is comparing theoretical benefits with actual benefits.  The actual benefit in question being, of course, that you have an existing product that works.

Comparing the pros and cons of writing a new application in language A versus B is not the same as comparing an application already written in language A versus rewriting that application in language B.  Why?  because any productivity gains of one language over the other are typically massively overridden by the loss of all the domain knowledge, testing and fixes encapsulated in the existing product.

Should you EVER rewrite?

So, are there ever circumstances when you should rewrite?  My answer here is an emphatic“maybe”.

Let’s consider some of the possible situations:

1.  An irretrievably sick code-base
The symptom here is that it takes exponentially longer to add each new feature – per the chart above.  Another symptom is that defect reports continue to come in as fast, or faster than you can fix them – you’re treading water.
However, an irretrievably sick development team is a much more likely culprit than an irretrievably sick product.
Don’t let developers convince you that they can’t maintain a codebase – what they most often mean is that they don’t want to maintain a codebase.

2.  The developers who wrote the code are not available
If you buy/find/inherit a codebase, make sure you have access to as many of the developers who wrote it as possible, for as long as possible.  If you didn’t…doh!
Again, don’t fall into the trap – developers will always prefer to write new code of their own than learn how the existing code works.

3.  A genuine change to a new problem domain
Sometimes, some of the fundamental assumptions and technology choices may no longer be valid for the problem domain that your product is addressing.  But, then I’d argue, you’re really talking about building a new product rather than rewriting an existing one.

4. Fundamentally incorrect or limiting technology choices
In some cases, the team that originally built the product may have made some poor choices in the technologies to use or the approaches to take.  They may simply not map well to the problem domain of your product.  However, in my experience, this is true much less often than developers claim it’s true.
Also, there are points where you start to hit fundamental scalability limits of certain technologies.  However, keep in mind that if you’re hitting those scalability limits, someone else probably has too before you, and solutions to the problem exist.

So, if you are even entertaining the suggestion of a rewrite, make sure you get the developers to give you a specific cost-benefit analysis of the rewrite.  Show them the charts above and get them to tell you why these problems won’t occur in this case, even though they occur in almost every case.

If and when you are convinced that this is one of those rare situations where a rewrite is the right approach, you need to make it surgical:  where will you make the incision?  How deep do you cut?  What are the risks?  What are the potential side-effects?  How can I make sure no functionality is lost? How can it be done incrementally?

Divide the rewrite into a series of smaller changes, during which functionality absolutely cannot be lost.  Rewrite parts of the system at a time with a well defined, understood and testable interface between old and new.

Better still, don’t rewrite.

Good luck.

Agree, disagree?  Please leave a comment.