Strategy for Startups: The Cost Of Change
Hello! I build IT teams and design IT Systems for startups and nonprofits. I consistently encounter the same problems, so I set out to create a series of guides to help others navigate the IT Ecosystem. You can learn more about my philosphies via my website dave-bour.com or via my weekly newsletter.
In the past year, the US housed more startups than any other country. Abundant wealth and accumulation of resources has made the prospect of funding new ventures quite attractive, but we’ve increasingly utilized it as leverage to offset the cost of inefficiency.
When your capital is no longer used for innovation, rather, to enable inefficiencies, that is a problem.
We’ve baked this into our processes and have accepted it as a new standard. This sets a poor precedent for the next generation of problem solvers, but, I will argue, is also the driving factor behind high turnover, dissatisfaction at work, and reduces problem-solving effectiveness.
Change is a primary driver behind inefficiency at work and it’s become our ‘go-to’ for everything that deviates from our personal expectation or outcome. For instance, how often at work do you hear that the software employed for some task doesn’t do X — but this other software does X. Can webuy it? Can we switch? Hipchat becomes Slack. Outlook becomes Gmail, then becomes Outlook again. Cisco/Polycom became Bluejeans which became Google Meet which became Zoom.
Every time we switch to a different service, buy a new service, or create a new process, we pay a change-cost in the form of information that gets lost, bottlenecks that form, time to learn the new thing, effort to get other people to use the new thing, justifying the new thing. With change comes inefficiency, expressed as friction in business processes.
These costs are not all absorbed as financial loss. Change fatigue will reduce your team’s capacity to adopt and learn new processes. Downstream or auxiliary projects will suffer missed timelines due to resource-loss to accomodate the changes. Elevated stress levels in environments that change constantly will cause increased turnover. For now, it’s a good thing we have abundant wealth and accumulated resources.
The benignness of change-as-default belies how painful the removal will be after we exhaust our leverage to offset it’s cost; but through scrutiny, patience, and awareness, we can prevent it from seeping further into our practices.
In this article, I will identify drivers of change, how to recognize costly change, key descriptors that indicate reactive change, and equip us with tools to find our way out of this maze. For now, I will argue that to stop the bleeding, this will require adopting a new mindset — one of minimal change.
First, let me point out that we’re horrible future-state planners — often failing to consider the ramifications of our proposed change or the dependencies that will be affected by the change: this is a well documented condition of being human.
Second, it is worth acknowledging that some change is necessary. Consolidating five services into one, adding a new tool that directly achieves a goal, reformatting a website to make it easier to use are all good examples of structural change. Unfortunately, these major undertakings are often planned haphazardly — failing to include relevant stakeholders, anticipate resource requirements and timelines, and forsee unintended consequences.
Yet, even correctly surmising the ramifications fails to safeguard us against ill effects of change when we scrutinize what makes us seek it in the first place — that something better than our current circumstance must exist. (Sidenote: the drivers for change vary and are well identified in Robert Greene’s The Laws of Human Nature. Mr. Greene’s book focuses on individual drivers of change (pleasure principle, et. al.); deftly navigating a line between psychology, culture, and concepts of human development.)
In most businesses, the pursuit of something better is a fallacy that haunts the decision process. The premise under which we base a decision to change is tied to an expectation that something better exists. However, our inability to view a problem objectively, detached from expectation, promise, or outcome will ensure that new problems arise in the solution.
Would you be satisfied if I told you that nothing better exists? Even if it’s true, would it suffice?
What Drives Change at a Startup?
Your ability to identify legitimate drivers of change will become a differentiator in prioritizing work.
Change is driven by:
- adaptation to shifting circumstances,
- strategic plans occuring in stages,
- a belief that a better circumstance exists.
Agility is a core tenet of identifying a startup. Agility implies that barriers to change are lower, enabling the organization to more swiftly when opportunities occur or to pivot in response to circumstances. There’s also a lack of policies, procedures, and change management practices which make it easier to influence change without due care. The ad hoc nature of change allow surface-level impressions, or first level thinking, drive the conversation.
When change is driven by a belief that a better circumstance exists, and we’ve creating conditions that allow the change to occur without due care or effective planning, then the cost of change will negate the perceived benefit.
Initiating change from a reactive state will ensure the creation of a new set of problems.
If only we can step back before the decision and ask ourselves, “What am I missing because I’m so focused on this one thing?” It’s a great tool to consider alternative solutions, identify flaws in our approach, and generally widen our field of view.
In the context of startups and scale-ups, change is often in pursuit of a perceived improvement. Yet, the urge to change stems from an emotional pursuit of perfection which change will fail to satify. For example, at some point in our lives, we’ve all expressed a want for a new computer because our current one is too slow. How many of us have quantified how fast a new computer would have to be for us to be happy? This can be expressed as formula:
Expectation / Reality = Personal Dissatisfaction
Our threshold for dissatisfaction is personal and widely varied. At work, the formula changes:
Expectation / Reality = (Personal Dissatisfaction * 10)
We’re much less willing to entertain dissatisfaction at work, but this makes sense. We’re not paying for the change (financially uninvested), we’re often not responsible for the ramifications of the change (no shared responsibility), and we’re increasingly approaching work with a short term mindset (reactive thinking). What is the average length of time someone holds a role at a startup — 1–3 years?
Every change can be reframed as swapping out one problem set for another problem set. No product is flawless or perfectly fits your use case.
So the question becomes, “Which product’s problem set do you wish to deal with?”
Let’s start with a reactive-driven change example — You’re an IT Pro who joined a company using Product A as their phone/voice solution. In your first few weeks, it is made clear that this product has reliability issues and you’re tasked with finding a replacement.
Via Google, you find Product B. Product B is touted for its reliability and the transition is sold as a solution to the reliability problems of Product A. You execute the move to the new product at a high monetary and resource-investment cost to the organization.
After the change, you find that the faxing feature allows you to forward faxes to just one person, no longer an entire group of people. While normally a minor feature, your organization relies heavily on faxing and needs many team members to monitor incoming faxes.
When the organization developed tunnel vision around reliability, they swapped oneone of set problems out for another.
Somehow, not-perfect has become an unacceptable answer. Maybe this speaks to our inability to deal with uncertainty?
To a lesser extent, you should be aware of the ‘shiny thing’ syndrome, whereby a fine solution is swapped out for a sexier solution. A dead giveaway is that it “has this feature that we like” or rather, is differentiated by one/two simple features.
After a meeting, you have a diagram sitting on a whiteboard in front of the team. We have this problem whereby you need to save this diagram for future reference; so you take a picture of it and upload it to Google Drive. Wouldn’t it be awesome if the whiteboard could just, like, save the diagram as a file in Google Drive for you?
After creating a light business case for approval and working with IT for procurement, your new jamboard has arrived. It:
- weighs about 40 pounds and requires a lot of assembly,
- is too heavy to hang on the wall and requires a cart,
- often mistakes what you’re trying to draw on it,
- requires constant troubleshooting to connect to the internet everyday.
Our new whiteboard costs an arm and a leg and doesn’t work half the time, so no one uses it. Now we don’t have a whiteboard in our conference room. We have this problem…
In cases such as this, you’ll repeatedly find that the original solution was:
- conceived in haste (urgency-influenced), and/or,
- failed to take into account technical or cultural limitations (lacked planning), and/or,
- failed to account for a future-state of the business (lacked knowledge).
Which can be restated as being driven/influenced by urgency, failure to include stakeholders, scope, or lacking information, and/or failure to thoroughly plan.
Dissatisfaction + an uneducated assessment = a new problem + a lot of work
How do we break the cycle?
You can learn to identify it in order to avoid it, improve your business acument to manage it, or become a thought leader to help justify it.
If you choose to employ a strategy of avoidance, let’s begin by recognizing that no company is perfect, but some lend themselves to the problem-set-swapping fallacy more frequently than others.
When joining a new company, you may find the following descriptors indicative of poor change management.
- ‘lightspeed’ = we function in a reactive state under the guise of opportunity-grabbing,
- ‘looking for someone who can move as fast as we do/can keep up’ = prepare for texts at 10:00p each night and that reactive life,
- ‘adapt to rapidly changing environment’ or ‘deal with uncertainty’= we don’t really know where this is going/don’t have a solid plan
You may also wish to avoid the modern day door-to-door digital salespeople on LinkedIn asking for your time to discuss how their service can fulfill a need of the company. The equivalent of cold calling, these shots in the dark encourage changing anything to their service, regardless of need or benefit.
If you choose the noble path of tackling the problem head-on through confrontation, aka ‘Be The Change’, you’ll find grounding in Project Management certifications such as the PMP, or the same-but-more-accessible CAPM from the Project Management Institute. These certifications teach useful, proper project management which negates the number one pain point — failure to justify and plan.
Supplementing certifications with business strategy acumen will be most useful in this approach.
If you can hone an ability to articulate the intangible costs — change fatigue, cultural adoption of the new product or process, explaining the ‘why’ to the former product stalwarts — will go a long way in convincing others to stay the course or justify the change proposal. This requires a high degree of empathy and awareness. Always put yourself in the shoes of an employee — you’re going about your day as a Marketing Coordinator, trying to plan for this upcoming event, and IT is making you change the phone and app used to call and receive calls from vendors. Your old phone number didn’t show up in the new system, so no one can reach you. Your manager is stressed from the upcoming trade show and demanding that you finish coordinating set delivery. “How do I get the app again??”, skipping lunch and half listening to a ‘required’ IT training you’re forced to attend for the voice migration project. How do you migrate voice, anyways?
Any change needs to be in the service of your customers, colleagues, or business goals.
Unless you can substantially improve your colleagues working conditions, better serve your customers, or significantly impact the bottom line, you should scrutinize the change with all available resources.
Change is Paid for in Time
Efficiency is a function of resources applied over time towards a result. In business, we want to use as few resources as possible to achieve the result as quickly as possible.
Change is shifting a river’s direction of flow, it takes time to channel new pathways and efficiency is lost abruptly, only to slowly be regained to what it once was. An organization is an ecosystem — but whether the change is small or large, it will create ineffiency at an inordinate scale. In this article, I’ve outlined large scale change, but at a small scale, we can take a common example of changing a staff member’s email address. Through the lens of an ecosystem, everything is intertwined, and changing an email address will remove access to all OAuth accounts, require new business cards, communication to partners, vendors, and teammates, ineffiencies attempting to reset passwords and change logins. This will consume staff member’s time, energy, and that of IT who will need to assist. A vendor may have to get involved after they’ve lost access to important files stored in a service authenticating the user via their original cloud services UID, which is often email.
Change cascades and if you find yourself in a constant state of it, then you and your teammates are going to experience change fatigue. Like any other irritant, our capacity to accommodate persistent change will decrease over time. Burnout, frustration, and poor psychological wellbeing will result.
The solution I am proposing is a reframing of how we see change. Change is an act of swapping problem sets where minimal net gain if often be achieved. This is not to say that change is not warranted, but when our abundant wealth and accumulated resources can no longer offset the inefficiencies, we may have to assume a new posture — change isn’t bad, it’s costly.
These recommendations are just the tip of the iceberg when it comes to organizational technology postures. Please reach out to me at dave-bour.com to discuss more.