Welcome to the SAS product power breakfast hosted by Dave Kellogg and Thomas Otter. This is recorded in front of a live studio audience on clubhouse and playback later on podcast.
Well, Thomas, off to you. I think we're about start time.
I am I am vaguely set up David. Are you are you happy and comfortable and on and can we hear you?
Yes, I think so. Can you hear me okay,
we can hear you very very well. Your your dulcet Irish tones are a great contrast in my, my severe South African accent. So excellent.
Perfect.
Excellent to excellent to have you today. So this is Episode Six of the SAS product power breakfast with Dave Kellogg. Thomas Otter and our special guest today is is David is David Clark, so so perhaps we'll start off David. I met you was probably about 15 years ago, when I was a gardener. And you just been clear, I think it just been acquired by by workday week a week. So we go back some way. But maybe you give the audience a bit of your your history where you've come from and what you've been up to and what you're doing today.
Sure, yeah. So nice to be here. Thanks for the invite. And yeah, I've been hanging out in the industry now for about 20 years, and in a few different companies. So I am at a college, I worked in a company called lambda technologies, which was one of the early Irish sort of software tech companies. And we went public in on NASDAQ in 1996. And at the time, that was actually the second biggest filter IPO after Netscape, which shows the high end go was and it was kind of a fun company doing integration middleware stuff. And really before when this development was big, and yeah, it was good place to be. But really, none of us knew what we were doing. It was everyone's kind of first job. So when your company grew rapidly for a while, the good one, and then stopped growing equally rapidly, which was kind of less, that's fun. But it was interesting. And then a few of us went and set up as a company out there called King clear, which was aimed at really doing integration for web based systems, and which were becoming increasingly prevalent is around the terminal millennium. So we ran that for about seven, eight years, nine years, I guess, and then eventually ended up getting acquired by workday. And I spent 12 years at workday through its growth phase through its IPO. And afterwards. And yeah, finished up there last summer. And sort of having done really two if not three shifts, I guess. And then focusing on mostly in Australia and stuff, bit of investing a bit of advising bit of venture capital. And I'm also doing some work with the Irish government on some digital identity topics as they're related to government services. And that's somewhat interesting right now with vaccinations and passports and certificates and so forth. So we're certainly going to see a lot more of that. I think so. Yeah, that's, that's kind of what I've been doing what I've been up to, and, like, as I've come across you, Thomas over the years in a variety of capacities as an analyst, kind of critic and competitor, and, and occasionally colleague. Yeah, nice to be here.
Yeah, it's super, super heavy. So I feel like you've sort of lurked in a parallel universe to to, to, to mine. Mine along the way, your universe in a lot more IPOs than mine. But nevertheless, there's some similarities, you know, for those of you that are on the phone, and don't really know much about workday and get the and get sort of the scale of it. I think, you know, David, when you join workday, when you guys were acquired by workday, that was that was, you know, what was that?
2008 2008. So
how big was work? You know, how big were work was workday, then how many customers you they? You know, did they have how give the listeners a sense of what work there was in those days.
And workday was early. So I think at the time we joined we had was that 45 4050 of us, I think and workday at the time at about 180 employees. So we're kind of about a quarter of the combined company at that point. And workday had been up and running for sort of a year and a half with beginnings of customers and productions. They had about 30 ish, I want to say 30 ish customers, mostly small, but a couple of big ones even then. So we're just really entering the phase of trying to storm the ramparts of the SAP and Oracle incumbents to be evident disbelief of, of Larry Ellison developer time. Yeah, it's quite small, but growing quickly, and I guess, you know, the landscape at that point was Salesforce had gone public in 2005. So they had sort of legitimized the idea that you could actually run critical business systems on Then on the web, and you could outsource important business data functions to the client. Because you know, prior to that, and certainly practice sales forces success and IPO, it wasn't clear at all, custom corporate customers were rapid to adopt the cloud as a way to run core business systems.
We forget that now. But at the time, you know, SAS was still novel. It wasn't, you know, in the academics talk about a talk about a dominant, you know, dominant design, in tech, but, but it wasn't, then it wasn't the dominant design, you know, on premise was still significantly outselling, outselling cloud and, and, you know, the whole idea of on premise at the time was, it was highly customizable, highly adaptable, and you guys were coming to market with this idea of, you know, we were building a system and it's going to work out of the box, it's gonna be, it's gonna be really straightforward is gonna be really, really simple. Yet, you took on some, some massive, early customers like, like, like HP, you know, I remember when you guys closed the HP deal. I was, I was gotten the time and I was really amazed that you that you landed that deal. And I was even more amazed, you know, relatively soon after you went live with with with. with hp, it's often easy to close software deals with companies like HP, it's a lot harder to go to go go live with them. An hp at that time was you know, well over 100,000 employee, whatever, 100,000 employee company. So that was, that was mega impressive. The thing that interests me is it question is the How do you manage that as a product team, when you have your new small little company, and you have this this this massive customer, you know, that can just if you're not careful, can just just override and dominate your strategy on your roadmap? How do you manage that? that that that that that big, that big customer?
Yeah, good question. And the funny thing about HP, which is a good question a second, but in terms of thinking about recently in a different context, and how when you sign big customers like that, especially when you're a smaller company, your product can end up getting used in ways you didn't really expect. Like, especially when scale. So I remember a particular rant on HP, shortly after they went live, and finally, D merged, as you know, so they split out into it was two, if not three businesses. Anyway, this this buttons up. And then we had been working for a while on the feature to enable sort of people to be essentially forgotten the system partners partly related to GDPR as supporting capability. So we have to have a way to essentially delete or forget or remove people. And the intention was that that will be staged out gradually, because it was sensitive, sensitive feature, you know, quite deep data, the data model affected a lot of stuff. So we attend to the stage of that gradually release to a few people who would stick to the five people for a couple of weeks, and then scale up to 100, or whatever. I remember, I think the first week that one feature went to production, I got a call on Friday evening. And it was like phps, sort of customer success manager saying they found this feature, and they intended to use it the next week, to effect their demergers they were going to copy their test twice and in one copy, delete 100,000 people and the other copy, delete the other 100,000 people. remember going to the product team thinks it's gonna work. It was sort of slightly tail phases, but it did work. And but it was an example of how you know, as a startup growing quickly, especially dealing with big customers, you can find yourself facing some pretty surprising uses of your product, especially as it relates to scale. I guess that's the that was the first takeaway. And then in France, it was a creditor date on the other side of workday that they they kind of went after big companies early on the basis that profitable, that's where the money is, right? So successful big companies, you've the economics of your business, are that much simpler. But I think, you know, mistake that I have seen smaller companies make is they go after big companies for that reason, but then they're not thoughtful about how they're doing it in a few different ways, like the first obvious one is that your eyes are beginning to stomach and you're going after businesses that even if you close them, you're actually not going to be able to support technically, so the thing just isn't going to work because they have too many products or too many people are too many transactions, and you just haven't actually, you know, purpose enough to support that scale. So that's, that's an easy and obvious way to screw up I think, you know, more subtle, but a more maybe, and sort of damaging and possibility is that your roadmap is hugely and to lose it or distracted by the customer because they have legitimate expectations that you're going to do everything it takes to make them successful. But if that ends up putting away all of your strategy line, and you know it can actually be problematic, so you need to be very convinced that you're making the company successful that the company is going to be result in your product. I believe that's actually on your strategy line, not way off of us. And because in the other product, because, you know, dealing with very large companies, especially as a small company involves many people, and often the whole management team, you know, lots of the actual sort of coface workers. So it's hugely distracting of effort at that level. And then kind of an unexpected thing, or certainly, I think companies surprised by this, the big companies escalate quickly when they're dealing with small companies. So they sort of feel like they have this God given right to, to call the CEO at a moment's notice and to just escalate even relatively minor issues very quickly. So if you haven't gotten a process to deal with that, and you know, you're not sufficiently confident to say no to some things, you can end up quite separate from the roadmap and the effort, distractions, you can you can end up just just being sort of in this permanent state of escalation, and it can be quite quite disorientating, I think,
yeah, I've I've lived that, I've lived that as well, it's almost worse, when you're, when you're a small division of a big software company, that's which I was in at successfactors, within being a small division of of SAP, then is this, this double escalation problem where they escalate within success factors. And the next step is they escalate within SAP. So when this lay, when this lay one, something you've kind of, it's quite hard to say, it's quite hard to say no. And to have that discipline to say, this isn't really what we're trying to build, it goes back to the idea of you kind of, I think, if you're dealing with big customers, you have to be pretty convinced of where you want to be. Because if you don't have an idea of where you want to be, and you've got this open idea, or Well, let's just figure this out, as you go along, you will end up building, you know, every pet project that this big companies never been able to have anybody else build for them, you know. And that gets you down and sort of cul de sac and gets you trapped, if you like almost like a Stockholm Syndrome for this one big customer. So you think you're a product company. But actually, what you're doing is you're actually doing a project, the worst vendor to be as a project vendor on a SAS license model, that's a really bad place to a bad, a bad place to be. And
the point of that saying no is worth making. Because, again, sometimes the power dynamic ability is asymmetric in these kinds of relationships, but I think sometimes the smaller company thinks they can ever say no. And in fact, you know, knowing when to say no, and being able to say no is quite important to think of those relationships, and it can be surprising, to the bigger companies can be quite pragmatic about situations. And there's often I certainly saw it as a reluctance to convey bad news, like a roadmap slippage product issue, I can average a data problem, whatever it is, you know, there's going to be a desire to do almost anything to avoid having to bring bad news to the, to the big company. But in fact, you know, we learned pretty quickly that, you know, like radical transparency is really best in that regard, rather than, you know, hopeful. hopeful planning. So and, and I think you end up being more respected by them as a peer, if you're, if you're blunt, about stuff, and if you say no to things that aren't going to work don't make sense. And I think that's, that's kind of a, you know, an important skill in for smaller companies and dealing with with with bigger companies. Yeah, I
think related to that, you need to build relationships with the people in the big companies, you kind of think, Okay, oh, I'm dealing with, with, you know, I'm dealing with Siemens, or I'm dealing with Bank of America, or I'm dealing with, with with Walmart or whatever. And, oh, there's this big, unseen beast of a thing. But actually, most of the time, you're, you're dealing with individuals in those companies. And the way I was taught is that is that they were betting their careers on, on the product that I was working with. So if my product was successful, their career was going to be, you know, their career in their company was going to be was going to be successful. So you build up this relationship of trust, I think with with those key with those key people in their, you know, in the company, and if you open with us, people, it helps us help you so much, Dave, do you want do you want to hop in?
Sure. Thomas, I just wanted to say we had a hand raised there. So I pulled Bowman up on the stage. I don't know if you're ready to take questions, but we have.
We are always ready to take questions. We are flexible.
Thanks, everybody. Good morning. Kind of along those same lines. I'd love to learn your perspective on the role of large system integrators and the role that they play with enterprise software companies. I think workday was, in my mind, one of the last companies that was able to do what sa P and Oracle did with Accenture and Deloitte by the virtue of having those large practices and those large benches of individuals. Is that dynamic shifting? especially as it relates to large clients or large deals that get signed? I would love your thoughts on that. Yes, great
question. I think so yeah. When you start to deal with the biggest companies, they're accustomed to dealing in a certain way with enterprise vendors, and I think To some extent, at least for the first generation of enterprise cloud systems that are deployed, they fall in love the same playbooks. So it was Stephens running in the cloud. But in many cases, the projects looked a little similar, the project governance would center the project plans with similar and the project participants being, as we say, the biggest size, but similar and, and, you know, workday, we kind of Can't we, there's only so many things you can disrupt at the same time. And we were already using quite a lot of goodwill by getting people to move from from trusted, hated vendors into the cloud. So we didn't want to at the same time really take on, you know, a radical change to the project delivery and governance model. So as you say, any companies like Salesforce workday, were probably the last maybe generation of companies to, to do that, to engage with the big si s, in the same way that maybe the previous generation of vendors had. I think part of it was pragmatic, certainly, I know, for workday, because, you know, as you scale quickly, and you're delivering your services to 10s, and then hundreds of giant companies, you just don't have the bandwidth, on staff in the company to deliver that number of projects at that scale. So, you know, it had to be, you know, outsourced in some way to, to consultants, and the consultants who were trusted by the, by the customer community where the big five, or the big sector was different numbers of them over the years. So that was kind of how we operated. And, you know, for, for workday, certainly, and I think similarly for for Salesforce, and also for people like ServiceNow, and they didn't want to view services as really the major revenue or profit center. And so, you know, sort of, I know, workday, we just tried to have the services and organization wash in space, just breakeven. And, and we also didn't want to compete proportion of the business, firstly, because it's just a bit harder to manage. And secondly, it's just not as scalable in economic and financial terms as the as the core product isn't, is. So that can lead you to a certain dynamic where, you know, services was stable, that sort of 15 to 20% of revenue was breaking even that wasn't profitable, you know, where there was margin there, we would often, you know, purposely reinvested into customers, you know, to make them successful, to make them happy, because that was a big part of the flavor of the business. And we did look to advance even on projects that were being led and executed by an SI, for big customer, we would typically have, like, you know, workday people on staff as part of that project as part of ensuring quality and success and consistency. So that was kind of a dovetailing there, I think, and that's certainly true. everything I just said for bigger customers, like call it you know, 20,000 employees and up something like that. But I think, as we start to move down to the mid market, obviously, some of those dynamics change, and, you know, customers are less likely and willing, less likely to be willing to want to engage in the bigger size, and those kinds of projects, they're going to want to do more themselves or have more done for them. So I think strategically, again, a no for work to aim for similar companies as they move toward mid market, the way you need to think about implementations and projects and expertise is available for those things, these changes in the product needs to be more quickly implementable, and maybe less customizable, more pre packaged, in ways that enable companies to be more self sufficient, or at least to get a lot done without having to engage with it with a big si. Suddenly, if that makes sense. Northerners that answers what you were thinking.
That's tremendous. Yeah. Yeah. I mean, it's, you know, I've been often told it's a necessary evil, but you know, that's probably because most of the people that say that are x, Oracle, or SAP? It just says that are that is, so is your answer. Yeah. It's a very good answer. And so I'll think about it a lot more today.
The final point, maybe to make a bet that is that, you know, it's still in big companies and the size or big influencers, like they claim to have strategy, they certainly influence product decisions. And so I think, you know, they're, they're part of that enterprise ecosystem in the fortune, you know, fortune 500, certainly, fortune 2000 even, they're their big influencers. Yeah,
I think the one of the points there is that when you think about the transformation process, if you if you're a vendor, or a software vendor, then you tend to think about business transformation in the context of your software. But actually, there's often a whole lot of other stuff that's going on and your software is just part of the picture, you know, so, you know a company may be preparing for an IPO or company may be maybe expanding globally may be doing acquisitions may be completely restructuring from from being a federal organization to a central organization the other way around, and your technology is essentially you know, part of a bigger picture. And that is often driven by the by the by the size, so that the size often provide the impetus for The project in the first place, what I often find is that, that, that's, that's SAP, I used to find that the larger size were excellent in the sales cycle. And the smaller size were, were were the ones who would actually get the customer live. So it was always important to have the relationships and manners relationship are the largest size and, and, and the smallest size, but it was often the smallest size who knew the technical details of the product better than the larger size in large? A size D. But But Dave, you you have a quote on your blog, I think we talked about the the main goal of of services in a in a SaaS company is to drive MPs. I think maybe I'm misquoting you, but that sticks to mind was something I read on your blog, I think.
Yeah, I've always felt that software companies get confused about the role of services, like sometimes they'll hire practice leads straight from an SI who thinks the job is to maximize the size of the services business or to maximize the margin from the services business. And I think people, especially with company valuations at 20 times Arr, I think everyone now, it's increasingly obvious that the purpose of services is to maximize arr. And that's accomplished through some combination of doing stuff yourself when the customer wants you to, and enabling size to do the rest.
Yeah, I think that the thing that worked well, also on it, you know, that they, they were pretty disciplined, I think compared to the other vendors at the certification and, and the validation of their si. So they didn't, they didn't let anyone work on a workday project. They were actually much stricter than I think any of the other vendors where I'm standing like a workday appraiser here, but I do this grudgingly. But they did that really, really well. In terms of, of of creating a guardrail of, of around the SI quality at times. I think they ever did that, because it created a shortage of skills in the market. But it did. They were much I think better than the other, the other enterprise vendors at the at assuring some kind of quality level of of product competence in the, in the in the in the SI.
Yeah, I do think that, you know, over over time, and I think Robin was hinting at this, I think, you know, increasingly, people want projects to be shorter, they want products to be easier to use more self explanatory. They want things like integrations to be simpler. So I think, yeah, I think increasingly, a lot more of the smaller companies on se, were operating in the HR broadly defined space look a lot different than what they did. And similar stage. They're much more focused on implementation, implementation and configuration built into the product more, like maybe less skilled configurators. So again, yeah, I think in the in the medium term, it's, I don't see quite the same business model for the, for the level usciences as they've operated.
Yeah, talking to just one. Sorry, good. Go ahead. I just want to final comment, what I've closed up the alliances and ecosystem sought, I found more value in in having a better relationship with companies like AWS, or the hyper scalars. Because more often than not it any client or prospect before they go out to seek these business applications. They think about do we even have the infrastructure to run them engaging with AWS I found, you know, in enabling them with the field ready sales kits, or, or whatever, helps them understand the value that our business applications bring. And then the line of communication having that it's just so much better for us from from a prospecting perspective, or even a brand recognition perspective.
That's actually a super segue into the next sort of question that I had on my, on my list is that if you look at something like look at a product, like workday, workday, you think about as an application company, right, they build HR, they build an HR application. But they acquired clear, which was essentially an integration platform, essentially a platform technology. So it's a technology that provides capabilities to developers rather than a technology that provides capabilities to to end users I don't want to, to, to to describe play, probably not described clear very well. But as you get, as you start to get bigger as a as a as a software company, you have a platform, you have some sort of platform organization that's building building product for you know, your engineers To use to build applications, and one of the things I found challenging at successfactors was always balancing the requirements of, of getting a efficient platform and driving standards. And then at the same time allowing individual product managers and engineers to have, you know, have freedom to, to, to, to innovate, maybe you could talk a little bit, given your CTO background about the role of, you know, platform verse applications, and how do they, you know, what is a platform for an applications company? And how do you see that changing from say, when workday started to to if you're doing it today?
Yeah, great question. big topic. And, again, I haven't been inside your workday here. So I'm sure they're thinking is the dollar chain significant thing. So I thought that in general, I guess, firstly, from, I would distinguish between an integration platform, and then an application platform, so and, you know, for enterprise, SAS vendors, you need some way in which your offering is going to fit into the ecosystem of other apps, increasingly cloud apps that companies have, so need a good integration story. Again, fourth day at the time, we decided we needed to own that, which is why we were quite clear. And I think that was the right decision, then because integration technology was still relatively nascent, especially as related to the internet and to web based systems. I think that's changed now, and I'm not sure today is, you know, company, again, enterprise. And cloud computing needs to own, you know, to the same degree, its own middleware. But anyway, that there was a good reason for that at the time. And I think it's, it's, it's still valid. We got the broader platform question. It's, it's kind of interesting one, and then something I certainly grappled with over my tenure at workday. And I think it's a it's an evergreen topic is probably, you know, are we building an end user facing app? Or are we building a platform upon which we've built an end user facing out, but which could also be used by other people to build an end user facing app? And, you know, it's difficult to do both of those things at the same time? That's the honest answer, because, you know, it tends to be the DNA of a company to be an applications company or a platform company. And it's, it's, it's rare to see both in one company, and it's relatively both done well in one company. So I think that's something people struggle with. I think my favorite, it's hard to define a platform. But the favorite my favorite way of thinking about it, and I think the best definition I've seen is Bill Gates has been quoted, you probably heard about the city of the Bill Gates line, where companies like tech companies, and I've been guilty of this myself often talk about platforms in terms of API's, and interfaces, and programming and extensions, and so on. And Bill Gates once said, apparently, he was in advising Facebook, and they were proudly showing him their new platform, at the time, they were launching the first set of API's, and so on. Of course, that didn't work out well, for other reasons. But it was a good idea at the time. And then they were proudly telling, telling Bill Gates, hey, this is the platform, and he was going, like, that's a crock of rubbish, you know, the platform, you have a platform when the value that's captured by the ecosystem is greater than that captured by the owner of the platform. So you know, for him, then oh, by that measure, windows are the ultimate platform. So Microsoft made a ton of money, other windows, but the ecosystem broadly defined by as these around windows, made much more in aggregate than Microsoft did. And so I think, to me, that's a good definition of a platform, because it implies you're kind of an important part of Yes, but only a part of this broader economy that's arisen around what you're doing. So you know, AWS is the platform, Windows was a platform. Sort of, you know, Microsoft is your is a platform. But as you look at enterprise apps, it's increasingly it's difficult for me to look at any of them and say, yeah, that's a platform, which, you know, where's the biggest missed opportunity, because the kinds of primitives and software infrastructure that you need to build, like highly scalable, and enterprise applications is hard to build. And it's a pity to see everybody building it multiple times, instead of seeing it be reused. So I think, you know, companies like Salesforce, like ServiceNow, and like SAP successfactors, like workday, have all this componentry that they could make available as a platform where people could then build powerful apps on top of it, but that need to reinvent stuff all the time. But it just hasn't happened. And you know, it just really hasn't happened. And, you know, again, I was part of this whole dialogue over years. But, you know, the answer I keep coming back to is that it's either in the DNA of the company to enable an ecosystem in the way Bill Gates described us or not, and I think, in many cases, application companies just don't have those instincts and don't have that DNA and therefore, it's, it's hard for them to do it. Yeah, I
think, you know, if you look at Oracle, it's kind of fascinating, but it has a little bit of both in Oracle in the sense that the database business is a platform business. Right? Right. So, so if we go back to the 90s, SAP was the early 2000s. ACP was Oracle's biggest reseller. So SAP sold more Oracle databases, then then the Oracle, then then Oracle sold, and the Oracle Application sold. So it was a fascinating example of a company where you had both you had this application team that was fiercely competitive with with SAP. Yet, the database team, if they got a development request from SAP, they probably take it more seriously than if they got a development request from that from their own from their own applications team. I guess that's another definition of just a desk definition of platform is Who do you prioritize? do you prioritize your own engineers? Or would you prioritize your engineers from from, from somebody building on your platform?
That's right on if you talk to the doctor, the Amazon guides, and famously AWS got going essentially as a product as ation of internal platform infrastructure that they had built to be used by the website. But when you talk to the AWS guys, they will say that, you know, at some point, and they had these whale customers, so soon enough, after launching, they had Netflix was one of the early ones, and then the US government as well. And then pretty quickly for them, you know, the Amazon Marketplace was just one of like, three or four way on customers, and it wasn't treated any differently in terms of access to priority or access to, you know, internal API's or anything. And again, that was a deliberate, purposeful, you know, leadership decision that was made, and that was stuck to inside of Amazon, and clearly a big part in helping you make AWS, what it was. So yeah, as you say, I think if you don't have that clarity, those instincts to allow, you know, competition to develop and and, you know, competitors to succeed over your own product, then I think that I think you're not going to succeed. And I've seen a lot of half baked attempts by applications companies to brand themselves as platforms and offer platform, the kind of features but not to not actually embrace it in a genuine way and think that's better. To have. Yeah,
yeah, it's a half. It's also what I think sometimes what happens is that, you know, somebody outside will have an idea for a product capability, start to build on the platform, and then the application team will say, Hey, no, we wanted to do that. Yeah, right.
Yeah, but that's what Twitter used to do. And to people, when they were kind of tinkering with the platform business. And you're absolutely right enterprise, software vendors, and some of the prime vendors there, they consider their potential market to be everything, and therefore reserve the right to do anything at any time, which is a difficult space to integrate into if if somebody has a lot more capital than you can turn around and on top of your crush your good idea, as soon as it shows any signs getting traction, and, again, that's just, it's it's a it's a DNA thing, where you're willing to allow competition to flourish up to and including potentially allowing an external entity to be better than a product that you yourself already make. And to sort of recognize that and for example, shut down your internal product and favorite, the external one, because that's better for the ecosystem. But they're the kind of decisions that culturally are genetic to either make or not make. And like I said, I think it's hard to be an app company on the platform company,
for sure. So yeah, moving a bit more inward. I want to talk a little bit about, about architecture. And, and, and the role of, of architects and I'll tell you, where, where this question is coming from, you know, when I started in HR technology in the 90s, we spent a lot of time thinking about data models. And there was a lot of thought and, and, and design in a waterfall architecture, or, you know, waterfall engineering practice, on the on the on the data model. And, and you know, how, for instance, in HR, you know, how does the employee object work with the person object, how does the person object work with the, with the, you know, with the cost center object, and the position object, and so on. And these models were, were sometimes flawed, but they were well thought out. And they were, they were a lot of intellect went into the, the object model before before coding started. And what I see happening today with a lot of startups in HR tech, is, you know, they just start building stuff. And it's really cool, and it's really innovative, and it's really exciting. But then, you know, a couple of weeks or months later, they hit an architectural roadmap because they're not actually thought through the, the, the object model of how to actually, you know, how this thing's all gonna fit together. And so, there's got to be some middle ground somewhere about about architecture, when it comes to things that have a complex data model like finance and HR and supply chain, supply chain and and so on. If you're a small startup, building an application that is relatively complicated, what point in time do you start, you know, worrying about about, you know, architectural questions, either the functional architecture like I've been talking about or ever, you know, order. Technical, technical architecture. Give me some sense of how you have you've seen that change and and some thoughts on architecture.
Yeah, it's good question. I think. So, like, to me, making a software company, the architects are the most important people, and some Evans important sales, but but like, to me that the thing that really makes these companies work is the people making the difficult and strategic technical decisions about the product, how it's built, and how it's designed, how it's built and operated, and where it's going. So, you know, I know that sort of Personally, I always depended heavily on the input of like a small number of like highly talented architects whose judgment I trusted, and I kind of over time, I was thinking, What is it? What is the skill set? Like, what are these people actually doing? And, you know, these would be individual contributors. And, and even, like, when I was running, like large, like 1500, person organizations, I still had, you know, two, three, sometimes four, individual contributors reporting directly to me, just because they were they were tivity Architects, just because I valued so highly their technical take on things and, you know, trying to define the role. And it's kind of everything and nothing, but the best I could come up with was that, what I used to look for from architects was the ability to synthesize a very deep knowledge of where the company is at today in terms of its technology with a good understanding of where the business and the company needs to go. And then synthesize synthesizing that into the set of strategic technical decisions and directions, obviously, informed by an understanding of the technical market and possibilities and so forth. So that was what they were doing, they were synthesizing, you know, where you were, at this time, with where you wanted to get to, and then having a point of view on how the product technically would need to evolve to get there. So I think that's what architects were doing. And then they'd have to have that point of view, they have to get the key indicators. So often, you know, some of these decisions, like we're going to go Amazon or Microsoft, or we're going to use this database, not that we're going to do this data model of that data model, we're going to deploy, like r&d, not monthly, these kinds of decisions often need leadership to make happen in the organization. So these people, architects typically then have to command the respect of the technical staff. And they've often come up through the ranks of lift, lift, the dream of mid systems work, and so on. And, again, you can architect to different levels. And as companies and states get bigger, you can have system level architects who own the database piece of the transaction processing piece of the reporting piece, but then you have people who have a higher level perspective, or looking at how all the pieces fit together. You know, for example, as you started looking at acquiring or being acquired, like an important question, certainly for the acquiring companies, you know, how do we fit these things together? How does the integration happen? And, you know, that's kind of questions that I would just kick over to an architectural sense lead, but I would say, like, look at our company, and knowing everything we have, and what we're doing and where we're going, and looking at this company, you've never heard of a month ago, but now you've spent a week looking at their source code and talking to all their technical people, like, tell me in 10 minutes, like, Can this work? And how will it work? And, you know, that's the kind of questions that an architect a good architect will be able to answer for you. And, you know, again, to me, that was, that was that was invaluable. So I think there's some, there's some characteristics and maybe a little high level, but that's, that's really what I look for in architecting.
Yeah, the thing that used to keep me awake was dependencies. And, you know, knowing that, when products get get bigger, once you can put all the engineers in a room and they talk to each other, then dependencies are then easy to manage, right? Hey, you need to build this before I build that. But you know, when you start getting up to say, you start getting a point where you've got maybe like 100 engineers or even 50 engineers, you start to have dependencies like feature a needs to be built before feature B. And, and we have a customer, customer depending on you know, we may have a customer depending on feature B and engineer building feature a doesn't know about the dependency of of customer of the customer. So vj slips and that means a feature B slips and that means that you missed, you missed the, you missed the customer, Mr. Customer deliverable. So, you know, I, the one of the most important from people for me as a product manager was the was the we would rotate the senior architects through the dependency management process was it was a ship job, right? But we put a senior architect on our managing dependencies and, and so for a couple of releases they would be a be tracking every single customer commit And then tracing through to all the, all the dependencies so that we would know that, you know, what really couldn't slip in the in the, you know, in the back end. And orphans is kind of weird, you know, there was some weird dependency of some minor lookup table in, in feature, feature way away from from the thing you're trying to deliver. And if you didn't do that change, then the UI wouldn't work, and you couldn't deliver it. And they would know all these things and be able to really triage and prioritize all these, all these dependencies as a really big part of the, you know, big part of that exercise. Um,
yeah, and I think just on that point, I think, of course, then what I, what I would want from a really good architect would do that for a while, and then come back and say, you know, answer questions like, why do we have dependent? why did why did we have these dependencies at all? Why do we have them? Can we minimize them? How can we write precisely, here's three ways we could do that we can organize differently, we can use this different technology, we can break the product up in a different way than it's currently broken up. And so it's somebody who's not just kind of, you know, not just not just kind of pouring oil on troubled waters, but it's actually thinking strategically about why things are inefficient or problematic, or not working or dependent or slow, or it can, some of the insights can be quite surprising from from people who are really good at this because they can, they can come up with solutions, you hadn't even imagined to problems that you really didn't know you had. And that's, that's kind of the alchemy of software, it's as a production processes, it's amenable to those kinds of radical insights that can, you know, significantly change, you know, your rate of productivity, or your rate of quality of output or whatever. And quickly, and again, that's, that's, that's a uniquely software thing. And architects are the they are the alchemists, to me invest in that sort of situation.
Yeah, I was often at war with architects, but but they were always the most interesting people to have lunch with, sometimes had the most weirdest of hobbies as well. But anyway, that's, that's another story,
communication stuff, because again, like not all sort of developers or engineers aren't necessarily are good at or relish communication. But often, again, as I said, you know, in the realm of architecture, you know, you have to have more than have good ideas, you have to be able to sort of sell them, especially to the technical staff, and including, often to a skeptical management team, who, maybe we'll be a lot less qualified than you are, in the technology you're talking about. So I think, you know, sort of highly developed a communication sensibility is also a sort of a big, not a requisite, but a bonus for, for us.
And from the perspective of a product manager, I think it's really important that you, you, you have an architect that you can talk to. So you'll be making decisions often about features and and you'll be making vague vague thoughts about what it's going to cost or how long it's going to take and, and the individual engineer that you're dealing with, may often be far less capable, even though they're in the details of scoping it out, then at a higher level than the architect will be the architect will understand or having a grasp of the, of the broader, you know, the board and dependencies and of the of the of the board architectural requirements. So it's always good to always good to be friends with a friend with a friends with an architectural too. So perhaps perhaps moving on to talk about about, you've been in a situation where, where, you know, you've done, you've been acquired, so k clear was some time ago, but k clear was, was acquired by by, by workday. So you've been through, you've been through that cycle. You also workday tends not to talk about this very much, you know, at least historically, hasn't talked, talked about. Its its acquisitions. But But you know, over the years worked itself as made as made multiple, you know, multiple acquisitions. What's your advice for for, for startups or scale ups? When, when either they are courting or they're being courted by the bigger, bigger, bigger enterprise vendors? What do you what have you seen startups do do wrong when they, when they start talking to to to the bigger vendors about the possibility of being of a strategic strategic acquisition, where do they go? Where do they go wrong? And what can I do to avoid that?
Yeah, again, I am not of any anything specific here, but certainly, in general, based on what I saw there, and what what I've seen and I'm seeing elsewhere, and to me, just, I think the most important thing is that in a good transaction companies are bought not sold. And so you know, we're startups are sort of under duress or in distress and, you know, kind of bad sort of shopping themselves, but that's really, you know, Good situation, and do you have any control that you're in that situation if things aren't working out, but in terms of a good outcome, you know, companies are bought. So you know, where the the initiation of the approach comes from the acquirer in there, for strategic or market presence, or whatever reasons, they've decided they need an asset in this space, and they've come up on you, and now they've come calling. And I think that's, that's a good situation to be in. But I think, at that point, you need to be clear if, you know, if you're interested, because it can be super time wasting, and for a company to sort of engage in these dances and be a little ambivalent themselves about what they actually want. So and, you know, the best situations, I've seen, our founders, when approached, are clear that they will or won't sell and if they will sell, we're pretty clear on who owns what will interest them in terms of the deal and the structure and so forth. So I think having thought of a little bit about that, for where your company is at leaf stage, are we looking to sell actively? Okay, that's one thing or different approach concerned, one of the, one of the criteria we use to evaluate it, are there certain companies, we would never, you know, we just don't like them, we would never accept an offer from them. Other companies we would be able to Office from and the first cases like, what are the financial structures that would potentially make us interested. So that's, that's pretty the first observation. The second thing is that most deals don't happen, even when companies are talking so and, like, there's a lot of talk goes on all the time, you know, between bigger and smaller companies, and most deals don't happen. And I think I've seen first time founders and relatively inexperienced, founders be surprised, I think that when they're talking to the company, this deals likely to happen. And they're going to misinterpret the cool things of the Corp dev person as being you know, as good as as good as a signed deal. And it's not. So, you know, avoiding distraction is kind of super important. Because, you know, as CEO, as a founder, you got to assume the deal isn't gonna happen. And, you know, even if you're moving along down the process, you want to minimize distraction for yourself in the team, and don't get people's hopes up. Because, you know, these things often usually don't happen. And it can be distracting disappointing if the companies started to sort of act as if, as if this is this is kind of a done deal. And so I think, yeah, don't be distracted, know your value, and don't be afraid to negotiate hard. And, you know, I think it's easy to look at my industry in multiples, and, and, you know, be I think, be demanding about what you get, and how it structures and, and then if you are engaged in one of these processes, and you're serious about it looks like it might have been treated like a sales process, like, don't be casual about us, because, you know, all sales processes are challenging, and they can fall apart at any time for any reason. And, you know, an acquisition process is no different. And, you know, one thing that did surprise me a lot, and still does, seeing, you know, founders be quite casual about the acquisition process, you know, even when their practice knowing that it's time consuming, they can be kind of sloppy about it, they're taking days or to get back on queries from bankers or from the acquire. So I think a real focus on getting a deal done, once you're in practice, makes it makes it a lot easier to happen. And I think also, maybe Finally, instead of building relationships, or even the company and thinking about how the integration is going to work, first, anything to do more likely, because you have built relationships among a cadre of people who are likely to end up, you know, making a decision to proceed in the in the end, I think that's, that's helpful. And secondly, if the deal does happen, it means you've kind of built relationships and you have some sense of what happens on day one after kind of the, the champagne has gone flat and warm. And, you know, kind of you're back in the office on Monday morning, like what happens next. So I think, you know, having relationships built and having a realistic expectation of the next steps after the acquisition is helpful, and the more successful integrations I seen that characteristic.
So this is the SAS power product breakfast. And it is recorded in front of a live studio audience Dave, Dave tells me I have to say that I've said it now. Dave, any questions from your side?
No,
I just been tweeting a few of David's soundbites. I love the cool things of a Corp dev person are not the same as this ideal. That was
one of the quotes. I did I didn't warn you. I did warn you he's got this like poetic thing like most all Irish people have got some distant relationship to William Buckley eight or something somewhere in his family tree.
Of course.
Here we got a head razor Thomas. I'm gonna bring him up.
Cool. Great. So Leon, hello, Leon. Hello,
thank you. Listen, I this is absolutely awesome content and I can't believe there were so Few people here, this is going to be like, you know, the famous Sex Pistols gig in Manchester free trade Hall in 77, where everyone said they were there. There's many people who said there were there would have been millions.
We'll take that. We'll take that. Yes,
I've got it. I've got a question for you, sir. I, I until just a few moments ago, believe that I had spent significant portion of my career at companies that had platforms. And the way you articulated it, which I, which I totally get, you know, AWS is a platform company. And, you know, some of these app companies that have platform capabilities really aren't. But, you know, going down to another level, and what if you, if you're trying to decide your product strategy as a software vendor, and I'm just like, imagining there's this kind of, you know, gradient, and on the right side, I've got AWS, which is absolutely a platform company. And over on the left side, I've got maybe someone like, I don't know, like intercom or someone who's like, clearly an app company. But if I'm one of these people in the middle, and you mentioned a couple of them by name. They're building capabilities that they would describe as platform capabilities. And it seems that the enterprise customers that they have need those capabilities, like they don't just need another feature. And they probably need something more than just a checkbox, they need some kind of declarative or code based way to put those things together. And how in this context, should they be thinking about a platform or as part of your message, like, that's the kryptonite that leads to too much complexity. And you should be really doing everything you can to avoid getting sucked into that platform, Maya, because like a lot of the companies I work with, you know, one of the things we talk excitedly about is we're moving into enterprise. And we need to start building enterprise capabilities, which includes a lot of stuff that we you know, possibly self deceivingly core platform capabilities, I hopefully that question makes sense
that he gets exactly where they are, if you're anywhere in the middle of that sort of curve that you just described. And you face this conundrum, like, because it's clear as your Amazon, what you're doing, it's clear if the other end is identical. And yeah, it's clear that you're not company, and that's what you're doing. But if you're in the middle, you end up having these platform meetings, and you're a little conflicted as to what they aren't getting, who's supposed to use them, and whether they're free, or you're charging for them and all that all that kind of stuff. And so I think that that is a conundrum, I think, you know, I think that sometimes there's people conflate enterprise with complexity. And actually, enterprises like to run simple software, if they could, but for various reasons, some good, some bad, they end up building these ridiculously complicated, sort of convoluted systems serving, you know, enterprise doesn't have to be complex. And I think, as it relates to some of things we talked about, like API's, and programmability, and so on, and to code based environments. The key principle for them, I think, for an app company, anyway, is that those things, whatever you can do around those things has to be easily upgradeable and testable. Because the pump, the underlying app is going to get upgraded frequently in a SaaS model. And insofar as, you know, third parties, including customers have built, you know, extensions or customizations around that they have to be upgrade safe. So I think that's, that's kind of the the first principle of, you know, platform II capabilities. But like I said, I think most companies just don't, in my view, don't think clearly strategically about where they are on that curve. And as a business, and as a, as a as a, as a kind of financial revenue generating entity. They don't think about it in those terms. And that just leads them to kind of inconsistent behavior. So they'll build platform, the things, you know, but then try to charge for them. They'll try and tax the ecosystem and interesting things come along, they'll compete with, and interesting things that emerge in the ecosystem. And they won't offer, you know, why these tools to people who are qualified to use them. So I think that most, most companies in the middle of those curves haven't thought this through clearly and haven't got a clear position on it. And then their strategy ends up being confusing to their customers, the primary is through ecosystem and, and that ends up, you know, materializing as an ecosystem that is underdeveloped relative to what it could have been. And I do think, and, frankly, this reflects, and what I'm doing at the moment, and some of the companies I'm working with in investing, and I do think that companies need to think more clearly about this and have a more platform oriented mindset from the get go in terms of solving enterprise problems, have a good opportunity to disrupt the way a lot of this is done today in enterprises. So,
so you said a very interesting thing that about thinking clearly and in your opinion, should it be like as long as you're thinking clearly and have a well articulated point of view, understanding you know, both understand trade offs? Is that the key? Or are there some specific points of view that you would say 90% of app companies should think about platform in this way? And, you know, unless there's a specific reason that you shouldn't,
I think it's the former, I think it's that you need to think carefully about what you want to be and why given you know, what you make your industry, your target market here, your corporate DNA as to how you think about these things that give us clear thinking. And mostly, if I go to an app company, and ask them five or 10 questions along the lines that we've been talking about here, they'll give me a series of inconsistent mudding you know, answers that don't really make sense taken together. That much like I'm surprised when I occasionally go in somewhere, and I'll get clear answers. No, to me, there isn't a right or wrong, because you're essentially choosing to position yourself deliberately somewhere on the spectrum of I'm just an app that people can use as it is, or on a platform which can be extended to repurposed in various ways and
maybe I'll add one or maybe a one piece of advice to people from outside you're trying to build on a platform or one of the bigger vendors never be the first right? if if if a big vendor announces the platform only build on it when their own engineers are building on it. Right?
So a fair enough Thomas I'll keep an eye on the time and I just brought the tally up. Vitaly, please weigh in
haven Honey. Yeah, great are Vitaly is our is our is our top guest he's he's on every week. He's winning. He's winning the is one of our most consistent visitors. So Vitaly, welcome. Your question, sir.
Thank you, Thomas. And I think the time just ADM works beautifully for me. So thanks for having at least one show. That can work. And David, thank you for, you know, all the content that you share with us. It was a great talk. So my question is more about like the maybe kind of a little bit of redefinition of a platform in kind of this day and age where and usually used to think about platforms is, you know, something that runs code, or let's say something similar to code. But then you kind of provided the Bill Gates definition, which is, you know, something that allows the ecosystem kind of generate more more value than the company that provides it in in that regard. I'm wondering, what is your kind of look on companies that let's play the kind of taking different spin, and I'm talking primarily on the API companies like stripe, and Twilio and plaid. And you know, there's more similar to that, that are, again, not exactly platforms in the classical sense, but they do enable a wide array of use cases for the people who use them.
Yes, good. Good question. And it's probably pretty illegal to dimension, another analyst in front of Thomas, and maybe Dave, but I will anyway, so I think Ben Thompson, who writes strategically, is quite an interesting thinker on some of these topics. And he would distinguish between the platform, which is mostly what we've talked about, and then an aggregator, which is a company that, you know, provides technology that essentially, you know, owns demand in a given area. So it's, you know, sort of in Google on demand and search, because that's everyone searches there. So they, they then can, you know, rent that demand out to suppliers who are trying to advertise to those people. So I think there is, we're kind of at a time to tease out this distinction. But I think, yeah, there's a distinction between the platform business where you're directly using the thing they have, and then an aggregator who has some technology, but it was more of that cornering, really cornering a demand in the marketplace, and then sort of offering that to people who want to supply things to do not demand. So yeah, I think it was a we pretty much have time to dig into today. But there's that that is an important distinction to draw. Yeah. Thank you. That's great.
So we are we are at the top of our I had a whole lot of questions, David about his golf experience. Actually, let's finish with that. David, tell us about your program experienced as a wrap up for today's session.
It's kind of embarrassing. I got roped into a golf tournament and like, I'm terrible, but sort of sponsored tournaments and they got to play with the pros and who did you play with? And I pick a genre and is a Spanish golfer. And so he was kind of my most, most famous partner over the course of the weekend, but he was pretty good, actually. Surprisingly, unwilling to engage in conversation about Basque separatism, which I was hoping to open to discuss with him, and he wanted to stick mostly to the stick not finishing, but to the golf. Right. Yeah.
Well, well. David, we were gonna have to have you back on the show. I think. If everyone agrees, let's have a look. Clap for that. But I would love to have you. I'd love to have you back on. Dave, do you want to close the show?
Sure.
Thanks very much. Hey, David, thank you What a great session. That was. Thanks to everybody who joined. We will see you next week where we have Brett quaner, former Salesforce alum, current venture capitalist, informal seed, Siebel executive. And these we Thomas has been recording these and we are releasing this as a podcast.
Yeah, it should be a podcast will be out in the next at least by the weekend. If not, if not tomorrow. So do do keep an eye out for the podcast and do tell everyone about our show. And I look forward to seeing you next week. And I thanks very, very much, David for coming on the show. And Dave as always great host great co host and see you guys next week.
Yeah, thank you all voted the session with you. We're at the Sex Pistols concert. Remember that?
