Positioning platform engineering in a down market

Abi: Well, I just got back from a bike ride where I listened to your talk at PlatformCon and just made me so excited for this conversation because you have such a unique personal experience and perspective on platform investments and platform teams. And in today’s macro environment, one trend I’ve been seeing is a lot of platform teams and DevX teams unfortunately getting laid off. And so today I’m hoping that this conversation and your personal experiences can hopefully provide some advice and guidance to leaders of these teams to navigate the times. And so I’d love to just dive right into your personal story at Meetup, which as I understand began with you joining that organization and going through an acquisition and dissolving a platform team. So I’d love for you to take us through that story and I’ll ask questions along the way.

Brian: I confess I did do that and learned some interesting lessons I think as part of that. But yeah, so thanks so much for having me on today. It’s a really interesting macro environment. It’s tough and I extend my sympathies and condolences to folks who have been caught up in layoffs or going through them in some other capacity. It’s a really, really rough thing emotionally. If you’d like to talk about it, reach out to me. I’m happy to chat and give you an e-hug or whatever I can. But it’s also coming at, I think, a really interesting inflection point for the conversation around operations teams, DevOps, platform engineering, sort of the interplay of those two things. But just to give you some of my background. So I started my career at ThoughtWorks many years ago. Spent a bunch of time as a consultant with them, part of or in proximity to some of the early thinkers around the DevOps movement there. Got to know some of those folks a little bit, wandered off, did the startup thing for a little while.

My startups died and sank into the swamp. And at any rate, I wound up joining and working at Meetup for a little while as a director of engineering there working with their platform team, than eventually as head of platform that eventually is head of engineering more generally at a really weird and difficult inflection point I think for Meetup where Meetup had been acquired by WeWork. WeWork then subsequently imploded rather spectacularly and made the decision to divest themselves of all of the random bits and bobs they picked up along the way. Or maybe not all of them, almost all of them. And Meetup was one of those. It was one of their, I think from a branding standpoint, it was one of their splashier acquisitions. There was a lot of talk about synergies between ah, Meetup needs space, WeWork has space and wouldn’t that be great?

It was all the wrong kinds of space. So unfortunately did not have the much desired synergies, and as a result, we experimented with business models a little bit. There’s a bit of a nudge from WeWork there as well. And at any rate, WeWork imploded, Meetup went with that. And so the first thing we had to do is turn around and execute on some layoffs. And I think every single company in the WeWork portfolio did that. Really, really rough time for everyone involved. And part of that was trying to figure out, okay, this company is 20 years old. What does this mean for us in this present moment? And how are we going to reframe what we’re doing? And at that time I had been head of platform engineering and then moved into this sort of VP role for the period of that transition. And I had to figure out what I was going to do with our product engineering organization to move us forward.

And the talk that you’re referencing in a given PlatformCon is sort of this provocative framing, which is that maybe the optimal cost of a platform engineering team is zero, right? Because in principle, if you’re a company that builds products, if you’re doing product engineering, then ideally every dollar and every brain cell you spend working on your core concern is put towards advancing that product in some way. And platform engineering at the time for us was somewhat amorphously defined. I think now is interesting because it’s starting to get a little bit tighter and I’d love to learn from you and how you’re framing your thinking about that at DX. But at that time we’re trying to figure out what’s the relationship going to be between platform and product going forward. And the decision I made at the time was I would like all of that money and all of those brain cells to be put towards product and I would like to try to deemphasize the role or the relationship between these two departments.

My belief was that we would advance further and faster if we brought those people together. Did sort of what I think of as the classic DevOps, the classic framing of DevOps, which is that DevOps is a collaboration model, it’s a culture. It’s not a discrete separation of responsibilities. It’s simply a way of thinking about how to bring people with operational concerns and people with development concerns together so that the software that you produce is faster, better, easier to maintain, better operationalized, everyone goes on call so that the risk goes down in terms of maintaining the software and improving over time. That was the idea. It didn’t exact, I mean it didn’t remove the need for operational work by any stretch of the imagination. We still had a core product with a large footprint. We ended up, I think, bringing back a little bit of a separation of concerns there and ironically sort of going back to the battle days of bringing most of the operational folks together in one team. But for what we needed at the time, it was a very workable model I think I’d say, right?

I won’t say it was spectacular or anything, but it did what we needed it to do. And by the way, just huge credit and shout out to everyone who was part of that journey. I think everyone was a little frazzled. We had layoffs from WeWork and then COVID hit and then Meetup famously as a company that encourages people to come together and meet in real life. So COVID not an ideal macro environment for us as a business.

Abi: Well, thanks so much for sharing that story. First of all, it’s a candid story and a difficult time that you as a leader in your organization and of course so many people involved there had to go through. So I’d love to just follow up on some of the things that you’ve already shared thus far. And I want to start with something you just touched on at the very beginning where you said we’re at an interesting inflection point with regard to, and you said platform ops. And that was interesting to me because what do you see right now as there’s all kinds of shapes and flavors of this platform ops type stuff going on? How do you see the space right now? Do you see a lot of teams basically doing the same things, similar things just called different things? Or do you see distinct different functions and focuses out there?

Brian: I think the way people think about platform as a concern is starting to solidify a little bit. I will say in candor that when I took on a job doing platform engineering, I’m not sure that I had a solid definition in my mind of exactly what that should be or could encompass. And I’m not sure that the organization did either. We just knew we needed something. And I think I see that changing a little bit. And I think the macro trend that I see here is that companies are moving away from this conception of, well, I don’t know. We have this sort of aspirational model of DevOps as this collaboration and culture style that in most places, at least in my experience or in the sense I have of the industry more broadly, more or less immediately moved into operational teams, traditional operational teams with an expanded or altered skillset.

And I think what I see in platform engineering is sort of a healthy re-embrace of a model in which platform is seen and developer experience are generally seen as a first class concern of developers within an enterprise. But rather than being about filing tickets or writing cloud form templates or whatever, it’s about building a healthy API, a healthy interface from the folks who are doing more product work to the team or the tool set or whatever the capabilities that allow them to make maximal use of their time working on the product side. I think that’s finally sort of elevating itself as the face of platform engineering and useful contrast to how we’ve thought about ops or DevOps historically. And I’ll give a shout out here to Charity Majors who I think is awesome and I really look to as a leading light in these conversations. She published an article a few weeks ago just hot off the presses that starts to articulate this stuff really, really well and it’s starting to change, I think, my thinking or at least help my thinking around how that stuff gets framed.

Abi: One thing that’s so interesting about your story that listeners could have missed is you came in as the head of platform engineering and then ultimately ended up dissolving the platform engineering org as VP of engineering. You had mentioned to me before that you actually came into that role already with sort of a preconceived opinion that platform teams aren’t always a good investment. Where did that opinion come from? Was it during the process of learning, when you joined the company that was your initial impression, or did that come from experiences at other companies where you’d seen the same pattern kind of play out?

Brian: Yeah, sure. I want to offer a quick correction. I didn’t join immediately as the head of platform engineering. I did move into that role later. And I would never want to shortchange the wonderful person who was head when I came in, Lena Krug, she’s super cool and she ended up doing a bunch of architecture work there that was super impactful and now she’s moved on to other stuff. But at any rate, yeah, I mean to answer your question, I think I did come in with a lot of skepticism. Is this a good investment? I’ve been through a lot of microservices and more broadly architecture transitions. And I’m very skeptical that in a lot of cases, by the time you reach the end of that journey, that the product organization is actually iterating faster and more effectively than it did before. I think that there are a lot of different ways to think about software architecture, but that the overarching goal in my mind is the goal of a software business is to use money to hire people to make software to make more money.

And fast iteration in very abstract terms is finding a way to do that more efficiently, more effectively, like finding a way to move into revenue generating activity more quickly. And we as engineers like to and often do spend a bunch of time investing in our own productivity. But there’s a real question in my mind as to whether or not the time invested in productivity is a net payoff by the time you’ve finished the investment work. You go back and you say, I’m going to shatter this thing out into its own service and it’s going to be great, it’ll make us so much faster. But if it takes you three months to make the change, you would better hope that you are so much better off by the end of that change that you can make up for the lost time in between. Now that’s kind of an abstract model and I’m not sure it’s always entirely fair, but in gross terms, right, there’s an opportunity cost to doing productivity work. When is that going to pay off? You have a model for understanding that. I don’t know, does that answer your question?

Abi: Yeah, and you brought up microservices. So I sort of wanted to add my own perspective that not only are these types of investments, not only do these types of investments not always pay off, but a lot of these investments into things like microservices are often new things, almost new fads in the industry. And so companies sort of pursue them haphazardly, and that I think contributes to the problem of them not really paying off in terms of business impact and value. Around the decision to dissolve the platform team in particular, what was that conversation like? Did it come as a surprise to the members of those teams? Not maybe the layoffs, it sounds like it was a turbulent time for the business. But was there sort of a question of why that team? Was there a conversation around that?

Brian: I think what we said was like, if the reason why you have, at least in that framing or in that conception, there are two reasons why you have something called platform engineering. One is operational support, keep the lights on, keep the rain off the heads of folks who are doing other work. And the second is accelerate the rate of change for software developers and help them move more quickly in the product realm. And for the former, we still needed that support, but there are other forms that the support could take. And for the latter, I tend to think that some of what larger companies do for internal platform development can feel like an indulgence a little bit. Those companies can afford to get away with targeted localized investments in developer tooling that small companies can’t because they want to keep everyone as close to the product side as possible.

And so the determination we were making in that instance is we were a company that had a little bit more money and a little bit more size. We’re now moving into a different environment, we’re going to be a little bit smaller, we’ll be a little bit more focused. Can we still afford to make that investment? Are we still the kind of company that can and should be making large scale structural investments in developer productivity when there exists open source libraries, third party tooling, when there exists things that can help us move us forward in that sphere without us having to pay an engineer to build a tool set that then we have to maintain in perpetuity?

And if there’s any structural problem that affected Meetup deeply, it was the need to maintain lots of bespoke software in perpetuity. So what can we do to get out of that habit of rebuilding developer experience solutions again and again and move towards a platform or a framework for thinking about how we do these things that leverage the support of the open source community, the support of the broader technical community? What can we do to accelerate our progress in that direction?

Abi: And I really love that perspective. I mean, it’s probably difficult to hear if you’re on the other side of it, but yeah, it is the reality of how someone in your role at that time had to think about this decision and how a lot of companies out there today are having to perhaps wrestle with decision as well. I’m curious to know what happened after. So you sort of mentioned you had this belief that some of that platform work was sort of, indulgence maybe isn’t the right word, but not core to what was needed at that time at the company. And you had, I think, a belief that some of that work could and should be just absorbed by the product engineering teams themselves. So I’m curious, did that happen or did that work just die off in your view?

Brian: I think a lot of it did happen. Yeah, I mean the example that comes to mind for me most immediately is that Meetup had hired a couple of spectacularly talented web developers who’d built a React platform for doing server side rendering. Meetup is a piece of software that relies heavily on SEO. It was really important to us to have a good SEO experience, but we also wanted to have modern tooling for the website. And so Meetup built a fabulous internal web platform that in its aims and particulars was largely replicated, I think, in the wild by tools like Gatsby and Next JS, right? That it was a problem shared by a lot of React shops. And so that tooling became more widely available. And so part of the transition away from that was to sort of make, you make the hard left turn that is difficult to make when people are comfortable with the status quo where you say we need to make some tough decisions.

And one of those is we have this awesome tooling, we’ve poured a bunch of money into it, everyone loves and admires and respects the human beings involved. Can we afford this? Right? Is it meaningful for us to continue to support our own bespoke tooling for something that the broader community has invested a lot of time and effort in? I do a lot of Next JS work these days, and candidly, my answer is, I don’t know, maybe. There are things that I wish Next JS did a little bit better. And I think in looking back in hindsight did pretty well. But I don’t think it was that shocking to folks.

And I think that because of the extreme nature of what had happened, folks were a little bit more willing to go along with that and also because everyone really wanted it to happen. I think everyone who came along for the journey really to the enormous credit of the founders of Meetup and the human beings involved, they really wanted the thing to work. Everyone knew that the software process could stand some improvement. There were probably opportunities out there to take advantage of that we weren’t in a position beforehand, so folks were, I should say it was a turbulent time and not every decision was met with extraordinary celebration or joy, but I think that on the technical strategy side, folks seemed pretty bought in.

Abi: I’d love to shift now, and thanks so much for sharing in candor, like your experiences at Meetup. I think it’s going to be really valuable for leaders of platform teams to hear the sort of counter perspective of navigating through turbulent times. And that’s what I really want to talk about now is we are in a turbulent time right now with the current macro environment. In your view, how can leaders of platform teams, what’s your advice for navigating this moment? How do they avoid getting laid off? How do they avoid being viewed as a target or unnecessary cost center in their businesses?

Brian: That’s a phenomenal question. And here, I don’t know, I hope I can help, but the number one thing to me is you have to appear valuable. Doing advocacy is really important. Doing outreach is really important. Treating the work that you do as a product and engaging with the rest of the organization through product framing, I think, is really important. In the same way that a startup has a challenge to make people thrilled about the work that they’re doing because you’re trying to build a constituency, I don’t want to sound or seem political about it. I think that genuinely a platform team needs to frame the thing that it’s doing as a service that it’s offering the organization and you want that service to be safe and healthy for the people who are providing it. You need to make it sustainable and engaging, but you also want the people in the other end of that relationship to feel like the money that the organization’s putting into that work feels like they’re getting it back.

For every dollar that you’re putting into a platform engineering organization, you want to feel like you’re getting back more than a dollar’s worth of investment from whatever metric you choose to frame it around as a leader or that your organization is assessing you against, whether that’s developer productivity or operational overhead or whatever, your goal becomes, I think, how do I make sure that people don’t think of this as overhead, but think of it as an investment that pays dividends? Which is why I sort of like this framing of if the ideal size of a platform team is zero, if every dollar is optimally put towards product engineering work, how do you make it feel as though every dollar put towards platform engineering, it has to be multiplicative. It has to pay back to the organization. So you’re doing in some ways sort of classic optimization work.

How do I make sure that the work I’m doing is as broadly impactful as it can be, is as high quality as it can be, is as specific and engaging to the problems that my developers have as it can be, so that when people wake up in the morning, they say, oh, think goodness these folks exist and not, oh God, I have to use this crappy framework that these three people in some of their city built and what am I going to do about that? And I think it can be both of those things at once. I keep on thinking back to SoundCloud, which had a really interesting journey towards microservices. And one of the things that looking back at it they did spectacularly well, I think, is that they had a standardized, centralized library that all of these services were expected to use. And that meant that every single service could be deployed and operationalized and observed in the same way.

It was really, really, really useful. But the thing that made it irritating is because there was one team maintaining that software and because the team maintaining software, the library I should say, had no visibility into the impact of a breaking change, every once in a while they would change a method name and ship out a new version of the library. And every single team that was downstream of that platform team had to take responsibility for going in and figuring out what broke, because it was not a monorepo, there were no automated refactoring tools, you didn’t have visibility across repositories. I think that starting to get better in the industry, but at the time there was simply no way of propagating that change out.

And so the cost of that upgrade was borne by every other team within the organization. So how can you provide all of the benefits of here is a thing that does what you need it to do only much better than you would probably do it yourself? You need people to feel and understand the impact of that, to understand that what they’re giving up in autonomy is paid back more than double in terms of the benefits that they gain from the utility of that software. And then make sure that people feel thrilled when they use it, not downstream of a change that they have no control over, but active participants in a product that’s evolving that they get really excited about.

Abi: Well, I love that story and the advice you’ve shared. I was taking notes as you spoke, and to me it sounds like it kind of boils down to three things. You started with talking about how advocacy and communication need to be a good storyteller. It sounds like you need to be constantly communicating and reselling the value of what you’re doing and demonstrating the impact you’re having. At the same time, it’s also table stakes to make sure you’re focusing on the right problems, problems that matter to the business, and also actually doing the job well building the right solution. I’d love to ask you about focusing on the right problem. How should platform leaders today be making sure, and you shared a few tips in passing already, but how should platform leaders be thinking about making sure they’re focusing on the right things?

Brian: That’s another fantastic question and I wish, I mean, I think it’s going to be situationally dependent. It depends heavily on what does your organization value? What the outputs of the system are are in large part determined by the constraints and the expectations of that system. What does your system expect of you? What does the organization want from product engineering? How does it gauge success? Is it revenue? Is it features produced? Is it usage? What’s the macro target that your organization is optimizing for? And ask yourself, how does standardized tooling help accelerate our journey in that direction? And you can meaningfully pick a variety of different ways of thinking about this, right? Can you optimize performance? Can you build standardized performance measurement tools or help optimize the performance of the core library such that when people using it get an elevated experience more broadly. Is it around monetization?

Can you do optimization work around payments flows or whatever? Can you absorb that service as a platform level concern and then make sure that it’s high quality for everyone? Are there ways that you can smooth the path towards the provisioning of new services or the creation of new experiences? One thing that’s been staggering to me as I get older is just the sheer complexity of the cloud ecosystem these days. We at Workspace are doing an a la carte cloud thing, and it’s actually been really, really pleasant. It’s pretty straightforward. You simply pick the thing you want, you have a relationship with that one vendor, and it’s not, whatever, I’m not God’s gift to software, but I’m finding it relatively sustainable so far. And this stuff has become staggeringly complex. And so I think finding the right abstraction for your organization and then making sure that people can get bought into those, that’s a way of speaking to, whatever.

If the organizational constraint is around deploying more services into production more rapidly or engaging with the product development process more frequently and shipping things out to customers more aggressively, how can you smooth that path as much as possible? And I think there’s a ton of interesting work that’s sort of happening now in that space. And I think that that’s becoming a macro concern for everyone is we don’t want to build our own platform internally. We’re not going to go and build our own Heroku or whatever it is, right? What’s out there that we can use to smooth that particular path?

Abi: Love that advice. That’s funny about building our own Heroku. We actually use Heroku. I’ve been using it since 2010.

Brian: It’s awesome.

Abi: I’d love to get your advice on the other piece of the puzzle that we touched on earlier, which is the advocacy and the communication. And something I always think about is a lot of platform teams don’t have PMs. A lot of platform teams are really heavy with the tool builder sort of archetype of engineer and engineering leader who maybe aren’t as experienced in stakeholder management and communicating with the business. And as you touch on, that’s so important, especially in the current environment. So as you’re a pretty seasoned executive, what kind of advice would you have to someone who’s maybe been an engineer for the past 10 years of their career and just stepped into a platform leadership role? What are the conversations, the presentations they need to be having that should be on their checklist?

Brian: Well, so I think that’s an interesting question, and I say that to all your questions because they’re all interesting questions. But one thing that I think about is that, in some ways it’s a bad answer, but that’s the responsibility of leadership more generally, right? Leadership, when you step into a leadership role, advocacy and communication become part of the job responsibility. It’s important not just to do great work, but for people to understand how that work reflects on the business, how that work benefits the people who are downstream of it. So I’ve said that in general, building up communication skills, building up the ability to advocate for your own team, it’s hugely important for your team’s role and relationship within the broader organization. It’s not enough to do great engineering work. People have to feel it. I think sometimes engineers sort of discount the value of marketing, but marketing at its finest to me is simply communicating effectively about the work that you’ve done.

If you genuinely believe you’ve built something great, it’s important for people to understand how that great thing impacts their lives and how they can engage with it to make it better. And I think that’s part of it. When I was at Meetup in that platform engineering role, I tried to get budget to hire a product manager and I couldn’t convince anyone that having a full-time product manager for a platform engineering team was a thing, which I regret. I wish I’d pushed harder on it. I think it would’ve made a difference in how we approached it. But even if you can’t get budget for a full-time PM hire, there are all sorts of things that you can do to build feedback loops around those relationships I think that are meaningful and useful. One thing that we experimented with was bringing in tech leaders or engineering leaders from the rest of the organization to come be an advocate on behalf of their team with the platform engineering team as sort of a proxy PM.

So we’re bringing you into our sprint planning process, here’s the things that we’re planning on working on, can you give us a sense of what’s highest priority for you? Can we engage you with that process? Which then in turn makes them feel like they have a stake in the work because when they advocate for something and it gets delivered, that’s really exciting. They can take that back to their team and say, look at this cool thing. And it turns them into advocates hopefully for your organization. You’re making allies of people who you want to be users of your software. So even if you can’t or don’t want to hire a full-time PM, it’s really important to cultivate relationships with your customers and your constituents in the organization. And so one way you can do that is simply grab those people, bring them in and say, hey, are you interested in giving me two hours of time a week?

I’d love for you to be part of our planning process. One trick that we used to play at ThoughtWorks actually in difficult stakeholder management is like, if you have a rough sense of what your, God help me, velocity is, you have a budget of points that you can play with. You hand off eight points to this one person and say, you pick eight points worth of stories, you pick 12 points worth of stories. The devs were doing refactoring work, they get to pick five points. The rest, who knows. But you can sort of carve those off and treat that as a proxy for a monetary budget with a very time constrained view.

This is our one week or two week of perspective on what gets delivered. Rather than having people fight endlessly over what’s highest priority, you simply give them a budget and say knock yourself out. And that can be really invigorating and get you out of a bunch of nasty conversations around prioritization. And also, I just like to talk about it because I think it’s a super effective tactic and I wish people would use it more often. Velocity isn’t an ideal tool in a lot of ways, but having a budget you can allocate is super, super handy.

Abi: Yeah, it’s really interesting the analogy to how you would manage projects at ThoughtWorks with clients because what I hear you kind of saying is treat the engineers and teams at your company as if they were your customers in the same way that you would do consulting work for an outside firm.

I really like that analogy. One thing you’ve said a couple times, and I know you mentioned in your talk and I know it’s sort of a provocation, is that the optimal spend for platform is $0. And this just came to my mind, but I was reading something earlier this morning, actually. I think it came from, I’m going to butcher the pronunciation of his name, but Jean-Michel, he was the former CTO at Shopify. And he’s working on a book where he talks about platform engineering and he’s published something that says the optimal investment in platform is 50%. 50% platform, 40% features, and 10% experiments. So I’m curious to get your reaction or reconcile that kind of point of view with your experience.

Brian: I don’t know, far be it from me to contradict someone who’s delivered software at that scale. That’s super interesting and I’ll have to go take a look at that. But absent a reading of the article, I’m not sure I have a good framework. I mean, the framework I think about is that companies pay for lots of things that don’t necessarily contribute directly to their bottom line, and they do it as operational overhead. And companies are always trying to ask themselves, which of these things is meaningful for us to own and possess in house, and which of these things is meaningful for us to outsource or pay a third party for or whatever. And I think I’d say the sort of macro trend in the SaaS world is that more and more of those things are, this didn’t necessarily happen yesterday, right? Companies use third parties for all sorts of things.

But the macro trend with a lot of SaaS stuff is how can I offload this responsibility so that I don’t have to think about it anymore? And so that to the degree it’s business overhead, it’s business overhead that I can manage through a vendor relationship rather than an employee relationship. But no company wakes, well, unless you are a provider of infrastructure and cloud services, most companies don’t wake up in the morning and say, how can I make the best infrastructure in cloud services I possibly can? It is a side effect of their need to run software at scale. It’s not the thing that they produce, right? Customers probably aren’t paying you for your infrastructure unless you’re, again, explicitly selling infrastructure. They’re paying you because they want the thing that you’re making that you provide for them. And infrastructure is a means to that end. And a developer acceleration is a means to that end.

And so, in an ideal world, I would have software that’s always clean, ready to go, optimally structured for fast feature production. I would always be able to reach for a serverless interface whenever I need it so that I can deploy something into production and scales automatically and I don’t have to worry about it. And my belief with serverless is that while the APIs and interfaces to me often feel like they’re not quite there yet, the general trend towards here’s a function, please go run it is a powerful one and one that we’ll see grow over time. I think they’re in an interesting sort of dip where Lambda came out and excited a lot of people. And then I think there have been some struggles around the developer experience around that and all sorts of folks in our building really useful extractions on top of that aligned away a lot of the complexity of the underlying interviews platform. And also, whatever.

There are people who have spectacular experiences with Lambda and that’s fine too. But I think that the general impulse of a business is how do I focus as much time and attention on the thing I’m producing? There’s another, there’s a great old talk there called Boring Technology Club. Have you seen this one? Oh, I love this thing. It’s a former engineer at Etsy who talks a little bit about, look, if you’re trying to solve a big problem, one framework to think about this through is, I only have so many innovation tokens to spend, right? Let’s say I’m Stripe and I’m trying to raise the GDP of the internet. That seems hard. I’ll spend an innovation token on that. Given that human beings only have so much time and attention and brain power, do you really want to spend one of your innovation tokens on some highly elaborate database?

Is the juice worth the squeeze with that stuff? Or are you better off simply picking a technology that you know but hate? And I think there’s a really strong use case for picking a technology that you know but hate. You may not get up in the morning and get super excited about it, but at least to the degree it fails, you’ll know how it fails and why it fails and be able to work around it effectively. To me, Ruby on Rails sort of falls pretty comfortably into that category. Hate is too strong a word, but I’ve had good experiences and less good experiences with it over the years. But by and large, it’s excellent. I still think it’s first in class at what it does.

If what your job is to shift domain objects into production, it’s spectacular at that. And to the degree its frameworks have faults, which you didn’t hear from me, you can work around them effectively if you’ve been doing Ruby on Rail for a while. And so there’s an argument there for minimizing the innovation tokens that you spend frittering away on things that seem cool but you don’t know how to do yet, because the things that you don’t know how to do yet will have their own flaws. Whatever you love today, you’ll come to hate tomorrow except Clojure. Clojure will always be great.

Abi: One thing that was really interesting to me that you mentioned was that businesses won’t always only invest in things that actually contribute to their bottom line. And it made me speculate. I also am not super familiar with how Shopify came upon the 50% being the optimal investment in platform, but I do know Shopify.

Brian: If you do a lot of rails work there, maybe Rails needs it.

Abi: That’s funny. I love Rails. But they are big on developer happiness. That’s one of their sort of mottoes, if you will, and they run a big developer happiness survey. And so I wanted to ask you about that, right? There’s a really good argument around looking at things in terms of a dollar in and more than a dollar out, but how does developer happiness also factor into the calculus around investments and platform? If the experience of developing software at a company is just unpleasant, even if it’s maybe not slowing the business down in a sort of calculably detrimental way, is there a cost you can place on sentiment and happiness and quality of life for developers in a large organization?

I think one thing I’ve been doing is looking into a lot of the peer reviewed research around developer happiness and its impact on performance. And there’s definitely a positive relationship between happiness and performance, both in the immediate sense of there’s research showing that developers perform better at tasks when they’re in a certain emotional cognitive state. However, I think the understanding of how developer happiness translates into monetary value, which is the question I posed to you is one that’s yet unanswered.

Brian: Yeah, I don’t have a good framework for that one. I think that you can make an argument that, through that sort of ideal spend of zero framework, like ideally people are deliriously happy already, but we don’t live in an ideal world. We live in a world with complicated software choices that don’t always fit the shape of the problem that we’re trying to solve. And so what are we going to do to smooth past those? Which leads you into the conclusion that I’ve heard other people make and I eventually came to, which is that the optimal spend is not zero. The optimal spend is something greater than zero. I would be fascinated to hear an argument that the optimal spend is 50%, and I think I’d buy it.

If they have numbers on that, that’d be super interesting to hear, right? Because it would change my whole way of framing how to think about that problem. And from a separation of concern standpoint, maybe there’s a thing there. But I think in some ways it relies on really thoughtful, careful choices about where you choose to spend that platform engineering time. Because some of it’s going to rebound to your benefit and some of it won’t, right? And so how do you manage that optics conversation internally at your company?

Abi: Yeah, that’s a really interesting point. Brian, I think your perspectives and the advice you’ve shared today will hopefully be really valuable to leaders who are navigating the current times. Really enjoyed this conversation. Thanks so much for coming on the show.

Brian: Thanks so much for having me on. I love the show. It was a super fun time of day. It was great to get a chance to chat. And for anyone out there going through a tough time, let me know if I can help with anything and best of luck. Take care.

‍

‍

‍