Carrot Centralization

One of the joys of my job is I get to talk to hundreds of people about their technology problems. Some hire us; many don’t. But it’s extremely interesting to see how people from around the world see software and what problems they want to solve.

Not long ago, one of our more enlightened clients, part of a big organization, said to us, “Look—let people ask for workflow after you launch this.”

Then the other day, a potential client in a global organization explained their goals this way: “We could build something to automate this, or we could just talk about it on Slack when we need to. The second option is going to work better for us.”

A lot of people come to us with a list of systems that all do roughly the same thing. Postlight, they ask, can’t we just have one system instead of 15? Can’t we just monitor all our data and analytics with one dashboard and enter data using one API? Can you make it easier to upload a video? It takes a half hour. (One client once actually made a video of someone uploading a video, and sped it up 10x, to prove to management how much time was being wasted.)

Of course you can, we say. There’s no technical reason why not. And lots of cost savings if you do! And we’ve talked about this subject on our podcast. It comes up a lot.

Okay, all are agreed, we’re going to centralize and consolidate, and we start discussing a plan. And over time, people start to express their deepest hopes and thoughts. Can we, they hesitantly ask, you know, make it so that the right people can approve everything before it goes live? We have a complicated organization, so we’re going to need a complicated workflow…

It sounds very sensible. It sounds like the right thing to do. Let the software system cut risk and promote good behavior. Good for the organization, good for employees, good for everyone. We can put some rules in place and cut all kinds of risk.

Except! Now someone wants to add a new employee to the HR system. Except now, they need 12 pieces of documentation and all of them need to be added at once, and some of those documents have to be approved. Once they’re in the approval process they’re locked, so when updates arrive to fix corrections, an admin needs to remove them from the approval queue. Some of them need to be stored securely. Finally, there’s administrative and legal approval, and integration with the payroll system.

The problem is, employees don’t submit bug reports. They ask a question, their problem is added to a queue, and then it fades away. Responses are rare. No one believes their software will be improved. They learn to be helpless. When the system tells them they’re locked out, they believe it, and they wander off to get coffee. And frankly, that’s on us, the software people, but I guess it’s good for the coffee people. The software industry is bad for people but it’s been great for the coffee industry.

This all starts when you start factoring humans out, trying to cut out places where they can make mistakes. Again, it feels right. But that’s because the people who make decisions about software platforms are professional managers with budgetary control. And that means they are risk managers. So they don’t ask you to build a great toolkit for people to be more productive. They ask you to cut risk. It’s their job. They have meetings and tell everyone that the software COULD, SHOULD, and MUST behave in such a way that no one can ever make a mistake, ever.

What you need to do, and we’ve found this over and over, is sit down with the people who are using the systems today and get them to show you how they work. It’s not always the best experience (which is fine, because it’s our job). A lot of times they need to just get angry and vent for a few hours about how no one has listened to them in the past. A lot of times they believe you won’t be able to help them and it’s pointless.

That’s okay. There’s no way to prove otherwise. Just listen. They’ll show you that it takes an hour to upload a file, that 90% of their work gets paused at one phase, that if someone is on vacation all approvals stop, that the analytics don’t make sense, and you’ll see the parts of the system they don’t touch, too.

Then act on what they tell you. Build something really little that helps them. Just one little tool that lets them do things more quickly. One red button to unlock the block. People might wonder what the hell you’re doing. Managers have heard this person complain so often that they’ve tuned them out. They blame the messenger.

Go back and show it to them. You’ve never seen a faster turnaround than when that person gets just a little love. They’ll start testing more things. You can train them to submit bugs. They’ll get invested. And critically, they’ll start showing other people. They go out for drinks with their peers and they’ll say, “Actually, I swear to God, I think they might finally try to fix it.”

Here’s the hard part: That doesn’t mean you can stop managing up. You can’t just walk the floor and be the shop steward of technical needs. The managers have the budgets, the goals, and the magic pen that signs the checks. You need to build their system, too. You have to build a system that works for the people who use it daily, and for the people who like dashboards, too.

It’s tricky because we’re an industry of disciplines. Should you do more research and understand your user? Or build a live prototype that works on mobile? Should you launch something on day one? Or day 30? Mobile-first or build the API first? The answer is: It depends! There’s no one answer, no magic solution, and anyone who tells you there is has something to sell you.

But it’s really worthwhile, as you’re deciding what to build and how to build it, to ask yourself: Is this going to be a carrot or a stick? Are we centralizing and consolidating so we can control things, or are we centralizing so that we can make things easier and more efficient?

A big organization is going to hand down technology policy. But technology change always comes from the bottom up.

You know how Linux showed up? Someone would set up a spare server in the closet to chew through some log files. Easier than getting it provisioned and getting another Oracle license.

Slack? Free tier. Suddenly started to work better at work.

GitHub? Started with a decentralized version control system and added some services around it. With a free tier, too.

The thing is, carrots work. Sticks don’t. Computers can’t make people do things. They have to want to do things. As a product studio, we try to play it down the middle: To listen to the people doing the work as well as the folks at higher altitudes, and fit it into the larger goals of the organization.

That’s what I love hearing from potential clients, people who realize that some of the best long-term value they’ll get out of our firm is by paying us to not build things. Let them ask for workflow, but in the meantime, people might find that they can get a lot more done without it. Maybe instead of trying to automate every process so that it all works and looks the same, assume that people just want good tools to do a good job, and help them do it faster so they can go out and have a beer with their friends. You might think our job is to build software but just as often it’s to help you avoid building the wrong software. And when you build, build carrots.

Paul Ford is the CEO of Postlight. Send him an email: paul.ford@postlight.com.