Screaming in the Cloud - Molding Leadership Within Tech with Adam Zimman

Episode Date: September 22, 2021

About AdamAdam Zimman is a start-up Advisor providing guidance on leadership, platform architecture, product marketing, and GTM strategy. He has over 20 years of experience working in a variety of roles from software engineering to technical sales. He has worked in both enterprise and consumer companies such as VMware, EMC, GitHub, and LaunchDarkly. Adam is driven by a passion for inclusive leadership and solving problems with technology. As an Advisor he works with a number of startups and nonprofits. His perspective on life has been shaped by a background in Physics and Visual Art, an ongoing adventure as a husband and father, and a childhood career as a fire juggler.Links:Twitter: https://twitter.com/azimman

Hello, and welcome to Screaming in the Cloud, with your host, Chief Cloud Economist at the Duckbill Group, Corey Quinn. This weekly show features conversations with people doing interesting work in the world of cloud, thoughtful commentary on the state of the technical world, and ridiculous titles for which Corey refuses to apologize. This is Screaming in the Cloud. This episode is sponsored in part by our friends at VMware. Let's be honest, the past year has been far from easy due to, well, everything.

Caused us to rush cloud migrations and digital transformation, which of course means long hours refactoring your apps, surprises on your cloud bill, misconfigurations, and headaches for everyone trying to manage disparate and fractured cloud environments. VMware has an answer for this. With VMware's multi-cloud solutions, organizations have the choice, speed, and control to migrate and optimize applications seamlessly without recoding, take the fastest path to modern infrastructure, and operate consistently across the data center, the edge, and any cloud. I urge you to take a look at vmware.com slash go slash multi-cloud.

You know my opinions on multi-cloud by now, but there's a lot of stuff in here that works on any cloud. But don't take it from me. That's VMware.com slash go slash multi-cloud, all one word. And my thanks to them again for their sponsorship of my ridiculous nonsense. This episode is sponsored in part by our friends at Jellyfish. So you're sitting in your office chair, bleary-eyed, parked in front of a PowerPoint, and oh my sweet feathery Jesus, it's the night before the board meeting, because of course it is. As you slot that crappy screenshot of traffic light colored Excel tables into your deck, or sift through endless spreadsheets looking for just the right data set, have you ever wondered why is it that sales and marketing get all this shiny, awesome analytics and insight

tools, whereas engineering basically gets left with the dregs? Well, the founders of Jellyfish certainly did. That's why they created the Jellyfish Engineering Management Platform, but don't you dare call it JEMP. Designed to make it simple to analyze your engineering organization, Jellyfish ingests signals from your tech stack, including JIRA, Git, and collaborative tools. Yes, depressing to think of those things as your tech stack, but this is 2021. And they use that to create a model that accurately reflects just how the breakdown of engineering work aligns with your wider business objectives. In other words, it translates from code into spreadsheet.

When you have to explain what you're doing from an engineering perspective to people whose primary IDE is Microsoft PowerPoint, consider Jellyfish. That's jellyfish.co and tell them Corey sent you. Watch for the wince. That's my favorite part. Welcome to Screaming in the Cloud. I'm cloud economist Corey Quinn, and periodically I like to talk to people about different aspects of the industry. One that I think is interesting that doesn't get spoken about a lot directly is the idea of leadership. My guest today is Adam Zimmon, who's a startup advisor providing guidance on, as mentioned, leadership, platform architecture, product marketing, and GTM strategy. GTM, of course, standing for go-to-market.

Who goes to market? That's right, Little Piggies. Adam, thank you for joining me. Thank you, Corey. It's a pleasure to be here. I imagine that you usually don't advise your clients to call their GTM execs Little Piggies. Well, I mean, I guess it depends. You know, if you're actually a bacon manufacturer, then that might be actually a reasonable thing to do.

Yeah, there's a level of investment in the product that you usually don't see in most environments, but we take what we can get. So snark and cynicism aside, what is it you do? You know, ultimately, I look for ways in which I can add value. And, you know, I've had the privilege in my career to be exposed to a lot of amazing VP roles while you were there. We spoke back in 2017 briefly while you were in that environment. And in fact, my first guest on this show was one of the folks on your team, Heidi Waterhouse, who's been back at least once since then and hopefully more than that. But it's been an interesting ride there. Before that, you were at places like GitHub or Jithub, as I insist on pronouncing it. EMC slash VMware, where does one start and the other stop? Hard to say. It's sort of a giant corporate shell game. But you've spent a lot of time in large

companies and small ones as well. And now you're effectively hanging out your shingle as a strategic advisor. This is true. I mean, I think that one of the things that I've found is that doesn't really matter what size of company you're at. You're going to find new and interesting challenges and you really don't have to look that hard. And so, you know, one of the things that I've found is that it doesn't really matter what size of a company you're at. You're going to find new and interesting challenges, and you really don't have to look that hard. And so, you know, one of the things that I've found consistently, and, you know, I would say that this was most poignantly phrased for me by Emily Freeman in the context of DevOps is this amazing thing of people, process, and technology. And the reality is, is the only one that's complicated is the people. And oddly enough, small companies, you still got people, big companies, you still got people. So therein

lies some of the challenges. And people are inherently non-deterministic. You never know what you're going to get by applying the same input, even to the same person, just separate out by time. It's a challenge. And the problem that I see across the industry is that very often you'll have a team of engineers and you'll pick the best and brightest one of those engineers and congratulations, you manage the team now. Now, management's inherently an orthogonal skill. And what you've simultaneously done is gotten rid of a great engineer and introduced a terrible manager. And that's through no fault of this person's own. But when I started managing teams, I got surprisingly far by just doing the exact opposite of all the stuff that my previous terrible bosses had done. And that works really well right up until it doesn't in a variety of probably fairly easily predictable ways. is that there is no book on how to do these things. If you want to climb an engineering ladder, great.

There's a bunch of very qualified people who will tell you how to go from wherever you are technically to where you want to go and what you have to demonstrate and what you have to do. Leadership is squishy in that sense. At least it always has been to me. The interesting part that I would challenge you a little bit on is that there are thousands of interesting books on leadership, even smaller subsection on management specifically. I think one of the challenges there is that they're not well circulated within tech as an industry. I think that there are a few that people come back to and like Andy Grove's book on his experience building Intel. There are a lot of books out there

that have done a lot for talking about how to manage people and how to think about what are the specific tactical things that you do, right? It's, you know, having one-on-ones, it's having meetings with clear agendas, it's being able to look for ways to set expectations with your organization. I think one of the challenges that I see pretty consistently is the fact that that effort to be able to go out and find that information or to learn those skills is something that is put onto, as you said, this individual who has come into management through punishment, right? They've been extraordinarily successful, and now you will punish them by putting them in a role where they can no longer do all the things that they enjoyed

that made them successful. And I think that you see time and time again where organizations put people in these roles, but they don't do anything to either prepare them for it or do anything to continue that notion of professional development or training for those individuals once they're in those roles. There are a lot of books out there for any discipline under the sun. Some are good, some are terrible, most are somewhere in the middle of the road. Law of averages winds up working out. I think a key difference on some level is I can take to Twitter or a forum or something like that and complain about software. The computer isn't doing the thing I think the computer should be doing, and that's great. I can't very well go and complain about managerial issues while actively having a team and not find myself no longer having managerial

issues, if you catch my meaning. It's hard to find communities around this stuff. I think that you're right. And I think that this is one of those things where not only that, but I think that we also in tech have predominantly taken a very hierarchical structure to the way that we think about management and leadership. And to the sense where oftentimes it is not only discouraged, but downright forbidden for an individual contributor to challenge their manager if they want to continue to have gainful employment. And I think that this is a cultural thing that, you know, it's funny, you know, I know that you recently did an episode with John Alsbaugh and you were talking about incident remediation. And I think that one of

the things that I've always tried to do as a manager, as a leader, is think about opportunities for being able to do that type of incident response for people. If you have a person that leaves, whether that is forced attrition, whether that is a voluntary attrition, whether that is something that you wanted to happen, something that you didn't want to happen, what are you doing from a perspective of kind of a post-incident assessment to learn from that? And I think that the next level of that is how do you do it so that you actually, in some way, incorporate that for the individual that's actually leaving? Because ideally, they're learning from that experience as well. Back when I was a generally terrible employee,

I decided at some point I was tired of dealing with computer problems and wanted to deal with people problems instead. Now, let's be clear. I found a path to do that in a very different direction than I expected at the time. But at the time, it was great. I'm going to go ahead and become a manager of a team. And I talked to a number of folks about, all right, what is the path to go from decent technical engineer? I was a senior SRE type at

most of these places, into management. And not just talking to people at the companies I was at, but talking to people in the larger community and every engineering manager who I respected and talked to about, it always seemed like they got this lucky break at just the right time. And that made them a manager for the first time. And once you have a track record of having managed people, then you're in, you can go back and forth between IC and management roles, but well, you've never managed people before. So we're not going to take a chance on you to manage people. The way that I did it, honestly, was I, a few times I wound up joining startups where I was the only ops person. We suddenly started scaling and having fun problems. And well, I did negotiate for that

director title. So, all right, I have teams now. I was more of a team lead than most things in some cases, but it led to a pretty interesting evolution in how I approach these things. I find now that the right answer is for me not to manage people at all, because what I fundamentally do here at the Duckbill Group is basically become the loud, obnoxious center of attention. And I think that what managers need to do is showcase their people instead. And those two things, at least to my view, are opposed. And it's very challenging to do both of them, let alone well. For me, at least, I tend to back away from the management side of things almost entirely and abdicate the role, which is great. People self-manage, right? Well, I mean, I think that there are individuals

who definitely will have the ability to self-organize and self-manage to a degree, right? I think that the challenge that you run into is as the organization scales, as the nature of their role tends to change with that scaling organization, it becomes more challenging for them to navigate through those changes, right? A great example would be, you know, I have had the pleasure and the privilege a number of times in my career of managing extraordinarily senior individuals. These are individuals who, to your point, don't need a whole lot of care and feeding.

But what they do sometimes need is they need someone who is able to be in rooms that they're not in, whether that's from a higher level leadership meeting, understanding larger organizational goals, or they need someone that's going to check them. They need someone that they can trust, someone that they can bounce their ideas off of to know, is this something that's going to be perceived of value or something that's going to actually take me in the wrong direction, or somebody that's kind of like paying attention to the work product that they're doing and giving them some coaching, whether that's cheerleading or whether that's connecting of saying, hey, there's also this other person you should talk to. Those types of things are really valuable for those individuals who are,

to your point, a little bit more self-sufficient. On some level, I ran into this trap a lot, and having over drinks conversations with a bunch of people who went down similar paths, it's blindingly obvious that it's a dumb move in hindsight. But an awful lot of us did it. Where we're sitting there as engineers with the belief of, ah, if I can make my manager or beyond, several skip levels up, look incredibly foolish in the middle of a large meeting, they will inherently see the value of what I have to say and will thus elevate me to management. As it turns out, they elevate you

to customer because you're not working there anymore in many cases. And when I talk to people about this, it usually has that light bulb coming on moment of, as soon as you hear it, of course, it is blindingly obvious that you aren't going to sarcastically obnoxious your way into being management. Instead, the path there, in hindsight, also blindly obvious, is act as if, act managerial, help to effectively carry on your manager's message to the rest of the team. And when you have reservations or whatnot, talk to them in private rather than calling them out. And it's the obvious stuff of who gets promoted to management. Well, the people that look managerial.

And that is what that looks like in many respects. And this is one of the reasons why when I talk about management, I like to separate the notion of management from leadership. Because I think that anyone can be a leader. You don't actually have to be the administrative manager of an individual to be a leader to them. I saw a great poster once when I was younger. Leaders are like eagles. We don't have either of them here. Yeah, yeah. I do miss good motivational posters. Oh, yeah. You know, I think that there's some truth to it. I think that finding people who are genuinely invested in being able to enable the success of others, which is how I define leadership, is challenging.

I think that, you know, especially in rather capitalistic type industry like we're in, there is a lot of measurement of people's success by their own personal achievements and by their ability to beat their own drum. And I think that it's something that is, frankly, a failing of our industry, where we don't do a better job of encouraging folks and rewarding folks that actually look out for others and enable the success of others. Because I think that that's something that is ultimately you think about how you build strong teams. And it's not about getting a bunch of individuals who can do amazing things individually. It's about getting individuals who are capable of working together and being able to do more than they would be able to if they were simply working individually. Do you ever find that people are chasing management in many respects because they think that it's something very different than what

it is and then find themselves in situations where, well, I'm the dog that caught the car that I was chasing and now, only now do I realize that I have no idea how to drive the thing. Oh, absolutely. So this is something that has been interesting me a lot recently in the sense that I think we as an industry also do a very poor job of measuring management, measuring leadership. We give a lot of power to managers through performance reviews, right, to measure their individual contributors. But there are very few companies who actually efficiently do things like 360 reviews, which has always confused me because I think that

that implies that you're getting feedback from all around you, as opposed to what you really want is you want feedback pointed back at you, which would be 180, but maybe that's just... Let's be clear, it was also pioneered by the German Wehrmacht in World War II, which is, yeah, basically how some people I've worked with do tend to manage. Yeah. I think that if we can think about how do we measure the success of a manager, is it simply a function of the output of their team, or are there other efficiency metrics that you should be looking at? A very obvious one is how efficient is a manager from a perspective of the utilization of their resources? And when I think about that, I think about are they actually able to effectively hire?

Are they able to effectively retain the people that they hire? What does it look like for the people on their organization from a promotion perspective in terms of skill growth? Do they become more valuable over time? Those are ways in which we can think about how we measure the manager potentially directly. And then there's indirect things like, what's the qualitative aspect of those individuals that work for them? Are they people who are enjoying the work that they're doing? Are they motivated to continue to work towards the company's vision and mission to be able to actually make their manager look good, but also make the company successful. A challenge too, because I've seen this myself is, all right, you're now elevated to manager.

Congratulations. It's not really a promotion. It's a lateral move. However, a lot of companies don't treat it that way. They don't compensate it that way, et cetera. And oh, okay. Management, it turns out is not for me. There's no real good way to say I'm going back to an IC, especially at the same company, without it being perceived by many, rightly or wrongly, as a demotion or a failure. This question of the motivation of people, why do they want to go into management? I think that oftentimes this is misplaced, right? A lot of times the number one motivation that I've heard has nothing to do with wanting to actually help people or solve people problems, as you said earlier. It has to do with, I want a bigger paycheck. I want more seniority. I want more responsibility.

And therefore, the only path available to me is management. In fact, many career ladders at organizations require an individual contributor to go to a management position before they can become a principal or a staff level engineer, which is nonsense. First of all, why would you torture the individual to do something that is so completely and utterly outside of where their interests are? Secondly, why would you just decimate your lower level individual contributors, your newer individual contributors, by having someone who is completely non-inclined towards management be responsible for them. Oh yeah, used to be your peer, now they manage you, and great.

I think people underestimate exactly how broad the blast radius of a manager is. Yeah, talk to anyone and they'll be more than happy to tell you the worst manager that they've ever had. At the same time, they'll also probably be able to tell you the best manager that they've ever had. Oh yeah, I've called both of those out, only one of those by name by the way, in conference talks that they've ever had. At the same time, they'll also probably be able to tell you the best manager that they've ever had. Oh, yeah. I've called both of those out, only one of those by name, by the way, in conference talks that I've had. Because it's, yeah, you can probably guess which one I would call out and which one I would not name publicly. Yeah. It depends on the conference, I guess. Oh, yeah, absolutely. It was, you know what your problem is, Khan. Yeah, it went super well. It was fun. And management, especially in the current era, is getting interesting as we're seeing the heating up of the market in a bunch of different ways. And I understand, to be clear, that Twitter is not a perfect microcosm of the industry. But there's a recurring theme that I'm seeing among a number of engineering types that seem to get, and again, I don't want to get letters for this, so if I misstated audience, please go ahead and be kind. But there seems to be a certain thread running through engineering

communities that the purpose of a company is to provide a utopian work environment for its staff. Now, as someone who runs a company myself, yeah, I absolutely want to provide the kind of working environment I wish I'd had in a bunch of different environments. And that's not going to work for everyone, but that's okay. But fundamentally, we're here to make money, and ideally enough monies that we can keep the lights on. And that does mean that however we want to treat our staff, that has to be subordinate to, can we continue as a going concern? So yeah, it turns out we can't sustainably outbid Netflix on every hire that we make. And we aren't able to wind up having three catered meals a day as a full remote company delivered to everyone's house.

Now, I'd like to in a world where money flows like water, but it doesn't. For better or worse, there are constraints and constraints shape us. But there's a thread that I'm starting to see of, I hesitate to call it entitlement, but it trends slightly toward the direction of folks who are in tech and in some ways seem very far removed from business realities. Now, let's be clear. In the FANG world, yeah, it's pretty attenuated. And in startup land where, well, we're VC-backed, so we're losing money by the billion, but we're making it up in volume. Great. That is not necessarily what I'm talking about here. I'm seeing a thread where, oh, engineers are clearly the smartest people

in any company, which means that every other department should defer to them. I disagree with that position. I want to follow that thread a little bit with regards to engineers. So I've worked as a a little bit with regards to engineers. So I've worked as a software developer. My condolences. Yep. I've worked as a technical salesperson. I've had the opportunity to work in pretty much every department with the exceptions of HR and finance. So that has been part of my career of jack of all trades, master of none. But it has given me some interesting insights in terms of the value that different organizations, different individuals bring to a company. And I think that one of the things that I will say is that for the longest time in large organizations, especially

non-tech industry organizations, the engineer or the developer was at the same expectations or the role as someone in the janitorial staff, right? It was basically, you're part of the plumbing. You just do the things so that the tech just works and we're going to have the other business folks that are more responsible for actually making decisions that are going to make our business money. The quintessential example is, you know, someone like Kraft Foods or someone like John Deere, right, where you're building tractors for the longest time. The guy who ran the website wasn't

going to be the guy who was going to make or break John Deere's quarterly earnings. Now you've got tractors that literally are more computers than they are mechanical devices. And so you suddenly have this change in dynamic with regards to the importance of that developer. But I think that something that's interesting also is that those other people who worked at the company didn't go away. They're still there. They're still important. In fact, they're still oftentimes making the buying decisions on behalf of the developers. The developers aren't the ones that are making those choices. And so you need to figure out how do you actually make the technology choices and the technology outcomes accessible to individuals that are in roles that were historically had nothing to do with tech.

This episode is sponsored by our friends at Oracle Cloud. Counting the pennies, but still dreaming of deploying apps instead of Hello World demos? Allow me to introduce you to Oracle's Always Free tier. It provides over 20 free services and infrastructure, networking, databases, observability, management, and security. And let me be clear here, it's actually free. There's no surprise billing until you intentionally and proactively upgrade your account. This means you can provision a virtual machine instance or spin up an autonomous database that manages itself, all while gaining the networking, load balancing, and storage resources

that somehow never quite make it into most free tiers needed to support the application that you want to build. With Always Free, you can do things like run small-scale applications or do proof-of-concept testing without spending a dime. You know that I always like to put asterisk next to the word free. This is actually free, no asterisk. Start now. Visit snark.cloud slash oci-free. That's snark.cloud slash oci dash free. I've always been a big believer in the idea that

if you're going to transition into a new field, be it into tech, out of tech, etc. Great. In almost every case, you should find ways to do that laterally. I think that this idea that, oh, you're going to go ahead and just start over with an entry-level job after you've been in a field for five years. No. Find the position that's halfway between where you are and where you think you want to go next and start getting exposure there. In time, it's those niches that add value that distinguish you from other folks. It turns out that they don't generally want to hire someone into almost any role that comes from central casting, where it's, all right, give me a standard MBA with the following

pedigree and drop them in as my new executive, whatever. No, they want to see things like industry experience. They want to see things that distinguish folks. And having experience in industries that are not traditionally purely what this role is, is super helpful in a lot of different ways. What I do pretty clearly blends finance and tech. That goes reasonably well. Increasingly, it starts to blend media, which is something I don't pretend to understand, but here we are, he said into the microphone. Yeah, well, as long as you're not starting the next Fox News, I'm fine with that. No, no, generally not. Okay, fair enough. But I think that you're right. This is one of the things where, trailing back as we've throughout

this conversation to the notion of leadership leadership this is something that I found extraordinarily rewarding and empowering that I've done with individuals that I've brought into new organizations either through initial conversations during an interview process or during as part of their onboarding is I sit down and I actually talk to them about what are their plans what are their expectations what are their goals not only for the next 30 60 90 days in this role that we're talking about but what are their plans? What are their expectations? What are their goals? Not only for the next 30, 60, 90 days in this role that we're talking about, but what are they thinking about from a perspective of what do they want to do in the next year, in the next three years, five years, 10 years? Like what are those checkpoints of what do you want to do in this role?

What do you want to do at this company? What do you want to do with your career? Like where do you see it headed? And it doesn't mean that you're writing this in stone or that like, I'm going to hold you to it. But I think that one of those things that's really empowering for a leader is to be able to help those individuals find those connective threads that tie one position to the next

and help them get there. If they're somebody who is saying, hey, look, I'm currently a developer, but I really wish that I could give more talks. Okay, well, that's great for me to know. Let's put you on some projects that maybe actually would result in a great content for a talk that you could give at a conference. And then we'll figure out how do we work with the marketing department to be able to help you bring that to fruition. There's a lot of ways to be able to leverage this experience that you have as a leader, as a manager, to an

individual who's coming up in their career and saying, hey, look, this is how some more ancillary things are connected and being able to bring those back to them. I really wish on some level that there was a more defined path toward a lot of these things, where this stuff is explained to folks. So often I had terrible managers that in hindsight weren't that terrible because I didn't understand where the role started and stopped. I tended to view the role of the manager as there to protect the team, the end, and be our advocate in the organization and get us the thing that we want and what do we want, comfy chairs. And it turns out that that isn't ever how it really works.

If I had to define management, it would basically be balancing competing priorities more than it is almost anything else. And counterintuitively, the higher you rise in an organization, the more responsibility you have and the less you can actually directly do. Everything you do drives influence, and that's it. that's how they see their career progressing. This is a close corollary to the engineer that wants to move into a product management role because they want to have greater oversight into the decisions that are being made about what's getting built. And what you come to realize for any engineer who successfully made that transition is it's really complicated and difficult to be able to have that mental switch take place between this is how I'm going to build it versus this is the priority of what needs to get built next. And all too often, you see engineers that land in product management roles that are dictating how

something should be built. And suddenly the engineers are just like, no, I have no respect for you because that's not your job. And likewise, in a management role, oftentimes people view that as an opportunity for them to make all the choices, make all the decisions, and suddenly lose sight of the fact that they used to be on the other side of that outcome themselves and were disappointed when they weren't included in some way, shape, or form, or their priorities weren't taken into consideration. As you look through your own career, what is the worst job experience you've ever had?

Or the worst job you've ever had? Or the worst boss you've ever had? That's always a good one, too. Pick a superlative and not the good kind. Hit me. Yeah, no, I mean, look, I think that probably the worst experience that I ever had with a manager, with a boss, was actually when I was first a software developer. And my manager would occasionally just come up behind me and just stand and watch me code. And we're not talking about pure programming where it was just like we're working together.

No, it was literally would come up, stand behind me on my shoulder and just stand there, not saying anything, just watching me write Java code. And that was probably the most disconcerting experience that I've ever had in a job ever. I lasted about six months. And then I was just like, I need to move on to something else. It turns out one of my failure modes was that I was great for the first three months in new ops roles because things were invariably a fire. And I know how to solve those things. And then it becomes a maintenance role. And I'm bad at that. For the longest time, I thought I was just

a crap employee. And I am, but for different reasons. Instead, though, for me, it turned into a, I need to find the thing that I'm good at and embrace that. And I have to say, it was not being basically a cloud comedian on Twitter where my primary means of communication is shitposting. But, you know, here we are. And this is how we've gotten here. I mean, know your strengths, man. Know your strengths.

Yeah, lean into it. I mean, you went to college in Maine. You know what it's like there. It's dark and cold. Nine months out of the year. So all we do is sit inside and develop personality disorders. And well, here we are. Well, hey, I mean, I took a break from tech after that first job in software development. And I actually went back and worked for a guy that I met while I was in school as,

and I worked for him. He was a general contractor. So I have a appreciation for Maine winters in a way that I never gained as a privileged college student when I was actually digging snow out of ditches to be able to pour concrete at six in the morning and then later in the day I got to go up and use 80 pound weight shingles to reshingle a roof in 20 degree weather. So it was an eye-opening experience but I'll tell you I learned pretty much everything that I know about how to build infrastructure from that eight months that I spent doing everything from framing, ditch digging to electrical and plumbing and roofing. Kind of fun how often it is that we wind up trying other things. And this is part of it, too.

As much fun as it is to complain about various jobs and whatnot that we have, let's be very clear here for a minute that I'm not dealing with hot tar being paid seven bucks an hour. There are advantages to the war jobs I have. I mean, that was a number of years ago, but I still got 10 bucks an hour. My first job at the University of Maine call center, working in tech. In those days, I think I was being paid something like 5.35 an hour to answer phones, which again, not that hard of a job. I made a lot more money a couple of years later when I moved to construction. Yeah, wouldn't recommend any of those things for me these days, but it was instructive. But at the same time, I would argue that you also have benefited from those experiences in the way that you approach the things that you do now. And I think that that's one of the things that I've tried to bring forward in my career is look for

those opportunities to make those connections and understand the value of those experiences and be able to help to enable other people because I've had those experiences. To me, at least the answer is to turn whatever you've done, whatever happened to you into some form of empathy. The idea of, well, I had a struggle coming up, so you should do. Let's instead focus on making it better for the people who follow. Send the elevator back down, as it were. I mean, I think that that's great advice, and I think that it's something that's done far too infrequently. One of the things that I've noticed is that that aspect, unless somebody's actually been through the experience where somebody's done that for them, it is oftentimes something that is a lot harder for people to see.

This goes to your earlier statement around the expectations that maybe are changing in not such great ways with regards to what people are expecting from companies, what people are expecting from managers. I think that there is a distinct lack of expectation setting that takes place at companies in terms of what is the role of the company? What is the role of an employee? And how can those two come together to still have a positive interaction,

but aren't overstepping on either side? Because that's really where you get into problems. That's where, like, all of a sudden, you have these companies that are looking to fill the role of, I will take care of all aspects of your life, when in reality, that's not a very healthy relationship for an individual to have with a company. So I want to thank you for coming to speak to me. What are you up to these days and where can

people find you and why should people find you? I don't know that anybody should find me. I hope this email finds you never. I hope you're free. No, I mean, I would love to find folks that, you know, I can add value to and help out. It's easy enough to find me on Twitter. It's just at A-Z-I-M-M-A-N, A-Zimmon. And they're welcome to reach out to me there. My DMs are open, much to my displeasure sometimes, but happy to help people who are looking for help. I'm particularly interested in spending my time with those individuals who maybe are coming from underrepresented backgrounds in tech and looking for ways to be able to either get into tech

or to move up within leadership roles in tech. But I'm spending a lot of my time doing a lot of coaching, doing a lot of advising for small startups. And then also just as a small side project, I've been working pretty extensively with James Governor and a woman by the name of Kim Harrison on this little thing called progressive delivery, which is, as far as we're concerned, it is the next iteration of the

software development lifecycle that we've written about and talked about pretty extensively. James and Kim and I are working on a book together to be able to capture all those ideas and bring them and coalesce them for people to make more consumable. But, you know, ultimately we're trying to say, hey, look, the way that we've done things leading up till now, moving from waterfall to agile to continuous delivery into what's next and look at some of the market conditions that have changed. A lot of the stuff that you talk about, I think that you would be the first to point out how things have changed since the launch of AWS. Oh, yes. It's more confusing now. Oh, way more confusing. And the ways in which people consume cloud-based services has radically changed.

And so I think that the way that we are building software, the way that we're consuming software, is something that we need to put some serious thought into. And the players that are, you know, as I spoke about earlier on this talk with you, are different. It's no longer just your developers that care about your AWS choices, or care about the cloud service choices that you're making. You've got other individuals, you know, whether it's the finance side, like you focus on, or, you know, thinking about it from a perspective of the marketing team, or the HR team that's thinking about which cloud service, HRIS, are they going to use? There's a lot of people that need to be party to those choices that you're making and how you build out your company stack, as it were. And the progressive delivery model looks to take into consideration that changing and evolving

group of people. And we will, of course, throw links to that in the show notes. Thank you so much for taking the time to speak with me. I appreciate it. Corey, thank you so much for having me. It was a pleasure. Adam Zeman, startup advisor, and oh, so much more. I'm cloud economist Corey Quinn, and this is Screaming in the Cloud.

If you've enjoyed this podcast, please leave a five-star review on your podcast platform of choice. Whereas if you've hated this podcast, please leave a five-star review on your podcast platform of choice, along with a scathing comment telling me why you as an engineer are best suited to be the manager of everything. If your AWS bill keeps rising and your blood pressure is doing the same, then you need the Duck Bill Group. We help companies fix their AWS bill by making it smaller and less horrifying. The Duck Bill Group works for you, not AWS. we tailor recommendations to your business, and we get to the point. Visit duckbillgroup.com to get started. This has been a HumblePod production.

Stay humble.