How you can finally work with humans

An expert rant with four theses and an anecdote about successfully introducing game-changer technologies into established organizations

Today, AX Semantics is a pure-breed software company: We have this cutting edge AI thingy that solves a bleeding neck problem for companies that create content on a regular basis, we eat, sleep and ...breathe agile methods and if we do something, we  try our best to do it, then measure and learn, and decisions are based on data. Sounds like agile paradise, but it wasn’t always like that. In fact, when we started out, we your typical content agency by the book. We went through a lot of learning and suffering on our way form being a people-business to being a scaleable tech company. And I want to share four key observations that I made during that process. But let’s start with an annecdote:

It started with an ending

So there we were. An agency with a solid customer base and a pool of brilliant young talents. We sold our (wo)manpower by the hour, did conception, projects and a lot of creative work, and charged insane amounts for our services. It was like a season of mad men with better clothes and music. But all good things must come to an end, it seems. Our personal endling arrived around 2009 in the shape of authoring marketplaces, who would broker your text jobs to a pool of authors, and use a nebulous rating algorithm to manage their payment. Maybe they also beat them with sticks while negotiating prices - this is a neoliberal market after all - but at the end of the day, they were much more scaleable than us, and cheaper by a factor of 100. So we had to change something and we decided to try to become even cheaper and even more scaleable by using software to automate the copywriting process as a whole.

Free your mind - and the rest will follow

Basically,o this whole thing started out as an experiment to see if such a thing as automated text generation was possible at all, and before we knew, we made more revenue with text automation projects than we could get out of our established fields of business. So after a while, the elephant in the room was what we should do with the new and fast-growing business area. After a lot of discussions we decided to dedicate the whole organization to it. And that sent us on a rough ride. We had to change the way we worked, obviously, but also our company culture and the way we thought about our processes and products. This was at times a very painful process, and we had our fair share of setbacks, but in the end, we had turned the company inside out and become a functioning software provider. 

So at that point, you would think that we had solved it once and for all. You can probably imagine how surprised we were when we talked to our customers and found that they were in for the very same process of transformation if they wanted to include our AI into their daily business. Working through the same transformation over and over again, some observations kept recurring. And those, I would like to share with you in the form of four theses for introducing digital innovations into an established organization.

1. Change happens on many different levels

So the first thing I observed when I talked to my customer was that they used to have these big change missions. Someone in the top tier of their management would go to a seminar, come back with sparkling eyes and say: “We will to the digitalization now”. The impact of these projects would tend to be short-lived and not exactly life-altering for the company. You just can’t do a complex transformation in a top-down project. And here is why: Change happens on many different levels in a company and a good deal of them are bottom up.

Culture

Almost the first thing I realized when I walked into an editorial office with my shiny new AI thingy was, that people were treating it like any other asset that they would buy. They asked, when exactly it would be finished and argued with deadlines, word prices and down-to-the-cent project plans. They treated it like it was just complicated - i.e. soleable by effort - and not complex, as it was. Customers needed to drop the mindset that a disruptive project could be anticipated and planned on a micro level. They had to learn that complex problems are solved by starting early and working in continuous, incremental adjustment.

Another problem was hierarchic, taylorist decision-making and the error culture that comes with it. Nobody needs an authoritarian boss who starts playing the blame-game once a target moves or an experiment fails. You need to create an environment in which you can try stuff out, and, most importantly, fail without losing your face. If you adopt a complex technology, for which you will need to find out where it fits, how you have to embed it and who will be best suited for using it, you will have to rely on things to emerge and be sensitive to that. And you will take a lot of wrong turns and make a lot of false assumptions. And once things start falling into place, you need to be flexible enough to change course and not cling to a long outdated project spec sheet. That’s nothing bad. That is just how change works.

Process

So once people in an organization have started tolerating continuous delivery, moving targets and emergence, they are challenged to find methods to work with them. And this is often the next issue in established organizations: Their processes are good for buying projects and managed services, but not so fit for the challenges and pitfalls of agile delivery. Often enough, I heard managers say things like: “We are totally agile here. But my boss wants this to go live on September 3rd.” And even if you agree on going MVP first and then deliver continuously, sooner or later someone will come up with a devastating “so when’s it gonna be finished”? 

Let me clarify something here: These people are not stupid. They usually just don’t trust agile methods to fit the needs of their stakeholders. So the new processes basically need to provide them with transparence and tangibility. Even if there is no clear spec sheet or final target any more, stakeholders need the reassuring feeling that things are moving in the right direction and that there is measurable progress. And second, they need the confidence that once something needs adjustment, they will be able to actually control and readjust the process. So keeping things short-cycle and relying on adjustment rituals like standups and Kanban boards may seem like voodoo to some, but those things help a great deal in keeping a process touchable and transparent.
 

Product

You have probably guessed it already - the next thing I’m going to say is: “Do, measure, learn”. I am a strong believer in lean and experimental projects, because seriously, you can’t predict the future, and your management can’t see the future either. Even if they seem to rely on that assumption when planning projects sometimes. But agility is not about shrugging your sholders and accepting whatever happens. For a lean process, you need clear experimental setups and very precise and narrow hypotheses, and nothing will ever work out properly if you don’t have enough data. In our case, data translates to users and usage. So for example, it is crucial to come out with an MVP and confront your tech with actual real-live users as early as possible. But also, you should not be afraid to scale and let a broad number of users test and stress your product. We went really intense about this, up to the point when we made our license plans radically cheap, just in order to drive up the number of cases we could observe and learn from. The discussions about this were fierce, but we never regrettet this step a bit.

2. Formality doesn’t matter

Another question that almost every customer asked me in the early days was: “This is AI and I am just an editor/manager/political scientist - will I be able to handle your software at all?” People seem to be afraid that they would have to become developers to use the software successfully. And in the beginning, that was actually more of a fact than a fear. But over time, I observed a trend which took the sharpness out of this discussion: The difficult formal parts tend to go away! What remains is the actual task. So if a software feels hacky and all command-line in the beginning, it usually gets UI and UX features over time, that make it easy to use and take all the difficult, distracting formal bits away from the user. Let me show you what I mean with the example of our own software.

So here is AX Semantics, probably in 2010. The core was basically the same, except for the fact that it was still written in one of the world’s most hated programming language, VBA. The configuration was pretty stone-aged as well: People hacked parameters into an excel sheet. About six people in the world knew how to use that thing, and all of them were developers at AX Semantics. Well, more like the developers of AX Semantics who had been with us for more than a year, because that’s how long it took to get familiar with that monstrum. If customers wanted something done or changed,  they have to ask us and hope for our developers to understand their needs correctly.

Fast-forward to about 2014: We had gotten pretty weary of arguing with our customers by then and had - in an outburst of despair - decided to bolt an abstraction layer on top of our NLG-engine. So we intruduced the script language ATML. Customers could now learn from our devs how to configure the NLG AI themselves. All it would take was two weeks of training, and they would most definitely hate us afterwards because it was painstakingly complex. But they could do it themselves, and about 50 people could teach our AI now.

Kids, this is what solid venture capital looks like. In 2015 we decided to raise and invest bigtime into the usability of our software. We released an e-learning platform, we developed tons of UI code, and out came something we called NLG cloud-cockpit. The ATML code was still there. The core still had a pretty strong smell of VBA to it, but several hundred users could learn within two days or so, how to make this thing write and talk and imitate their writing style. 

And now look at this bad-boy. This is our current UI, which we call NEXT.ax. It is not relying on customer code at all any more. Instead, it uses another AI component to predict what a customer would code, based on the naked text input.

And this is what I mean. All the formalities - writing code, configuring rules and such, have been abstracted away from our users, so that the only thing left for them to deal with is how to write a good story. 

3. Don’t replace old business - do new stuff!

And then there was that one question that would send me flying off the handle in customer meetings for good. If you ever want me to yell at you, just say something like: “our soccer content is like totally emotional and like sooo complex. I don’t know if a machine can ever do it in the same quality.”

So here’s a fun fact, I liked to throw in, just to break off the argument. I ask my customers whether they know that guy. That Italian tractor manufacturer. What was his name again? Must be Ferrucio something. Yeah right, Ferrucio Lamborghini. So do you think that the tractor manufacturer Ferrucio Lamborghini really built his first sports car to plow faster?

It’s always a fun anecdote, but at it’s core it has a serious principle: You don’t use disruptive innovation to free yourself of your operative boundaries, solve your resource scarcety problem for you and give you supersmart analytics and real-time action, and then use all that just to do the same lame-ass stuff that you were doing before. Where’s the point in that? Saving a cent or two per text? Seriously, grow up, folks!

You use disruptive innovation to disrupt what you are doing. That’s the whole point in disruption. And that translates to doing freaky new stuff. Which means rethinking and questioning the oh so sacred traditions and ways that your organizations has amassed over time. What you want is probably not another tractor. Besides that, all the tractor-makers in your company will feel a lot less disposable and more respected if you let the new system do new stuff, and not something that exactly matches their job description. People are a lot les sceptical towards a innovation and also judge it a bit fairer if they don’t perceive it as a threat to their ability to pay rent. And if you give them that feeling of security, you won’t have to go into the infight with with employees blocking off or even sabotageing the disruptive project. Trust me on that one, I’ve seen this reaction numerous times, and as a digital innovations person, you really don’t want to deal with internal flak.

Our customers usually give in to my cursing and begging and flattery sooner or later and eventually end up exploring new potentials instead of reproducing old business. Which are often things like real-time publishing strategies, excessive multi-language content (did I mention that our AI speaks 110 languages) and individualization.  

A team who achieved real mastery in this game of self-disruption is certainly the digital editorial team at the Stuttgarter Zeitung - our regional Newspaper. Not only did they automate a sensitive topic like hyperlocal air pollution reports for the region and manage to be the first newspaper to win a local journalism award with AI generated content. Oh no, they didn’t stop there. They also actually teamed up with some local hacktivists and designed an air pollution sensor, and then they taught concerned citizens how to build these sensors themselves. So they ended up having close to a thousand (!!) of such sensors in the Stuttgart region and thus created a very unique and immensely valuable data asset which noone else has. I would not be surprised if this would provide them with a B2B2C business model in which they acted as a content publisher AND data hub in the end. 

4. Stop buying projects!

There is one last observation I would like to share with you, because it proved to be a real hinderance in people accepting innovative technologies. The ready-to-go one-stop-shop project. When we started out, customers literally expected us to plan a project with them out of the hollow air, with timelines, efforts, milestones and the whole shebang, while they barely knew what kind of tech they were even ordering here, let alone what they would have to bring th the table to make it work. If you have guessed that this didn’t go particularly well in some cases, then you are very right. It went horribly wrong, because we cannot guess and fulfill an expectation that has not even emerged yet. Especially when you introduce an entirely new and unprecedented technology, it is very likely that some amount of finding and matchmaking will have to be done before you start to grasp what the final project will look like. And a classic project setup will just strangle that finding process to death. And boy, there were days when it felt to me like my customers had just smoked some banana peels before sitting down and tripping up the latest changes to the spec sheet. “Can you turn the algos around, so we can make data out of text?”, “I thought the software was able to come up with an initial story itself.” “Could you please turn the lever for longest cohesive subsequence to 11 in 1000?”. I felt like trapped in a Kafka novel sometimes.

This is not supposed to be another hollow rant against classic project planning. I think we all heard enough of these from foaming agility zealots in the last few years. And I am not blaming my customers for that behavior either, because it is just what they are used to - especially when they are from a corporate environment. I am blaming the process. The point I want to make is that with complex and new technology, you will have to involve and even qualify your customers, so they will be able to develop sensible expectations towards your products. Basically, when you sell an end-to-end project, you act like one of these helicopter parents driving your kids to the school gates every day. When you try to solve all of their problems for the kids, you deprive them of the chance to build their own skills. Even worse, you are not even giving them a chance to involve and build an in-depth understanding of what’s going on.

So we redesigned our go-to-project approach in order to help our customers forming and arguing realistic expectations towards the chances and limitations of our tech stack. And we did it by teaching them how to use our NLG platform. We said: Hey, we are not selling you a project if you are not willing to train at least one person on your side in AX Semantics. And the results were thrilling. Not a single banana peel was smoked after that change in process. And even if we still did all of the heavy lifting, customers were feeling much more confident with what they ordered, were more open to experiments (because they could do rollbacks and fixes by themselves) and most importantly, they planned sensible and successful projects in the first place, because the finally knew what they were working with.

Enough with the ranting though. I am curious for your feedback now. Did you ever find yourself in a similar situation? And how do you approach the introduction of game-changing technology into your organization? Leave a comment or tag a friend below.