How Complexity Creates Defensibility for Technology Vendors
“Ease of use” is often touted as a benefit or key feature of a product, something that many enterprise technology vendors state they can do.
But think about this for a moment: Is it in a vendor’s best interests to make their technology simple and easy to use? For vendors selling to enterprises the answer, in my opinion, is No. It isn’t. And I say this knowing full well that we advertise Ease of Use as a key advantage of TypeSift.
So now that I’ve painted myself into a corner, let’s see if I can Houdini my way out of it.
Why is Enterprise Software so Complicated to Use?
I once watched my 3-year old niece unlock her mom’s iPad, navigate to the Videos app, pull up a list of Dora episodes, scroll to the one she wanted and then tap to start watching. She even knew that if she tapped the screen the volume controls and position scrubber would disappear. If a notification popped up she’d flick it away with her finger.
Then I got in trouble with my sister for letting my niece get a hold of the iPad in the first place.
My point is that Apple is the best example of a company whose products are so well designed a child could use them.
So why aren’t enterprise tools so easy to use? Why is there so much bloat, so much configuration, and so many levels of menus and screens to navigate just to accomplish one task? Vendors may argue that because you are doing something complex the tool must be complex itself. I think we need to hold vendors to a higher standard, because that sounds like a copout. And sometimes it feels like functionality is purposefully obfuscated. Is there something nefarious going on here?
No. There isn’t. These tools are just badly designed. Why is this? From my experience there are three main reasons:
- Interfaces are often designed by engineers, not UX/UI experts.
- There’s a human bias towards making things more complex
- Features are added on-top of legacy code. A lack of design patterns, failure to plan for future functionality, and tight deadlines result in Technical Debt.
Design: I’ve seen enough complex screens made by software developers that are engineers first and designers second to tell you the UI/UX is built in a way that makes sense to the programmer, not the user. The vendor will then construct training manuals, videos, webinars and courses to educate the user on how to use their tool. Then they charge you for it.
Bias: Tools that are deceptively simple to use often hide deep engineering design work. Most technical designers (myself included) will lament that the beauty and elegance of a product’s internal design often goes unappreciated by the end-user. In a user’s mind the product needs to “just work.” How the engineer made it work is of no interest to them. This is a lonely place for an engineer to be, so it’s natural to want to “show off” some of the complexity of the tool, if not to brag then at least to feel appreciated for the hard work. The opposite bias is also true, that the simpler the product is to use the less its value. The truth is usually the exact opposite.
It’s much, much harder to design something simple than to design something complex. This is not a new concept. Shakespeare and President Woodrow Wilson put it best,
You can apply these sentiments to interfaces which are “visually verbose”, with lots of options and many steps involved in completing a task. It’s hard, from a design perspective, to know what options to show up front, which to tuck away, and how to lay it all out in a way that is intuitive to the user. This is often why you see every button, menu-item, and feature displayed up front in a dizzying array of options. To be clear I don’t believe technology vendors intentionally make their products difficult to use, but I do believe there is a bias towards doing so.
Technical Debt: In most industries there are best practices called Design Patterns. In software development one of the most classic is known as the Gang of Four. There’s also the opposite called anti-Patterns. To keep things simple, you can think of Design Patterns as “the right way” of doing things and anti-Patterns “the wrong way.” What makes them right or wrong depends on a variety of factors but the one I’ll belabor here is planning for the future. That is, “How can I design the system now to plan for the future of the product?”
Using Design Patterns requires much more thinking up-front, probably more than you’d spend coding. It’s like the old adage, “Measure twice, cut once.” At TypeSift we’ve adapted this to our own motto,
This often requires a trade-off. No two engineers or developers are made equal. The ones with more experience can typically recognize Design Patterns, plan for the future, and implement the design in production with minimal effort. Junior engineers can’t do this simply because they don’t have the experience. Senior engineers are expensive, and the really good ones are rare, whereas junior engineers are typically the opposite. This means a technology vendor’s teams are often a mix of the two (and everything in between). When you have tight release schedules and Project Managers pushing you to get features out the door, vendors end up making sacrifices in the overall design opting to just “get it done” and come back to improve later. This builds up something we in the industry call Technical Debt.
Technical Debt is expensive to pay down, which means vendors just keep building on-top of old designs. This continues to add complexity to the system, often showing up to the user as a complicated interface.
All these factors combine to create an interesting side-effect: Any user who can overcome the complexity of a tool is considered a Power User.
We’ve all seen them before. A Power User can navigate the bends and turns while using a product to accomplish a task more deftly than anyone else. When they go to work it’s a stream of rapid clicks, keystrokes, or mouse gestures as they skip over the hurdles of complexity. Anyone that is not a Power User may feel intimidated, frustrated, and a distaste for the technology.
Now consider this: A straight line is simpler than one with zigs and zags. Simplicity takes you from A to Z in a single bound. How do you think a Power User would feel then if, suddenly, everyone had a straight line from start-to-finish to complete a task which, before, only a Power User could do?
How I Obsoleted Myself as a Power User
When I was a young software developer I worked for a consultancy that implemented software for a major manufacturer in the States. The client had a 24-hour operation which meant that at least one member of my team (myself included) had to be on-call.
I was part of 2nd-line (remote) support which was called in when On-Site support couldn’t solve the problem. We had implemented software from a very reputable vendor, so we never encountered “bugs” in the tool but rather corner cases that arose naturally in the manufacturing process which had to be “dealt with.” Unfortunately, this software wasn’t the easiest thing to use. And while the developers at HQ had a lot of experience with it (because we had to implement it), the On-Site support did not.
I cannot describe to you the terror-inducing panic that fills your chest when the horrendous ringtone of the Support Phone goes off at 3AM. Groggy, I’d boot up my laptop to log-in and trace the problem.
I am not a nightshift person. Call it a weakness. Call it a limitation. Call it whatever you want, but I just cannot handle overnight work, and I was being called every other night. I wanted to solve this once and for all.
I realized there was a set of typical issues that kept coming up. My first idea was to make a list of all possible issues and then provide solutions to On-Site staff. The problem was that On-Site support may not be able to properly diagnose the underlying problem. So even though they had a list of common problems and solutions, they didn’t have a way of narrowing it down to the right one.
My solution came in a (now considered) low-tech way: An Internal Wiki Page.
I went through my notes and past experiences, cataloguing all the possible symptoms and error messages I could think of. Then I provided a step-by-step guide on how to debug the issues to arrive at the source of the problem. Once determined, there was a set of steps to solving the issue. Any time a new problem came up that I hadn’t encountered before I added it to the Wiki.
The number of support calls I personally received started to go down and three months later I received an email from a new On-Site support staff thanking me for starting this document. In her own words she was able to follow my steps to find the problem and solve it quickly without involving anyone else.
My brother-in-law told me that I had “obsoleted myself” because although I hated being called in the middle of the night I was still being paid (by the hour) every time I was called.
Is this true? Was the value of my work so easily replaced by one Internal Wiki document? Did I “automate” my way out of more money in my pocket?
Or was there more value in not having my sleep interrupted? What was the benefit of being fresh to design new solutions during the day instead of “dealing with” the same problems in the middle of the night?
Sure, I made a little less money because I wasn’t being called, but I also gained back 2 or 3 hours of sleep every other night. My company still made money off the support contract because we still had to carry the phone (even though it went off less), so our business wasn’t losing money there. On-Site support didn’t have to feel frustrated that they couldn’t solve the problems themselves. And the client didn’t have to spend additional money on paying us to pick up the phone in the middle of the night.
Now mind you the final amount of money and time actually saved was probably on the order of thousands as opposed to hundreds of thousands. It was just a low-tech Wiki after all. But the outcome is still valid. That small Wiki was like the rising tide that lifted all ships equally. What happens when these types of process improvements are applied on bigger problems, across more business units, and at scale?
How Complexity Creates Defensibility in the mind of the Power User
There’s a term in the Startup world called “Defensibility” which basically answers the question, “How do you make sure another company doesn’t come along and eat your lunch?” In other words, “How replaceable are you?” This question is also true of employees.
Complexity creates a cognitive bias in the user whereby Power Users tie their value in the business to their skills with a tool. They don’t realize their true value comes from their knowledge and experience, which is not so easily (or ever) replaced. This (false) defensibility in the mind of the Power User creates an unusual source of (true) defensibility for enterprise technology vendors.
The more vocal a Power User, the more resistant they will be to change in technology, and so the higher the defensibility of the vendor’s solution.
Not because the old tools are better or more feature-rich, but because they are more complex. Power Users will strongly disagree with me here but that makes it no less true: Ease of Use erodes a Power User’s (believed) Defensibility.
The other thing to realize is that the regular users who hate the technology will come to the Power Users for help in completing a task. They don’t want to become more proficient in the tool’s use, they’d rather the Power User just complete the part of the task that requires the tool. And since there are naturally fewer Power Users than there are casual users, this creates bottlenecks in the organization.
This is such an important piece of the puzzle. A classic example is when someone asks, “Hey, can you just pull these numbers and send it to me in a spreadsheet?”
This creates an unhealthy dynamic in the company because even if a better, simpler, easier tool came along, many regular/casual users may not adopt it because it’s easier to yell over the cubicle wall at Joe to get something done than to add yet one more thing to the list of a million other things that casual user needs to know. So, the user gets the small, short-term gain of getting someone else to do it in exchange for a much worse long-term pain of bottlenecks, delays and inconsistencies. Users benefit in the short term, but the business suffers in the long term.
And how do major tech vendors solidify this sense of defensibility in their Power Users? With paid certifications.
Between certifications, training courses, and overall complexity many vendors’ interests are aligned more with the short-term gains of the user rather than the long-term benefit of the business and its employees.
So… Power Users are Bad?
No! They’re not!
I know it may seem like I have a vendetta against Power Users in this article but that can’t be further from the truth. What I’m trying to illustrate is that Power Users believe their defensibility comes from their proficiency with a particular tool, and (intentionally or not) major tech vendors play into this perception. However, the keen reader may have noticed that I was hinting at something: A Power User’s true defensibility comes from something much more powerful.
Does the Sword Make the Swordsman? A Power Users’ True Source of Defensibility
Does Ease of Use make people more replaceable? No. It lets you focus on what makes you truly irreplaceable. As an employee where should your value come from? Your ability to operate a complex tool, or your knowledge and years of experience?
I think that most people would answer the latter.
There’s something one of my advisors said to me that I will never, ever forget,
And both are a result of time.
What if you’re not as experienced as a Power User? Companies still need employees to operate the tools. And the faster you can get ramped up the sooner you can start adding value and the sooner you can start building real knowledge and experience.
Broad-sweeping changes due to disruptive technology are a fact of life, which means that if you tie your valuation as an employee to your ability to operate some expensive, complicated tool, then you’re running the risk of being replaced if an easier-to-use tool comes along. Or if the company hires someone else who can also operate that tool.
Despite what Artificial Intelligence Doomsayers may preach the one thing no tool will be able to replace is your knowledge and experience. Just because you know how to operate a complicated saw doesn’t mean you’ll know where to make the cut.
And therein lies an employee’s true defensibility.
I’m often asked if, to protect Power Users’ defensibility, we should gamify TypeSift to include features that only Power Users can “unlock.” In our opinion this would hamper the software for everyone else.
Instead we choose again to believe that the rising tide lifts all ships equally. If every casual user in the business were elevated to Power User, then every Power User becomes a Subject Matter Expert (SME). SMEs add value to the rest of the business by using their knowledge and experience to help others (in addition to doing their actual jobs). Any tool that makes it easier and more efficient for an SME to add value to the rest of the business not only makes that SME look like a Rockstar in everyone’s eyes, it allows everyone using the product to gain more value from each other.
This is the ethos behind TypeSift.
- It’s not in the interest of old, enterprise technology vendors to make their products easy to use because that would 1) Eat into revenues from training, and 2) Because they’d lose the support of Power Users.
- When making a technology selection, if the vendor states they are “easy to use” but are also offering expensive, multi-day training packages, ask yourself, “Are they really that easy to use?”
- If a technology is easy to use, why would you need to be certified on it?
- Looking at the consultants who use that tool, how big a portion of their work is providing coaching, consulting and guidance on business strategy vs. building work-product in the tool? If you’re hiring consultants (Power Users in their own right) just to build work-product it’s likely because you have a bottleneck.
- Power Users end up becoming bottlenecks for the company. I was a bottleneck at 3AM, and production would be halted if I couldn’t fix the problem. Empowering on-site support to better diagnose and solve problems effectively turned them into Power Users, freeing me up to focus on design challenges.
- As companies grow its natural to have a mix of Casual and Power Users. You’ll often have more Casual than Power Users. If you’re a Scaleup, invest early in making as many of your Casual Users into Power Users, something massive enterprises won’t be able to do as easily.