Fin.com CEO Evan Cummack was invited to join Anthony Algmin for an insightful discussion about data leadership and scaling Fin's work insights platform. Their session focuses on the relationship between humans and technology, AI driven process improvement, and exploring how work management software can help CX leaders with performance measurement and coaching. A lightly edited version of their conversation is transcribed below, and the Data Leadership Lesson's Podcast can be listened to here, or viewed on YouTube.
- Evan explains that although Fin applies effortlessly to customer relations and workflow problems.
- Evan delves into Fin’s deployment strategy, explaining why a “targeted” approach using aggregate data as a background is more effective than working with multiple teams at once, and how excess individual data can be used to generate “post-facto” conclusions.
- Evan elaborates upon how Fin adapted to its clients’ needs, transitioning from an AI-enhanced personal assistant to a company in pursuit of browser-based analytics with broad implications for better understanding the necessary strategies for successful and efficient individual and system-wide technological interaction and behavior.
- Lastly, Evan offers observations that he has made from his position about the experiences necessary for someone to become a manager or CEO at a major technology startup.
Today we welcome Evan Cummack. Evan is the CEO of Fin - a company shaping the future of work. Fin Analytics is a cloud-based comprehensive measurement platform for operations that helps leaders drive efficiency and reduce operating expenditures through data-driven process improvements. Prior to Fin, Evan was a general manager at Twilio, the fastest growing SAS company in history by revenue.
Evan, can you please give us a little bit more of your career story personally, and how you ended up doing what you do now at Fin?
I'm from New Zealand originally. I came to Silicon Valley in 2011 with nothing more than a suitcase and a dream. I came out with the idea that I'd always wanted to work in the technology industry, always wanted to build software, and always wanted to be in Silicon Valley - even before I knew where that was geographically.
Within a few weeks of arriving in San Francisco, I had talked to some of the companies that I had been admiring as they grew - companies like Heroku, and Dropbox, and Twilio, and ended up with a few job offers. I chose Twilio based on the product itself. I'd been playing with the product and I just thought it was incredible and magical. I started there at the same time as a couple of other folks, and we essentially started the enterprise sales team all in one go. I started the sales engineering team and built that team out over the course of about five years.
Twilio started to become a very serious, large company and had high PO prospects, and it kind of sunk into me that whilst this was very fun and the growth was amazing, I had come to Silicon Valley to build product and build software. Thus, I took a little bit of a detour, went back into product management, built various products at Twilio over a period of five years, and ended up as the general manager of a group there which was called IOT and wireless. Basically, we were targeting cellular connectivity device makers. The most obvious example of success, I think that we had in that time was your lime scooters - all the lime scooters around the world were using our conductivity infrastructure. We also had other customers building wearables and other types of connected devices.
What led you to moving on from Twilio and ending up at Fin, a whole new startup?
I was approached by a venture capital firm who was hiring for a CEO role for this company, Fin. Fin is an interesting company for a number of reasons - the technology is interesting, the vision is interesting, and the company background is also super interesting, and that might be a good place to start actually describing what Finn is.
Fin was started by two consumer technology folks who had really great backgrounds. Sam Lessin was the first product leader at Facebook, and Andrew Kortina was a co-founder of Venmo. These two guys got together and created a consumer startup called Fin Assistant - an AI-enhanced personal assistant product. They ended up with hundreds of agents working for them - and these are two people who come from consumer software, where everything is metrics-based, everything is based on optimizations and AB testing and small tweaks, but all of that requires you to have good data, and good analytics - and what they found is they had all these hundreds of human beings that were completing tasks for their customers and really no idea what anyone was actually doing.
They built an in-house tool that was capable of capturing human interaction occurring inside a web browser, and this is relevant now because essentially all the tools we use to get our work done all day, every day, are in the browser. The tool takes meta-data and data about those human interactions, sends it to the cloud, and then in the cloud, we apply these kinds of big data analysis techniques. We do that so that we can surface obvious insights about how certain patterns in human behavior and human interaction with software result in different business outcomes, different cost outcomes, or just different outcomes. It's really about taking these millions of hours of human software interaction that happen inside businesses every single day, quantifying it, and then allowing us to query that as data.
Is your target market the phone support for customer organizations, or is it something beyond that?
That's a very good way of phrasing that question for a particular reason, which is that a lot of our early customer adoption has been customer experience teams and oftentimes it's not phone support as such. It might be chat support, or email, or even inside sales, but you're correct - early adoption of the product has skewed toward teams that are interfacing with customers. However, we see customers now in places like accounts receivable, accounts payable, data entry - anywhere where there's a relatively time-consuming human task.
I think that there's a reason that we see that early on, but that's certainly not our vision - our vision extends quite far beyond that into much more creative-knowledge work. I was saying to one of my colleagues a few minutes ago that I'd love to know how my behaviors throughout the day compare to that of successful or the most successful series of companies’ CEOs - could some system tell me “you don't spend enough time with customers”, or whatever it is? Are there ways to draw data about very highly creative roles and compare those against benchmarks and other things? I think that that's an interesting path for us.
How transferable between these different slices of functionality is the AI?
In cases where you start with an outcome and then you want to figure out what series of actions were more or less likely to arrive at that outcome, then you want to use machine learning models. You don't really need AI to go from, “here's the starting state, here’s the end state, show me all of the journeys that happened in between and which of those journeys was the optimal journey and show me the outliers as well”. Once you start looking at the outliers, then you can zoom in on those and see very interesting things going on - whether people are consulting the knowledgebase too often, or whether it relates to some technological problem, such as a page freezing all the time, or people having to fill in the same form three different times because of the validation rules.
When we start talking about this pattern of technological adoption, people's minds immediately jump to this idea of managing humans, making them more efficient, and maybe it feels a little punitive. The real value, though, is in understanding process, and a lot of our customers won't even configure the system in such a way where they can zoom into individuals - they just want to know the best way to do something across an entire team. We think about the process as being at the center, with various actors who are involved in executing a process - there's humans, there's technology, and then there's the people who actually define how the process should be carried out. We want to help you to understand how all those things come together. First of all, to be able to actually know what's going on, which is surprisingly a challenge for a lot of companies – well, actually maybe not so surprising at this point in time – and then to figure out like how you might want to change those things.
First, when you're working with a new customer, do you bring Fin in and address issues across the board, or do you do like to start with a bit more of a targeted area and go from there?
Second, are you able to identify patterns and adapt them to new clients, or do you have to keep that totally separate per client?
We do allow customers to opt in or opt out of providing pre-aggregated pre-processed outcome data to industry benchmarks. For example, you could take something that's very preprocessed, like meantime to resolution or first touch resolution or some of these statistics that require a lot of aggregation to go into them. Just knowing the number doesn't tell you a lot, but we can show you or allow you to opt in to see that against a benchmark from an industry.
To your first question - when we go into a new client, the tool will do quite a bit out of the box. We do need to understand a few basic things like the structure of your team and those sort of start and end points as it relates to different units of work. Once we understand that we can start showing you some pretty interesting data. As the customer, you have the ability to slice and dice how you see the data as well - it's not necessarily all completely preprocessed into reports. You can sort of post-facto generate new things that you didn't know you wanted to know about.
We did try and work on a team-by-team basis. There's not a lot of incremental value that comes from deploying with two teams simultaneously if they're doing very different work. There's value for both teams, but the additional value of doing them together is not super multiplying. However, within one team, there's a lot of value in deploying to every single person. By looking at every piece of work that's done, they'll figure out where those outliers are and what's causing them. So one team at a time is a pretty common pattern for us, but we do like to be across every seat just so we can get that big, full picture of the data.
From a technical stack perspective, is Fin fundamentally a software as a service? Talk to me a little bit about that technology stack that you're working with and what it looks like from an integration perspective on the client side.
On the client side it's a browser extension and the reason for that is, if you think about a lot of popular analytics products - Google Analytics, Heap analytics, Mixpanel - these are kind of like product analytics. The idea is “I'm the one building the product, and I want to know how all these various users are using my product”. Fin is sort of flipped on its head from that - it's “these are all my users; they all work for me. They're all employed by me or we’re all a part of the same team and they're using a whole bunch of different products that I don't actually control. They're using Salesforce and Zendesk and Google Docs and Slack and all of these products that I didn't build myself”. By integrating with the browser, we can understand all the interactions that are happening throughout the day and the browser integration is fairly lightweight in the sense that the analysis logic is not, for the most part, happening in the browser. The browser understands various rules as to when it should be turned on or turned off. We allow the user to turn it on and off as well. It's essentially site configuration data. Other than that, it doesn't really do a lot. It passes data to the cloud where the intelligence lives.
In exceptional cases, and depending on what the customer is looking for, we can collect some very sensitive data. For example, we do have the ability to record the screen if that's something that you want to do. You can turn that on and off conditionally based on what's going on - maybe you're trying to debug a software issue that's just very hard to find and so you want to turn that video recording on in certain conditions. When we do that, we have different options as to where that data is stored. You can store that data on premises if you like. We essentially ask the customer for an Amazon S3 bucket, but that could well just be an Amazon S3 bucket-compatible storage system that you run somewhere. We do understand that some of that data is of a certain level of sensitivity that even if we're following bulletproof security practices, folks may wish to keep that under their own control.
So you’re saying that instead of going and creating independent API integrations to every interface that the client has, you are pulling from the browser. I assume that you have to do some custom work for different kinds of applications that they're using - if they’re using Salesforce in one place, or if they're using some sort of homegrown tool elsewhere - but as long as it's coming through a webpage, you are able to hook into that data judiciously and analyze it, with the ability to serve the results, through a web interface, to the people that are using the insights and analysis.
Correct. There's a slight nuance to that. Before this call, you were just mentioning that Google had changed the Google Meet interface, right? And so sometimes large vendors make changes to browser-based applications and we have ways that we look at that and try and get ahead of it. For some of the major applications that customers are using all the time like Salesforce and Zendesk, we do actually integrate against their APIs as well. There's certain data that we take from the API that's more reliable and arguably easier to get at than trying to get it through the browser.
The browser can do interesting things – it can tell you, for example, when pages don't load, or the fact that a certain page is loading very slowly and that's slowing your team down - these are things that you can't get anywhere else. There's one other major advantage, which is that most enterprises are now at a point where they are, if not one hundred percent on the browser, close to one hundred percent on the browser. Oftentimes they'll have some internal tool that they've built that's part of a workflow. So maybe a customer sends a ticket into Zendesk, requesting a refund. That's what kicks off the work - we understand what queue it was on, et cetera. Maybe the refund ends when a certain form is submitted in Netsuite let’s say, but maybe on the way there there's some in-house CRM or some in-house usage system that the agent is going to view. By working through the browser, it means that we can allow you as the developer of that application to very easily make sure that it is Fin-aware, or that Fin is aware of the application and how it works and what you might want to get from that application without doing a ton of custom API integration.
There have been a lot of companies that have tried to do things similar to this in the past with visual AI, sort of like watching the screen and trying to understand what's going on as someone uses the desktop application. It's just very hard, it's very brittle. With going to the browser, all of a sudden, every application has this declarative user interface that's capable of introspection, and so it makes building what we're building quite a bit more feasible.
This is really clever. Because you're watching it in real time you get the benefit of quantifying the time it takes for certain steps. Just because you're present and watching it the way you are, it really gives you a richness of available insights to that process that very few alternatives would have.
You basically have the same field of vision as the user. For example, I was on a Google Meet call a few minutes ago and I couldn't get the camera to work. I was thinking that it would be interesting to correlate the Google Meet user interface with deals closing in Salesforce - does the salesperson close more deals if they are more likely to have their video on when they're talking to customers? There are all kinds of examples because everything happens in the browser. You can really start to imagine, “okay, I'm going to correlate data that we may not have thought of correlating before and we may not even know to correlate it yet. We might have been collecting it without knowing that there's value in collecting it”. Being able to go back and look over it in diverse ways is very interesting.
How do you manage, at that kind of a metadata level, keeping all of this straight?
First things first, the data volume is growing quickly. It's a difficult challenge - we are hiring as quickly as we can. Great data people please visit Fin.com/jobs or email me at firstname.lastname@example.org, because hiring is a top priority.
One of the things that limits the data volume is that we have a strong view toward privacy and effectiveness. There's a whole bunch of data you could imagine us collecting that would be hard to think would ever be useful. Maybe that's the wrong approach. It's not necessarily that we're fixed into that approach, but we do configure the data that we're trying to collect, and some of that is just to limit noise and then for others it's for privacy. I’d love to be able to give the data in a very raw format to customers and just say, “Hey, use your Python notebooks, or load this into your data pipelines”, whatever it is, and do some analysis on it.
We do expose REST APIs, but anyone who's ever tried to download massive data sets through a rest API knows that it's a cumbersome process. We have some customers doing that today but it does limit the scope of what we would want to expose.
I know that Snowflake has Snowflake Marketplace, but I'm not sure that's the exact solution to this problem. I think there needs to be something like REST, but for sharing these large data states between trusted partners. Maybe I'm missing something, but we've toyed with the idea of giving customers a SQL connection string, for example, and partitioning data out onto a data warehouse that belongs to them and letting them run with it. I think there's a bigger solution to this problem where you have different data sources provided by different vendors and you can pull them in and mix them in different places. That's something that I definitely want to think about how we solve.
There's a lot of data that has a low likelihood of being useful - you can track every click event in a web browser - but does that help you further?
There’s an analogy here. Many of our listeners are early adopters to technology and I'm sure that a significant number of them have heard of the Tesla move in terms of their automated driving away from radar-driven systems to now going full on-vision. They've abandoned what was an enormous source of data that they could use in lieu of refocusing a vision-based autonomous driving type of mentality and I just see this parallel there is.
Is there in this world of basically unlimited data some data that just isn't worth the trouble? Is that what we're seeing now? This isn't Fin-specific, but just in this space.
Until you know it's important, maybe. There’s a formula that you could write up which relates to the cost of storage versus potential future value. A good example for us would be cursor movement data. We don't track where the cursor moves around the screen; we could, but broadly speaking for us, that data and the cost of storing it versus the perceived future potential value doesn't work out. I think as that as the hardware and general capacity curve keeps coming down, the outcome of that equation basically goes above zero.
From where the Fin vision started to where you are today, how has the organization evolved? Do you still have hundreds of people doing the assistant business, or has it completely moved to all the AI and software as a service model?
The Fin assistant business no longer exists. Last year we were very fortunate to work with a lot of very public software IPO companies. There's a lot of operationally heavy software startup in the world now that didn't exist before - people who are solving problems in the real world, but using cloud software, and there tends to be a strong operational component to that. The demand for the product was there so we jumped on it and pivoted the company sometime middle to late last year and went on kind of a hiring spree. That's when I joined and we added a team of fairly seasoned B2B experts cross-functionally. We added a lot of folks who had done this before in some shape or form, so the company now looks much more like a traditional B2B, SAS software company. We raised some money and we're running full speed at this problem now.
You're sitting in a chair that a lot of folks would aspire to sit in one day and there's a couple of questions that I have related to that:
First, what unique skills should a person who wants to be in this kind of role be developing, and what kinds of things should they be doing to have that kind of opportunity?
Second, once you do have that kind of opportunity, what advice do you have to anyone who's running a business that's growing quickly and they're just trying to hold on?
It's interesting for me to have been offered a job as a CEO. It's much more common in Silicon Valley for founders to run their companies. We had this unique situation where the product was not born by mistake, but it made a pivot which wasn't necessarily where the founders wanted to be applying their time. In general it pays to differentiate between consumer and B2B. If you want to be CEO of a consumer technology company, it's kind of a crap shoot. You have to have insight into what the world wants and there’s typically a lot of failure. One in however many companies make it because that founder or CEO said, “I think the world needs this phenomenon that doesn't exist today, let's go chase it”. Everyone thinks they're crazy, and they turn out to be the ones that are correct. It's very hard to control for that.
B2B can be a little different where there is a predictable march forward of technology and the technology platforms that are available to businesses that allow them to serve their customers better. For us, and I think for most B2B software companies, it's a question of having a thesis about what the future looks like, having a vision for some broader phenomenon, and being very diligent in understanding customer problems and solving those problems. If you can understand a problem, solve it using software, and communicate to the person who had the problem that you've solved it, you've won. You're just repeating that process over and over.
For me at least, there was a lot of value in having worked in sales and worked in the business side of things, but also having spent a lot of time thinking about product development and going deeper than is expected on both sides. Being good at both things to the greatest extent possible is going to allow you to understand the problem the customer's having, solve it in an effective and somewhat novel way, and communicate back to them, “hey, I've solved this problem and I think you should trust me to be the person who provides the solution”. It’s formulaic, but it does require quite a lot of diverse expertise. You also must be willing to be the person who says, “I'm going to go and hire however many people that I need to hire to make this thing true”. This is the hardest part by far. You have to believe in what you're doing to be able to truthfully bring people along on a journey and say, “Hey, we're going to go solve a problem and it's going to work out for all of us”.