Set in stone — the night trolls of software

There are software systems that are notorious for being hated by everyone. Their users hate them. They are hated by the people who pay for them. They are hated by the people who feel their effect far outside their software realm. They are even hated by the people who make them.

We UX people love to hate them and with enthusiasm we will mock them and compete in who can find the most horrendous screen shot or user story. We’ll take our very limited view of the system, its users, it’s use and spread vitriol like a food journalist reviewing a particularly bad meal.

In many ways, the work of a critic is easy. We risk very little, yet enjoy a position over those who offer up their work and their selves to our judgment. We thrive on negative criticism, which is fun to write and to read.

Anton Ego (Ratatouille)

I will admit that I have had my fun with this. But recently I’ve started thinking how I can approach situations like this more usefully, for me and for everyone involved.

Because all of these horrendous crimes agains UX have been dragged out into the daylight before. The producers know about them, the users know about them, the purchasers know about them, all the stakeholders. Nevertheless these systems seem to be petrified like a troll caught in daylight. Shouting it louder and finding more poisonous ways to explain how bad these systems are isn’t fixing the problem. It does about as much good as showing up in the steam-room of a locomotive, scolding the conductor that they should be conducting a Japanese electric bullet train. It blatantly ignores the fact that the train is running full speed.

The criticism can be categorised into at least the following:

1. Limited functional view a.k.a. why can’t all systems be as easy to use as the Uber app? Ignoring the complexity of the system.
2. Limited understanding of the role of the software. Ignoring different needs by different user groups and other stakeholders.
3. Limited understanding of change management. Ignoring the difficulty in replacing a (admittedly terrible) system which requires changes in processes, training, even staffing or organisational structure
4. Limited understanding of operations. Ignoring the safety critical factors of many of these systems that cannot be risked, stopped or put on hold to make way for a new system.

Solving limited problems with no active users is easy. Keeping a system (or a train) running while you’re developing it is hard. And switching out parts of a locomotive that is hurtling down the tracks at breakneck speed is neigh on impossible.

So these days two questions haunt me: How do these systems “happen”? And more importantly, how do we stop them from happening?

Companies have tried to solve this with side-by-side development of two versions (old vs new) which requires a big-bang switch for their customers. Or they have ignored the problem until they have effectively petrified themselves to death and new technology/services takes over. Both of these solutions risk bankrupting the company.

I would like to make the case that the following factors are key, both in preventing this from happening and also to loosen up the petrified joints of an established system:

1. Team
2. Vision
3. Leadership

I will discuss them in turn.

1. Team

People who love working in an ever-changing environment and experimenting with new technology or experiences excites them are very different people from those who value stability, familiarity and the repetitiveness of nurturing and slowly building on something that is established.

Startup-people will tell you that as soon as a product is established there will be a shift in the team. It’s often a very difficult time for the company, not only growing but also losing valuable knowledge as the entrepreneurial types who created the product move on and new people with more interest in running the product come in.

This is when you’ll see the first signs of stiffness setting in. Mostly they are welcomed, the “cowboy” mentality of the early startup phase doesn’t apply when lots of users rely on your system for their work. But this is a moment to watch out for and this is where vision comes in.

2. Vision

When a system becomes established with many users relying on it, the primary focus of the team becomes running the system and the company. Building on the product that was created, strengthening the value proposition and the tech.

What I have seen repeatedly happen at this point is the company struggling to survive on the revenue they are making from the product (moving from pre- to post-revenue changes the way we think about funding a product). The team hones in on how to serve the customers better and increase revenue. Product managers get inundated with a deluge requests and feedback. Not necessarily a bad thing and some might say a luxury problem but inherently reactionary instead of visionary. At this point it is very easy to lose sight of the long term.

Losing sight of the long term means that technical debt accumulates, special requests (though not strictly in line with the product’s core value) are implemented and the vision gets replaced by operations.

The antidote to this having a strong vision for the product, company and team. Why are we developing this product? Why are we building this company? What are our core values? What is our core business? Who is our audience? What are their goals? How is their environment changing?

This means that sometimes the team will be tasked with working on things that are not immediately billable. It might be to clear up technical debt or prepare to move to a more modern technology. Or to re-implement features that are already in the system using a new approach or tech. Or deciding to not implement a feature that is not in line with the vision of the product even though that will disappoint some customers.

Decision like these cannot be taken with out a strong vision that the company and most importantly, the board believe in. Which brings us to leadership.

3. Leadership

It takes strong leadership to create, maintain and follow through on a strong vision. One that looks beyond this quarter, this set of customers, this technology stack, to a grander future. Not only for themselves but for their target audience.

With that kind of leadership the company can set up the right environment for both entrepreneurial thinking and operational thinking team members so that they maintain the vision and incorporate some discipline.

With that kind of leadership it is possible to set a bold vision, trusting that the company has a strong enough backbone to defend it because they realise that trying to be everything for everybody soon enough means that you are nothing to nobody. And that slower growth is more sustainable.

This sort of leadership is the key for stopping these systems from happening.

What I find is that UX directors, product managers and other middle management is often put into place to fix the issue of the night-troll without the vision and proper backup. They might be given full control of the team but have limited control of the vision and no control of leadership. They are given a task to solve without the proper means and are effectively set up to fail, at the risk of the mental and physical health.

I hope you’ll recognise the signs before this happens to you.

And I hope that more leaders take a step back and start leading towards a bigger, grander picture than the next quarterly settlements of accounts. For the sake of their company, their staff and their users.