Ben Mackley, Zoom

Thank you for tuning in to today’s full episode of the Breaking Changes podcast. I’m your host and chief evangelist for Postman, Kin Lane. With Breaking Changes we explore topics from the world of APIs, but through the lens of business and engineering leadership. Joining me today we have Ben Mackley, solutions engineer manager over at Zoom. Ben shared with me such a powerful view of how important it is for today’s API lifecycle to be a business-led affair, shifting the long history of it being an IT thing. So let’s dive in. Start with the basics: who are you and what do you do?

Yeah, so I’m Ben Mackley, I’m a solutions architect manager at Zoom, and I connect enterprise software systems together as the solutions architect manager. So my team works with our platform. It’s called Zoom Contact Center now, but we were essentially a chatbot, and we connect with other CRMs and other software providers out there. So our team is really involved in the nitty-gritty with the APIs, making sure that the data is flowing properly, that we’re secure when we’re connecting systems together, and that we’re fulfilling the customer’s business needs as well.

Interesting. I like that it’s not just about the connections and what flows through the pipes, it’s about actually meeting business needs of people, the human beings that are involved here, which is so important. But we’ll dive into this a little bit. The integrations part of this is really interesting, but I want everyone to understand a little bit more about you and your journey, where you’ve come from. So where’d you get into all this? How did you end up at Zoom?

So it’s been a winding journey. I think with most people’s careers that end up as architects, it usually takes a winding path. I started a company out of school, and I haven’t been technically minded, at least when I was going through school and at the beginning of my career. I was more interested in starting things and doing a startup and solving education problems specifically. I realized that technology was the way to create an impact that would scale across many people, and because of that I got into technology. The startup didn’t end up working out, but that led down a path where I was kind of searching for what to do. So I did product management, I was an engineer for a while, and then I finally found my home in solutions engineering. Solutions engineering is working with the sales team selling B2B software, and as the solutions engineer I was often doing the implementations and would be connecting the systems together. That’s kind of what led into solutions architecture, where I’m at now.

I didn’t realize this, but throughout my career I’ve worked on platforms, and generally within the industry there’s more products than there are platforms. When I say platform it’s not like AWS or Google Cloud as far as hosting all of the services, it’s more having a one-stop shop to do everything that a business user would need to do. So I worked at a process automation company that automated processes within different companies, whether it was HR onboarding flows or more on the technical end. Then I’ve also worked at a user monitoring company, Quantum Metric. They did a combination of application performance monitoring as well as user experience monitoring; that was a really interesting experience. And now, interestingly enough, at Solvvy it was the first time that I was working with a product team, but then we got bought by Zoom to be a part of a broader platform with Zoom Contact Center.

I love the journey. I love the product management, engineering, solutions architecture and engineering focus and journey, because I don’t think those career paths are getting as much attention in this Silicon Valley or technology narrative. You hear a lot about engineers and being an engineer, you’re starting to hear more about product management, I wouldn’t say it rivals as much, but I hear very little advice, guidance, or showcasing that solutions engineering or solutions architecture is even a path that you can find and go to. So why did you end up here? Because it spoke to you more, or what are the reasons?

I feel like the sales teams in B2B need somebody that thinks both on a business side but also understands the product. I got into sales because, working in the startup, I realized how important sales is to the lifeblood of a company. If you’re not selling your product, if you’re not interacting with your customers, then the product will die eventually, and then the business will die because there’s no revenue coming in. For me, I’ve always wanted to solve the biggest problems that are out there, and I think within technology there’s a lot of problems that need to be solved, but the flow of solving a problem always starts with a customer’s pain, not with a technical solution. So I think I got into solutions engineering because I wanted to understand that lifecycle of identifying problems and solving problems in the right way. Coming from the startup world where you wear many hats, solutions engineering is very similar: you have to understand the technology, you have to understand the customer, you have to be able to communicate with the customer, and so information has to flow many different directions. Much like product management, solutions engineering is a connector role, which makes a lot of sense that solutions engineers and solutions architects work with APIs, because APIs do the same, connecting different systems together and making sure that the technology can communicate in a similar way that we communicate as humans.

Yeah, it’s about connections. That’s an important emphasis that I’ve thought about, but I think you put it pretty succinctly, and the difference between solutions and product management. So I always say the API space, the whole tech realm, is very API producer-centric, and that narrative has been set by API management providers, analysts like Gartner and Forrester and others, and vendors talking about producing APIs. But for me, the best API producers are also API consumers, because you understand that pain. So from a product management and API producer perspective, I’m producing an API, I need alignment between business and my developers who’s producing this, but I need to find that alignment with consumers, I need that feedback loop, and we iterate on this API, and the velocity we’re able to achieve and the value generated is based upon my bridge as an API product manager. But what you’re describing in the solutions realm is the same, but from a consumer side. Like I’m guessing you suffer a lot of pain and see a lot of problems that are introduced by the APIs you’re depending on at Zoom for integrations, these CRM solutions and others. So what sort of war stories do you got for us from that perspective?

I think you described it really well, that most API consumers, so I’m more of an API consumer as a solutions architect as opposed to an API creator, and most API creators don’t often consume their own APIs that they’re developing. I’ve seen it both ways. When I was working at a process maker doing process automation, we had a phenomenal engineering team. They rebuilt the platform API-first, and so they had the Swagger documentation for all the endpoints. You can actually run our entire system in a headless way without our UI using our API endpoints. They did a phenomenal job of creating a platform that we could tap into without having to go to the engineering team for custom requests. On the flip side, we were getting there and we were improving as far as helping them on the consumer side, of giving them feedback of what would be helpful, but I feel like that was almost underutilized. So the marketing aspect of the product that they build, like letting our customers know and then letting our salespeople know and how to sell our product to a technical audience, I feel like there was a huge gap there. I was there at the beginning stages of the product so I don’t know where they’ve gone since, but hopefully they’ve been able to make that shift to sell to those technical audiences and educate the consumers in a way where they can understand the power of the product. Then I’ve been on the opposite side where, as a solutions architect, we’ve craved APIs on our own side that our engineering team could build, so that we could pass the work off to the customer instead of having to do custom work and building custom products for every customer that we have. So it goes both ways, and having a connection between the team that’s building, the product management team, the engineers that are creating the APIs, and then the consumers that are going to be utilizing them, whether it’s customers or the internal users at the company, is really important. But I know that you’ve done a lot of work in this space, so what have you found to be effective as far as working with customers? Has there been a process or a method that you’ve used to get the feedback when you’re creating the APIs that have been helpful?

Yeah, this is definitely one of those areas that I’ve seen different things work in different organizations and different ecosystems because of the culture or the industry, or where I think everyone collectively is in their API journey. So like most areas of API lifecycle, I always asterisk, you know, this is not one solution that’s going to fix it for everybody. But definitely feedback loops are what I’m seeing right now shift. The narrative around APIs for the last decade has been: here’s a portal, here’s reference documentation for everything, here’s where you can submit a ticket, here’s a community forum, and we’ll use the community forum and the tickets as this feedback loop. What I’ve seen is, with companies like Twitter, a good example of this, not big on naming names, but Twitter I think is a really interesting example. They get a lot of hostility in that form, because for some reason forums as a feedback loop mechanism brings out the anger in some of us, and we say things in ways that we feel empowered to be kind of mean and ruthless, or maybe we’re just not being heard in the right way.

What I’m seeing evolve right now is developer experience and investment in developer experience change and diversify these feedback loops that you set up. So the forum and the ticket becomes blog posts and social feedback around it, or it becomes channels that are very suited to the audience who you’re targeting, because you’ve done your research, you’ve done your due diligence on who we are targeting with this. So you’re using TikTok appropriately because you’re targeting the right audience, or you’re using Hacker News because you know who you’re going after is right there, and so your feedback loops get tailored to that channel, that target audience. If it’s internal, it’s done through Teams and the feedback loop, if it’s for microservices and APIs for a certain domain within an enterprise. So that developer experience, that investment in consciously constructing a feedback loop, really defines how you gather that, how you use it, and the tone of it.

Back to the Twitter example, Twitter, for their Twitter Spaces API, before they got to work on it they actually fired up a Twitter Space to have an audio conversation, a town hall discussion about what should the Twitter Spaces API be or do, or should we even have one. A whole bunch of people showed up, a bunch of developers in the developer community, and Daniel, the product manager in charge, looked at some of the names and goes, “Oh no, these are some of the angry people from the forum, oh my gosh,” and had a lot of anxiety about that. But then once they turned on the audio they were very cordial and very social, and so he’s trying to figure out: was it that they felt more empowered to be mean and cruel on the forum, did he interpret it wrong, is the audio more of an experience, the town hall format, and on audio people are friendlier? He’s still processing all of that. But my point answering your question is, developer experience is shifting investment, developer experience is shifting how we construct these feedback loops, and the maturity and visibility — public, private, partner — of our APIs very much dictates what channels we use and how we gather feedback, and then how we listen and filter through based upon the volume of feedback we’re getting.

Yeah, I think that’s an incredibly important point. When I was studying education, I did my master’s in educational technology, and the way that we learn is through feedback, whether that’s technologically, like with APIs, and with programs that we write, the reason that we have error logs is because it’s a feedback mechanism. What you were describing with Twitter makes a lot of sense, because companies that are open to feedback are the ones that are going to be improving and creating not only a great developer experience, but I think the great developer experience translates to a great user experience down the road and really a product that serves the customers, as opposed to a product that customers have to adapt to their own environment. So that’s an interesting idea of developing these feedback loops according to the product that it needs, like might be Hacker News, might be Twitter feed, might be just issues on GitHub that aren’t posted, but really every product that is open to feedback will get that.

What’s the cultural — I see a lot of folks who talk about feedback loops, talk about product management, talk about empathy, they’re even like, how do we develop empathy for our customers, but really aren’t honest about it to the degree, because it’s a little scary to open yourself up to this criticism, because you’re probably getting feedback from some of the loudest folks. So how do you find the signal in this noise, and what you’re doing? You’re hearing business goals, you need business alignment, you got developers and teams, and you’ve got customers. How do you find the signal in that noise?

Yeah, there’s so many signals that we’re being attacked with, both internally and then externally, that it’s hard to parse all of that out, and I think that’s really the role of what great product managers and great solutions architects do, is they’re able to determine the signal out of the noise. So a few things that I generally do when I start a project: getting face-to-face time with a customer, because I think there’s the qualitative aspect and then the quantitative aspect, and with signals I think you need to marry both of those, the qualitative with the quantitative, to understand and correlate. A discussion with a customer will often surface their major pain points. The process that we generally go through, we call it scoping, but we’ll talk through what their pain points are, and eventually we get to a desired solution, but during that process we take that qualitative feedback in of what’s important to them, what they want to get to. It might be something like, where’s my order function that’s built into our bot, or can I get a refund for an item? Based on the feedback of the problems they’re facing, we’ll compare that to, in most cases it’s financial, like how much time will it take and how much resources will it end up being to create the solution they have. If it’s a huge problem for them but it’s only, I don’t know, fifty thousand or a hundred thousand dollar impact that they would have, and it’s going to cost just as much to create it, they’re not going to see the ROI. So even though it would resolve their pain point, the numbers aren’t correlating with the qualitative information. By pulling multiple sources, the qualitative and the quantitative, you’re able to triangulate what’s actually important from all the indicators that are coming through.

The general rule of thumb that I have when making these decisions, and that I got my team on, is if we’re not going to see a 3X ROI, then there’s probably something else out there that we focus our time and attention on, which means we need to dig further to see if there’s other problems or other stakeholders that would be involved, we need other data points to understand what else could be out there and not just focus on what’s in front of us. So it’s a long answer to the question, but I think getting as many data sources as possible and then trying to triangulate them and correlate them to see not only what’s feasible but what’s going to have the biggest impact, and then from there it’s really hard to do it perfectly, but creating a prioritization and a project plan and coming to agreement on that is the process that I’ve found. But is there anything that you’ve done as far as understanding how to parse out the signal from the noise that you get when developing products?

I mean, I’m the first to admit, I wouldn’t be a good product manager, because I get too emotionally caught up. I want to talk to everybody individually, I want to hear, for Breaking Changes, this show won’t go out till January because I’ve already talked to so many people, and we’re releasing two a week. These are super valuable conversations that I’m having. The number one reason I do Breaking Changes is to get to talk to you and to learn from you. But then there’s also this bigger mechanism where I filter out and find the signal here and how does this fit into the overall lifecycle. Everything you’re doing right now, I’m going to put into our master guidance around feedback loops and product management, and so this is actually one of my channels for my feedback loops, and this is part of my job in building an API lifecycle and governance, a producer and consumer lifecycle that all works together. This is what I’m building out of these conversations, just so you know you’re a guinea pig, so you’re in the physical feedback loop right now, and I’m doing what you just asked me how I do it.

So my challenge is, I love just talking to you and I get so caught up in the moment that I forget about the big picture, and I just want to make everyone like they’re so right, and I’ll be talking about you for the next four or five days and everything we did, but then in the bigger picture I’ll lose that signal and get distracted by the noise or the next signal. So I actually would not make a good product manager, and I need people helping me with that, and luckily I have a team behind the scenes here who helps me stay on track, because otherwise I don’t think I would get a product out the door. I would have all the conversations, I would gather all the signals, but I wouldn’t get it out the door. But with that said, surround yourself with smart people who can pay attention to things that maybe you don’t see, diverse people, diverse voices that are going to ask questions that you didn’t even think about or see or point out data from it. So having those people around you, prioritizing channels and what matters the most, because we can find too many channels, we can gather too much information, and know when you need to start filtering that down. But then for me, I just follow my gut and what I feel intuitively is going to matter the most based upon those conversations I had and my understanding of the space and people. I talk to so many people, I trust my gut a lot. I know gut-based isn’t probably a sensible or scalable way, but I talk to a lot of people and I’ve been doing this a while, I trust my gut, but I don’t know if that’s right or wrong.

Yeah, I mean, I call it, you’re doing so much qualitative, you have so many qualitative feedback loops through the conversation that it’s probably why you can trust your guidance. You’ve done this so many times that if something feels off, even if you can’t pinpoint the reason, there’s data behind it, but the gut comes much quicker than the data does. And yeah, I think that’s why it’s important that your team —

Yeah, definitely the team is critical for me, because that’s why I’m at Postman, because I was doing this a long time on my own independently, and it only got me so far. You have to have a team, you have to have people working. And I’m also learning, one of the things I’m learning from my team, I hired someone named Deepa Goyal from PayPal recently, and she’s helping me think through all the product manager developer experience stuff, and repeatedly in conversations I find myself, she catches me in an API producer mindset, where she’s coming at it from a developer journey, from a consumer perspective, and she’s like, “What you just said didn’t make sense,” and I explain again, “Yes it does,” and she’s like, “Well, that’s you’re the producer, no, this is about the consumer,” and she’s constantly advocating for the consumer. It just made me realize how locked into this mindset I am, and that’s really what I think captured me about you and your perspective.

So everything that you just said about prioritization and finding the signal, how do you reconcile that with the APIs you depend on? So you connecting to a CRM solution that is trying to prioritize what they should build and what they should make available, they have somewhat of a barrier between you and them, you have one or two channels that you can submit your feedback. How do you make yourself heard, or how much time do you carve out for being the signal for these providers, these producers, and giving them what they need to produce not just what you need, but a better product that’s going to make your job easier down the road?

Yeah, I think the answer is, I don’t carve enough time out to get feedback and to help the producers create better products. Internally it’s really easy, because having Zoom Chat or Slack or the internal communication tools, it’s really easy for me to connect with my integrations engineering team or our back-end teams that are creating these APIs. We have a really good relationship and we’ve developed that over time. With other vendors, oftentimes we’ll come into an implementation and we’ll be one of two or three or four different vendors working on the project, and it’s a lot harder because we don’t have that trust and we haven’t developed a set routine as far as how we communicate, and it’s learning that relationship every time. So for me, the process that I generally follow is, if I have to choose who I’m going to be working with, if I have to choose the producers that I’m working with, I’m going to look for the ones that are open, the ones that have invested in their developer experience and have created documentation and that have done marketing or that have resources to talk to others in the community, because I know that when I do come with feedback to them, they’ll at least hear that and internalize it and it won’t fall on deaf ears.

I was talking with a friend of mine who’s using the company that I worked at previously, and he was trying to integrate with a customer on the chat side, and he was telling me that the process that they have, they don’t bubble up their errors. It’s a very tight system, and there’s always a trade-off, right, having an open system means that there’s higher security vulnerabilities, and so you can’t be completely open, but at the same time, if you’re completely closed, it’s very difficult for others to work with you. He was having this problem where the error messages weren’t getting bubbled up and the events weren’t bubbling up, and so he wasn’t able to connect the systems together to create this monitoring with the application and with the chat. So the chat was essentially not showing up in that real-time user monitoring that they had. He talked with the customer team and brought this up, he’s like, “I’m not seeing the errors and I’m not getting the events that I need to handle these issues,” and the customer team essentially said, “Yeah, we know, it’s because it’s going to be less secure, and we’ll let our development team know, but we can’t make any promises.” Just hearing his frustration, and having gone through that myself so many different times, I’m in a position where I can choose who I work with, at least more than I have earlier on in my career, and so that’s what I generally look for now, people that are willing to be open and to take feedback and give feedback, so that feedback loop is really tight, so that we can deliver product quickly and that we can deliver the best developer experience and customer experience. Then once the relationship is established, it’s really just doing the work and building on that, but setting everything up for success and choosing the right people to work with is incredibly important throughout that process.

Yeah, I heard a couple really interesting things in there. I’ve long advocated that part of your feedback loop, the design of your API is part of your feedback loop, meaning the status codes you return is part of the feedback loop with your consumer, and so thoughtful design is really important, because you’re going to minimize people having to come and submit a ticket and be the direct feedback loop mechanisms, because this indirect, kind of soft feedback loop, part of your design is good or bad, so your volume of tickets will be lower or higher based upon this. So the design of your API is very much part of your feedback loop. But the second dimension of what I heard you say is, for me APIs are a balance between access and control. I see this — we just released the State of the API report today at Postman, and one of the biggest surprises for me, or not surprises, things I want to see more of, is it’s heavily skewed towards internal APIs and microservices. The majority — we ask people where are you doing private, partner, or public APIs, and it’s overwhelmingly like 50, 60 percent private, then a smaller slice of partners and a smaller slice of public, because people have a lot of anxiety about opening up. They don’t have a lot of confidence in this balance. What you just described in this company, they’re worried about opening up, pulling back the curtains too much and giving access to too many errors, because they don’t have a lot of security confidence, observability, monitoring. So really I think what you just described is how much your design and the operation of your API is your feedback loop and does set this tone for what you’re going to be able to gather and filter out, that signal from the noise.

Yeah, I think it all starts in the design phase. On the product design, how are we developing error codes? It seems like such a trivial thing, but in the long run of launching an application and maintaining an application, the maintenance is much lower if the design is spec’d out properly and user input is taken, and you do the testing to identify what error codes should be coming up. So it’s a process, and I think it’s one of the reasons why it’s so difficult to do well. I’ve seen some companies that have done it well, but more often than not there’s a lot of room for improvement with most companies. The reason why it’s so difficult to do well is because the design phase takes so much time and effort. For me what I’ve found is, there’s the adage “measure twice, cut once,” and I think within software design, and especially with API development, it’s more “spend eighty percent of your time designing and getting input and testing up front,” and then that twenty percent of time, the build is actually easy and should be the shortest amount of time as far as the entire lifecycle of creating a product. It’s really hard to do design well, and coming back to that idea of product management, I think good product management takes the time to do design well and to get customer feedback and include that in the product.

Interesting. So one of the things I’ve noticed in the space is we have a lot of times trouble having conversations because we’re not grounded in some fundamental things. One example is the lifecycle. When I ask people what is the API lifecycle in an organization, I would get ten different answers, and once I did that at Postman and got ten different answers, I’m like, all right, this is a problem, because we’re not all in agreement. We verbally say we’re in agreement on what the lifecycle is, but when you get down to it, it’s actually no, we’re not. I noticed that the lifecycle for a lot of, you go talk to developers, is develop, deploy, and then somewhere in there we added tests, so you develop and you build your test-driven development and then you deploy, and those tests benefit, and then we start shifting security a little bit left, so you got a security review in there. But it’s still development, test, security, and deploy, and then once we start adding this define and design stage, we got pitchforks from developers going, “No, I’m not a designer, I’m not a YAMLer, I’m not going to design in YAML, I’m a developer.” And so code-first kind of is winning out over design-first.

But what I heard you say is, this is a product management task. So I feel like the define and design stage, and then we’re also seeing — that’s the bookend at the beginning. At the end of the conversation, once you deploy, there’s observe, I have observability, and distribute as the next stages. Those bookends, those two areas, are also product manager, because what metrics and how am I measuring all this success, and then am I distributing it and documenting it, getting it in front of the right people, and then getting that feedback loop back to the beginning. So those bookend stages, I see a lot of groups expecting their developers to do those, but the ones that I’m seeing be successful are the ones who are bringing in product managers and architects to work with those product managers to do it well, and then product marketers, I would say on the distribute side, there needs to be product marketers involved in that to actually get it out. So that’s a long lifecycle for a product manager to work with customers and work with the internal teams to define and then design a solution, because including engineering is really important in that stuff, and I think they’d like to be included, they just don’t like to run it, it has been my experience. They like writing code, they don’t like defining business problems. But that lifecycle takes a long time.

So I think there’s information gaps, and I think that’s one of the things that I’ve realized in my role recently, stepping into management, is most problems are communication problems. Even at the API level, that’s what we’ve been talking about, error codes are a way to communicate that something is broken. So building good communication paths, and I’m doing it in an agile way where it’s iterative, where you can go through that process and then come back and go through it multiple times, and the tighter that loop is, the quicker the product will get out and the higher quality it will be. So I think oftentimes we think that it’s a divide, like quality, if we want a higher quality product it’s going to take longer, but at least in my experience it’s been the opposite. The products that ship quicker end up being higher quality because they have that loop tied down pretty quickly.

Yeah, communication is key. So I’m going to let the cat out of the bag here with the podcast called Breaking Changes: there are no breaking changes, folks, there are just poorly communicated changes that cause systems to break. So I would totally support you that it’s all about communication and it’s all about us human beings not doing that well, or doing it well.

Yeah, and has there been something that you found that makes that effective, of going through those steps and building a process as far as going from design to the development to the deployment to the observability to product marketing and getting that loop done?

Yeah, the foundational piece, which I just talked about, the lifecycle, is the first grounding piece that’s missing, people don’t have a common definition of what the lifecycle is. So how do we get from define to distribute and then back again? So everyone’s just wandering around, running around and doing what they can, and there’s some overlap in it, but once you get people with a clear lifecycle definition, saying the same things, being able to speak to it in a common way, things stabilize. The second one is role-based, so who are the owners or who are the stakeholders at each of those stages of the lifecycle, who should be in the room and who shouldn’t be, because this is what you said about developers, developers want to be included in define and design, they just don’t want to own it and they don’t want to do all that business research. So having very clear ownership and roles defined for each stage of the lifecycle is the next grounding piece, because then you know who to communicate with. You know, “Hey Joanne, I just finished the requirements, can you look at it,” “Hey Ted, I just finished the mocking, why don’t you play with it and see if it actually meets the contract that we discussed.” Without those clear stages and roles, that communication doesn’t happen, and that’s where the friction comes in.

Maybe this is just the developer mindset, but to me it’s almost like designing good applications is the same as designing good processes for building those applications. Just like we would define a GET request and say which query parameters we can use with that GET request, I think defining a role is very similar to API documentation, where if we say who owns a role and what responsibilities are associated with that role, and then communicating that with the team so that everybody knows who else to talk to, allows that information to flow much more smoothly. So from an architect mindset it’s interesting to me how the same principles apply whether we’re dealing with code or whether we’re dealing with humans or something completely different.

Yeah, I was trying to write this up in an articulate way yesterday, but everything we’re doing for applications and integrations, the reasons why we’re doing APIs, the same applies to the APIs, because the infrastructure we use to deliver each stage of their APIs have APIs behind them. So we can automate, we can communicate, there’s a lot of things you can do strategically with your API lifecycle that you can accomplish with APIs that’ll help you automate, stabilize, communicate, iterate, collaborate, all these things that are the nutrients, that are the deficiencies that exist in the lifecycle. We noticed this with our apps, we were building web apps and then we’re building multiple mobile apps, then we’re building partner integrations here and there, and we started identifying along the way, we need a strategy for this, we need an API strategy for these resources, these capabilities and experiences. Now we just need a strategy for our APIs also, and the lifecycle and the governance in a similar way, so that we can begin to stabilize how we do APIs and get more consistent in how we communicate, because without that, the humans are the biggest problem, because that’s how we work. We’ve got to be able to collaborate and work together and understand and find that forward motion, and without that structure and framework we’re never going to get there.

So how have you seen the best systems set up? Like you described that flow of product management bookending the development, and then on the observability piece I imagine there’s a DevOps team that helps with the deployments and setting up those processes, and product marketing to help interface with customers, but it takes coordination. So who’s sitting on top of that, what is the best organizational design to help with good API design? I imagine with everyone that you talk to, that you have some good insight.

Yeah, no, I’m working on it, I have a lot of good insight, working on how to put that out there and communicate that, and like I said, these conversations are part of that. So I talk to a lot of groups who have a center of excellence when it comes to their API design, their governance, that are creating design guidelines, security guidelines, things that are cross-cutting across the lifecycle. So defining the lifecycle, but defining how we document, how we test, how we secure, and providing as much guidance and enablement along those lines from a central standpoint. Now with that said, I’ve also seen a lot of groups try to govern with a capital-G governance from top down, and hand these down to teams and just cause mayhem, because it was mandated, that every API’s got to be exactly the same, every team’s got to operate exactly the same, use the same source control and CI/CD, and it’s just not how it works across an often distributed enterprise landscape that’s either broken up by lines of business, tribal boundaries, acquisitions, geographic regions, regulatory compliance.

So the ones that I see working are, there is a centralized guidance and investment in resources, they have champions that are part of federated teams who then help champion those centralized concepts and tasks, but capital-G governance on the ground floor is lowercase-G governance, or more appropriately enablement. So I can apply these standards because someone else did the work to go find them and to make it easy for me to do it in my VS Code, and apply standard pagination or standard design, and I’ve got linting rules, someone thoughtfully put together a set of spectral linting rules that, when I’m editing a YAML document or a JSON document for my API contract, it’s catching most of the mistakes that I’m going to make as a designer and enabling me to deliver a better API. And oh, by the way, I can have those in the pipeline if I want, if my team’s mature enough and my API is mature enough, I can have them catch those design gaps in the CI/CD pipeline, because even me as an expert, Monday, Tuesday I’m great at remembering all those, but Thursday I woke up in a bad mood, I came to work, I pushed some code or an API contract, and I forgot thirty things because I was just in a really bad mood, even though I know better. So I need that pipeline to catch that for me, and I don’t see it as enforcement. So being able to centrally define a lot of these, distribute and enable teams to use as much, but then also leave room for autonomy and agency for teams to do what they need that may work and be a better solution, and then feedback loops keep that API strategy, guidance, governance a living feedback loop, and then gather feedback from those champions and teams, repeat, repeat. But you have to embrace a federated approach and find the balance between centralization and federation that’s going to work, and then you bring in the ops team, how do your ops teams fit into that, how do your security teams fit into that, those cross-cutting functions, and then you just find the dance that’s going to work the best.

I’ve been studying agile and how to actually follow agile, and I think one of the principles is self-organizing teams end up producing better code, and I like that idea that it’s not a central governance mandating things from the top down, but it’s almost like providing the teams with the tools they need, whether it’s a CI/CD platform or the linting to check the code, so that way the teams can focus on what they do best, which is writing code, or if it’s a product management team, talking with customers, defining what the actual business problems are and then designing the initial solution and coordinating between people. But having that idea of enabling teams with providing them the resources and the structures and really the tools that they need to succeed is really important. So that’s something that I’m going to try to do, but I know that it takes a coordinated approach, it takes many different people coming together and agreeing on that.

Yeah, that’s the trick right there. And so for my last question — I mean, I could keep talking to you all day, this is great, but for podcast sake I gotta keep reminding myself we’re recording a podcast — one last question for you along those lines is, how much of your day is technology, how much of it is business, and how much of it is people-related things, would you say?

So I find myself having to add technology to my schedule, because if not it would just go away, and I’ve felt that over the last few weeks especially. Sometimes I’ll come into a project and get deep in the technology, so it obviously fluctuates, but I’d say on average it’s at least 50 percent people, and then maybe 20, 30 on the business side and 20 on the technology. I found that with my roles that I need to be involved in technology outside of work in order to stay current and stay relevant and to help me on everything else I’m doing, but the demands of the day, being a manager being thrown in meetings and working out HR issues, tend to take the majority of the time. But the fun stuff, what I really love doing, is teaching on the technology, like I have past experience in boot camps, and one of my favorite responsibilities as a manager is mentoring and helping the team find the positions that work best for them, and then connecting everybody together to build great products. So I wish it was reversed, I wish it was 80 percent on the people side with the technology, and 20 business and HR stuff, but yeah, it’s the sad reality I think of being a manager, having to go through the day-to-day.

Yeah, well, I think at least you have an honest, pragmatic view of your day. I don’t think as many people are being as honest with themselves when I ask that, so I always love hearing what folks say. I could keep talking all day, Ben, we’re at 50 minutes which is like 10 minutes longer than shows usually go, so I want to have more conversations with you. One, I want to bring in Deepa from my team to talk to you, she gets the product management, I think you two would really dive in, and maybe we could do an added interview or a separate segment where she and you talk. The other I would love to dive into with you sometime is the ed tech, the education part of it, because you love teaching. I have to admit, my wife is a tech specialist, that’s what her career’s been, she’s a Spencer Fellow from Columbia School of Education, teaching technology in the classrooms, how does it work, that’s what she’s done for the last decade. So I’ve done APIs and she’s done ed tech, and there’s overlap. But that’ll be for another show, we’ll have to talk about that, because I think learning is the number one most important thing we can be doing in the API space, and I think it’s under-invested, we’re not doing as much as we should. So I appreciate the work that you’re doing too to help with that, because there needs to be a lot more resources on the API side. So I appreciate the podcast that you’re putting together and all the amazing people that you bring on to help with that education.

Well, we do what we can. Thank you.

Well, I gotta close it up there, to be continued though, because I love talking with you, Ben. This has been an amazing journey, thank you for sharing, and thanks for joining me today.

Yeah, thanks, looking forward to the next one. Definitely.

Thanks again to Ben for stopping by. You can find more about Ben on LinkedIn or Zoom at zoom.us. You can subscribe to the Breaking Changes podcast at postman.com/events/breaking-changes. I’m your host Kin Lane, and until next time, cheers.