​“I have to do everything myself, and I don’t have time to fix all of this.”
 
The CEO who said that to me was a successful entrepreneur who had grown his startup into a 25-person marketing company serving hundreds of brands. Our technology gap analysis had turned into more of a venting session about the growing pains he was seeing in his organization.  He was losing sleep about his company’s challenges arising from:

• Poor vendor management
• A hodgepodge of tech that wouldn’t scale
• Inability to keep up with new leads
• Stagnant R&D
• Lack of focus

 
A week later I found myself in a similar conversation, this time with a VP of Engineering looking for an outside perspective.  By most measures, his 350-person SAAS (Software as a Service) company was a success.  But behind the scenes lurked dysfunction common to many companies, especially those that have grown by acquiring other companies. My friend was aware of these issues but was struggling to make a business case that would persuade his fellow executives to address: 

• Duplicate processes
• Redundant tools
• Incompatible technologies
• Balkanized departments
• Misaligned priorities

 
What did these executives have in common?

• They were smart, successful managers focused on operating their business day-to-day.
• As the strategic needs of their business changed over time, small problems had grown into bigger problems.
• Both leaders were struggling to prioritize solving these kinds of problems.

 
They had accumulated strategic debt.
 
If “strategy” is how you define and implement a framework for success, strategic debt is what accrues when you neglect the necessary maintenance of that framework.

​I often speak with leaders struggling with strategic debt, and I’ve faced it myself: stuck in a cycle of endless meetings, fighting fires, continuously being in reactive mode.  Or struggling to get work done across departments, each with their own competing priorities.
 
As a leader, at one time you may have invested a fair amount of time and thought in your organization’s strategy. Over time, that initial investment loses value.  Your original framework for success drifts from the framework your organization needs today.  You accumulate strategic debt.

​You know you have strategic debt when:

• Organizational structure is aligned with former, not current business needs.  For example, a marketing person is responsible for technical issues (or vice versa).  Or what should be a single department is spread across multiple groups because those groups historically owned a piece of the portfolio.  
• An employee, manager, or perhaps the CEO has become the expert in an essential function.  That person can’t delegate or scale because her best practices live inside her head.
• A team’s portfolio has grown larger than the team’s capacity, but bringing new people up to speed (never mind recruiting them in the first place) takes time. It’s a lot easier to calculate the cost of an additional resource than the opportunity cost of not adding that resource, so the team continues to make do with existing staff.
• Different teams within the company a) have different processes for the same function, b) use different technologies for the same function or c) pursue competing priorities.  Or all of the above.
• Innovation has stagnated in an organization that once made its mark through innovation.  The organization now focuses on optimizing existing lines of business, not exploring new ones.

 
What examples from your organization would you add to that list?  
 
Strategic debt is comprised of the structural inefficiencies and gaps that grow over time by prioritizing short-term needs over long-term needs.  Each decision may have been locally optimal — but the accumulation of these decisions suffocates your organization’s ability to perform.  That’s because your people/process/priority infrastructure is no longer organized optimally for your current needs.
 
What gets measured gets managed
 
Strategic debt can be difficult to address because it is squishy and hard to quantify.  To quantify strategic debt you have to measure decision-making and operational performance across the organization over a long period.
 
Because it’s hard to quantify most strategic debt, it can be hard to justify spending time to address it.  But not all strategic debt is hard to quantify.  There is a type of strategic debt commonly found in software development that is highly quantified.  Not surprisingly, there is also a commonly adopted approach to addressing it.
 
Even though software development is creative work, that work is typically decomposed into discrete tasks.  Software teams estimate each task’s size independently and log their workflow from initiation to completion.  They track productivity and efficiency through metrics that are a natural byproduct of this process. (The “Accelerate metrics”, such as deployment frequency and lead time to deploy, are a popular example.)
 
Because software development workflows are highly quantified, it’s easier to recognize the effect of strategic debt on productivity — the drag as debt accumulates, and the boost with its elimination.  In turn, that makes it easier to persuade individuals and organizations to address strategic debt, or as it’s commonly called in technology organizations, “technical debt.”
 
In fact, the prevalent approach to addressing “technical debt” can be used to address any strategic debt.  That approach is to stop addressing strategic debt as a crisis — and allocate a recurring budget for it.  
 
In software development, 15-30% of a team’s capacity is typically reserved for technical debt.  An appropriate budget for your organization’s strategic debt may or may not be in that range.  Instead of a percentage, your “budget” might be a requirement for managers to include one strategic debt OKR Objective in their quarterly OKRs.  However you allot time and resources for strategic debt, what’s important is that your budget is greater than zero.

​Let’s say you’ve decided to reserve a budget for your organization’s strategic debt.  How can you spend your budget effectively to reduce that debt?  Here are some examples:
 

• Review roles and responsibilities at the company, department, team, and individual level.  Draw the org chart you would create today and create a plan to get there.  That might include a reorganization, hiring to fill gaps, or both.
• Have your leaders think through their “mental best practices” and codify them into procedures and protocols so the team can scale, others can grow, and company best practices remain consistently applied.
• Create an inventory of tools and processes across departments, determine which qualify as company best practices, and create a plan to eliminate those that don’t.
• Maintain your innovation pipeline.  Budget time and resources for experimentation.  (Some technology companies invest in hack-athons or “labs”.)  Create incentives to take the necessary risks to innovate.
  
  

What strategic debt do you recognize in your own organization?  Is it one issue or several?  Who decides whether to address it —  your CEO who’s still “fixing everything himself”, your fellow executives with competing priorities, or perhaps yourself?  Whoever your decision-maker(s), it can be difficult to make the case to carve out time from the day-to-day to address each component of your strategic debt in turn.  Instead, make the case once for addressing strategic debt as part of your normal workflow — by budgeting a portion of time and resources to work on your framework for success and pay down your strategic debt. 

 
The conventional wisdom about startup pitch decks is that the most important sections are the team and money slides.  And the conventional wisdom is not wrong.  Research shows that investors spend more time on these slides than any others.

But having met hundreds of startup entrepreneurs (and their pitch decks), I find I can glean a lot of information about you as an entrepreneur from your competitor slide.  Here’s what your thoughtful competitive research tells me, as captured in your competitor slide or simply from a conversation with you about your startup’s competitive landscape:

You Do Your Homework

A comprehensive, detailed list of competitors shows me, first and foremost, that you dig in and do your homework.  Competitive research is essentially research into how much of your opportunity has already been seized by others, not a topic most entrepreneurs are passionate about immersing themselves in.  Your diligence about competitive research tells me that you’re a professional about the less gratifying tasks in an entrepreneur’s portfolio. I can also expect other facets of your strategy will be similarly backed up by substance and attention to detail.

You’re a Realist

If you’re a startup, by definition you are trying to prove your startup hypothesis.  Generally speaking, your hypothesis is that customer demand will scale.  If you’re really early stage, your hypothesis may be that customer demand exists.  Some of the data crossing your desk will be beneficial to your startup hypothesis, and some, such as evidence of a strong competitor, will be detrimental.

How do you handle data that doesn’t favor your business case?  Do you filter it out?  Do you bury it?  Is your head in the sand (or the clouds)?  When you share thoughtful research into your competition, including strengths as well as weaknesses, that’s a strong signal the answer is “no”.

You’re Up for a Challenge

There are many bummer days in an entrepreneur’s life.  The day you say to yourself about the competitor you just looked into, “Dang, they’ve actually done a pretty good job of this” is one of those days.  If you’ve properly identified and acknowledged the competitive pressures facing your startup AND you’re still excited about your prospects, that tells me you’re more likely to be in it for the long haul.  Which is a must for any successful entrepreneur.

You’re Not a BS Artist

Entrepreneurs should be able to paint a compelling picture of their startup.  I worry if you haven’t. But I also worry how much of that picture is embellished.

When you acknowledge your competitors’ strengths, you give me confidence that you’re not trying to put a positive spin on everything.  “We’ve figured out how to design a smart phone people will want to use, unlike those clowns at Apple and Google” — not what I want to hear.  Unless I’ve worked with you before, I’m looking for reasons to believe your narrative.  Your clear-eyed competitive research is a very good reason.

Your Opportunity is Real

Nobody can be an expert in every domain.  Like many others I’m a “T” — shallow in a lot of areas, deep in only a few.  I’m probably not an expert in your particular niche and its ecosystem at this moment.  I bet most investors aren’t either.  More than your idea or your optimistic financial projections, a few minutes looking into your competitor list gives me a quick education on your space, the opportunity, and your (or anybody’s) prospects for success.

​Even though I’m a technologist, one of my favorite classes in high school was social studies class junior year, where we debated different sides of an argument (often not the side we started out believing).  Competitive research is like a pro/con debate on “I have a great startup idea”.  Use it to challenge your assumptions.  Your startup strategy and execution, as well as your pitch deck, will be the better for it.

This post is also featured on The Startup.  It was originally published on Shulman Rogers NEXT.

Unless you’ve been living under a rock (or perhaps in one of those rural Iowa counties with spotty internet access), you know at the root of the 2020 Iowa Democratic caucus fiasco was the little IowaReporterApp that couldn’t.  Created by Shadow Inc., a company that sounds like the evil nemesis in a James Bond film, this mobile app was built for a very special audience, 1,765 volunteer Iowa Democratic precinct chairs, for a very specialized purpose: reporting and tabulating the results of the Iowa caucuses.  Many of its intended users couldn’t download and sign onto the app, and it didn’t work right for those who could. Another example of sloppy software developers writing buggy code, causing a massive software failure at the worst possible time for the biggest stakes, right?

Not so fast.  It might have been a software failure at the worst possible time for very high stakes (more on that below), but don’t blame the coders for this one.  Blame the managers.

Yes, there was a bug in how the app communicated with the back end system.  It’s something everybody can point to and say, “See?  There was a bug in the code.”  Let’s see a show of hands: any software developers reading this who have created a bug before, please raise your hand.  All of you?  That’s what I thought.

The project plan for launching the IowaReporterApp was fatally flawed.  That a bug made it into the production system is but one of many things that went wrong.  If we look at how a software project like this should have been run and compare it to how it actually was run, we can see several management missteps.  When you’re managing a project to a drop-dead release date like the Iowa caucuses, often the best way to come up with a plan is to start at the end-point and work the timeline back to the beginning.  Let’s do that here, starting with:

7. User Training

A smartphone app handed to 1700+ caucus volunteers, many of them “newer to apps and that kind of stuff”, some still using flip phones (according to the Polk and Buchanan county chairs).  What could possibly go wrong?

Apparently some user training was offered, but that happened before users even received the app.  Many volunteers had never even tried the app before the caucuses.

You can’t blame the users for having issues with an app they’d never been trained on or even seen.  That would be like, uh, blaming software developers for not writing 100% bug-free code.

6. Product Release and User Onboarding

Before training the users you have to get them up and running with the app.  The Shadow project was so late the app was never actually published to Apple’s App Store.  (That requires waiting for Apple to approve the app, which takes 1-2 days — time Shadow apparently didn’t have.)  As a result, users were required to download a developer app called TestFlight which is used to pre-publish apps to beta-testers before general release.

It should have been clear to Shadow a couple of days before the caucuses that they were at risk of not actually being able to release the app to users (and that they weren’t going to be able to get all 1700+ precinct chairs to figure out how to use the developer app). That would have been their last opportunity to say “abort, abort!” and double down on the back-up plan, which was to phone in results.  A couple of days’ notice would have allowed the team to communicate the new plan to volunteers and recruit more operators to staff the phones (avoiding the 90-plus minute hold times for reporting results).

5. Beta Testing and Bug Fixing

Software coding and systems development is complex, with bugs an inevitable byproduct.  Multiple rounds of testing are typically necessary to suss out any significant bugs.  The higher the stakes and the lower the tolerance for bugs, the more rounds are necessary.

Typically the final round(s) of software testing is beta testing, where the product is put in the hands of a relatively small set of engaged (and well-informed) users.  This can be the only way to unearth bugs caused by usage patterns unanticipated by the developers, as well as an important opportunity to gather real user feedback to inform ongoing product development.  (Apple’s previously mentioned TestFlight app is designed to facilitate beta testing feedback.)

Shadow’s CEO said they’d had people beta-testing the app “for weeks”.  The Washington Post, on the other hand, described the app as almost entirely untested.  What’s clear is that Shadow didn’t do beta-testing right.  One or more of the following must be true:

• They gave their beta-testers support and hand-holding they didn’t give the general audience.
• Their beta-testers weren’t representative of their general audience.
• The beta-testers didn’t use the same product as the general audience (were they onboarded through TestFlight?).
• Beta-testing feedback wasn’t collected or given appropriate attention.

Otherwise, the fact that three-quarters of users couldn’t figure out how to log into the app would not have come as a surprise on C-Day.

4. Integration Testing

Typically the final phase before unleashing an emerging software product on beta testers is integration testing.  Unlike earlier phases in which software components may be tested independently, in integration testing the entire system is tested end-to-end.  This is the phase where you should catch bugs in places like “code that transmits results data into the… data warehouse”, which is how Shadow’s CEO described the infamous IowaReporterApp bug.  I don’t know why the bug wasn’t caught during integration testing (or beta testing), but you can’t blame the developers for that.  Maybe management didn’t allow enough time for testing…

3. Initial Development and Testing

I can’t see the app (since it was never publicly released), and nobody has publicly said anything about its development process.  So I can only comment as an outside observer:

• The one-fourth of caucus chairs who were able to download and sign into the app were able to use it as intended.  I have not seen, in broad media coverage of the incident, any complaints about the quality of the app itself.  If the app had usability issues beyond user-onboarding, we’d know about them at this point.  (This is a good thing.)
• Completing development of a typical mobile app in a two-month timeframe would be aggressive even if it were the only phase of the development lifecycle.  Add in all of the other phases in this list, and well, any experienced manager could have predicted the shtuff was bound to hit the fan.

​
2. Design

There have been over 800 cyberattacks of political organizations in the past year alone.  In this climate, security is a fundamental requirement for any online political product, especially one used operationally to tabulate votes, especially votes as high profile as the Iowa presidential caucuses.  Security is not a feature that can be tacked onto a software system; it has to be designed in from the start.

Unfortunately, it is difficult to evaluate the security of the IowaReporterApp system.  The Iowa Democratic party took the approach of keeping security measures themselves a secret.  Prior to the caucuses, Iowa Democratic party chair Troy Price wouldn’t reveal what security measures were being implemented or even who was building the app, saying, "We want to make sure we are not relaying information that could be used against us."  As for any political organizations that might want to use this system in the future, well, that’s their problem.  (He didn’t actually say that last part.)

(Nevada democrats were already planning to use the same app for their February 22 caucuses — not surprisingly, they’ve abandoned those plans.)

Security through Obscurity, as this approach is called, is a discredited practice.  Once the “secret” is out, the “security” is lost.  Truly secure systems, such as the protocol for encrypting and decrypting the content you’re reading right now via HTTPS, are secure despite being open.

1. Signing Up for the Impossible

Working under the brightest of lights, with zero tolerance for slipping the date or allowing any security breach, did the Shadow team ever really have a shot at successfully launching the IowaReporterApp in a little over two months?  Even if they were merely repurposing an existing app (which they weren't), it would have been a tall order to complete multiple rounds of testing, fix bugs, release the app, train users, and get everything locked down in that period of time.  Add in design and development time, and the answer is a resounding “no”.

Signing the contract to build the app — this was the first and biggest mistake made by Shadow management.  This was an impossible ask of the engineering team.  I’ve signed up for the impossible a couple of times in my career and lived to regret it.

Shadow was signed on only about two and a half months before C-Day, judging from public payment records.  Why was the schedule so compressed in the first place?  Apparently Iowa decided to go with an app late in the game. According to the New York Times, “[only] when Iowa Democrats, on the advice of the national party, abandoned plans to have caucus results called in by phone because of security concerns and instead build an app, they chose Shadow from multiple bidders.” (I imagine over the last few days there’s been a lot of kissing of spouses and children by the other bidders.)

It’s been reported that previously Shadow had nearly gone bankrupt after failing to gain traction with an earlier campaign-texting platform.  I can understand why they saw the Iowa caucuses as a chance for redemption, maybe a make-or-break deal for the company.  But when you’re signing up for the impossible, the alternative is always preferable, even if it means running out of money.  At least that gives you a chance at an orderly dissolution that doesn’t result in everybody associated with the company running away like rats from a burning ship.