Marc Wilson: "Be part of the process"

Appian’s founding is different to many other software companies. We started the company in 1999. It was a very different age.

At the time, people thought we would never have a recession again because of this thing called the “internet”, all you had to do was decide what product you wanted to sell online, go public in six months and you would be set for life.

That really was the mentality at the time.

Of the four of us who started Appian, I was the only one who wasn’t working in the technology space. We were reaching the point in our careers where we were ready to move on to the next thing. Initially, I was planning on going off to business school. But we wanted to see if we could start something.

When you were of that age in the United States in 1999, you could start a company in the technology field and if it didn’t work you could just go out and find a new job a week later, and all would be well with the world.

When we started, we knew we would be a software company, but we didn’t know what software we would write. We didn’t have a business plan, our sole company expense was business cards, and we financed the company by not taking a paycheck for the first four months.

We decided that we would do consulting work in technology, primarily around partners such as MicroStrategy, a business intelligence firm which is still running today. We spent a year doing consulting work around them. We were successful in getting projects and adding people to the team. We built up a decent consulting arm.

In 2001, we began to dabble in various kinds of products and ideas, and the first real product we built was because some of the other companies we were talking to stated that there was a need.

It was a portal, and this was before the way we know portals today. We built it on top of a then-dominant java application server for a client that needed a portal product to compete in the US Federal market. We were able to successfully take it to two other significant customers.

The first product we sold was portal technology to a small group in the US army. It was targeted for about ten thousand people, a small fraction of the US army. 9/11 happened just after we started building the app. Shortly after, the secretary of the army looked at what we were building and stated that he wanted to make the product available for the entire army.

Suddenly, we were building a portal for two and a half million people as our first software project. Most companies like to build up to their largest project – ours was our first.

It gave us a very good appreciation for complexity and feature functionality at scale. To every other system that we have had a look at since we have being saying “Ok, you have ten thousand people using your software at the same time. Come back when you have two hundred thousand.”

We learned many lessons very early and one of those was that we wanted to be in an industry that would be very hard to commoditize, did not have a clear future, and had a level of complexity and nuance that would cater to the type of mentality we had.

The portal industry is very much a commodity nowadays.

Ultimately, we decided to go in the business process management (BPM) space. We did a big survey to decide which direction we wanted to go.

We took to the BPM space the technologies we had built for the army such as the portal, the document management technologies and the high end internal security applications. This gave us something very different to the other BPM vendors at the time.

Most of the other vendors had grown up at the time of the integration space. They grew up with the notion that everything they were doing with BPM was about maximizing straight through processing – trying to cut people out of processes to make them quicker.

For us, with our knowledge management and portal background coming into the space it was instead a question of how we could get more people involved, and more informed about what is going on. And thematically this has continued in our software park fifteen years following our inclusion in the BPM space.

Absolutely. When we were beginning to break out of the federal space and we were starting in the BPM space, one of our slogans was “Be part of the process”. 

To this day, we feel that the biggest problem with technology is friction. It tends to fail because it creates too much friction between what it is intended to do and what the user needs to do. And that is what causes systems to break down. 

Most technology projects don’t fail because the technology itself is bad, but because of how it is presented or what is intended is too detached from what the user actually needs accomplished. 

At Appian, one of the mantras our teams have is that we need our software to be a joy to use. This is where our investments go into. 

Another phrase that we have is this one: Is it walk-up usable? Can you just sit anyone in front of a screen and without have to train that person, it makes logical sense to them what they can do? 

Again, this comes from our heritage: we are here to help people move forward.

Be part of the process.

 We have had different growth spurts over different points in time. We hit about two hundred people in 2005. We slowed down over the next five years as we dealt with a big global recession. Coming out of that in 2012, we had 90% percent of our revenue in the US public sector. 

Since really getting our feet underneath us in the commercial sector, this has now gone down to 13%-14%. And this not because our public sector has gone smaller, it is because everything else has gotten bigger. 

Today, we are about 1100 people. We went public two years ago. We are consistently returning 30% plus quarter after quarter of customer subscription growth, which is the real metric we are focused on. 

This is the growth trajectory we want to be on. 

What we haven’t done as a company historically nor post-IPO is to get a lot of money, grow exponentially in a short period of time and hope to hold on to our culture, which is what many other companies have done. We have been much more conservative in terms of how we go about doing things. 

We want to preserve our culture. A 30%, 40% or 50% growth is a pretty good, and with this rate you can maintain control over how you want to develop your company.

Today, I think the market is confused. 

I think many of the phrases which come out of the press do not help in any way, and this is probably true for many technologies. 

As soon as a phrase becomes popular in technologies, every technology company raises their hand and says “we do that too!” 

At different ends of the spectrum you have the out of the box solutions, which are supposed to be faster, versus custom code which gives you exactly what you want, at a cost, but is really hard to maintain. 

What we are pushing is much more of a third way of doing things. Something which I would like to call the best of both worlds. 

What we have seen in the recent past is point solutions cloaked in the cloud which has in reality been a way of casting old approaches in a new light. Because they are in a cloud, point solutions think they are doing something special, but what has been the result of that? 

Companies that went out and bought a slew of different point solutions for each problem ended up with the exact problem they were trying to avoid. 

They have ended up with fifty different silos for fifty different problems, but in the cloud. 

What needs to be solved in the future? There needs to be a lot of silo busting. 

I think this has really been a realisation of late, and this is where our technology has tremendous power. 

The best of breed approaches which consists of mapping individual solutions to individual problems has created a much bigger problem and that is silo systems which don’t allow individuals to operate. 

Coupled with that is that we have seen a shift in outlook from the customer prospect base. It used to be focused on cost-cutting in this technology space and the emphasis has now shifted to customer satisfaction. 

Customer satisfaction isn’t just direct interaction with the customer, it involves changing your middle office and back office to ensure that your front office is getting the right answer in an hour rather than in two weeks. Software purchasing to improve customer satisfaction rather than hardline cost-cutting no longer requires justification.

There needs to be a lot of silo busting

Low code is one of those areas that has contributed to the confusion problem in the market. 

There are different facets of low code. 

The citizen developer is a very exciting concept but is only feasible in a world that has some control around it. It is not very shocking to say that most people in an office have themselves at one point or another been a citizen developer using one the top tools available such as Excel. 

What do you want to do with these Excel numbers? That is a business user deciding how they are going to build their application for it to make sense in the business world. 

What has resulted from that is that everyone has their different spreadsheet to do things. There is no uniformity, no ability to learn from each other. Half of the time is spent trying to figure out if you have the most up to date version of the Excel spreadsheet or go hunting for it. 

My concern is that without the presence of controls, the concept of using low code tools to empower the citizen developer can have these consequences. 

We have seen in our client base successful examples of citizen developers. Those are people in the business side who had some acumen technology, were trainable, were mentored, and had a good structure in place. 

Those were also organisations that had begun to teach scrum and agile methodologies or similar approaches to get people thinking.  So I think it is possible, but that the ability to do it effectively is still in an immature state. 

Rather than thinking of it in the way people usually do and jump to a citizen developer context, our use of the term low code refers to the feature side. It is something which is inherent to the way applications should be built across the board. 

Why are we coding things when we ought to be taking the time to think more deeply about what the application’s actual purpose is? Another term we employ is the concept of “decreasing the friction” between the idea and the application, and low code is intended to do that. How quickly are we able to get things done? 

That’s what low code is really for. It is not necessarily about increasing the population of people who can build, but about increasing the speed with which these people can build.

Decreasing the friction” between the idea and the application
 

We have watched some of the technology developments in this space. We do not have any specific partners in this space from a technology perspective. 

Quite frankly, the partnerships we have with this space are best defined by the consulting firms we are involved with. 

The technology which defines that space today could be described as hopeful. It is difficult to do what they are intending to do. The ability to analyze data and determine process has a lot of logical sense behind it when you are to be able to create algorithms by interpreting millions of different data points. 

This is further behind than machine learning, AI, or other many other aspects of the data science world but it suffers from some of the same problems that exist in that space today. 

You can separate AI and machine learning algorithms in two different buckets to begin with. There is a lot of effort that goes into data science. 

With it, you can look at a lot of data, analyse it using big data sets or however you want to do it and come up with an answer or a plan. That is next generation business intelligence statistical analysis. That’s great and it makes sense. 

The other avenue that these technologies want to go down is how they are going to affect the day to day, minute to minute flow of activity that goes through a business: Fraud detection at a better level, or real-time upselling activities. 

And the activities that are going following those sort of topics are tending to take place as some sort of science experiments. What they really need is to be pulled back into the organisation as operational elements of value. 

You want to be able to build a great algorithm which is going to be able to take inputs and give you what you want to do based on data streams in a way that positively affect your different processes. 

What we are finding is that we are an extraordinarily good platform for operationalizing exactly that kind of insight. 

One example we have seen for instance: How do you maximise the utility of maintenance crews for going and fixing broken wind turbines in the south west of the United States?

Now it will no longer be a question of simply identifying the broken ones that need fixing. 

The questions that need to be answered are: What is the park price of electricity in that market? Do we have others that we can fix the same day? What is the availability of the crew in this park versus that park? 

I think process mining will follow a similar path and aim to get the metrics and the viewpoint of what is going on to inform potential changes instantaneously. 

Yes. Building up to the release of the next Appian world, we have made many loud statements with many examples of the strong partnerships we have with Amazon, Microsoft, Google and so forth around the investments that they have made in all different kinds of AI and machine learning technologies. 

Those really are the platforms that are getting the investments allowing data scientists to go in there and leverage them. 

So the best thing we can do is to make it as seamless as possible to integrate with them. We have examples today where in the course of a single process we might be interacting with five or six different services from five or six different vendors. 

If you can make that part really easy, it allows the emphasis to really be placed on the tough stuff, that is the data science itself. 

And knowing that the results can be brought into applications quickly makes the investments that you make in data science all the more valuable for organisations. They can see the immediate upside. 

As soon as some work has been accomplished, they can immediately bring it into their procurement process, for instance, and give the company a better sense as to whether they are spending their money well or if improvements could be made. 

Knowing that the results can be brought into applications quickly makes the investments that you make in data science all the more valuable.

 Yes. We are seeing examples where machine learning, AI algorithms and Blockchain has become a vital piece of the system. 

We have seen examples from some of our pharmaceutical clients where they are interested in using Blockchain to track medical devices. 

They want to leverage AI and machine learning algorithms to determine where the biggest risk factors are so that they might get a different treatment in a case management process as it moves along. Many factors go into this: the device itself, the geography we are talking about, the time of the year. 

All these technologies, IOT, RPA, IA and machine learning have come after another over the course of the last several years and we will reap the real benefits when they all come together.

All these technologies [...] will reap the real benefits when they all come together.

The technologies that have become increasingly interesting to me are those that are helping solve some of these underlying data issues that are out there. 

Quick, wrapper-like APIs which breathe new life into old systems I find simply awesome. 

One of the biggest problems with integration is that the inhibitors are increasingly not technical, they are political. 

And if you beat back that political wall by just saying that this is easy,  then there, it’s done. 

There has been much promise and very little examples of what AI and machine learning have been able to deliver so far, but that stuff is coming for real. It is only a matter of time. And that is what I’m most excited about, what’s coming next.

A lot of people have been historically fearful of process automation, or fearful of RPA for the same reasons: “Will there be any work left for humans to do?” 

What we have found is that most of the work that we have replaced has been of the repetitive, boring, mundane and in many cases ill-informed type. 

We have got many transformation projects that have been successful in our organisations, and while they often have the opportunity to slash resources as a result of some of those initiatives, in almost every single case they have ended up repurposing their people. 

They have found that they can get more out of them and they became real assets as opposed to just tools. 

I believe it has opened up many new paths and ideas for organisations to go about doing things. If they don’t need someone sweating for four hours over something which can now be done in two minutes, that doesn’t mean that person has to leave, but instead that person can focus on something else that can be done. 

Again, we have seen more of the market shift from cost-cutting measures to customer satisfaction, with people deployed into different spaces. 

There are all sorts of things which can be done to help with these transitions, and there will be many organisations looking at this as a way to reduce payrolls. 

But every époque of history that has gone through these mass changes has shown us that it ends up in creating more jobs.

We have seen more of the market shift from cost-cutting measures to customer satisfaction.

Absolutely, without question. But understand that middle skilled people have been able to develop because they created what I would call a mental map. 

Of who to talk to, where to go to, which system to go to whenever they needed something done. And one of the failures of most organisations’ systems has been the inability to bring it all together. 

People need to be better trained and better put to use. So much of the complexity of the jobs we are talking about here were complex because the system couldn’t help them out. 

Wouldn’t it be much better if you, as a customer service employee answering phone calls had everything on a screen in front of them, instead of taking fifteen minutes and sounding like you didn’t know what you were doing, not because of your incompetence but because of the environment you are stuck in. 

The right training can empower people if it’s in front of them. That’s the optimistic view we have at Appian.

The right training can empower people.

I think it varies immensely company to company. 

A good way of seeing this is that so much of this comes down to corporate culture. 

We are a software company. They are things that we have grown up as, that have been advantageous to us, such as our way of recruiting and sustaining our workforce. 

I like to think that the things that define our core values aren’t unique to software firms. When you look back over the last 20 or 30 years, the turnover in companies that exist is amazing. 

It is hard to realise when you are just thinking in the mindset of a year, two years, but if you go back thirty years and look at the top 50 companies on any stock index, most of them don’t exist anymore. 

That turnover happens sometimes because companies make bad decisions but more often than not they disappear because their culture couldn’t keep up with the reality of the present. 

A company that wants to go forward is a company that is going to have to embrace these kinds of changes, and the companies that don’t will be almost certainly be replaced by the companies that do. 

That is what history has shown us. All these events, the industrial revolution, getting out of analog and into digital, the work process showing up, people predicted the workforce to be slashed in half but that has never happened.

We have gone down paths we couldn’t foresee, and I think that this will happen again. 

A company that wants to go forward is a company that is going to have to embrace these kinds of changes.

I’m going to talk about one which to me is one of the best examples of Appian’s use, and that’s the work we done with Aviva, the insurance firm. 

We have given them a comprehensive, complete view of their customers, and their customer satisfaction rating has shot up tremendously. Before they had 18 to 25 screens, their system relied on individuals under intense time pressure to get the right answer by going from one screen to another repeatedly, they had inconsistent data… 

Now they have one screen. They have everything in front of them. 

It is a unified experience. We have cut the time it takes to respond by 90%. It’s mind-boggling. I’ve received word from managers at Aviva that when people get transferred, they complain because they want to take the Appian system with them, because it changes their outlook and their job happiness. 

But what was also interesting about this was that the system was built on so many other systems of data. 

Usually, success happens when you find that company that has their act together on the data side so that people don’t have to worry about that. All you need to do is build a beautiful app on top and it will all work. 

But Aviva is a company that has built itself up over a hundred years, through multiple acquisitions, different combinations of companies, lots of duplicate systems, with lots of client and technical data. 

They have three systems that do this, fifteen systems that do that, some other screens that were brand new, and in order to ensure you are giving the best service to the customer you have to have it all. 

The integration story there became very interesting. Some of those integrations were easy. But they didn’t know what to do with the green screens until we actually used RPA. 

We screen-scraped the green screens in real time to populate Appian records so that no one knew what was going on underneath, they just saw the end result and complete data unification across the different systems. 

That was great, and over time they were able to tear down and consolidate some of the systems in the back whereas before they would have to wait and schedule a time during which they would have to pause the front process. 

Now they only have one interface, and what goes on in the background can be taken care of at its own speed. It was a great story. We saw the results and so did they.

Now they have one screen. They have everything in front of them.