The Changelog: Software Development, Open Source - Generative engineering cultures (Interview)

Episode Date: September 17, 2019

Dave Kaplan (Head of Software Engineering at Policygenius) joined the show to talk about Generative Engineering Cultures and how they have become the goal of industry-aware tech teams. We talk through the topology of organizational cultures ranging from pathological, to bureaucratic, to generative, the importance of management buy-in (from the top down) on leading a generative culture, the ability to contribute original value which is deeply rooted in the concept of aligned autonomy. We also covered the 6 core skills required for us to be empowered in our teams.

Bandwidth for ChangeLog is provided by Fastly. Learn more at Fastly.com. We move fast and fix things here at ChangeLog because of Rollbar. Check them out at Rollbar.com. And we're hosted on Linode cloud servers. Head to Linode.com slash ChangeLog. This episode is brought to you by DigitalOcean. Guess what?

DigitalOcean recently added MySQL and Redis to their list of managed databases. Their full managed databases lineup now includes the three most popular databases out there for developers, Postgres, MySQL, and Redis. It'll eliminate the complexity involved in managing, scaling, and securing your database infrastructure.

And instead, get back to focusing on building value for your users. Learn more and get started for free with a $50 credit at do.co.changelog. Again, do.co.changelog. All right, welcome back, everyone. This is the Change Local Podcast featuring the hackers, the leaders, and the innovators of software development. I'm Adam Stachowiak, Editor-in-Chief here at Changelog. On today's show, we're talking with Dave Kaplan, Head of Software Engineering at

PolicyGenius about generative engineering cultures and how they have become the goal of industry-aware tech teams out there. We talk through the topology of organizational cultures, ranging from pathological to bureaucratic to generative, the importance of management buy-in from the top down on leading a generative engineering culture, the ability to contribute original value, which is deeply rooted in the concept of aligned autonomy. And we also cover the six core skills required for us to be empowered in our teams. So Dave, we're here to talk about generative engineering cultures, something that's important to you at Policy Genius, and you've written an excellent post for us on change.com all

about that topic. Why don't you kick it off by telling us, I mean, what does that even mean, generative engineering culture? New terms for me, and probably for a lot of our audience. How do you define such a thing? Yep. So I'll start with the end, what the goal is, because I can probably say that concisely, and then we can talk for quite a long time about what it actually means. Goal that I have for my engineering org is I would like at least 75% of them,

of the individual engineers, to be contributing original value, something that they conceived some opportunity and solution on a regular basis. Here at PolicyGenius, we have a cycle of planning every four months. So I think that's a good time period where I can expect engineers to contribute that type of value. The generative term actually comes from this guy, Ron Westrom. He wrote a book and a series of articles in the 90s where he went and he studied different organizations. And he wanted to understand what type of cultures existed out there. And he came up with this spectrum of organizational cultures. And so what he found out is that, okay, on the really negative side, let's say all the way on one end of the spectrum,

there are what he calls pathological cultures, very fear-driven, very siloed. Everybody just does what they're told. You know, if you follow the news recently, it's something like Theranos. Great book, by the way. It was an amazing book. As soon as you say that, I'm thinking exactly how that book played out. It was very pathological. So was The Leaders. Good book and good Netflix documentary. Oh, is there a documentary? I haven't seen the documentary yet. It might have been HBO. HBO, yeah. You're right. It was HBO. All I know is Theranos was a company had

something to do with like genetics or dna or something and then there was like huge scandal just for those of us completely on the outside didn't see the book didn't know there was a documentary what do you mean by there like was there some pathology going on there yeah theranos was a company that was around for and i may be remembering this, but about 10 years, a very big cult of personality with their leader, the CEO. So it's Elizabeth Holmes. She's under investigation right now. And basically she had this very novel idea, which was, can we as consumers go to CVS or Walgreens or whatever? And can we have a machine that will take our blood and take a very, very small amount, especially for those of us who are deathly afraid of needles,

and can it run all sorts of tests on it, genetic tests to understand your health and to understand potential risks that you may have down the road. Essentially, it's like going to Quest Diagnostics, but doing it for a very, very low price and doing it in a very, very easy way. And so they were trying to develop this software and hardware that would do that. And I think they raised billions of dollars. Billions, yeah. They had everybody in the world that was rich or influential in Silicon Valley,

in venture capital, giving them lots of money. From the Clintons to political to Silicon Valley titans, whatever it might be. A lot of people were really... And she was very captivating. She has these big eyes. This is going way deep

into this. The book, by the way, is called Bad Blood. But she's a very captivating person. She's has these big eyes. This is going way deep into this. The book, by the way, is called Bad Blood. But she's a very captivating person. She's got these big eyes. Yeah, she's got, so she's known to have big eyes that are, you know, in quotes, beautiful. I think she's got nice eyes, but she didn't blink very much, you know? And so, they were just big eyes that were just very captivating. So, when you would speak to her, it's intimidating and captivating. So, you felt like you had to follow her. even though she may not know what she's talking about she seemed like it very much so she was a very good leader in those ways i see yeah it got so dangerous that she actually would like overrule literal scientists on like the true scientific ability from being able to take this small amount of blood and examine it without

diluting it too far and all this stuff and she was very fixated and this is why it's called pathological she was very fixated on like the idea that you can have this device in your home like you can have an ipod anyway so we're way upstream my fault i think for asking for kind of worth it though i mean it really describes the pathological... Well, the pathological culture is like all surrounding the singular individuals on top, right? Oh, and people in her organization were deathly afraid of her. Not just while they worked for her. After there were whistleblowers, she went after them legally.

And they had these very, very airtight NDAs. And the reality was, was they were selling the lie for 10 years. And they just kept raising and taking people's money. And so it's probably one of the worst modern examples of that. Another great example is if you watch the documentary on FIRE, the company behind the FIRE Festival. Oh, yeah. understand an entire company's culture, let alone the engineering department's culture, then you can kind of understand, is this going to be a good fit for me, my personality, the kind of effort I want to put into my employment somewhere or whatever, my career. So I think really kind of there's somebody out there thinking I've worked at a Theranos-like company before,

and you know it very well when you've worked there and you felt fearful of the leaders and the, you know, the effects on you and your life. That's right. And it's, it's definitely shaped, you know, me and my career. I can't claim that I ever worked for a company that was quite as bad as what they described at Theranos, but you know, I've, I've experienced different cultures and the good effects that it has on the people and also the actual product that is produced and the negative effects that it can also have. What he described as the middle of the road. So, you know, okay, pathological, nobody wants that. That's all the way on this one side. In the middle is probably

the most common that we see with organizations, especially ones that have reached a certain size is the bureaucratic culture. You know, this day and age with empowered cultures and all that, I think bureaucratic is thrown around as a bad term, but there's a reason why it exists. It's a rules-based culture. Anything you do, you know, if you're an engineer, are you following the tech vision? Or if you need to expense something, are you following these expense programs? And the idea is, you know, with bureaucracy is to create as even and as fair of a process for a very unwieldy large organization. The trick is, is can you find a way as you grow to reach what's called a generative culture, which is the term that Ron Westrom coined, where you instead allow people and trust people to make really good choices on the ground, still reverse that decision-making process instead of having all the decisions either made through

rules or through top-level management, have them made by people that are closest to the problem. Can you do that as you scale? And that is the challenge that I'm undertaking. That's what we're going through here at PolicyGenius and a lot of other companies as well. Just to frame it a little bit more, there's a book that came out a couple of years ago by Jez Humboldt and a couple of partners. Jez is, if you're not familiar, she writes the DevOps report every year. They set out, her and her collaborators, to understand whether all of these modern practices that have come about in engineering in the last 20 years, generative culture was one of them, you know, Agile and Scrum and things like hackathons and CI, CD and all that, whether they actually fulfilled the promise of what they were preaching. And so they tried to create a survey, a quantitative survey, to figure out whether these practices resulted in high-performing teams.

And the book is fascinating. Half of it is about what they learned and what actual techniques do contribute and which ones don't, as well as half of it is because I think they anticipated that people are going to question their methods is just a study in how they created this survey and how they got it to what they call a quantitative state rather than just being qualitative. And out of that, they did find that generative cultures and the aspects that define a generative culture are one of the biggest indicators of a high performing team. And what that means is just what I said a little bit earlier, is that decisions are made on the ground. People can come up with original value and find opportunities and actually find the solutions and execute them on them independent of top level sign off. And they can do that on a frequency. It's a culture.

And this is something that resonates with me. It's a culture where nothing falls through the cracks. When you're part of a bureaucratic culture and, you know, every your headcount needs sign off,, your roadmap needs sign-off, somebody's dictating your every move, things fall through the cracks. I'm accumulating tech debt, I'm accumulating product debt, security debt, whatever. And you always feel like you have to ask for permission to solve those problems. And when you do get the permission, it's usually few and far between. If you're lucky, maybe two projects a year between the big product projects. So can you find a way

where you can solve the product requirements and you can solve these issues which cause real slowdown and churn on teams and empower people to do it and make the right choice? That's the challenge, which I think most companies try to attain. Few do. And then the ones that do have a lot of difficulty maintaining it over time. And so that's a lot of what I wrote about. Do you start out as a generative culture or do you have to evolve into it? You mentioned scaling into, I'm not sure if, do we generally, as we create cultures, begin either as a bureaucratic or pathological terribly and then move into a generative or is it sort of like can you just jump right into generative it's a good question i think it depends on the company and the size of the company i don't think small companies

start out as bureaucratic that usually happens over time four or five people in a we work you know everybody wears a thousand hats and has full autonomy to make decisions. Right. But certainly as the size, you know, usually around the time you get to, okay, a hundred, 200, 300, now you start to layer in rules and approvals and check here and check there. Or, you know, even worse is, you know, the long roadmap. Here's what we're going to do for the entire of next year, entirety of next year and have your work spoon-fed to you. So I think the answer is that, no, you don't start out. You do start out sort of in a generative way, but it's more on accident than deliberate. And then I think very naturally you work towards a more bureaucratic as your leaders move up in the organization because they've hired a whole bunch of folks.

My conjecture is, and I'm just completely, complete conjecture, because I've never been through this before, is that as you scale up in company size, the move to bureaucratic, and like you said, it's kind of a restorative, or it's like, it gives me a nasty connotation, like bureaucracy, bad, you know?

But rule-oriented, maybe that's just a way of saying the same thing without the nasty term it's a reaction to a problem it's not like all of a sudden we hit this company size it's like now we're a bureaucracy and like there was a vote taken we're going to be bureaucracy now it's like there was a problem and we're trying to achieve some sort of we're trying to react to that problem by introducing some rules we're at a size that we need some rules now. I think I tracked, Adam probably as well, the beginnings of GitHub, the company, very closely, both on the product side as well as just watching them scoop up all of the talent amongst open source developers that I know. And they started off very, very generative and really almost anarchical.

Just complete individual freedom. You work on what you think is important. And that lasted for a certain amount of time until it didn't work anymore. In fact, they were giving conference talks and they were like saying, this is the way forward. People work on what they think is important. This is freedom, this is et cetera.

And it crumbled at a certain size. And I was like, wait a second, this doesn't work anymore. they think is important. This is freedom. This is et cetera. And it crumbled at a certain size. And I was like, wait a second. This doesn't work anymore. We need some rules. We need some guidance. We need other things. And so when you say it's difficult to achieve and maintain, I definitely see how it's difficult to maintain as you grow.

But it's interesting that you kind of have it de facto, unless you have a pathological scenario where the person that started the company is just, you know, gripping with power. As you're small and as you get bigger, you kind of start to need more structure, more rules, but that then, you know, grinds things slower. And so you're trying to fight against that need maybe. Totally right. I think you're totally right. And that is exactly why it happens. That's also why I'm careful to say that even though the connotation of bureaucracy is a bad one, it comes about for usually good reasons. And actually, usually because they want to treat people fairly as you said, the company starts and it's generative. Usually the people that are there in the beginning are very mission driven, hopefully experienced, and they get a lot of hands on experience in different parts of the organization. All of a sudden it grows and they are still the ones who know the most about every part of the organization. They were down there in the beginning doing the dirty work. And what happens is either they hold on to that and say that we're the only ones who

can make intelligent decisions about the future of this company and the details of the future, or they find a way to scale that knowledge out and get new people who are close to the problems to solve those problems. And so there's a number of ways to do this. And also, there are a lot of companies that do the opposite. They very, you know, with good intentions, they say, okay, no, we want to empower people, we want, you know, the people closest to the problems to solve it, but all they get is chaos, because they have people solving different problems that don't actually amount to value for the company. It's also bad. And I pointed this out in my article

that I've been in places where there were a lot of good intentions, but without the right structure to create this generative type of culture, it really actually degraded into chaos. That was what I would think could be the biggest potential problem with generative cultures. If I'm looking at these three culture types, pathological, bureaucratic, generative, I think for most engineers and for myself, I can speak very clearly that the generative one is the most attractive to me, right? Like I want to be empowered. I want to have, what do you say, original value. I don't want to just, you know, grab a ticket and go do the coding. And at the same time, I recognize that if a bunch of me's out there just go about doing what's right in our own eyes, right? We just, I'm just out there

adding what value I think is there. That is kind of, can become our own eyes, right? We just, I'm just out there adding what value I think is there. That is kind of, can become like anarchy, right? It can become chaotic. Absolutely. And so how do you still shepherd, right? Moving forward together as a unit, as a bunch of individuals working as a team

versus as just this like blobby old collective. Yep. So that's a great question. And the phrase is aligned autonomy. So it's a realization that leaders have where, okay, maybe I don't need to create the whole roadmap. Instead, my job is to create alignment. Okay.

And there's lots of kind of tried and true methods of doing that now. We use OKRs, so objectives and key results, which is gaining a lot of popularity in the industry. And exactly for this reason, it's a way to create alignment around the goals of the company and make them extremely clear, but without being prescriptive. Now, of course, you know, it depends on the ability of the leaders to actually create them in that way. So they're not prescriptive. You know, as a counterpoint, for example, a previous company I worked on, we spent about two months every year coming up with a roadmap for the next year. It was a very grueling process. It was a very prescriptive process. We would come out with literally the projects we would work on. We would start with the projects before the value.

And then of course we would, you know, maybe execute on 60% of that as things changed on the ground. What we do here, where I think we've got a fairly good OKR process that predates me, I think that this push has been in the blood of the company for quite a while, where I came in as to help on the engineering side spreading this, is that creating those objectives. So for example, maybe they are top level objectives of we are going to achieve X revenue at the end of this year. Maybe it's a little more detailed X revenue in these business lines with this NPS score, net promoter score, to make sure that we're doing it, but without sacrificing customer happiness, right? We're going to have this level of engagement with our products.

Very, very objective-based things that if we achieve will lead to the success of the company, but in no way are prescriptive. Now, those are top levels. And so what happens is, you know, we start at the beginning of the year with, you know, the leadership team collaborating and generate these very, very few top level objectives. And then every department goes and takes what's my piece of that. Okay. And as it goes down, it gets a little more specific because, you know, saying, you know, revenue and, you know, customer support, you know, is not surprising, shouldn't be surprising to any company. But then as it goes down, well, what does that mean for marketing?

What does that mean for product? What does that mean for engineering, which usually levels up into product O'Cares, but also has to have their own to make sure that we can scale ourselves and the technology and that it's maintainable. And then we draft up our own and then it goes down to every single team. And then what happens is there's a review process. This is what we propose. This is how we can contribute. Here's an objective. Here's something you can actually measure us on. So for example, some of my OKRs this last four months were about, some of them were about recruiting because in order to get to a certain

size, I have to recruit engineers and leaders. Some of it was about scalability of our systems, things like removing tribal knowledge from our engineers where we maybe had a little too much, making sure that we are maintaining and prioritizing technical debt and consistently working on it. Things like that that are still very objective-based. There's a lot of different ways that we can solve those. And then once there's agreement all the way up the chain on that, now we've got that alignment. So if people do want to work on something and stand up and say, hey, I want to solve this problem, they can articulate how that is actually going to make this company successful. And I'm starting to see that now. When I first started here, I did have to help and form some cross-team

groups, guilds, which is a popular structure that I'm pretty fond of, to solve some of these problems, tech debt, et cetera. Now what I'm seeing is now having done this a few times over the last year is people are standing these groups up themselves. We'll have meetings where we're saying, hey, I'm going after this problem. I'm using 20% time to do it. Who wants to help me? And people raise their hands and management has nothing to do with it.

It's really, really gratifying to see. That's the cycle that we want to create. Now, there's a lot of detail that I can fill in from the start to where I am now and certainly where we're going in the future. But I do believe that that alignment gets at what you were talking about. This episode is brought to you by GitPr. Git Prime helps software teams accelerate their velocity and release products faster by turning historical Git data into easy-to-understand insights and reports.

Because past performance predicts future performance, Git Prime can examine your Git data to identify bottlenecks, compare sprints and releases over time, and enable data-driven discussions about engineering and product development. Shift faster because you know more, not because you're rushing. Get started at getprime.com slash changelog. That's G-I-T-P-R-I-M-E dot com slash changelog.

Again, getprime.com slash changelog. So we break this down, this fellow who wrote this book, Ron Westrom, he kind of described pathological, bureaucratic, and generative. You mentioned team of teams, but before we go into that, I kind of want to kind of examine a little further the attributes of how these play out. So a generative, for example, a regenerative, high cooperation, messengers trained, risks are shared, bridging is encouraged, failure leads to inquiry and novelty implemented. Those are sort of across the other spectrums. You've got low cooperation, modest cooperation. So you sort of have these reoccurring attributes. Why do you think he chose these particular attributes to sort of describe that? And how do you see them play out? Like, for example, messengers trained, what does that mean? Yeah. So, and even the, you know, some, some people might call this an empowered culture. I do think generative is the right one. And

the reason that he chose that term is because he was trying to describe the outcome. What happens when you create this type of culture. There are many ways to potentially create this, but in the end, it will generate value from every single person. And so when you say that he chose these attributes, if you listen to the way he describes it, he didn't choose them. He was an observer. He was almost a sociologist.

And what he found is that these were the attributes that correlated in certain groups of organizations when they figured out how to turn the decision making around from being from mostly from management to mostly from the people on the ground. So yeah, I wouldn't say he would describe it as the, you know, he chose these, but these are what he observed, if that makes any sense. And Jared, something you said before was naturally you and someone like you would want to be in a generative culture. From a brain perspective, we fare better when we're involved in our choices. So it would make sense as a human being, I would desire to be in a generative culture. But what seemed like was coming out was almost like a good culture would be a mix of bureaucratic.

Because as you said, Jared, you got to have some rules at some scale, but you want to have a generative underlayer. Would you agree with that, Dave? I would. And this is actually a discussion I'm even having right now, because I think as long as you're deliberate about what should be rules based. So, for example, you know, as you grow, you need an expenses policy and you need a good way of saying what is in that expenses policy, what's outside of that, how does something get approved, what is the approval process? You can't just give everybody credit cards. That is a great example of something that probably should be bureaucratic and it's probably okay as long as it's not too arduous. But I don't think limits the creativity and output of the company. Similar is things like HR rules and processes, things like performance views, et cetera. However, if it's about the core value of the company, if we're talking about a software company, which PolicyGenius is a software-driven insurance

marketplace, then it's really about the way that the software is developed. Who decides what the solution is? Who decides what problems we're solving? And is that at the team level or is that from the CEO? Okay. And you hit on a point that I think has actually been studied and has been proven. You talked about how that's a place I want to be a part of, right? And that's one of the reasons why you want a generative culture is because- Makes it worth doing. Yeah. It leads to employee happiness, satisfaction, leads to low attrition rates, and it also leads to high-performing teams that add value to the company. So it's a win-win if you can achieve it, but it's not easy. There's a book called Drive, and there's a fantastic

YouTube video where the author talks over some drawings, which actually talk about the study of motivation and satisfaction for employees. And, you know, it goes through some of the misconceptions around how employees are motivated only by money, which has actually been proven, you know, at this point is probably known pretty widely, that is a in extrinsic motivator. It's motivating for a short period of time. Actually, the more cognitively difficult your job is, which software engineering is very cognitively difficult, the less it makes a difference, as long as you're paid fairly. You don't need to make 50% more than everybody else in market, but if you're making under market, well, then you start to care. Whereas things like ownership and control of your own destiny and decision making are shown to result in high motivation and high job satisfaction.

This is all part of the same theory and as you said results in motivated individuals. So there's probably two ways we can look at this. It's probably worth us focusing more on the perspective of an engineering side, a person who wants to be part of a generative engineering culture and thrive in such a place or become part of one. But before we get to that, which might be the focus of the rest of the conversation, first, if you have a company or you are an engineering manager, you have a team that's are an engineering manager, you have a team that's very bureaucratic right now, what are some things you can do to move in that direction?

Are there, you know, there's, I'm sure there's policies. You guys are policy geniuses. So I'm sure you have some policies, some things you can do like, well, this, this is what, because you want to, you want to create a generative culture. You don't have one. It's not, you can't just snap your finger. So what can you do? Yeah. And I think this is what this gets into. The answer to this question gets into why this is such a difficult thing to achieve and why it's hard to maintain. So the easy thing to do, there's a couple of categories that we can go into here. There is the, certainly the policy part, which is management snapping their fingers and saying, go be generative. Here's the time to do

it. Go nuts, right? Then there is the hard management part, which is the coaching, which takes time and a lot of repetition, right, with different folks. And then there is the being empowered, which I think is the most overlooked piece of the puzzle. You can't just empower people and delegate. You know, if you've been through any sort of management training, you know that there's a whole scale of delegation. There are certain skills that you need to learn in order to be effective as an empowered person to be able to actually solve a problem in a robust and high quality way. And that's the part that is the path to getting there. And that's why, you know,

we're still on the path and maybe we'll always be on the path because it's something that you have to maintain. Yeah. Like a garden. Exactly. And I think there's some things you can do very quickly. The policy is the quick one. So these are very opinionated ways. So I'm sure there's other ways to achieve it, but I'm a big fan of 20% time. And this is not Google's 20% time, which is go work on whatever you want, which honestly, they would even admit they've had some varied success there. You know, they've had things like Gmail come out of it, but they've also had just as many, you know, failures. But this is more of Marty Kagan's 20% time. So Marty Kagan, who is a huge figure in the product space, he actually started as an engineer over at eBay,

if I'm not misremembering that. He runs Silicon Valley Product Group. He's got this great saying. He says, I talk to all my CEOs because he consults with different companies to get them into a modern product practice. He says, I make a deal with every CEO I work with. You give the engineers a minimum of 20% time to work on architecture and

technical debt. I'm paraphrasing him. And I will never come and ask you to rewrite an application. Because the reality is, is that if you've ever worked in a place where all of your time is allocated for you as an engineer and things do fall through the cracks, if you're there long enough, you wind up having to eventually go back to someone in charge and begging them to rewrite your entire architecture, which nobody is happy about asking to do and nobody's happy to be asked that. And I think it's a very smart way of thinking about it because instead of saying, okay, you have 20% of your time to go do whatever, it's 20% of your time to shore up the engineering department, the architecture, whatever it is that will make this scale and make it a fun environment to develop in and work on. It's funny you mentioned Marty too, because his

book Inspired, I'm not sure if that's the one in particular you're referencing, but I will say that if you're listening to this and you're in product management, I read that book. I bought it September 2nd, 2014, apparently, according to Amazon. And this book is the one that enabled me to really understand product development, you know, the cycles of it. So I can highly agree that this book or that person, Marty, I didn't know his history, I just knew the book. I just read the book.

And it was an amazing book for product development. So I love that book. Yeah, and he really changed the way that a lot of folks thought about product management and moved it more towards the experiment-driven approach. And he's not the only one. There are certainly other people in the industry that have written about it. You know, Eric Reese has a book called The Lean Startup, which I always tell people is the gateway drug. You read it and there's no way back. But where Eric's book is a little light on practicality

and very much more about philosophy, Marty's is all about here is a book and you can go do it right after you read this. Yeah. I felt the same way. Yeah. I felt like every chapter I read, I can implement, you know, that, that cycle we were, we were in agile. So we were doing, you know, we were highly committed to scrum, even if we made our own rules, Hey, that's what you're supposed to do to bend them to your will for your reasons in agile.. But I felt like I could read that book and literally implement things right away. The problem is though, and I experienced this, which you've talked about before in terms of teams of teams and the empowerment of generative cultures, is it has to be top down. Because if you're trying to do generative from the bottom up or from

within, you may be able to sway that vote or persuade higher management or executives or whatever term you want to give to people that have chief in front of their name. You may be able to get them there, but if they don't respect the top-down approach to generative cultures, they're going to constantly unwind what you wind up. So for example, if you're in there and you're implementing a generative culture and your CEO doesn't agree with it, and they're constantly sidestepping you and undoing those things, you know, putting specifics into somebody's daily things, then they're not going to give you the objective. They're going to give you the process constantly. What is your thought on that? You're totally right. And this has happened to me multiple times in my career. Honestly,

it's a conversation and it's a, you know, it's a work stream I really hope I never have to deal with in the rest of my career, where you're trying to convince people to do the right thing, to do the thing that has industry standard, that is well documented, rather than spending the time on actually doing the thing, which is hard enough itself to implement. So for example, I remember, you know, as agile started gaining popularity, and there started to be, you know, examples of how it was benefiting, having to go back and convince my organization, which was largely Waterfall at the time. And ultimately, what that looked like was I had to carve it out on the teams that I had, but the rest of the organization wasn't there. And so our success was limited.

And I say that, you know, I don't want to have that ever again, because whenever I was looking for a new position or a new job or a new company, this was something that was top of importance for me. And these are the questions and the things that I talked to who was hiring me. So when I talked to Jen and Francois, who are the co-founders here at Policy Genius, I remember that first call. And immediately they were right there with me. They started talking about Marty Kagan,

Silicon Valley Product Group. They're like, we're going to the workshop literally in two months. And I was like, okay, we're in alignment here. The difficult conversation that I've had throughout my career, I don't have to have here. I mean, in the end, it's a weird paradox, right? Because you're empowering the people at the bottom, but the people at the top have to enable it. Yeah. So is this idea of a generative culture, has this become such a buzzword in our world,

in software creation, in startups, in product development? Is this a really well-known thing that people are actively subscribed to? Or is this a newer term that people are still adopting? Or are they already doing it, they just don't know it? So some people are, many people are doing it and don't know it. And so, you know, they've been either burned in the past or they've had great mentors. I've been fortunate to have some really great mentors throughout my career who've told them empower people the right way to delegate, the right way to mentor without being prescriptive. And so they are doing it, but don't necessarily know the term. I've had that mentorship, but then of course, I'm pretty up to date on the industry.

I think it's part of my job. I read a lot. So I get to also gain the benefit of the success and failure of other companies who've also contributed to this topic. Reality is, I mean, this term was coined, I think it was either early 90s or late 80s. It's been around for quite a while. It's only been applied to software development recently. It's not to say that there haven't been empowered teams in software development, but it hasn't been formalized. And I think that's what Jez did with Accelerate,

is they went and said, no, no, no, this is what this means. Here's the person who originated it. And yes, it does contribute to high performing teams, if you're able to achieve it. Where a lot of people, where there's a big missing gap, and is where you know what i tried to focus on in my article and one of the reasons i'm here talking to you all is that i think where there's a missing gap is the actual practices in how to achieve this kind of like the way that as you said marty filled that gap in product management where we knew we had to go towards experimental, but he said like, here's how everybody's doing it. That's where I'd love to fill that gap. Yeah. Well, it's almost like when you're looking for a position today or, you know, in the last 10 years, one of the questions you asked was really around workflow,

like, are you waterfall or agile? And I'm wondering if, if it's the same question we can ask of, or our listeners of our show can ask of, their next gig or the thing they're in even now. What kind of culture do we have? Is it generative? Is it pathological? Is it bureaucratic? And maybe they can answer it themselves or what they think it might be, but I almost wonder if that's a question or one of those things that's a criteria or an attribute that you begin to seek out and look for whenever you take your next opportunity? Well, if somebody says yes, if you say, are you a generative culture? And they say yes, just by saying that at this point, I think that's a great sign because that means they know what it is. They've read about it. You know, if they say they don't know what that is explained, they still may have aspects of it. And that's where I think you need to get into the details of, you know, and that's where your attributes, I think, are really helpful. The ones that, you know, that you threw out from the Ron Westrom article is, you know, how do you handle, you know, issues? Like, for example,

if there's an outage, how is that handled? And I'm sure most people would like to say, well, you know, we are collaborative about it. But getting into the details, you know, do they have postmortems? Are they non-blaming postmortems? Are they about understanding, you know, was the issue a technique or was it a process issue? Or, you know, do we not have the right safeguards in place rather than blaming people? You know, how does cross-team collaboration work? Does it even happen? Is it encouraged? Is it a reality? Those are the things that you want to see. And when you start to hear that things are fairly siloed, that people use strict scrum, which is good, I think, but without giving people the time to work on things outside

of those sprint tickets, which are handed to developers, that's when you start to go a little bit more towards that bureaucratic side. And Agile is an interesting change. I'm fully bought in. We practice a fairly robust, I'm going to use that word, form of agile here. You know, we're not dogmatic. We know the reasons why we do what we do, and we know the benefits that it'll have to the organization. But having come, you know, and spending enough time in this industry of having come from Waterfall, I'm also able to see the downsides of Agile and realize that it's up to us as managers and engineers to overcome them. And I'll tell you that I think one of the biggest

downsides to Agile is the loss of time management skills. I have written in my article a number of skills which engineers need to learn in order to be empowered, in order to go solve problems. I think the most important one is just knowing how to manage your time. I can't tell you how many companies I've talked to. I have peer groups in New York City, you know, where they say, yeah, we tried 20% time, we tried 10% time and it didn't work for us. But when you get into the reasons why, it's because, you know, they blessed it, the management blessed it and said, you have 20% time now go. And then people didn't know what to work on, or they couldn't find the time to work on it. And why couldn't they find the time? More often than not, it's because they didn't make the time. Now that is a real skill.

And when you're in a waterfall environment, you have to have time management skills, because there is very little structure. You know, it's kind of a misunderstanding that waterfall is more arduous than scrum. Actually, scrum is a very arduous process. There's a lot of structure in there. And it certainly does not make you faster in the short term. It's more about making you faster in the mid and long term so that you can avert bad starts, false starts, bad pans. Waterfall, I mean, what could be quicker and less arduous than I'll only talk to my product manager every two weeks and I'm only going to show results every month and we're going to release six months from now.

But it really forces you to, as an engineer, to develop time management skills. What is my objective this month? What is my objective this week, today? Whereas with Agile, if it's not focused on, engineers could come in every day and feel like they're being successful by just taking the top ticket off of the queue. And it feels really good in the short term. It starts to feel really terrible in the long term because you just start to feel like your last six months was just an aggregation of small little tickets. So I think it's very important for managers to work and coach with their employees so that they can develop those skills so that they can, yes, 80% of the time I'm doing tickets

and that's really important for the business and that adds a lot of value. But there's also my time and it's super important for me in my career to be able to figure out how to be creative, not just in the technical solution, but also identifying opportunities and also my own solutions, not ones that the product manager gave to me. There is that aspect of agile that I'm very acutely aware of. This episode is brought to you by TeamCity. TeamCity is a continuous integration and delivery server developed by JetBrains that helps you build, test, and release your software faster. It supports all popular build tools, test frameworks, version control systems,

issue trackers, and cloud platforms out of the box with no plugins required. TeamCity visualizes your build, tests, deploy pipelines, collects statistics on each step, pinpoints the root cause of failures, and suggests which commits might have caused the build failure. The professional version of TeamCity is free even for commercial use and lets you set up up to 100 builds and run up to three builds in parallel. For large organizations out there, JetBrains offers TeamCity Enterprise, and right now they're extending a special offer to our listeners. Get additional build agents and new licenses of certain enterprise versions with a 50% discount. Head to TeamCity.com slash changelog to learn more. Again, TeamCity.com slash changelog. So Dave, one of the things you mentioned that you have to be able to have

to engender this culture is people who are skilled to be empowered or they can thrive in an empowered state without descending into the chaos that is the fear, right? Against the rules is, well, what if everything just falls apart and people aren't being productive and there's not much being generated? And that comes down to really, I think the people who are doing the work, you have laid out six core skills that are required to be empowered. We talked about time management and planning, but this is really from your perspective. You're coaching these things to people.

And so I'm curious, when it comes to time management and planning, like, how do you coach that? How do you teach that? Like, how do I decide what to work on if I'm not, it's not dictated to me? So this is probably best described. Let me give a little intro that is also like an anecdote, which I think can help people listening maybe understand what I'm talking about here. So when I started at Policy Genius, I do think they had a generative culture. Jen and Francois had a really good implementation of OKRs, which helped align people.

But the engineers at that point, all of their time and all of their work went into product OKRs. So 100% of their work was dedicated to sprint work and tickets. And that was fine because it was a survival stage startup, for the lack of a better term. But they had just made a pivot, right? The company was blowing up and is continuing to blow up and really had gone from that survival stage to the growth stage, which is where we're in now. And something happens within the engineering world when that changes. So when you're in the survival stage, accumulating tech debt is the norm, right? Because you don't even know if you've got a product, right? So accumulate tech debt so you can get

experiments out, prove that there's a market fit. But once you got that market fit, now you have to, in a very appropriate way, pay down that tech debt and also continue to pay down and make sure that your architecture is maintainable, scalable, extensible. So when I started, I didn't know what the problems were. And I did my round of one-on-ones and different folks told me about different problems they saw. What I did my round of one-on-ones and different folks told me about different problems they saw. What I did is I put together a survey and I modeled it after, it's another one of a product trick, jobs to be done survey. I'm going to throw out a lot of terms here. We don't have to go into all of them. So I modeled it after jobs to be done survey, very long survey, like 40 questions, but essentially broke apart and shredded

the engineering workflow all the way from gathering requirements to delivering and maintaining software and everything in between. And basically asked people to rate, you know, level of frustration and level of sophistication on each of those areas, you know, from one to seven, one to seven Likert scale. So out of that, I got a nice quantitative read as to where the problems were, because I was new, you know, and I didn't want to be the wrecking ball and come in and apply blanketly a whole bunch of solutions where there weren't problems. So that helped me get buy-in from the team and also helped them all gain awareness of what each other was facing and what problems were

ubiquitous. Out of that, what we did, and this is in the first month that i started we created a 20 time which was fully agreed on by jen the ceo and the head of product francois so we gave them the time and then we gave them a little bit of structure i said okay well we don't have a generative culture yet we don't have these six skills that we're about to go into so how can we get people to solve some of these problems well let's create guilds okay spotify guilds all right and uh let we get people to solve some of these problems? Well, let's create guilds, okay? Spotify guilds, right? And let's get people from across different teams to band together to solve very specific problems. So we had a DevOps guild to go after CICD issues that we were having.

We had a quality guild to go after some test automation issues that we were having. We had a data engineering guild to go after some proof of concepts that we wanted to do for our data warehouse. We had a front-end guild to go after front-end standards, which we had identified as being different on every team. And there was a lot of difficulty with moving between teams. So we had the problems. So we identified the opportunities. Now we have these groups of people who moving between teams. So we had the problems. So we identified the opportunities. Now we have these groups of people who could solve them. And so that was the trick of when I started the generative culture is I said, okay, I'm not going to run any of these groups. I'm going to nominate somebody and none of my managers are going to run these groups either. We're going to nominate one person who's an engineer on each of these guilds to be the chairperson. And it is

their responsibility to come up with a charter. What is it we're going to solve? How are we going to work together? How often are we going to meet? How are we going to do work? And then to get back together. And ultimately, they were responsible for the success of those guilds. And these are people that had never led big initiatives before, but showed a lot of, you know, of wanting to do that. So by nominating them and then having those periods of one-on-ones or check-ins, let's say every week in the beginning to see what problems they were coming up against. And at first, because they'd never run initiatives like this, there were tons, you know, how do I,

how often do we meet? How do i get people to work on tickets for my guild along with their sprint tickets even though they had 20 time that was still a difficult problem and to get people to figure out when to do this work and how do they pair program and how do they coordinate how do i run meetings and make them successful so they don't they feel engaging rather than just me talking at people these were were the things that started to surface up. And so when I wrote down these six attributes, that's an aggregation of basically a year of coaching various folks through care people. And it wasn't, these guilds, they're short-lived.

We did about four months. We're now on our third cycle. We're about to go on our fourth cycle. We would tear them down after they were successful to agree and then we would start them back up again. And that was part of the secret sauce. We didn't want them to go on forever, not deliver until a year later, and then diminish in value. And so that's my intro, a little bit verbose, but some of the things that I learned. So obviously the time management's a big one. And I think it means something different for the chair people than it does for the actual folks who are just guild members.

We're still doing a lot of work. For the guild members, it's really about how do I actually get 20% time between the tickets that I need to take and all the scrum meetings, which there are a lot, where do I find that time? And so it's a lot of coaching with people to, and on the very smallest scale, make sure that when they come in in the morning, they know what they want to achieve. And when they leave, they can measure up against that plan and either say, I was successful or not. And hopefully they're more successful, the more that they do that. But then also to plan out their entire week, their entire month. If you think about it, 20% time, what does

that mean in a two-week sprint? I mean, that's two whole days. So, you know, can I group it together and instead of doing an hour every day, which requires a lot of, you know, context switching, can I put a block on my calendar two weeks ahead of time and say, no, these days are going to be dedicated to the guild time and everybody does the same so we can all, you know, get up together and pair program. For the chair people, it means even more because not only is it doing that but it's also planning the meetings it's setting up meetings it's creating agendas it's planning out it's a part-time job yeah on top of their full-time in some ways it is but it's one of those skills that as you do it, it feels really, I mean, it's like anything else,

I guess it feels really tough and it does feel like a second job at first, but after you've done it for a cycle, it starts to become automatic. And it actually, you start to realize that you're being more efficient with the rest of your time as well. Most of the engineers that have achieved a good balance of this 20% time, they feel like they can do four or five things at once now. I've got one tech lead now who recently became a tech lead that was on two different guilds, mentoring somebody new and doing sprint work all at once. And they start to feel on top of the world. And really all that changed is they learned some really, really good time management techniques. So that's why it all definitely starts there. And it's also really important for their career development. You know, we all have a different definition of, okay,

what does it mean to be a senior engineer or staff engineer? But one thing that is actually becoming fairly consistent is it's not just about technology anymore. You know, just because you're the deepest in technology and you know the most, you know and you have the widest breadth doesn't mean you have the biggest impact. And so to really be a staff engineer, I think there's a lot of other skills you need. I mean, because if you're mentoring people, well, then you're now having an outweighed impact next to the engineer next to you. And in order to do that, you have to be able to balance your time. If you're, you know, handing up a guild or something like that, you're having a strategic impact on the organization. So these are things that really help people advance in their career very quickly. So it's all good skills to learn inside and outside of a generative culture.

Would you say that a generative culture is a culture that desires to create leaders? Absolutely. And I think that's the perfect word, leaders. Doesn't mean managers. And I think that's the perfect word, leaders. It doesn't mean managers. And I think a mistake from a lot of older software companies, certainly some of the places I've been, is the only way to progress your career is to become a manager. But more and more, you find companies creating this dual track career progression where going up the technical individual contributor track doesn't mean that you're not a leader. You are absolutely a leader. You're just not doing performance reviews. You know, you're not giving people those that you're not giving people a performance lists. Instead, you are leading in a different way through actual like technical, technical acumen, changes to the technical vision, things like that. The reason why I asked that was something you said, and I wasn't sure if your philosophies

on guild creation and leadership within those guilds is directly attributed to a generative culture and this idea, but something you said there was that you didn't give the guild leadership, or I think you called him a chair, to somebody who's already a manager, to somebody who's already in a leadership position, because one of the ways that you create a leader is giving an opportunity to lead or enabling the ability to lead. It's not just simply, you know, stamp them and boom, you're a leader. It's more like sometimes you can't even be a leader unless somebody else believes in you, almost like representation. I can go back to the very moment I understood what leadership meant for me. I was in the military and I'll share a quick story because Jared loves these.

At least I think he does because he says so. But I was in, you know, real quick, you know, kind of overview of how a unit works. You have different lines, I suppose. That's probably too vague to explain. Long story short, I was not a leader, right? The person who was a leader, first squad leader in the front that was second in command of our unit was basically just not doing right. And all of a sudden the drill sergeant said, hey, Stachowiak, first squad leader. And I broke rank, came up to

the front and stood in that place. And at that moment, you know, for lack of better terms, I became a leader. Over the next several weeks and months, I learned what that meant. But I didn't think about being a leader until somebody gave me the chance. And I think it's those kind of cultures that enable that. I can't say would have never, but I tie everything I've done in my life back to that moment of being given an opportunity to lead. Even though I didn't earn it, probably couldn't even do it. I learned how to. The same thing happened to lead. Even though I didn't earn it, probably couldn't even do it. I learned how to. The same thing happened to me. Back when I was at Bloomberg, I remember the head of the department

came to me, you know, two, three levels above me at that point. I had heard that I had a knack for SQL Server, right? I became a bit of a database guru and said, we want you to, we have a big problem with consistency of this technology. We use it on all of our teams, but there's no consistency in the way that it's written or the way it's deployed or maintained. And I want you to create this working group, essentially back then a guild, but you know what you would call a guild today. And I want you to run it and create that consistency. That was my charter. And I felt the same way you did. I don't know if I deserved it. I don't know if I was ready. I don't think I was ready,

but it really gave me a taste for leadership. And I realized that I liked it, you know, that organizing and that empowering. Yeah. From that day forward, I was never the same soldier. You know, I can go in all the ways, but it doesn't matter, you know, but I can say in every way I had changed because I don't know, I just felt like somebody desired for me to excel and be better. And so because somebody believed in me, I believed in myself. I love that. And, uh, and that is a lot of it, right? I mean, the teacher, this in management, right. You know, make sure you give at least, at least hopefully one, one compliment constructive criticisms. But the same thing goes for delegation. I mean, you got to delegate to people and it shows no matter how you do it,

even if you take a very high security approach and say, hey, come back to me with a plan so I can review it. You're still telling somebody that you believe they can do it, which is very gratifying. It definitely changes the way that people think about themselves just as it did for you. Yeah. Well, let me ask a question from a different angle than when we're talking about leadership. Whatever leader needs is at least one follower and sometimes multiple followers. And there's a real and valuable place for followers as well.

And there are people in organizations that don't want to lead. Maybe they're naturally a wallflower. Maybe they're very good at what they do and they don't want more than that. Is a generative culture a place for them? Or do you need to be a self motivated, thriving leader, you know, kind of a personality in order to have a place in such an organization? It's a good question. And I definitely, I think most engineering leaders struggle with this because it's, you know, you get to a point with, you know, people who are very good individual contributors, you know, and how far can somebody go in their career without ever expanding out? I think there's a lot of nuance, to be honest, because there's so many skills involved. So it really depends on case by case

basis. Here's my part of my belief is that you don't need to lead some big initiative. I mean, there are some skills that people don't enjoy or don't ever want, whether it's presenting or leading meetings and things like that. But you don't need to be that type of leader to produce original value. That is what I expect. So you can do that independently. You can do that as part of a group. You can be the one engaging and synthesizing the solution. Part of our career rubric focuses on product focus.

We say that we want, and this is also part of our identity, we say we create good product engineers. And what we mean by that, and this is also part of our identity, we say we create good product engineers. And what we mean by that, and this also goes back to Marty, so I'm stealing from Marty Kagan. It says if you want innovative products, then you need your designers and your engineers to be involved with synthesizing the solution. So that's on the product side, right, that don't have the product manager come to the engineer with the solution, have them come with the problem that the customer wants solved. And then they, you know, they can find the right way to solve it. But I think the same thing goes in these guilds. Maybe the leader is not even the one. I have some guilds where honestly the leader is not the one, the thought

leader, and that's totally okay. You know, and some of the people that are actually the staff on the guild are the ones coming up with the solution ideas. It's a different skill set. But I do expect that. I mean, I think just only executing somebody else's vision, I don't think you're going to go super far in your engineering career. I think that's fair. What about original value in terms of examples? So at Policy Genius, from your team,

what have you seen come out of your team that surprised and delighted or you would have never thought of yourself? Or what's some examples of what, if I'm trying to add original value in my role, in my job, what does that look like? Yeah, so I'll go with one of the most recent ones, which was just really cool to see. We had an engineering tech lead come in. He just rolled off of a different guild that he was on that completed its mission. And without any prompting, came to our engineering all hands and was like, hey, I'm putting together a group.

He had an identity already picked out for it. He used Fifth Element as an identity Ruby rod because we use some Ruby on our backend. And he said, we've got some big SQL query problems. I've noticed this. I had some slow queries. I dug into it. I found that there is a slew of them and they're not using good practice and causing problems for our users. And so he's like, hey, who wants to join this with me? We're going to go after this? We're going to go after this. We're going to learn something about SQL and about how to use ActiveRecord and Ruby.

And we're going to solve this one meeting at a time over the course of 10 meetings. And by the end of the meeting, he had like, I think he said he was looking for four people to join. I went to their preliminary meeting and he had eight or nine people there. They were all super engaged in it. That was a really cool thing to see. And that's, you know, that's the type of thing that people notice all the time. And when you don't have the culture for it, you go, oh, later, we'll fix it later. Somebody else will fix it. Instead, he took ownership of it. Another one, which is very close to my heart because I'm a big fan of the right level of documentation. And I don't think we have the right level of documentation. We had a little too much tribal knowledge going on, which is very common with a smaller startup

that grows into a bigger one. The folks that have been around kind of know how to set things up. But it becomes a problem with scaling. And so we had one of our objectives was, and OKRs in total, was to reduce the time it takes to onboard at PolicyGenius and set up your environment to less than half an hour and to be able to test changes in a production-like environment in less than five minutes. And at that point, depending on the team, it was somewhere around, you know, a full day to set up your environment or even more. And a lot of that was because of the tribal knowledge.

Like you needed someone to sit next to you in order to set it up. So two folks stood up, a group of, I think it was five people, and they called themselves the Doc Squad. And they went after this problem. It's not even a technical problem. But, you know, they started looking at peers, other companies. What are they doing? How are they solving this problem? How are they maintaining it so it doesn't atrophy over time?

How can we make standards? How can we pay down the debt? And they came up with this whole list of standards. It was great. They started farming out tickets to teams so that they could update their readmes and Confluence pages. And now they're dedicated. They've put it into maintenance mode at this point, but they're dedicated. They're going to have one meeting a month, check back in, see how it's going, make sure it's not degrading. And yeah, they solved that problem without any sort of prompting. That was really cool to see. You mentioned, I think just kind of in passing, I don't think we went through the list exhaustively,

you mentioned time management, but this idea of these six core skills required to be empowered and a big requirement to have a generative culture is to be empowered. And a lot of our career is around skill development and skill acquisition. And in here you have several skills that need to be, based on what you say here, required to be empowered. And ultimately what we're trying to do is create an environment where we're able to make, identify, and solve problems that are independent of, say, being told what to do, management, so to speak. What do you think about these skillsets? Can we kind of go through some of them? Maybe you mentioned time management. Which ones are the most important? Are they all

the most important? Where would you begin? So opportunity identification is the second one I had on there. I tried to put these in what I thought was order of importance. That's an interesting one because when your culture is not generative, you don't see opportunities, you see problems, and you get angry about them, especially in a culture where things fall through the cracks. You know, using the opposite example, if we didn't have a generative culture, that person who started up this, you know, sequel pay down, you know,, might have looked at that and been angry that this had happened and probably would have complained to their manager. But when you start realizing that actually these are not problems, these are opportunities

that we can solve, we can learn from, we can make the system better, and that there's always going to be debt. You're always accumulating debt. You're never debt free. I've never heard of a company that's been debt-free. But that you can make these a strategic pay-down task and really motivational, I think that's when you start seeing them as opportunities. technical knowledge, your understanding of the system, your ability to manage your own time, to manage quality, to tie that into the goals of the company. I think that's when you start to see these as real opportunities. And then you see opportunities everywhere. So that's a skill. I think it's a bit easier, but it's definitely changing the perception of people.

That's a personality kind of thing, though. There's a lot of people who are negative thinkers and it's easy to say problem. Then you have positive thinkers who say opportunity, right? I don't know if you follow this fellow named Jocko's well-known, you know, basically you'd say, I lost my job today. He'd say, good, because now you have time to go find a new job, maybe a better job, right? So it's never like, oh, end of the world. It's more like good. Now you have time to train harder. Now you have time to find a new job that's better for you. Girlfriend dumped you. Good time to find a better woman who's better for your life. You know, whatever it might be, you know, speaking from a man's terms, that seems kind of like that.

Like you need somebody who's more on the positive side and not the negative side when they think about things rather Rather than see them as problems, it's an opportunity. So it's a very interesting point. My philosophy or my thought on this is, I think you're right. I think people are naturally, some are naturally more positive, some are naturally more negative. But I do think there's something about the way that you talk to yourself and the way that you use language that affects how you think about things. So here's an example, a personal example. A previous company, one of my favorite

managers, I remember I was having a conversation with him and I'm like, okay, I'm worried about this. I'm worried about that. I'm worried about that. He said, stop saying that word. So you can be concerned about things, but you can't be worried about things. And he said, you know, he said he struggled with that himself also because he took a lot on, you know, and it started to weigh him down even after he left work. And I think there's something about that. You know, even coaching, I've coached some folks who did use the, you know, the problem word more often and also didn't think about the solution towards using better language. And you can see a difference in the way they act. They definitely have a natural proclivity, and that's true.

Let me riff on this for a second, because it's strange. I've actually been thinking about this exact casting, because I'm more of a pessimist person. The optimist in me says I'm a realist, but the pessimist says, nah, you're just pessimistic. And I've found myself, I'm very good at poking holes in ideas or solutions. I can see what's wrong with things. Maybe I'm critical. Yeah, so the optimist would call me perceptive, but maybe I'm just critical. And so I find that a lot of things I'll say, here's the problem with that. And it's just the way I talk. And I've noticed that I say that a lot. I start a lot of things, I'll say, here's the problem with that. And it's just the way I talk. And I've noticed that I say that a lot. I start a lot of things with, here's the problem. And I started

catching myself and realizing that I'm saying that a lot. I'm saying, here's the problem. And I didn't think of, here's the opportunity, because maybe I'm still too pessimistic to think of that. But I did change. I've actually tried to change my language that I say to myself and to others to say, here, this is the challenge. Because I like challenges. I don't like problems, but I do like challenges. And it's the exact same thing. I mean, when I'm saying here's the problem, I'm not saying this is why it can't work or

this is why it's bad. I'm saying like, here are some things that are in the way of whatever it is. So I've been trying to recast the word problem into challenge. And it's a small thing. Words do matter. But it's made an effect on me where I start to see things as challenges, which I'm ready for a challenge. And it's been beneficial in my life.

Now, maybe I should change that to here's the opportunity. Maybe. I think they're one and the same, though, honestly. Because I think opportunity and challenge is very similar. And especially if challenge is used in a way that's on the positive side, not the negative side, like here's the problem, that's definitely negative. Whereas challenge is still positive. Most of the time when I call out problems,

they're actually just things that need to be overcome in order to head in a direction. And so they really are challenges. And anyways, it's just interesting that the idea of thinking of a problem as an opportunity. I think it's interesting how you discover that though, because that's essentially the habit loop is like there was a cue, right? You would say something negative, so then you would become negative and the result would be negative. Whereas now you use like negative and the result would be negative. Whereas now you're like, I want to change that habit about myself. When I say the word problem, I want to catch that.

Or when I feel compelled to say the word problem, I want to catch that. And the new routine you run instead is not to say the word problem, you say the word challenge. And so now the reward is more positive. You still get the similar same reward of like overcoming that challenge, but now you're using something more positive that also affects someone like me who's often on the other side of you're saying, here's the problem with that. Yeah, that's,

that's true. I can actually appreciate now here in, here in your, the playback of the psyche of Jared on that, I can appreciate that so much more. It's interesting. And Dave gets to sort of witness this in real time. Some of this actually is a result of being a podcaster

because a lot of people do not have the pain and anguish or the opportunity, if you will, to listen to themselves talk. And whether it's QA or trying to find interesting tidbits of our shows for promotion, whatever it is, I get to listen to interesting tidbits of our shows for promotion, whatever it is, I get to listen to our shows. And a lot of things, I hear myself talk. And I'm like, you know what? You say problem a lot.

And maybe I wouldn't have picked up on it otherwise. So just a fringe benefit of podcasting. That's great. Yeah, hopefully, if you don't podcast, hopefully you've got a good mentor who is not afraid to give you that feedback. Because I think everybody wants to know that. Right. Yeah, for sure. What am I saying that's being misinterpreted?

I mean, even that point of like worry versus, what was the other word? Well, I used to worry versus concern. Yeah. Yeah. I mean, it's weird to have these little things. It's just a word, you know, and it's a throwaway a lot of times. And you don't even know that you're casting it in that way because of an inner feeling. But having that pointed out to you, then you start, then it's like, what's the prince, prince and the pea? I

don't know that old fairy tale about the, you know, there's a pea in the bed and you can feel it like a, like a boulder, you know, it's like this tiny little thing, but it feels like a boulder once you get it pointed out to you. So whether it's a friend or a mentor or a significant other, like these are helpful things for us to be self-aware and then, you know, shift and change and hopefully improve over time. So identifying opportunities, probably running up against our time here. I don't want to go through all six of these, Adam, but they're all written down on the post. Let's say them at least if we can't go through them all. Yeah, I could do some quick ones. Yeah. Hit them real quick then.

Yeah. So peer organization is one and stakeholder communications, probably two sides of the same coin. Peer organization is very much, it's still a communication thing. It's a planning thing, but how do you get people rallied around an idea? Make sure they understand it, they embody it, they own it. Stakeholder communications, the other side of that, how do you make sure that when you're solving a problem, you're not doing it in an ivory tower, which often happens in engineering orgs, and that you're really eliciting feedback about the solution from folks around you. So, you know, in a lot of cases with engineering, actually, the stakeholders aren't like

product. It's actually a lot of times like senior engineers on other teams who might be affected by whatever you're paying down or whatever tool you're building. Scoping is a big one. And I actually added this later on. And I think that's the result of having done this very concertedly now for about a year. One thing I've seen trip a lot of teams up is they've got the great mission. They've got good communication. they've got good external communication, but they just bid off more than they could chew. I mean, every problem you can work on for years, you can probably work on forever is knowing how to really chunk it up. And if you're doing something like 20% time,

make sure you're getting value out, something that makes you feel good and changes the organization in very, very small increments. And so there's a lot of framing and that's a difficult one to learn. And there's a lot of technique that I think we can learn from product process there, things like story mapping. And then the last one is probably the most obvious one, but it's learning and application. And this is more about self-awareness, taking feedback and being able to act on it. None of this is possible, none of these skills without being open to feedback, without eliciting feedback, without going home and replaying events in your head a

little bit, and then thinking about how you can get better. I think once you get empowered, to your point about having that opportunity to be empowered, the next step is finding out how to progress in that competency. It's a very complicated competency leadership, and you need to be able you've said before, highly opinionated and that you've actually been down the road to kind of discover a lot of this. Would you say that this idea is still malleable? Are you still working on it or is this sort of fully formed at this point? So it's a good question. The article I wrote is opinionated about the methods, right? And in that I'm saying that these have worked for me and my team. They've worked for me at multiple organizations. This is probably because it's my last iteration

of it, probably the most successful because I myself have learned what to do and what not to do. So there's definitely other ways to do this and other ways to achieve this. And also, if you change other parts of the process, like let's say you're not using agile scrum, let's say you're using something else, then a lot of these methods probably will not work for you. Right. So it is, it is opinionated in that way. I will say, and I'll probably be proven wrong by history in future times, but that generative culture is a pretty objective concept. I like the term rather than empowered culture because it describes the output, right? It's not prescriptive about the method. I'm being prescriptive about the method, but it's not prescriptive about the method. And it describes

the attributes, which from my experience, having worked at multiple organizations, I do think they're fairly consistent when you see a group of folks who can really, everybody can contribute and have decision-making power. Those are the attributes that I see. Well, Dave, let me say thank you for, one, your time today covering this with Jared and I at detail, at length in a podcast. That's very appreciated. But even more so, your thoughts behind all this and sharing them on changelog.com. So for those out there listening, we kind of opened up with this, but Dave wrote this and published it on changelog.com so that we can have an opportunity to talk through it. So Jared and I can have a basis to kind of

dig deep into Dave's ideas and, you know, hopefully shed some light on some changes you might want to do in your organization or when you look for your next job or you look for your next thing, some insights into some new things you can consider when you decide that next career move or the next team you want to join. Or if you're in a current team now and you're thinking like, wow, this is terrible. Well, we got a pathological person above us. That's why it's terrible, you know, and some opportunity to change. So that's what I really hoped to get from this. And Dave, thank you for making that happen. It was great to talk to you.

Thank you for having me on. I really appreciate the time and had a lot of fun. Awesome. We did too. All right. Thank you for tuning into this episode of The Change Log. Hey, guess what? We have discussions on every single episode now. So head to changelog.com and discuss this episode and if

you want to help us grow this show reach more listeners and influence more developers do us a favor and give us a rating or review in itunes or apple podcasts if you use overcast give us a star if you tweet tweet a link if you make lists of your favorite podcasts, include us in it. Also, thanks to Fastly, our bandwidth partner, Rollbar, our monitoring service, and Linode, our cloud server of choice. This episode is hosted by myself, Adam Stachowiak, and Jared Santo. And our music is done by Breakmaster Cylinder. If you want to hear more episodes like this, subscribe to our master feed at changelog.com slash master, or go into your podcast app and search for changelog master. You'll find it. Thank you for tuning in this week. We'll see you again soon. Bye.