Tobi: Hello, friends. This is the Alphalist Podcast. I am your host, Tobi. The goal of the Alphalist Podcast is to empower CTOs with the info and insight they need to make the best decisions for their company. We do this by hosting top thought leaders and picking their brains for insights into technical leadership and tech trends.
Tobi: If you believe in the power of accumulated knowledge to accelerate growth, Make sure to subscribe to this podcast. Plus, if you're an experienced CTO, you will love the discussion happening in our Slack space where over 600 CTOs are sharing insights or visit one of our events. Just go to alphalist. com to apply.
Tobi: Welcome to the Alphalist podcast, where we explore the minds of some of the most fascinating technical leaders shaping the future of engineering. I'm your host, Tobi, and today I'm excited to have a guest whose insights and experience. are game changing for any engineering leader. Joining us is Camille Fournier from New York City.
Tobi: Camille is the former managing director, or one of the former managing directors, at JPMorgan Chase. She was acting in the technical function there, and she's the author of The Manager's Path, a go to book for engineering managers, and her latest book, Platform Engineering, a guide for technical, product, and business. Tobi: People Leaders has just been released a few days ago, I guess, right? Is that correct? About Camille: a month ago, maybe. Yes.
Tobi: About a month ago. And yeah, I mean, you obviously, um, like working for many big companies, um, and, and recently JP Morgan, you, you, you might know how to build and scale platforms, um, at startup and enterprises. Tobi: And, um, that's what we want to, want to chat about today. Camille: All right, well, I'm excited to be here.
Tobi: Great. So, um, maybe we start before we jump into platform engineering with your personal path through your engineering or into your engineering career. Like, why did you become ultimately a nerd or geek and, and what, what, what do you find fascinating about engineering?
Camille: Sure. Um, I mean, I've been a geek for a long time, so I was definitely one of those kids that loved computers. Um, I built my own computers in high school and installed Linux on, you know, I think it was CD ROMs, not quite floppy discs. I'm, I'm not quite that old. Um, you know, and, and so I've alway always been into.
Camille: You know, computers and tech stuff. And, um, I, you know, I went to college for computer science. Um, and, you know, I, and I, I did that because, I mean, look, I'm interested in a lot of things and I've kind of worked in a career of companies that are not, you know, pure tech companies for the most part because I am interested, you know, in In areas of business in the world beyond tech, but I love technology.
Camille: I love, um, well, I don't really write code anymore, although I have been doing advent of code this year for the first time, like seriously in a long time. And it's like, really like exercising some unused muscles for me. But you know, I like building systems. I like thinking about it. You know, the kind of logic puzzles of technology and, um, and I enjoy, I enjoy, you know, nowadays really like leading teams that are having to think about.
Camille: Those kinds of puzzles and, you know, the kinds of teams I've been managing most recently have been, you know, very sort of technical expert teams, the teams that are building platforms, the teams that you know, really understand how, you know, storage and disks and you know, storing blobs of data onto said disks works or, you know, really understand the network, really understand, you know, sort of the compute strata or the cloud Um, I, I do find like that technical detail of the work to be really just, it's fun, they're fun puzzles, it's fun problems, it, you know, combines science and problem solving and engineering and, uh, I guess that's, that's how I got into it.
Camille: I, I really enjoy that type of thing. Tobi: Okay. And how did that then turn into a fascination about a blog post? platform engineering and building platforms. Camille: Yeah, so, um, so I've always been sort of interested in, you know, what we, what we have called at certain times kind of back end software, right? So, you know, less, I don't have a very good eye for, um, building, you know, interactive and visual things.
Camille: I appreciate very much that skill. It is not one that I, that I possess. Um, and. You know, and more than that, I'm really, I am really interested in kind of like, look, I installed Linux on my, you know, home built computer when I was in high school. Like, I actually am interested in sort of the systems engineering, the, you know, the actual kind of hardware to software layer.
Camille: Um, and so I, I got into platform, I mean, you know, partly by chance I was hired to do a platform engineering, you know, lead platform engineering for a Company here in New York City called Two Sigma. Um, and so that was about eight years ago. I got hired into that job and it was actually a great fit for me because I had come off of being like a CTO at a startup where you do everything, right?
Camille: So you've got, you know, I, everything from IT, front end, back end. This was a, you know, a clothing rental company. We had warehouses, warehouse software, customer service software. So you've got everything web desk, web, mobile, all that kind of stuff. Um, and, uh, but before that I had mostly been building kind of large scale distributed systems.
Camille: Um, so I worked on the Apache Zookeeper project because I built a, global service discovery system, um, for, you know, one of the big finance companies here in New York city. Um, and, you know, I've always been interested in kind of that infrastructure software layer. Um, the idea of building software systems that sit in between kind of the hardware and the, and the building blocks, um, and application developers, people who are, you know, using that, that platform to actually build applications that serve various business purposes.
Camille: So, um, you know, when that opportunity came up at, uh, Two Sigma, you know, it just felt like a great fit because I do understand, you know, I understand hardware somewhat. I understand sort of the software interfaces and interactions with hardware and, and how to think about building these kind of large scale distributed systems.
Camille: And I just find that work really interesting. And and really challenging. And I also care a lot about building software for other developers. I really like, um, I like thinking about that customer group and, you know, what is it that people like? And I, I would not call myself like a brilliant, um, you know, product manager in that space.
Camille: That's, that's not really my skill set, but I do find it very interesting to think about, like, how can I make other people productive? How can I, you know, You know, how can I and my teams, you know, build systems that make the experience of working at this company for software engineers, like, significantly better. Camille: I'm really inspired by doing that kind of work.
Tobi: And, um, is the so called platform team or the platform, which is mostly like a central thing in an organization, um, is that the, the, the ultimate, ultimate. Um, continuation of, of, of, of DevOps and, and, and the, the, the, the attempt to, to centralize that. Camille: Yeah. You know, it, I, I have to admit that I, I had never really thought of it that way, right?
Camille: So, you know, I've been doing agile and. Proto DevOps, you know, almost before it like got a name, right? Like the idea that you would not support your own software, um, was somewhat foreign to me even early in my career. So, you know, the teams that I happen to work on, I think really embraced, like, very early Agile concepts, um, extreme programming for anyone old enough to remember that, you know, very early variant of Agile, but, um, you know, because of the type of team we were and where we sat in, you in this particular bank.
Camille: We actually did a lot of support for our own software. So it was not like we had big teams that we just sort of handed off the the code to. Um, and I don't actually know why that was in retrospect. I don't know if that was just the people who kind of set up this software platform that we were building, um, really believed that you would do your best work if you also had some, some amount of support responsibilities.
Camille: And I'm sure we had, you know, there was definitely support teams for like the actual You know, databases and things like that. But for the actual software, a lot of times we would be kind of responsible for, for supporting it. And so, I guess I have always, and deploying it, right, so deploying it, all those things that I feel like traditionally we talked about kind of the DevOps teams doing, even though of course DevOps itself was all about developers doing, developers and operators kind of coming together into one role or, or filling those functions both as needed.
Camille: So I obviously am a believer that DevOps is valuable. I've done it, you know, I've, I've been that person. Um, that being said, uh, I think that what we, what we see a lot of times in the way that people end up implementing DevOps is that you do get a real fragmentation of. experiences with the both like the software development and deployment support as well as the like actual kind of kind of production support experience from team by team.
Camille: Right. So on the one hand, I think it is a good idea that developers be responsible for supporting their own code. I think that just, like, it makes you much more sensitive to what works and what doesn't. Much less likely to throw things over the wall. It creates better dynamics. Like, there's just, there's a, you know, a laundry list of things that are good about that model.
Camille: Um, but, most developers are not experts at everything. And I think that there has been a real You know, this kind of trend that started with DevOps and continues to push every time you hear something like shift left, even though, you know, shift left security, shift left UX, shift left accessibility, where, you know, the meaning of that is like, oh, you push it earlier and earlier in the development cycle, um, so that, you know, you catch it earlier and you think about it and you design for it.
Camille: All of these concepts are very reasonable It all starts to mean that you're overloading developers with lots of jobs, right? Um, and I think that in the case of I think that in the case of any kind of system where, you know, there's a lot of complexity, let's just start with Kubernetes, right? I do think that, like it or not, you know, in a lot of ways, Kubernetes is the start of platform engineering for most people.
Camille: Um, because Kubernetes was a big open source software platform, not just sort of open source as a service, right? So Let's compare and contrast. Like, Kubernetes, you can really build stuff into it, um, where, and you can run it in a multi tenant way, right? Whereas a lot of these things, like, you know, a lot of open source systems prior to that, like databases, open source databases, Zookeeper, you know, you've just get, they're much harder to really effectively run in a multi tenant way.
Camille: Um, then systems like Kubernetes. So, I think Kubernetes kind of, you know, created this thing that was easier to build on top of, easier to support large, kind of, large teams, large, multiple different teams using it for multiple different purposes, but supported maybe by one team. Um, and I just, like, I don't think it's realistic for every single software team to have somebody who understands how to run Kubernetes on that team.
Camille: In the same way that I don't think it's particularly reasonable to have are realistic for every single software team to have people to do infrastructure engineering, who do a bunch of terraform wrangling. Maybe if the software you're building is pretty simple, and that isn't very much work, it's fine.
Camille: But there comes a point in which if you're, you got a big company, and you're building a lot of complex, software, and you've got a lot of different complex, you know, build and release processes, there's only so many people that have the expertise and the interest in doing that work. And trying to have it sharded out to every team means you're going to have very uneven experiences across those teams.
Camille: And even ignoring kind of the efficiencies, like, is it more efficient to be run in a central team or not? I think there's plenty of pros and cons on that. I just think that, you know, you, you often set people up for failure. by either expecting everyone to be everything to everyone, which I think is a little bit of a downside of DevOps, um, or by having one or two people on every team who are the DevOps person, or who are the build and test person, or who are the whatever person, where if you're on an application team and you're that person, what's your promotion path really look like?
Camille: What does your growth really look like? You're the one off on that team. You know, it's an okay thing to do for a little while, But my experience is that those people, you know, tend to kind of churn pretty quickly because they're, they feel either alone, they don't feel like they have a promotion path, they don't feel like they're tied in to the critical work of the team.
Camille: So I think platform engineering is kind of a recognition that we have a lot of complexity. that has, you know, built up over the last 10 years. Um, that the cloud has not actually simplified much for any of us at all. That just overloading development teams to do more and more and more and more may not work that effectively.
Camille: And that we can do more than just sort of centralize for cost efficiency reasons. We can actually build software abstractions that will make the application developers able to deliver You know, better, faster, more reliably, um, if we put the people who are really passionate about that part of the software all together to think about and build these platforms.
Tobi: And, um, what would be your definition of the platform? I mean, you just mentioned Kubernetes, infrastructure and code, et cetera, et cetera. Um, is there like typically an internal tooling that needs to be. Built, uh, to, to, to out build the platform of a company? Or is it, is it potentially just standard tooling?
Camille: So, so we, we define platforms. We actually use, we use sort of a modified version in the book. And, and I, and I wanna be clear that other people have slightly different definitions of platforms, which is fine. Like, you know, this is what, this is what we think is interesting to talk about and interesting to work on.
Camille: Um. I'm not going to sit here and say if you have a different definition of platform, you're wrong. I just think, like, if you, in the context of the book and in the context of the work that I've done, um, the definition of platform we use is actually from someone named Evan Botker, published something I believe on, um, I think it was on like a Martin Fowler's blog, uh, back in 2018.
Camille: And with some updated terms, we, the, the definition we use is a platform is a foundation of self service APIs, tools, services, knowledge, and support that are arranged as a compelling internal product. Autonomous application teams can make, can make use of the platform to deliver product features at a higher pace with reduced coordination.
Camille: Now, we. Because we're talking about platform engineering in specific, we actually think that it's only interesting to talk about this if you're building things yourself. Now, that doesn't mean that you're building everything. That doesn't mean that you don't have cloud stuff, that you don't have open source products, that you don't have vendor products, right?
Camille: All of those things may very well be in the mix. But if there's no software engineering at all being done, It's probably not really platform engineering in, in the scale and scope that we talk about in the book. That's not to say there's not work to be done, but you know, in our, in our mind, the things that you do when you actually apply your own software to the problem, um, is that you're, you're actually willing to kind of change and shape and code the systems themselves to make them more scalable for multiple different types of use cases to create, you know, to really manage their complexity more effectively, um, deliver more business leverage, um, through curation of what you're offering, creating software based abstractions.
Camille: Um, and I just think that It's very hard to get the top value out of platform engineering if you're not willing to do the engineering part of it. So for us, that's how we define it. And I think, you know, that is a little bit different than your traditional DevOps, which I think was mostly focused, again, on like, you know, I'm making this work for this team.
Tobi: Yes, writing YAML files, writing YAML files recently, right? And maybe monitoring definitions, etc. Exactly. So, so, um, let's say the Oh, let's agree then that the, the, the, like the start of a platform would be if I hand every team an AWS account, uh, with own billing, uh, which is connected to my IDP through some code, which is maybe regularly in an automated way audited together with, I don't know, GitHub.
Tobi: Um, GitHub access plus like automatic scanning of, of diverse security issues, et cetera, which is like maybe partly open source, partly not together with metrics, um, uh, Prometheus, potentially stuff like that. Right. And, and that, like, combined, Camille: Yeah, Tobi: combination of open source together with like your internal rules and conditions on what to use and what not, right?
Tobi: Yes. And maybe one example which I'd love to discuss because like I run This, um, private equity company, uh, called SaaS Group, where we acquire small bootstrapped SaaS companies. And we're discussing back and forth, like, to what degree should we build a platform? To what degree is it, can it be successful?
Tobi: Because we have so many different Small companies that we, we, we, we add, um, on, on, on top of, of, uh, of, of, of the, the companies we already have. And, um, we're not combining them necessarily. So we want them to be independent. And I think that's also really Um, really, really important, uh, important also for other teams, um, also in, in, in other big companies, right?
Tobi: Where, where teams should really independently be able to spin up certain things and, and, and, and without having. Having a very steep learning curve. I think that's also super important. How do you see that? Like, is it possible? Does it make sense? And to what degree does it make sense to build that? Build something. Tobi: Can, can it still respect the, the, the, the, the wish for autonomy and independence and, and, and, uh, in a, in a, in a very, very colorful organization?
Camille: The answer is maybe. So here, here's what I would say. In general, we advise people who have small teams, you know, who are, you know, at companies that are, You know, fewer than 50 engineers where you are able to have kind of just like cooperation solving problems, right?
Camille: That things aren't getting neglected. Um, but everybody knows each other and they're, they all work pretty well together. And so, you know, as platform ish problems come up, somebody picks them up and deals with them. You know, we tend to advise people that you don't really need like a formal platform team in those situations.
Camille: And it may be that if the If all of your different little companies, right, are really very independent, maybe it's not worth doing. However, there is something to be said for saying, well, on the other hand, you know, you actually, you are, you know, you have a situation where you've got a lot of different independent teams that probably aren't thinking about one another.
Camille: And the question is, do we want to build up a commons area that is just makes their lives a lot easier, right? So do we want to have a much easier way of, you know, provisioning and managing, like you said, your AWS accounts, right? And your, and your, you know, if they're all, if they're all kind of, do we, do we want to standardize the way that we think about A few pieces of this stack that aren't particularly differentiating for the value that these companies are providing in order to frankly drive some efficiencies.
Camille: I mean, look, if you're in private equity, efficiency driving is kind of part of the game here, right? Sure. And so you don't want to, you know, I don't know that you would want to say, oh, we're going to standardize, for example, all the programming languages and every tool every team uses. Yeah. You know, how you do your, your sprints or whatever, right?
Camille: But, you may want to say look like we are, we're going to push most people to use AWS because we're going to do contract negotiations at scale with AWS for all of us. And, Part of the way we actually get value out of that negotiated contract is we kind of need to know what's going on everywhere. And that starts to lead us to having a platform, right?
Camille: We, we have company, we have sort of the umbrella company provided vendor and vendor arrangements where it seems we can negotiate more effectively, um, as a group. And then we need to build in some software that makes it easy for us to know what's going on in that. And also, frankly, we just think this stuff is not, it's not differentiating to the company to, you know, have everybody have, you know, a standard AWS account format, for example, and a standard, you know, standard ways of provisioning that.
Camille: Um, and so, Tobi: And a secure way to access it, right? Camille: Yes. I mean, security actually maybe Compliance kicks in quite Tobi: early, yeah, yeah. Compliance and security is quite important, yeah. Camille: Yes, yes, exactly. And I think, you know, especially if you're, again, if you're acquiring a lot of small companies, now, you know, if you now have liability, For, for what's going on there.
Camille: And it's like, look, like we should do better for everyone. Part of the value of you being part of this portfolio is that you don't have to worry as much about security because we've got these experts for compliance. You know, we've got these experts, but you know, you've got to use this part of the platform to get that value because we can't You know, we can't just, you know, build one off solutions for every single one.
Tobi: How does success look like from your perspective? I mean, obviously you can push everyone into like a very stiff setup that people like or dislike. So, so acceptance or? Camille: You know, I would probably be in some ways a more successful, a more successful leader if I was more dogmatic, um, about, uh, about absolute, uh, adherence to my way of doing things.
Camille: I feel like you, you win some, you lose some with that, but at scale, um, the, that's kind of the way companies seem, seem to work. And I'm, I'm a little too, uh, ambivalent about telling people precisely what to do. But, which is funny for someone who's written multiple books, but there, there you have it. So, okay, so that, that aside, I do think that, you know, you want people to be using the thing you're building or else why are you building it, right?
Camille: So the more people you are getting to use, you know, the more of your portfolio companies that you're getting to use your platform, the more justifiable it is for you to have been putting in that effort. But I think that There are different ways to approach that, you know, truth, right? So a lot of times people approach that truth as, therefore, I am going to mandate that everybody use my thing.
Camille: And therefore, I, you know, I win, right? And they, and if they don't use it, it's their fault, and we're going to punish them, and we're going to, you know, You know, we're going to, you know, complain about them to the big boss, you know, whatever. Um, and, and so my belief is that, like, especially in the first two thirds of your kind of platform journey, you actually really want to be not trying to force people, but trying to encourage people.
Camille: Try to build something that people really want, right? I said that I, one of the things I like about platform engineering is I actually care a lot about about the experiences of the people that are using the software that I and my teams are building. Like, I care about that a lot. I don't understand why I would want to make someone's work experience worse by the tools and technology that I'm providing for them.
Camille: Like, that You know, it's going to happen occasionally because we're imperfect and like, you know, I, nobody builds perfect software, but like my goal is to make people's lives on balance significantly better and not make them feel like they are being straightjacketed into software that doesn't really meet their needs, that they're being slowed down, like then you're Then you're, you know, you're really hurting yourself, right?
Camille: You don't want to be building something that is hard for people to use and limiting for them and slows them down. You're kind of losing a lot of the value of the platform in pursuit of this sort of adoption goal. So, while I do think that adoption is important, I also think that people can really get It can really put blinders on you if you, if you just view that as your own goal.
Camille: And you also want to think about how do people feel about the software that you're building? Do they like it? Are you listening to your customers? Are you actually, you know, doing, just getting customer satisfaction metrics, right? About, about how things Uh, you know, how, how they feel about things. Now, I do think that like customer satisfaction metrics are a little bit imperfect.
Camille: I actually have a little bit of a, a rant at the end of the book about like, look, CSAT scores are great. If you actually have a sample population, if you only ask the people that love your stuff, how they feel about your stuff, and then you, You know, you talk about how great your CSAT scores are, which I have seen happen, and I do not, you know, like, you actually, you undermine everybody's trust in you, right?
Camille: Trust is actually a big thing, though. I think that one, one topic we haven't touched on, but I, that I think is actually really important, and it goes back to almost the DevOps part of this job, you should be operating what you're building. So there's, there's got to be some kind of operational component here.
Camille: Now, this is, you know, This is not something that everybody finds obvious. And I actually see a lot, I've seen a lot in teams I've managed, I see a lot in companies I've spoken to, that people are like, well, I'm going to build a framework, I'm going to build a library, I'm going to build a blueprint, and I'm going to give that to you.
Camille: And that helps, right? And that is true. It does help, right? It, you know, Giving somebody a good framework, giving someone a good blueprint, a good library, is useful work, but it's not the same, uh, leverage and value add as running the code for them, updating the code for them, managing it, making sure it stays secure, making sure if it, has incidents that you are actually being paged for it, right?
Camille: Um, the leverage of real platform engineering comes when you're operating what you've built. But that means that people need to really trust you to operate it well. And so a lot of times what we've seen in platform teams is we see kind of like two, two like polar opposites. You see the platform team that is made up more of like either classic like ops or DevOps y people.
Camille: And they do a lot of like. Open source as a service, um, so they'll run, you know, they run your databases for you. They run Zookeeper for you, right? They, they run Kafka for you. Um, and they're always sort of stressed out because they're always like having to create these like specialty versions of whatever for whatever team because they're not, they, they, they, they operate things well and they think a lot about the operations, but they don't apply kind of the software engineering mindset enough to the problem to say like, open source as a service.
Camille: Kubernetes, and a few more more modern things a little bit aside, is not a great, like, scalable way to offer these, these options. And in fact, a lot of these cases, it might just be better to get a SaaS offering for it, right? Um, On the other hand, you see, you see software engineers that build platforms who don't actually care about operations at all.
Camille: So they want to do the, they want to do the fun software engineering where they want to do the fun, like hard technical work of, you know, building these integrations and building this kind of cool software that, you know, has all your, you Security checks and compliance checks and whatever. Um, but they don't really want to like get paged if something gets broken.
Camille: And so both of these teams have different challenges that they need to resolve. And actually the resolution is that you want a team that blends both of these skill sets and blends these kinds of people together instead of having them separate. Tobi: Yeah, you can't, you can't really separate it, right? You Camille: can't really separate it.
Camille: But it is, you know, in the concept of, like, what does success look like, trust is a big part of success. If you want to build good platforms and you want to say, are my platforms successful, beyond, like, your CSAT scores, do people trust your platform? Do they trust when, you know, do they trust that when something breaks, You're on top of it.
Camille: If it's, if it, you know, if it's you, right? Do they trust that, that it's likely that if they're seeing an issue, they can figure out from whether it's you or them, so they're not waking you up all the time for problems that are in fact in their own code, right? Is there just this, you know, is there trust that, beyond that, is there trust that you're going to deliver what you said you were going to deliver, right?
Camille: Is there trust that you're going to listen to them when they, and they complain to you. Um, I actually, for me, that's one of the most important signs of a successful platform team is like, do people trust you? Because, you know, when we talk about platform, platform engineering, platform teams and companies, especially because these teams tend to be most, you know, important and valuable in large companies, the larger the company, the more The more important and valuable they can be.
Camille: Um, that trust is so important. It's so important to build and maintain. And, you know, it comes through, you know, building things that people like it comes through. You know, people feeling like they can reliably, you know, use your software and trust its operability for their critical business processes.
Camille: They, you know, they trust that you're going to do what you say you're going to do. Um, you know, if you're thinking about, like, what does success look like for my platforms, do people trust you? Like, don't, don't skip that part of it, right? Don't skip that direct, to go directly to customer satisfaction or joy or adoption or whatever, because like, you can force adoption on platforms that people don't trust. Camille: But you are creating a very bad situation for everybody involved.
Tobi: And to get trust, you have to properly communicate, um, uh, communicate expectations, uh, deliver on expectations, um, and, and be very transparent and also be, be your, your platform's biggest fan in terms of like being an expert, right? Like if you, I don't know, you run Cassandra, like my most beloved piece of software, and you don't have to, you don't have a clue of how to run Cassandra, then people will smell it after a while, right?
Tobi: Like, if the platform goes up and down the whole time, and I don't know, your database is super slow, um, and, and, and then it's kind of logic that people jump off. Tobi: And, um, so you, you kind of treat it as a product, right? Do you? Like, you treat it as if it's like an internal product and you, as a leader, you, you, you should ultimately be, be the product manager of it, right?
Camille: Yeah. So, um, I definitely, yes. So yes, um, I've written a lot about platform products and there's a long chapter in the book, uh, on the topic of platform as a product, because yes, you need to curate your offerings and think of them as products, right?
Camille: And so you need to put. A product manager mindset. In fact, I actually encourage people to hire a small number of product managers with the caveats that it's really hard to find platform product managers. Um, it's not quite the same job as like a consumer facing or, you know, SaaS product or business facing product manager.
Camille: It's got overlapping skills, but it's not exactly the same. Um, but yes, I think. I think having, first of all, just having that very like customer focused mindset of, you know, the people who use my software, even though we are colleagues, they are also my customers. And I, you know, and, you know, you, you, colleagues, you know, can be that jerk in that cubicle over there, or that jerk on the Zoom call, you know?
Camille: Customers, you might still think they're jerks, but like, they're your customers. You care about them. You know, your, your business succeeds or fails without your customers. And similarly, your platform kind of succeeds or fails without your customers. Right. Um, so absolutely. I think, you know, viewing your platform And, and thinking of it as product offerings with, you know, with an actual kind of product strategy, what are the big pain points that we are going to try to address?
Camille: You know, how are we thinking about nuanced metrics of success? Are we creating theories about what's wrong? You know, what's slowing people down? Or, you know, what would make this more, what would make this part of the business or this, this kind of, this type of engineering more effective? Are we then, you know.
Camille: actually designing somewhat experiments, right? So we're going to, we're going to invest in speeding up our storage systems because we think that, you know, the storage speed is actually making it, you know, hard for us to run simulations at scale. And therefore we're not getting data fast enough to make, you know, faster market decisions.
Camille: Okay. I've clearly worked in finance for a long time. Um, so we're going to speed this up. But we, you know, we need to actually then have a little bit of a closing the loop of like, is that making a difference or not? Like, because the, because, you know, back to the point of trust and communication.
Camille: Communicating how your platform is making a difference to people, particularly to senior leadership who may be less technical, may not be paying attention, may be hearing from a few squeaky wheels about how they're unhappy, With the platforms, there's always a few people that are unhappy, you know, being able to point to your successes is just, it's good.
Camille: It's a good, it's a good habit to get into. It's a good habit for leaders to get into. It's a good habit for leaders of internal technology, I think, to get into and something that a lot of people kind of neglect. Tobi: Does that work through metrics? Um, like, I don't know, developer experience, developer productivity, uh, like, uh, very well known metrics in the last two years, right?
Tobi: Uh, or, or, or popular things that, that everyone wants to look at and no one really does successfully together with, like in the private equity co, uh, case, maybe, maybe cost, right? Like bottom line. Uh, like we, we, we, we move the bottom line, uh, dearly downwards. Um, is, is that a good starting point? Potentially.
Camille: Yeah, I think that's a good starting point. I think, um, I also think that you kind of, so I think it can be easy to get into like really big metrics, right? Like cost, cost and whatever developer productivity means, which I think there, as you, as you sort of alluded to, um, I haven't even seen that many companies really do just the basic DORA metrics all that well.
Camille: And I think those are the ones that I like. I can easily get behind the DORA metrics. I think those are very solid, very well researched metrics. Just measure those effectively. And I have seen a lot of companies struggle to even do that. So trying to go beyond that, maybe to the space metrics or to whatever other kind of, I don't know, people, people promise a lot about developer metrics.
Camille: It's not at all clear to me how many companies measure them well, measure them in a comparable way. But all that aside, that is to say, I think those are all very good sort of high level things to keep in mind. And certainly you want to be measuring them as best you can and reporting on them. But you also want to think about like, The quarter by quarter, the smaller things that you're doing.
Camille: And how are you talking about those? Because it's not just like the biggest things that matter. It's also the like, again, it's the trickle of smaller things that you are enabling. Some of the things you're going to do are just like. This was not possible before and now it is possible, right? And that's not all of your work, right?
Camille: I think people can get hung up on like, well, we, you know, we enabled X, so therefore we are successful. It's like, well, did it matter that you enabled X or not, right? Um, but some of it's going to be, this wasn't possible, it is now possible. Some of it is going to be, you know, cycle times, developer metrics.
Camille: Some of it's going to be cost, right? Um, Some of it's going to be, look, like measurable performance improvements for the subsystems that you're, that you're using. Um, so I think there's a lot of different things you can measure. The point is more that you, as a leader, you are constantly thinking about what's the story we're going to tell about the work that we're doing?
Camille: Like, you know, a little bit of that, that Amazon, you know, the Amazon product managers, like, write, like, the press release before the product. Um, So that it's like, oh, you know, if this was successful, like, what would the press release look like? Which I think, you know, is it, I, I have very rarely done that, but like, I think that's a good way to think about, like, what does, like, wild success that we would actually put out to the press look like?
Camille: Um, forces you to think about, like, what, you know, what is really articulable, understandable to a wide audience? Because I think platform teams often, don't think enough about, hey, we've got to like communicate this to lots of people that may or may not really understand the nitty gritty of like, you know, IOPS, and like, oh, we like, you know, fixed this, you know, this encoding problem, and you know, there's all kinds of like obscure things that we sometimes have to fix that people won't appreciate, but you still want to talk about them in a way that they will appreciate.
Camille: Because people understanding your work and how your work is making the business more successful, that is really important. Tobi: Yeah, and I know so many teams that would just answer, well, what we do is not special, so I don't want to talk about it, right? Camille: Yeah, that's I, you know, I, I don't know what to say except, like, actually, like, first of all, what you do is awesome.
Camille: Like, you know, if you're listening to this and you're like, oh, I'm on a platform team, but like, it's not that special. It's like, like, like, that's crazy. You're doing fun stuff. You're doing, like, yes, of course, some of our jobs, everybody's job has some drudgery in it. Um, but the work you do matters, or else why are you doing it?
Camille: Right. Um, and. And I think, you know, and actually I think, you know, the, the job as a leader, my job as a leader is to help people understand why the work they do matters, right? And even if it's weird, obscure, deep technical work, it's help them tell the story of how their work matters because that's what you need to do to get recognition, to get promotions, to get whatever, like, you know, that's a little bit of, this is just like company politics, but.
Camille: You know, some of it's also like helping people refine their own sense of like how work connects to the larger story of the company, um, means that they get better at picking what to work on, which is important because no leader tells every single person in their company what to do precisely, right? You need people to understand kind of relative value.
Camille: You then be able to think about like, what is, you know, what is the larger group doing and how does my work fit into it? Because When people make day to day decisions, which most people do, you know, the better they understand what's important and what isn't, and they choose to follow what they understand to be important, which is a different story, um, the better that, you know, your company's going to do, right?
Camille: That's like part of the job. So I would say, You know, if you're an engineer and you're like, I just don't know why my work matters, you know, it's a little bit of like, your manager should be helping you understand that. And managers, if you're listening to this and you're like, oh my god, like, I'm just not really sure I know why my work matters, like, get on that, because that's actually pretty important, right?
Camille: Your job should not just be like, showing up and, you know, doing some boring ticket and going home. I, I, I want better for all of us.
Tobi: Yeah, that's really a problem in engineering from my perspective that, um, most people just don't care so much about, um, like advertising, um, talking about their work, right? Um, they, about their achievements, about their successes, um, this is like, I would say special in engineering, but also in, in, in, in smaller tech companies, like people just think like, Hey, what I do isn't special.
Tobi: So, which. It's in most companies not the case and there's like really hidden gems that others can profit from also internally, right? Um, if you talk about that, like with my 20 portfolio companies, like people should interact, people should share knowledge, um, and people can, other people can profit from that, right?
Tobi: Um, how do you prevent? Let's say that the typical issue that, um, we've seen that with, with DevOps, uh, DevOps people in, in the teams, right? When you have, like, let's say you have a small company and you have one person working in DevOps, then there's a lot, I would, I would argue there's a lot of the, the work being done, not necessarily necessary, um, and, um, maybe also, let's say career, um, Or a keep alive mechanism for the DevOps person's career, potentially.
Tobi: How do we prevent that in platform teams? Like that you're over engineering, that you're building like two complex Infrastructure, um, yeah. This, Camille: yeah. Just to keep thing Tobi: alive, Camille: so, right. That's, that's a great, that's a great question and, and it's not an easy one to answer. So like on the one hand, right, your, your DevOps, your loan DevOps engineer on a team, like part of, part of what I said earlier, right?
Camille: Part of the value of platform engineering can very well be that like. You're not the lone DevOps engineer on the team anymore. Like you're in a, you're in an organization, all of people that are all doing this at a larger scale, and therefore you have people to work with and you know, people to learn from.
Camille: And, and that's just, that tends to be just good for, for everyone. If you can make that work, if you're at the right scale of company to make that work, which is definitely not a tiny company. Um, over-engineering. Over-engineering happens everywhere for sure. And it definitely happens on product, um, platform teams.
Camille: It also happens on product teams. Let's be clear. Actually, what I, what I see happen on product teams or application teams, um, not platform teams, is that they over engineer, this is an aside, but it's an important one, they over engineer when they have product managers or business managers or whatever that give them, that give them no freedom to help shape what's being built.
Camille: Meaning that when you have this like weird, people have this weird idea that like, oh, the, if the product manager Uh, you know, says the what, and the engineers say the how, that's fine, but the reality is, like, the how is not often that interesting, uh, these days. There's a lot of how that's like, and maybe this will all go away and AI will just write all our code for us, but, you know, there's a lot of how that's like, you know, it's, it's, you know, it's blocking, it's tackling, it's just like, you know, throwing some code down.
Camille: You know, it may be interesting the first year that you do it, but after a year or two, you're like, all right, like, great. I'm gonna add another button to this page. I'm gonna, you know, I'm gonna change this to that. I'm gonna, like, you know, if you, if your engineers on your, on your product slash application teams, not platform teams, feel like they have no voice in what is being built at all, because they are so dominated by a product manager or you know, business manager or whatever, right?
Camille: Um, they are going to over engineer something, I can 100 percent promise you, every single place I have worked at where that has happened, weird stuff has come out. Some team you've create, you create shadow platforms, you create Weirdly, it's like, oh, well, for us to do this, we need a 20 node Cassandra cluster to, you know, handle our, you know, 20 gigs of data, because, like, that's the only way to, like, make sure that if a nuclear strike attacks both Germany and New York City at the same time, we won't lose anything, right?
Camille: You know, like, like, you will, so, so, as an aside, for anybody who happens to be in that space, You know, if you over control, if you view engineers as like cogs to be given very precise tickets to implement, um, maybe AI will just do that for you someday and therefore you won't have to worry about this problem, but today, uh, they are probably over engineering something.
Camille: underneath. And you should really be looking out for that. And probably you would be getting better outputs if you brought them a little bit more along on deciding what to build in the first place. Because they're creative and they're smart and they probably have some ideas. Okay. Over engineering happens in product teams.
Camille: Over engineering happens more in platform teams. I will 100 percent agree. And that is why it is so important. So important if you're going to build a platform team to be very thoughtful about how you are communicating what you are working on, how you are deciding what to work on, um, and, and, you know, and how you're setting goals and holding your team accountable for delivery.
Camille: So what I see is that, look, I just, I think that you, this is a leadership problem more than anything else. Um, leaders who don't want to have hard conversations with people about what is important to work on and who aren't willing to, to say no, actually, we really am, we should not rewrite the system. I know it's sort of annoying to you that it has these flaws, but rewriting it is going to take.
Camille: twice as long as we think it's going to take. It's going to cost us a lot of momentum, and it's not going to really provide value. If your leaders on your platform team aren't willing to have those hard conversations, you are going to get people over engineering things. Um, now, on the other hand, you do need to have thoughtful processes for evaluating what needs to happen, because there are times when your platform team is right.
Camille: We cannot scale this existing system. Like this existing system, if this company doubles in size, is going to fall over. If this, or if the, if the volume of X, Y, or Z doubles in size, it's going to fall over. And it's going to be very expensive. for us to fix it then, we should be investing in fixing it now.
Camille: It's kind of the job of, like, this, like, platform engineering leaders kind of need to know platform engineering to do the job, because you gotta be able to tell when that is true and when that's bullshit. And I, you know, I've done the job, right? That's, that's my, my technical background is large scale distributed systems.
Camille: I know, I know enough about certain parts of it, and I know how to hire people who know the other parts of it. This is kind of like, like, I think this is a big, it's a big risk when you're hiring platform teams and you're hiring platform leaders. Um, you want people who are good managers, but you also want people who kind of know the space because It is much harder to know the technical yes or no in this than it can be in certain other areas.
Tobi: So ultimately, you have someone who worked as an engineer and then maybe as a CTO or in DevOps, so who did infrastructure, who then turned into a leader. So that's where the CTO comes into play. Also likes product management. You Camille: know, that's actually the one thing I worry about with, uh, I sort of tell people after I've written the book, I'm like, you know, I really believe in platform engineering.
Camille: I wrote a book on it because I really believe in it. But I sometimes sit back and wonder, Maybe this is just like not something very many people can do. Like, you know, like that, like, like to be a little bit, you know, a little bit arrogant, like myself and my co author are both very good at these things.
Camille: And maybe Like, we're not very, you know, like, maybe this is, this is something that there's not actually all that many, I, I don't know, but I'd like to believe people can learn how to do this, like, I, you know, I do, I'd like to believe that people can learn how to do this and that, you know, they would be willing to do it, I think it's not just that, that we're good, it's also that, like, it's actually really hard, like, there's a lot of just hard stuff that's like, how do you do planning really well, how do you do, like, how, all that communication stuff, it's, I wasn't born knowing how to do this.
Camille: Like I had to spend a lot of years learning how to communicate to Tobi: various types of executives, right? Camille: I spent a lot of years learning how to do large scale infrastructure, project management, planning, and communication. Uh, that's not, you know, I think these are all learnable things. Like I was not born knowing how to do this, but it isn't easy stuff.
Camille: Right. Um, and so. However, again, I think there's a lot of tips and, like, like, the book is full of, like, ideas for how to break these kinds of problems down, right? The planning issue. How do you break down the planning issue? Unfortunately, it's work, but it's like, look, like, if you've read anything about, oh, Amazon does it this way, or like, let's do OKRs.
Camille: If you've read any of those leadership books or any of those leadership blog posts about just do X, Y, Z, Um, the truth is, it's never just do X, Y, Z. It's always actually figure out what really works for you. And for your team, and then teach a bunch of people how to do it, and then do it in iteration for a few years until you all get pretty good at doing it, and then you'll be able to do XYZ, right?
Camille: OKRs, uh, writing six pagers, right? Like, planning, none of these things is easy. easy in any form. Um, but I do think that it's important. So I think on the technical side of like, you know, calling, trying to, trying to avoid overengineering on the, on platform teams and trying to avoid like projects that don't matter.
Camille: Actually, while I think being able to call bullshit is really important, like, some of the shortcuts are, do they have a plan? Do they have a plan that has milestones in it? Do they even have a plan for the first half that has milestones in it? Maybe you don't have the whole plan, but you got the first half plan.
Camille: Can you Think about what the benefits might be. Can you even, even if not in, in, uh, metric form, just in like qualitative form, with something slightly more tangible feeling, can you write that down, right? There's a lot of different approaches you can take. I find that even when I'm not an expert, and there's plenty of platform level technical areas I am definitely not an expert.
Camille: Networking is a great example. I do not Know anything about networking, but. You know, I think it's also okay to ask people, you know, detailed questions about it and then frankly like gut check people with other people, right? So like, if you've got a few people that are good at networking in your company, even if you're not, Um, and you can get them all to agree on something.
Camille: It's probably the right thing to do. You still want to ask them questions and press them on it, but now whether it's the right thing to invest in now is a different, that's a management skill, right? But like, whether this is something that it needs to be done, I think, you know, I don't Like, this is just part of management and executive leadership, is like figuring out for areas that you're not the deep expert in, how to, how to tell who knows it well, how to get that kind of meta expertise of the people on your team, or maybe the people in your wider network.
Camille: Maybe you call in a consultant to help, right? There's a lot of different ways to do this, uh, but Like, you've got to ask the questions and you've got to be willing to say no. If you're not willing to, like, ask the questions and say no ever, you're gonna overengineer occasionally, no matter what you do, but, like, you're definitely gonna overengineer if you as a manager is, like, never willing to be like, we shouldn't do that.
Tobi: So I have hard conversations. Um, I was just about to, like, shortly come to the, to, to, to the, to the, to the finish line and ask you for, Three top tips for CTOs who wanna, , wanna start, uh, building a platform, but you just gave 10, right? So , Camille: you know, uh, I mean, look, uh, read, read the book or skim it. At least. I, I, I really, you know, I, I actually think we put a lot in there and it is a book for leaders.
Camille: It's a book for. You know, it's, this is not about the technical implementation details of writing platforms. There's, there's some technical stuff in there, but not, not very much. And as long as you are mildly technical, you will be able to generally understand it. Um, read the book. Uh, but, you know, I, I think, look, like, don't start it too early.
Camille: I actually, like, very, I feel like very often people who are trying to sell you something are like, do it now, you know, do it while you're a three person startup. We are not trying to sell you anything here. Don't do this if you don't need it. Um, but you know, if you need to do it and you're at the scale that you need to do it, I think we've got a lot of great advice in the book.
Camille: I would say, um, uh, you know, start, start small and start pragmatic. Start with a problem that you all, that you kind of everybody agrees that you have, right? You do not need to start by trying to build the be all end all platform for your company. You can start with like. Everybody is having trouble with, like, deployment.
Camille: And let's just like, like understand what's going on and make that easier for everybody, right? That's fine, like that's a perfectly fine way to start. Um, you know, you like figure out like some agreed upon common problems across your different engineering teams, and start with that and rack up some quick wins.
Camille: And some of that will be stuff that doesn't scale, right? Some of that will be like, I'm, we're just going to like help this team solve this problem, right? You don't want to, you don't want that to be the only way that you operate for the rest of your existence as you grow, as the company grows, and as you scale.
Camille: Um, you'll do some of that no matter what, but like, That's not, if all you're doing is like one off projects for various teams, you're not building a platform. You're just, you know, you're sort of an enablement team, which has value, but like, isn't really, it's not this kind of scaled thing, not the scaled leverage that I think we're talking about there.
Camille: Um, but a little bit of that. In order to, like, get people comfortable, in order to get to know what people are doing, um, because, frankly, working with other teams that have already, that have existing problems, and maybe even have solutions for those existing problems, is actually a great way to figure out what your platform should do.
Camille: Because a lot of the great ideas are not going to come from your platform team, they're going to come from product engineering teams or application engineering teams that had the problem first, and And their solution is probably not going to scale for the whole company, but it may have the beginnings of the best solution for the whole company. Tobi: So, do product discovery, right?
Camille: Very important. Anyway, lots, I have always had lots of advice on this topic, but I did write a book on it because, you know, I had a lot of thoughts. Because of Tobi: that, yeah. Camille: I had a lot of thoughts. You know, I, I do think the book is really, like, it is a dense book. There's a lot, there's a lot of stuff in it.
Camille: I think if you are a, if you are a scaled engineering manager, even if you're not in the platform space, there's probably some stuff in there that would be useful to you, unless you think you are already an expert at running, re architectures or large, large scale, large running projects or dealing with your own stake, internal stakeholders.
Camille: We've got a lot of good stuff on that, that is, you know, probably generalizable beyond platform engineering, but is very important for internal teams. Tobi: And you actually convinced Tim O'Reilly to publish it. So I think that's, uh, like enough said, right? Camille: You know, we've got an animal on the cover and everything. Camille: It's a Marvel movie.
Tobi: Great. Yeah, I have to absolutely check it out. And I hope my listeners do that as well. Um, let's, uh with a little surprise for you. Um, so I actually spoke to a, to a former colleague of you at JP Morgan Chase, uh, where you acted as managing director and built a platform and there is a hidden.
Tobi: Easter egg in a custom ingress that you wrote there, which is a little time machine feature that actually allows people using that ingress to travel back in time. And we now have the chance to jump back to the year 2020, When you were like just getting started with that platform and and also on the on the side writing that book and you now have the chance to whisper something into like like a little piece of advice into yourselves ears back then, what would it be?
Camille: Wow. Uh, if I was just to bring advice to myself in, well, if I was just to bring advice to myself in 2020, it would be knuckle, knuckle down because this, uh, this pandemic is going to be, 2020 is going to be a very, very difficult year. Uh, there's plenty of advice that's not appropriate for podcast. Um, yeah.
Camille: You know, I think the advice I always need that I give, give better to others than I give to myself is, is about picking your battles and, uh, you know, deciding what's really most important to focus on and abdicate for and what to just sort of let go, let be, let it, let it evolve itself, um, because You know, you can't fix everything.
Tobi: I have to give that advice to my wife as well. We have a lot of debates about it. It's uh, yeah, it's a real life advice, so thanks a lot for that. Um, thank you. So much for sharing your insights and experience. So I think the topic is really like hot for, for, for many out there still. And I think, uh, like people should consume your book and I will do that as well.
Tobi: Um, thanks a lot. Uh, I, I wish you a merry. Christmas or happy holidays, um, as we say these days. Um, and yeah, to my, to my listeners, uh, thanks for tuning in. It was, from my perspective, really enjoyable episode, and don't forget to like, to share, to subscribe. Until next time. Camille: Thank you. Tobi: Hope to see you soon, Camille.
Tobi: Bye bye. Bye. Thank you for listening to the Alphalist podcast. If you liked this episode, share it with friends, I'm sure they love it too. Make sure to subscribe so you can hear deep insights into technical leadership and technology trends as they become available. Also please tell us if there is a topic you would like to hear more about or a technical leader whose brain you would like us to pick.
Tobi: Alphalist is all about helping CTOs getting access to the insights. Please send us suggestions to cto at alphalist. com. Send me a message on LinkedIn or Twitter. After all, the more knowledge we bring to CTOs, the more growth we see in tech. Or as we say on Alphalist, accumulated knowledge to accelerate growth. Tobi: See you in the next episode.