API-soup into API platform - Conversation with Jabe Bloom - part 2

Transcript

Kristof:
Are there other places where you would want to invest complexity and in particular I am interested in… So one of my hypothesis is that humans need complexity to have like a human experience. And that means that you have to be able to invest some of your complexity budgets in your teams.

Jabe:
Sure. Yep.

Kristof:
How do you navigate that? And have you ever needed to navigate this?

Jabe:

Yeah, so here’s the things that I would start to talk about that like navigating. The first thing, and I talk about this at two different levels often, I talk about this is like… There’s two problems inside of organizations when we talk about organizational design. Let’s just start by saying that I use a term called designerly and designerly means the way that a designer would think about something as opposed to the way that like an engineer might think about something. And I think they’re different, the way that designers think and the way the engineers think. And to that extent, organization design is not designerly. It is organizational engineering. Most people who’ve been engaged in any sort of organization design have been engaged in organization engineering. It’s a rational process for assigning responsibilities through, you know, org charts and all sorts of stuff that are intended to do what we talked about at the beginning of the conversation, reduce uncertainty who’s responsible for, what, who do I talk to? Who do I, you know, with the single throat to choke nonsense, stuff like that. So it tries to make your organization deterministic. So organization design then I think is this thing that’s relatively unexplored and we should explore it more. Right. We should understand it and it should be informed by complexity. So the first thing I would say is that at two different levels we have problems. One is role-based descriptions. So everybody gets a role, what you should do. Terribly un-complexity defined, like ‘Who cares?’ Like, you know, in complexity, we don’t talk about ‘Define all the parts and then like stick the parts together and you get something.’ No, that’s not what we talk about, right? What we talk about is the interaction between the parts. So first thing you might wanna do, if you’re gonna do complexity informed organization design would be literally that role description should have a significant description of what roles they interact with and what those interactions are, like ‘Who does a software architect talk to? What do they talk about? How often do they meet? What are the interactions between the different roles?’ And so I think that’s really important. I would tend to also have this other argument around roles–just to start with, so we’ll do teams in a second, but roles now–which is that roles themselves can be inherently destructive or not useful because they have a residue or like memory of saying, ‘Okay, the architect is the person who architects.’ I have a problem with this. And at RedHat we call or, you know, inside the GTO at RedHat, we call this the five elements. And so we say is that to run an organization that’s creating software, you need a development capability–not role, but capability–, a operational capability, an architecture capability, a product management capability and leadership capability. Those are the five elements that you need or five capabilities that you need inside of an organization. And so that means you know, let’s take architecture, for instance, architecture isn’t done by architects. Architecture is a capability that a firm either has or does not have. And it’s done by everybody in the organization, right? Because product owners either are working in alignment with an architecture or not. Developers are either implementing the architecture or not. Operations: people are either influencing the architecture to become more operable or not. All of these capabilities are interacting with architecture. So again, you get this idea I think that there is a system of capabilities interacting with each other, and that is what you would want to understand if you were doing organizational design, you’d wanna understand what the capabilities are, how they interact. And I have like all these crazy spider-web versions of that, where I talk about the interactions, which might be fun to talk about at some point. I think if you wanna stick with roles, the first thing to do is you describe roles as in their interactions. Sometimes you’ll hear like Davis Snowden would call this crew theory. Like how do the, how do the roles interact with each other? Crew theory is I think more important in the military because like, you need certain, certain tasks to be performed. And if the person that performs that task is killed, then someone needs to be able to step in and do those tasks. And so that there’s more strict role-based kind of assignments in military theory, I think. In organizational theory, I think you could probably skip the roles and talk about capabilities and your responsibilities as an individual to perform certain capabilities. So that’s one thing. The second thing is teams. I really dislike the common term de-silo-ing. I think it’s not my favorite thing ever. Because I think that operators do different things than developers do. And I don’t think it’s great to think that you’re gonna turn your developers into operators and I don’t think it’s great to think you’re gonna turn your operators into developers. I do think it’s good that operators understand how to develop things for operations, but that’s a whole different discussion. They should be more like developers doing operations, but anyway. Sometimes I say to people–to understand that a little bit better–dev ops isn’t about consolidating development operations. It’s about developers becoming better developers by understanding the code in operation. And it’s about operators becoming better operators by understanding how code is developed. That’s what DevOps is. It’s not about smashing it into like a homogenous blob. As a result, then what I think is important when you’re doing organizational design is to less worry about what happens inside of the individual teams. Although, you know, probably having some description of their responsibilities, fine, but actually spend a significant amount of time, literally talking about how they interact. And so, like one of the things that I’m always surprised about–and, you know, I did a bunch of work with cats with call them around this, we used to call them cat naps, which is not a cat nap, but a cat nap. She’s very clever like that with her terminology. Anyway, and the idea was this and I’ve seen this a bunch of places, The Problem: which is someone rolls in with like an org-change, they change the teams and stuff like that. You’re assigned to a new team. Someone explains what your team is supposed to do. They never explain what any of the other teams are doing. They never explain to you, how the work you’re doing will like go to them, who who’s gonna talk to who, on which team, none of that stuff ever occurs, right? So to me, part of like an organizational transformation should be, every team should say, what teams do I interact with? And then they should all get in the room and say, how does our interaction work? Like what, what work do I hand to you? What work do you hand to me? Who talks to who, What are the topics, how often do we meet? Like how do we interact with each other? And again, ‘cause that to me is, is more complexity informed because it’s about interaction. It’s not about the parts, it’s about how the parts work together. And that conversation is just like absolutely missing from almost all organizational transformations that I’ve ever been involved in. People just, you know, they wanna reorganize into different teams and then they never want to have those other discussions. And I think that’s the highest kind of value conversations you can have at the team structure level. So does that help at all?
Kristof:
It’s really good to talk about the interconnections and how it’s all about interconnections, and putting a focus on that for, for people that are listening. That’s super important, I think. I need to tell a little bit more about our business to explain it. So we started we started as a Drupal consultancy long…uhm, 16 years ago. Along the way, we’ve tried to be self-organizing and non-hierarchical. We’ve bumped into issues with that. Like the tyranny of the structureless is something that we are on first speaker terms with. And what I’m trying to figure out is… well, at the same time for me, creating, doing business is about creating work experiences, is making sure that the people that I work with are not gonna hate their jobs. And that’s like a really important part of doing business because I’m part of a system in which those people are also parts. So if I make their life miserable, guess what, my life will also be miserable because, you know, we’re sharing a system. And so making sure that the experience is good is important, but at the same time, there’s a trade-off happening. Because if you don’t put any constraints, then you know, you get the structureless thing and then also guess what nobody’s happy again. Because you overspend your complexity budget. How do you navigate this? I don’t know if this is for this episode, maybe this is for a follow up episode where we go maybe deeper into the social aspect of systems, but it’s, this is like a big question that I’m chewing on. Because I’ve gotten to that we do need some form of hierarchy. Not all hierarchy is bad. Hierarchy is actually good. Or can be good. But there’s just, there’s a different way of doing hierarchy that respects the autonomy and the dignity of the people that are part of the system. And and then, yeah, figuring out how do you spend, or how do you give some complexity budgets to the team so that they can have their dignity and tell ‘em you’re respected?
Jabe:
So I mean, there’s a couple things that… so usually what I try to talk about, like complexity inside of social organizational structures. So there’s a couple things that I talk about. One is I think, it’s important under do you guys have an idea of a clique? You know what I mean? When I say clique, have you ever seen mean girls? The movie Mean Girls?
Kristof:
I haven’t seen it.
Jabe:
So it’s like this, in high school, did you have like groups of people? Clique. The weird thing about a clique is that it’s like a bunch of random people and then all of a sudden they’re together. And then all of a sudden there’s rules about who’s in the clique or who’s not, but who like, there’s usually almost never like an official leader. Who’s like in charge of the rules, the rules just kind of emerge. And part of the reason they emerge is to create the structure that is the clique, right? Yeah. They create a way of knowing who’s in the clique and who’s outta the clique and all that kind stuff. Right. So like, this is an example of what’s what Alicia calls “neurological recursion”. So neurology is just the study of parts and holes and recursion is the idea that there’s a loop and what she’s talking about when she talked about this, there’s a loop that goes between, the hierarchy and is the difference between bottom up and top down. Right? And so lots and lots of organizations, especially organizations that try to do agility or, you know, open space or, you know, holocracy or all these things are very concerned about bottom up stuff. But the argument that Alicia I think might make, or at least that I think she makes in her book is that bottom up is, does not create a new phase space ‘cause it doesn’t create closure in the system. So closure only happens when you get bottom up as the start. And then there’s some sort of test against the environment that says, does this configuration, this relatively random configuration of, I don’t know, people or components or whatever, does this work in the environment? And if it does, then there becomes a top down pressure to keep that unit organized. And that’s the top down aspect of it, right? So the hierarchical recursion is the idea that there’s bottom up pressures and then there’s top down pressures to keep the system together and that they happen in that kind of interweaved manner. I think the interesting thing to notice for me, at least the way that I think about this, is that the initial test ends up being against an environmental force. So you can configure something like a team. You put a team together and you see if they can operate together, that’s the test against the environment. And then when it does, they start making rules, right? About how we work and agreements and they build tools and that causes cohesion to occur, keeps the team together, right? Those stabilizing forces that happen in there are not from the environment, they’re from the team causing a loop to recurr that keeps them stabilized. So if the environment changes, one of the problems that you get is that some of these rules may no longer be valid in this new environment. They may keep the team together, but they may be counter effective to the actual environment that the team is addressing. So there’s some problems there that you have to kind of pay attention to. And so for that reason, one of the things I like to talk to people about, or try to convince people about is that you don’t wanna have… Well, you don’t, you should consider the difference between hierarchy and heterarchy. Heterarchy is context specific hierarchy. And if you embrace heterarchy, in other words, that we can organize our system into a hierarchy that’s specifically aligned to a particular context. Then one of the skills that you wanna learn is how to quickly build and take down hierarchies. In other words, you wanna understand how to create a hierarchy to respond to an event or a market opportunity. And then you wanna under understand equally. You wanna understand how to take it back apart so that you can build another one based on the next context that you enter. So the trick should be to, I think is to avoid the dogma of hierarchy is bad, but understand that hierarchy should be temporal. It shouldn’t be permanent. And that what you want is to be able to build temporary hierarchies that are responsive to market needs, not long standing hierarchies that are not like this. And I will tell you that, like that’s roughly me arguing against long standing teams, which is another agile dogma in my mind. And I think it’s important to understand that some of those dogmas get overplayed and people are dogmatic about them and that’s harmful to their organizations. So that’s, that’s one of the things I would think about is like, you know, think about not just the individual agency that you want the organization to have, but the organizational capability, the ability to organize yourselves as something that is missing in so many organizations. So many organizations can only be organized by a complete top down hierarchical command and control. The organization of the system is done that way. And that’s almost certainly… And, you know, plenty of people will talk about like, ‘I’m gonna have this top down organizational structure that I’ve imposed, but I’m gonna decentralize decision making.’ It’s nonsense. It’s because you think your organization is some sort of information processing system and it’s not. It’s a social system, that has to occasionally think about information, but that’s not what it’s there for. Anyway. So random rant.
Marc:
I want to quickly challenge you that on the… So first of all I agree that there should be no document about longstanding teams, but there’s equally an understanding that a lot of the issues that teams are solving have have long histories as in they are needed in a long time. So other, I think there’s a middle ground about hierarchies about, yes, you should always be aware that you might have to dismantle a hierarchy, but an other way to think about heterarchies is also that different hierarchies compete or coexist within a system. And at different times they have different weights in influence how they mediate the system as a whole. So in nature we have, we have seasons. Yeah. And so different parts of an organism will have stronger influence over the organism’s behavior depending on the season.
Jabe:
Absolutely.
Marc:
And I think we should think equally about organizations in this way. So when does a certain hierarchy need to have stronger influence and when does it need to tone it back? So hierarchy theory, for example, understands hierarchy just as facilitation of energy flows. And then, so if we, if we translate energy flows into value flows for organizations, then there are different times in the organizational’s whole life cycle where different values need to be favored over other values.
Jabe:
Hundred percent. Yep.
Kristof:
It’s is there maybe some form of like anti-fragile architecting of heterarchies where, because this is how this is how cells do it, right? A gene is translated into messenger RNA that’s that’s has a very short lifetime. It gets transcribed a couple of times, gets broken down and then you have to like start all over again. Is there something similar that you imagine that we need?
Jabe:
Actually… My father was a hand surgeon and an orthopedist. And it’s actually a talk that I’ve also… Or a concept I’ve also seen, talked about in resilience engineering communities, the Dr. Wood talks about it occasionally. It’s my primary example, objection to absolute antifragile, right? Like the idea that systems only gain strength. Right? So when you, you look at bones and bones have steoblast, osteopath, osteo-, there’s one more, I can’t remember, but there’s three different cells that build your bones or tear them down. And the interesting one to me is the tear down one, right? So like when you train for a marathon some which I ran foolishly more than once, but anyway, what some significant amount of training is beating your bones against pavement. And the reason for that is because if you go out and try to run more than 15 miles, you might have the cardiovascular capability to do that, but you can give yourself really bad shins. You can fracture your bones. And so what you have to do is you have to go out and run you know, an increasing amount of time. And often, honestly, like in the early phases of training, they’ll say like run 18 miles, but it doesn’t matter how fast you do it. I don’t care. You have to run 18 miles. Like you can stop, you can do whatever you want. You just have to run 18 miles a day. And the reason is because when you hit your bones, your legs against the ground, it activates your bones to create more bone structure. And these little cells show up and they start building more bone and your legs get stronger and your bones get stronger. You’re less likely have fracture. But the trick is that there’s costs involved in having higher bone density. And your body eventually, if you don’t keep doing that, these other cells will show up and they will start tearing the bone down, which is part of what I’m talking about, right? Is that when you talk to… A lot of anti-fragile only hears the like building bone density by having a positive reaction to a negative effect, right? Like hitting the pavement is bad and you’re antifragile because you build strength based on that negative interaction, right? That’s the anti-fragile. But in natural systems, it’s not good to be strong all the time. Often what you wanna do is tear the strength down to reinvest the calcium in other things, or to lighten your bone structure so you can do other things. And that’s the part that I think that we get in hierarchies that’s bad, which is, you know, the calcification, the way in which the system over strengthens certain parts of the system that should only be temporary. So, you know, I talk about like sometimes when I talk about kind of temporal design, one of the things I talk about is like you should decide or not decide, but you should be aware of a certain type of design parameter that you have, which is how long do I want this thing to exist? Is this like something that should like ephemeral, it’s like a flash mob or a swarm to solve something? Or is this like a temporary team or is this like a, you know, a team is gonna last for two years or, and then be careful not to build so much structure that whatever timeline you think the team should have, it outlives that, right. It becomes a self-perpetuating system. And you know, I talk a lot about that as being like in organizations, you end up with zombie policies and zombie teams. People do things they literally don’t know the purpose of because, you know, we needed it long ago, but the context is no longer appropriate. That type of stuff. You get the same thing with teams and organizational structures and hierarchies, I think and worse in lots of organizations, I don’t know in Europe, but in the United States, you know, people are compensated based on how many people report to them and therefore they ossify the systems under them to make sure that they maintain their VP title and their salary. So they don’t want you to have temporary systems underneath them. So anyway yeah, that’s one of the things I might say is like, I think that, being responsive to the environment is good. And being responsive in kind of an anti-fragile self perpetuating way is, is fine, but you should never overbuild something that you can’t take back apart again and have a thought about how to take it apart. I think so that’s what I would think about a little bit.
Kristof:
I wanna go back a little bit because there was something you were talking about like the Amazon example. And I hear, and I want to check this. It sparked an idea. I hear a lot of companies when I talk about developer portals, that’s what we do in our business. They’re talking about, ‘Yeah, we want to implement this API first strategy. And you know, we’re gonna have this marketplace where all these APIs are gonna be,’ and then it feels to me that they’re trying to replicate the Amazon model rather than really doing a platform.
Jabe:
Yep.
Kristof:
Does that mean that API first per se might be a sidetrack or there still is value in API first as like a first step towards more a more coherent API platform.
Jabe:
The first thing I usually talk about is like, when I was talking about the cycle times and isolating things, so platform is an interface, right? So APIs are part of that strategy to me, that it’s important to have these interfaces. And I mean literally interface, like the way that we talk about it in Ops-orientation, you need to make sure that you don’t have tightly bound internals. You need to have that abstraction there. And those APIs and the management of APIs and things like that I think are really critical for that. But that, to me, like in my mind is like a super thin line that’s often brittle, right? Like it’s thin and it’s brittle. It’s a contract-based system, right? And so a lot of people these times talk about project to product as like a movement in the industry. Like we’re gonna get away from project-based things. We’re gonna move to product-based teams. There’s some implications behind that, they’re longer lasting and blah, blah, blah. I think the other significant movement that we’re seeing is from service to platform. So service to me is close to API in that it is contractually based. It’s thin, it has to do with it doesn’t have to do with teams interacting. It has to do with the exchange of something like information or objects or things like that. So to me, the second step of a platform is to move beyond an API, and move towards, you know, I almost literally imagine it as the facts space, like there’s something there that’s beyond the razor thin line. And the thing in there is the commons. It’s the thing that we learned to negotiate. So in other words, it might be more like ‘I have an API, but I also have a way for teams consuming the API to submit patches, to talk to me about how the infrastructure works or how the application works or how the object model works, or…’ That there’s some way to get behind the API and work in the platform as well. And so like the way that I generally kind of see this evolve inside organizations is I it say like, there’s a shift between pushing tickets to pushing patches. And that’s what we see as becoming a platform. There’s a team then that is responsible for consuming those patches. And, you know, so, you know, one of the ways I try to talk about this to some extent is that like–and it’s hard to talk about because people really quickly get distracted by the terminology–but technologies that were used in open source projects for maintaining code, those methods are being reconsidered or reimagined in that it’s not just now maintaining code, it’s maintaining a platform which is, you know, I sometimes try to say’s like, it’s code in action. Like, it’s not just that I want your repos open to me. That’s not a platform, right? It’s that I want the operating platform open to me in a way that I can submit something and it will be in operation now, not just in a code repository, right. It’s not just the sharing of code because in theory, like I should be only consuming through the API. Therefore, the things that I should have access to from that perspective should be quite limited. But I should be able to then like peak around the corner and submit things to improve the API or to add things. That’s the thing that ends up being in operation. This is something like incremental elaboration. And then I try to talk a little bit about this idea that, you know, I think done well, there’s like a harvesting process involved in this. And so the way this works is like, when you first start coding something like, you’re not sure if anybody’s like, you’ve never tested it, nobody’s seen it in the world. Like, so if you created like absolutely perfect idiomatic code with complete unit testing, and like just went through your entire production process to make sure it’s bulletproof production code, and then you showed it to the first customer and was like, ‘Do you like it?’ And they were like, ‘Hell no, this is awful.’ You just wasted a huge amount of effort, right? So incremental elaboration would be, you should create something without a lot of unit testing without going through your complete production process. And you should put it on some sort of little isolated server over here, and you should show it to somebody and say, ‘Do you like this?’ And then you should, once you get traction, then you could say, ‘Okay.’ So there’s a difference in the quality of the code between MVP or a prototype and production. So now we need to make a production-ready code. Production-ready code at the application level has a certain level of qualities. You know, we need to be able to do this and that, needs to be operable on certain levels. We need, you know, to have visibility and, you know, observability stuff built into it, blah, blah, blah. Right. Great. Okay. So we deploy it, but now with this harvesting theory of the way this might work is that a platform team would go and go, ‘Okay, so other people are interested in the thing you just put into your application, but there’s another level of quality that is involved in taking that and making it platform ready.’ Because platform-ready, we might need multi-tenancy, we might need multi-whatever, you know, like there’s other aspects of the code that needs to get enriched. So to me, as you promote up these levels with these different parts of the code base, and you submit patches, you shouldn’t be building something that’s not being actively worked in a marketplace like a differentiation team. You should only graduate into a platform. So you avoid kind of “build it and they will come” type methodologies, but you have a platform team that’s basically there to receive that harvested code and create that next level of quality that is platform level quality and deploy it. And that ends up being like the way that you get this kind of fluid movement to create something more than simply an API, but a platform. And sometimes I try to say it’s like there’s difference between a platform and platforming and the challenge at many organizations is that they don’t know how to platform. Don’t know how to do that activity. And to me you know, again trying to be polite to my host, but like, to me, stopping at an API has the challenge or the potential of preventing the organization from going to that next level, which is learning to collaborate cross teams on a commons. Yeah.
Kristof:
What I’m hearing is that… So I’ve also been involved in the inner source community where they’re trying to take the principles from opensource and take them into enterprise. But it sounds like there’s some additional interactions that are necessary on top of inner source.
Jabe:
That’s right. Yep.
Kristof:
And is this described somewhere, is, is anybody like creating a platforming handbook or something like that?
Jabe:
There’s a couple groups that talk about platforming, but they become pretty abstract pretty quickly. And honestly, like intersourcing would be part of what is the input to this, but it’s also like something about team interaction and the socio-technical architecture bits that I try to talk through and things like that. So I should write more about it is the answer because I know that other people, when I talk to them, recognize it as being important. And I know when I work with people, it’s what I do with them, but I’m not sure how many people are writing down the lessons yet. I think again most organizations would have a massive advantage from, you know, moving from not having any sort of API to moving towards API management. It’s something, you know, that absolutely organizations need to do. The question is… so, like I say this sometimes to people, like when I started Praxis Flow with Kevin we were quickly known as being like a devopsy place. Like we did DevOps things, but we always used to tell people, the only reason we’re doing this is to research what happens after DevOps. And the reason why we advertise that we’re DevOps people is because we want to find clients who have done a lot of DevOps and aren’t asking us the basic questions. They wanna know what to do after DevOps. And I think the same thing is true about this platforming stuff. With the advent of Kubernetes and the way that Kubernetes is rolling out and the nature of cloud based infrastructure as a service aspects, these are the questions that the largest organizations are having to struggle with right now. Like, ‘Okay, like I now just can buy lots of primitives. Is that a good thing?’ ‘Well, yes and no, like are, how are you using them?’ ‘Okay. I have a service catalog. How do like, do I just like get rid of the ticketing system and make everything available via API? Is that the right thing to do?’ ‘Well, kinda.’ How do people get access to these things? If you lower the barrier to entry, to primitives, you can cause really bad economic outcomes. And this happens all the time, people all the time go to AWS and other places, give their developers access to it without approval. And then they get a huge bill and like, ‘Where do I go?’ So how does that stuff work and things like that. So I think that’s some of the questioning that people are trying to explore right now is like, ‘We’ve got, we’ve got the components that we can configure in these different ways. How do we know how to configure them better? How do we get the advantage out of them?’.
Kristof:
So one of the stories I’ve been telling to people that are doing API programs is that a developer portal is an interface for interfaces. And this is something that I’ve seen people that are trying to build a context-free way of consuming APIs are trying, are saying like, ‘No, that’s not important. It’s enough.’ Like, it’s this idea, that’s just a flat catalog is gonna be enough. And intuitively I am very strongly feeling about this because first, it’s our business. But also, I can’t believe it, there’s something missing. It’s really hard to express, what is that context? What is it that you do when you take this bunch of APIs and create that interdependence of these individual interfaces that is going to turn it from API-soup into an API platform.
Jabe:
Yeah. So, you know, again to me part of the answer ends up being these patterns of hierarchy inside of the platform. So, you know, I’ve been using the term primitives, but basically what I, when I talk about pattern, part of what I mean is these are the ways that you should use the CPU-pool, the, you know, mem-cash, the database as all preconfigured, so that you have an access in the catalog, not to, you might have access to all the primitives, but additionally, you have access to like high memory utilization, app, template, click - all preconfigured. Now I’m just working on my mem-cash-based high-memory-utilization thing. Everything is already preconfigured because we’ve found natural ways to do that. And we don’t want you to reinvent it. Right. Same thing with APIs. Like, it’s great to have the APIs all there, but it’s even better to my mind, to have a bunch of preconfigured interactions between the APIs that give you access to a higher level construct, right? And that’s, you know, when we talk about this neurological recursion one of the things we would talk about is the idea that when you get that closure that I talked about, like, again, the bottom up would be bunches of different APIs. Someone figures the APIs interactions in a certain way that causes a top-down interaction that says, this is a stable system. This is a stable way that these APIs interact well, that in theory opens a phase space. In other words, this thing can now be used in other configurations at a higher level. It can become the part of another set of configurations at a higher level. Right? And so, you know, to me, a platform has some of that happening in it, that applications of primitives. There’s different ways that I see it happening and unfolding in organizations. So one of the things might be like your application has preconfigured ways of doing observability. Like the tools are automatically built, in you don’t have to think about them as much, or you have to just tweak them. They’re already available. Another thing you get a lot in organizations is automated governance and compliance issues. So that the, the CI/CD pipeline, doesn’t ask you to perform the steps manually. It builds them into the CI/CD pipeline, so that your governance or your security constraints reject to build the same way that your unit tests reject to build. And that’s to build those services at the platform level, into the interactions in a way that the developer doesn’t have to go out and find them themselves. So that’s all that, like lowering the barrier entry, like the really stupid way of saying this, that I shouldn’t say stupid, because this is the thing that my boss says all the time, Andrew says this all the time. You know, the goal of a good platform is to make doing the right thing, the simplest thing to do. And so the question is like, what do you want people to do? Yeah. And, and then try to make the platform provide that as at low cost, as low cost to developers as possible. The anti pattern for that, by the way that I see all sorts of organizations is they go in and they say, ‘Oh, so like, what we wanna do is give the developer self-service access to like whatever CPU-pool or the machine over there.’ ‘Okay. That’s great. So what we’re gonna do is we’re gonna take all the forms that like the project manager used to have to fill out and all the nonsense and bureaucracy that the project manager did. And we’re just going to, you’re gonna expose all that nonsense directly to developer.’ And the developers are like, I hate this. This is awful. Right. Instead of figuring out how to eliminate that bureaucracy and slim it down and make it easier to consume the things. So I, you know, I, that’s the type of thing I think about, I guess when I think that makes sense at all.
Kristof:
We’re closing the hour, this has been a long like a marathon actually. I’d love to talk more. There’s a lot more here.
Jabe:
Absolutely.
Kristof:
I’d love to explore more about like how, how to bootstrap platforms and what are the patterns that you’re already seeing, being useful? Maybe also connecting it with intersourcing. There’s lots of stuff. Marc, do you have any last question?
Marc:
So all my qeustions would be bigger-ish, don’t wanna start them now. So the question is whether we’re doing a follow up?
Jabe:
Yeah. I’d love to come back. And I especially would really like to talk about the platform stuff.

End of part 2 of the episode we recorded with Jabe Bloom. You may also wish to tune in to part 1.
.