Generative engineering cultures

Dave, we’re here to talk about Generative Engineering Cultures, something that’s important to you at Policygenius. You’ve written an excellent post for us on Changelog.com all about that topic. Why don’t you kick it off by telling us - Generative Engineering Culture what does that even mean? New terms for me, and probably for a lot of our audience. How do you define such a thing?

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. The goal that I have for my engineering org is I would like at least 75% 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 Westrum. 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. He came up with this spectrum of organizational cultures.

What he found out is that on the really negative side - 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. If you followed 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. And so was the leader.

Good book, and good Netflix documentary.

Oh, is there a documentary?

I haven’t seen the documentary yet.

It might have been HBO.

Yeah, you’re right. It was HBO.

Well, all I know is Theranos was a company that had something to do with genetics, or DNA, or something… And then there was a huge scandal. For those of us completely outside, didn’t see the book, didn’t know there was a documentary, what do you mean by Theranos? Was there some pathology going on there?

[03:59] Yeah, Theranos was a company that was around for - I may be misremembering this - about ten years. A very big cult of personality with their leader, the CEO. It’s Elizabeth Holmes, she’s under investigation right now…

Oh…

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 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 a Quest Diagnostics, but doing it for a very low price, and doing it in a very easy way. They were trying to develop this software and hardware that would do that. 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, political, to Silicon Valley titans, whatever it might be. A lot of people, 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. She’s a very captivating person.

She’s got these big eyes…?

She’s known to have big eyes, that are “beautiful.” I think she’s got nice eyes… But she didn’t blink very much. 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’s 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 overrule literal scientists on 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. She was very fixated - this is why it’s called pathological - on the idea that you can have this device in your home, like you can have an iPod.

Anyways, so we’re way upstream… My fault, I think, for asking…

[laughs] Kind of worth it, though. It really describes the pathological side.

Well, the pathological culture - all surrounding the singular individuals on top, right?

Oh, and people in her organization were definitely afraid of her… Not just while they worked for her. After they were whistle-blowers, she went after them legally…

Oh, wow.

They had these very airtight NDAs, and the reality was they were selling a lie for ten years… And they just kept raising and taking people’s money.

Wow.

So it’s probably one of the worst modern examples of that. Another great example is if you watched the documentary on Fyre, the company behind the Fyre Festival.

Oh, yeah.

The guy who ran that also I would describe as having run a pathological organization, the same sort of fear in his employees, even in the face of what they knew was an impossible task.

Yeah. I think the reason why it’s important to maybe even understand the deeper parts of that is because you’ve got people out there thinking “Where in the world should I work?” So if you kind of understand an entire company’s culture, let alone the engineering department’s culture, then you can understand “Is this gonna be a good fit for me, my personality, the kind of effort I wanna put into my employment somewhere, or my career?” 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’ve felt fearful of the leaders, and the effects on you and your life.

That’s right. It’s definitely shaped 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 I’ve experienced different cultures, and the good effects that it has on the people, and also the actual product that it’s produced, and the negative effects that it can also have.

[08:07] What he described is the middle of the road. So - pathological, nobody wants that; that’s all the way on this one side. In the middle it’s probably the most common that we see with organizations, especially ones that have reached a certain size, is the bureaucratic culture. 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 - if you’re an engineer, are you following the tech vision? If you need to expend something, are you following these expense programs?

The idea with bureaucracy is to create as even and as fair of a process for a very unwieldy large organization. The trick is can you find a way as you grow to reach what’s called a generative culture? …which is the term that Ron Westrum coined, where you instead allow and trust people to make really good choices on the ground, still reverse that decision-making process, and 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? 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 years ago by Jez Humboldt and a couple of partners. Jez, if you’re not familiar - she writes the DevOps Report every year. So 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; agile, and scrum, and things like hackathons, and CI/CD, and all that - whether they actually fulfilled the promise of what they were preaching. So they tried to create a quantitative survey to figure out whether these practices resulted in high-performing teams.

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 were gonna question their methods - just a study in how they created the survey and how they got it to what they call a quantitative state, rather than it 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.

What that means is just what I said a little bit earlier - decisions are made on the ground; people can come up with original value and find opportunities and actually find the solutions and execute 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 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.

Yeah.

[11:48] 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. 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, do we generally, as we create culture, begin either as a bureaucratic or pathological terribly, and then move into a generative? Or can you sort of 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. It usually happens over time. Four, five people in a WeWork - everybody wears a thousand hats and has full autonomy to make decisions…

Right.

But usually around the time you get to 100, 200, 300 - now you start to layer in rules and approvals, and check here, and check there… Or even worse is the long roadmap - “Here’s what we’re gonna do for the 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 it’s just a complete conjecture, because I’ve never been through this before - that as you scale up in company size, the move to bureaucratic… And like you said, it’s kind of pejorative, or it gives me a nasty connotation, like “Bureaucracy - bad!” But rule-oriented, maybe - that’s just a way of saying the same thing without the nasty term - is a reaction to a problem. It’s not like all of a sudden we hit this company size and it’s like “Now we’re a bureaucracy” and like “There’s a vote-taking. We’re gonna be a bureaucracy now.” It’s like, there was a problem and we’re trying to react to that problem by introducing some rules. We’re at a size that we need some rules now.

I tracked - and 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 generative, and really almost anarchical. Just complete individual freedom. You work on what you think is important. That lasted for a certain amount of time, until it didn’t work anymore. In fact, they were giving conference talks, and they were saying “This is the way forward. People work on what they think is important. This is freedom etc”, and it crumbled at a certain size. It was like “Wait a second, this doesn’t work anymore. We need some rules, we need some guidance. We need other things.”

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 a de facto, unless you have a pathological scenario, where the person that started the company is just 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 grinds things slower. 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 usually for good reasons. And actually, usually because they wanna treat people fairly across different parts of the org. There is a way to avoid it though, and I think a lot of it comes about because, 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’re still the ones who know the most about every part of the organization.

[15:59] 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. There’s a number of ways to do this.

Also, there are a lot of companies that do the opposite. With good intentions, they say “No, we want to empower people. We want 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. I wanna be empowered, I wanna have (as you say) original value; I don’t wanna just 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 their own eyes. Right, we’re just out there what value I think is there… that is kind of that can become anarchy, it can become chaotic.

Absolutely.

So how do you still shepherd moving forward together as a unit, as a bunch of individuals working as a team, versus as just this blobule collective?

Yeah, it’s a great question, and the phrase is “align to autonomy.” 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.” And there’s lots of tried and true methods of doing that now. We use OKRs (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. Of course, it depends on the ability of the leaders to actually create them in that way, so they’re not prescriptive.

As a counter-point, for example, at 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. Then, of course, we would 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 was to help on the engineering side spreading this - is creating those objectives. 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 (Net Promoter score), to make sure that we’re doing it without sacrificing customer happiness. We’re going to have this level of engagement with our products. 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. So what happens is we start at the beginning of the year with the leadership team collaborating and generate these very few top-level objectives, and then every department goes and takes “What’s my piece of that?” And as it goes down, it gets a little more specific. Because you know, saying “Revenue and customer support” is not surprising, and shouldn’t be surprising to any company. But then as it goes does, what does that mean for marketing? What does that mean for product? What does that mean for engineering, which usually levels up into product OKRs but also has to have their own, to make sure that we can scale ourselves, in the technology, and that it’s maintainable.

[20:17] 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 - “Okay, this is what we proposed, this is how we can contribute. Here’s an objective, here’s something you can actually measure us on.”

For example, some of my OKRs this last four months - 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 have 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. Then once there’s agreement all the way up the chain on that, now we’ve got that alignment. So if people do wanna work on something, and stand up and say “Hey, I wanna solve this problem, they can articulate how that is actually going to make this company successful.” 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 etc. Now what I’m seeing is now having done this a few times over the last year, 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 gratifying to see. That’s the cycle that we wanna create.

Now, there’s a lot of detail that I could 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.

So when we break this down, this fellow who wrote this book, Ron Westrum, he kind of described pathological, bureaucratic and generative; you mentioned team of teams, but before we go into that, I want to examine a little further the attributes of how these play out. For example, I’ll read generative:

“High cooperation. Messengers trained. Risks are shared. Bridging is encouraged. Failure leads to inquiry. Novelty implemented.”

Those are across the other spectrum, as you’ve got low cooperation, modest cooperation… So you have these reoccurring attributes. Why do you think each of these particular attributes to describe that, and how do you see them play out? For example “Messengers trained.” What does that mean?

[23:48] Some people might call this an empowered culture. I do think generative is the right one, and the reason that he chose that terms 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.

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. What he found is that these were the attributes that correlated in certain groups of organizations when they figured out how to turn decision-making around, from being mostly from management to mostly from the people on the ground.

So I wouldn’t say he would describe it as he chose these, but these are what he observed, if that makes any sense.

Gotcha. And Jerod, something you said before was naturally you and someone like you would wanna be in a generative culture. Now, from a brain perspective we fare better when we’re involved in our choices… So it would make sense, as a human being, our desire to be in a generative culture. But what it seemed like was coming out was almost like a good culture would be a mix of bureaucratic - because as you said, Jerod, you’ve gotta have some rules at some scale - but you wanna have a generative underlayer. Would you agree with that, Dave?

I would. 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… For example, 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 is probably okay as long as it’s not too arduous, but I don’t think limits the creativity and output of the company.

Right.

Similar is things like HR rules and processes, things like peer performance reviews etc. 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?

Right.

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 wanna be a part of. And that’s one of the reasons why you want a generative culture, is because –

Yeah, it makes it worth doing.

Yeah, it leads to employee happiness, satisfaction, it 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. It goes through some of the misconceptions around how employees are motivated only by money, which has actually been proven, at this point it’s probably known pretty widely that that is an 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 on the market, but if you’re making under market, 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.

[27:58] There’s probably two ways we can look at this, and it’s probably worth us focusing more on the perspective of the 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’re 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? I’m sure there’s policies. You guys are policy geniuses, so I’m sure you have some policies… Some things you can do. Because you wanna create a generative culture, you don’t have one. You can’t just snap your finger, so what can you do?

Yeah, and I think 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 categories that we can go into here. There is certainly the policy part, which is management snapping their fingers and saying “Go be generative. Here’s the time to do it. Go nuts.” Then there is the hard management part, which is the coaching, and which takes time and a lot of repetition, 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.

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 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 could 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. 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. They’ve had things like Gmail come out of it, but they’ve also had just as many failures… But this is more of Marty Cagan’s 20% time. Marty Cagan, 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 the 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, “…and 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 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 is happy to be asked that.

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, 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. I love that book.

[32:12] 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’s certainly other people in the industry that have written about it. Eric Ries 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. I felt like every chapter I read, I could implement that cycle. We were in Agile, so 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 - 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 wanna 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 gonna constantly unwind what you wind up.

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 side-stepping you and undoing those things, putting specifics into somebody’s daily things - they’re not gonna give you the objective, they’re gonna give you the process, constantly. What is your thought on that?

You’re totally right. This has happened to me multiple times in my career. Honestly, it’s a conversation and it’s a workstream 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 is industry standard, that is well-documented, rather than actually spending the time on doing the thing, which is hard enough itself to implement.

For example, I remember as Agile started gaining popularity and there started to be examples of how it was benefitting, 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… So our success was limited. And I say that I don’t wanna 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. These are the questions and the things that I talked to who was hiring me.

When I talked to Jenn and Francois, who are the co-founders here at Policygenius, I remember that first call, and immediately they were right there with me; they started talking about Marty Cagan, Silicon Valley Product Group… They were 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.”

In the end it’s a weird paradox, 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 actively subscribe to, or is this a newer term that people are still adopting? Or are they already doing it and they just don’t know it?

[35:55] Many people are doing it and don’t know it. 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 have told them to 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.

This term was coined either in the 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. They went and said “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 there’s a big missing gap - and this is what I try to focus on in my article, and one of the reasons I’m here talking to you all - 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 “Here’s how everybody’s doing it”, that’s where I’d love to fill that gap.

Yeah. That’s almost like when you’re looking for a position today, or in the last ten years; one of the questions you asked was really around workflow, like “Are you waterfall or agile?” and I’m wondering if it’s the same question we or listeners of our show can ask of their next gig, or the things 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 criterion or an attribute that you begin to seek out and look for whenever you take your next opportunity.

Well, 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. If they say they don’t know what that is, explain, they still may have aspects of it, and that’s where I think you need to get into the details. That’s where your attributes are really helpful, the ones that you threw out from the Ron Westrum article, is “How do you handle issues?” For example, if there’s an outage, how is that handled? I’m sure most people would like to say “We are collaborative about it”, but getting into the details; do they have post-mortems? Are they non-blaming post-mortems? Are they about understanding “Was the issue a technique, or was it a process issue? Do we not have the right safeguards in place, rather than blaming people? How does cross-team collaboration work? Does it even happen? Is it encouraged? Is it a reality?” Those are the things that you wanna see.

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.

Agile is an interesting change. I’m fully bought in. We practice a fairly robust - I’m gonna use that word - form of Agile here. 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 spending enough time in this industry and 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.

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…

[40:12] I have peer groups in New York City 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 the management blasted 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. Now, 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.

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 paths.

Waterfall - what could be quicker and less arduous than “I’ll only talk to my product manager every two weeks, and we’re gonna show results every month, and we’re gonna release six months from now”? But it really forces you to, as an engineer, 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.

Right.

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 and 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.

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, against the rules, is “Well, what if everything just falls apart and people aren’t being productive, and there’s not much being generated?” That comes down to really the people who are doing the work. You had 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… So I’m curious, when it comes to time management planning, how do you coach that? How do I decide what to work on if it’s not dictated to me?

[44:17] 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. When I started at Policygenius, I do think they had a generative culture. Jenn 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 a lack of a better term… But they had just made a pivot 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 work when that changes.

When you’re in the survival stage, accumulating tech debt is the norm, because you don’t even know if you’ve got a product. So accumulate debt so you can get experiments out, prove that there’s a market fit… But once you’ve 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.

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 is I put together a survey, and I modelled it after – it’s another one of the product trick Jobs To Be Done survey. I’m gonna throw out a lot of terms here; we don’t have to go into all of them, but… So I modelled it after the Jobs To Be Done survey; a 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.

Basically, ask people to rate the level of frustration and the level of sophistication on each of those areas, from 1 to 7 (scale). Out of that I got a nice quantitative read as to where the problems were… Because I was new, and I didn’t wanna 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 problems were ubiquitous.

Out of that, what we did - this is in the first month that I started… We created 20% time, which was fully agreed on by Jenn (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 “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, Spotify guilds, and let’s get people from across different teams to band together to solve very specific problems.

We had a DevOps guild to go after CI/CD 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, we identified the opportunities - now we have these groups of people who could solve them. So that was the trick of when I started the generative culture; I said “Okay, I’m not gonna run any of these groups. I’m gonna nominate somebody… And none of my managers are gonna run any of these groups either. We’re gonna nominate one person who’s an engineer on each of these guilds to be the chairperson, and it’s their responsibility to come up with a charter, what is it we’re gonna solve, how are we gonna work together, how often we’re gonna meet, how are we gonna do work… And then to get back together, and ultimately they were responsible for the success of those guilds.” These are people that had never led big initiatives before, but showed a lot of wanting to do that.

[48:21] 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 had never run initiatives like this, there were tons. “How often do we meet? How do I get people to work on tickets for guild along with their sprint tickets?” Even though they had 20% time, that was still a difficult problem, to get people to figure out when to do this, how do they pair-program and how do they coordinate. “How do I run meetings and make them successful, so they feel engaging, rather than just me talking at people?” These were the things that started to surface up.

So when I wrote down these six attributes, that’s an aggregation of basically a year of coaching various folks through chairpeople. And these guilds were short-lived. We did about four months; we’re now on our third cycle, and we’re about to go on our fourth cycle. We would tear them down after they were successful to a degree, and then we’d start them back up again. 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.

So that’s my intro… A little bit verbose. But some of the things that I learned - obviously, the time management is a big one, and I think it means something different for the chairpeople 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?” So it’s a lot of coaching with people, and on the very small scale to make sure 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 spread? That’s two whole days. So can I group it together and instead of doing an hour every day, which requires a lot of context switching, can I put a block on my calendar two weeks ahead of time and say “No, these days are gonna be dedicated to the guild time, and everybody does the same, so we can all get up together and pair-program”?

For the chairpeople it means even more, because not only is it doing that, but it’s also planning the meetings, and setting up meetings. It’s creating agendas, it’s planning out.

Yeah. It’s a part-time job 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 – 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 then 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. They start to feel on top of the world. And really, all that changed is they’ve learned some really good time management techniques. So that’s why it all definitely starts there.

And it’s also really important for their career development. We all have a different definition of what it means to be a senior engineer, staff engineer, but one thing that is actually becoming fairly consistent is it’s not just about technology anymore. Just because you’re the deepest in technology and you have the widest breadth doesn’t mean you have the biggest impact. So to really be a staff engineer, I think there’s a lot of other skills you need. Because if you’re mentoring people, 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 heading up a guild, or something like that, you’re having a strategic impact on the organization. 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.

[52:28] 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.” It doesn’t mean managers. 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’re not giving people performance lists. Instead you are leading in a different way, through actual 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 - 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 opportunity to lead. It’s not just simply stamp them and boom, you’re a leader. Sometimes you can’t even be a leader unless somebody else believes in you. It’s almost like representation.

I can go back to the very moment I understood what leadership meant for me… I was in the military - I’ll share a quick story, because Jerod loves these; or at least I think he does, because he says so. But a real quick overview of how a unit works - you have different lines… That’s probably too vague to explain. Long story short, I was not a leader; the person who was a leader, a 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, Stacoviak, first squad leader.” And I broke rank, came up to the front, and stood in that place. At that moment, 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 kinds of cultures that enable that… I can’t say I 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 - I 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; he was 2-3 levels above me at that point. He had heard that I had a knack for SQL server - I became a bit of a database guru - and said “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; 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, that organizing and that empowering.

Yeah. From that day forward I was never the same soldier. I can go in all the ways, but it doesn’t matter. I can say in every way I changed, because I just felt like somebody desired for me to excel and be better. So because somebody believed in me, I believed in myself.

[56:07] I love that. And that is a lot of it. They teach you this in management - make sure you give at least hopefully one compliment to every five constructive criticisms… But the same thing goes for delegation. You’ve gotta 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.

Let me ask a question from a different angle then, while we’re talking about leadership. Whatever a leader needs is at least one follower, and sometimes multiple followers. So there’s a real invaluable place for followers as well, and there are people in organizations that don’t wanna 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 kind of a personality in order to have a place in such an organization?

It’s a good question, and I definitely think most engineering leaders struggle with this. You get to a point with people who are very good individual contributors, 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 a case-by-case basis.

Here’s part of my belief - you don’t need to lead some big initiative. There are some skills that people don’t enjoy or don’t ever want, whether it’s presenting, and 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, or you can do that as part of a group. You can be the one engaging in synthesizing the solution.

Part of our career rubric focuses on product focus. This is also part of our identity, we say that we create good product engineers. What we mean by that - and this also goes back to Marty, so I’m stealing from Marty Cagan… He says “If you want innovative products, then you need your designers and your engineers to be involved with synthesizing the solution.” That’s on the product side - don’t have the product manager come to the engineer with the solution, have him come with the problem that the customer wants solved. Then they can find the right way to solve it.

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 thought leader, and that’s totally okay. 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 skillset. But I do expect that. 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? At Policygenius, from your team - what have you seen come out of your team that surprised and delighted, or you had never thought of yourself? If I’m trying to add original value in my role, in my job, what does that look like?

[59:32] I’ll go with one of the most recent ones, which was just really cool to see. We had a tech lead come into – he just rolled off of a different guild that he was on, that completed its mission; and without any prompting, he 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 Rhod, because we use some Ruby on our back-end… 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.” So he’s like “Hey, who wants to join this with me? We’re gonna go after this, we’re gonna learn something about SQL and about how to use Active Record and Ruby, and we’re gonna solve this one meeting at a time, over the course of ten meetings.”

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 8 or 9 people there, and they were all super engaged in it. That was a really cool thing to see. 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 was 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 have a little too much tribal knowledge going on, which is very common with the 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.

So one of our objectives or OKRs in total was to reduce the time it takes to onboard at Policygenius, and set up your environment to less than a half an hour, and to be able to test changes in a production-like environment in less than five minutes. At that point, depending on the team, it was somewhere around a full day to set up your environment, or even more. And a lot of that was because of the tribal knowledge. You needed someone to sit next to you in order to set it up.

So two folks stood up a group of five people - they called themselves the Doc Squad - and they went after this problem. It’s not even a technical problem. 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 can 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 gonna have one meeting a month, check back in, see how it’s going, make sure it’s not degrading. So yeah, they solved that problem without any sort of prompting. It was really cool to see.

You mentioned in passing - I don’t think we went through the list exhaustively - 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, require to be empowered. And ultimately, what we’re trying to do is create an environment where we’re able to identify and solve problems that are independent of, say, being told what to do. Management, so to speak. What do you think about the skillset? Can we 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?

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.

Using the opposite example, if we didn’t have a generative culture, that person who started up this SQL paydown guilt 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 gonna 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 when you can make these a strategic paydown task and really motivational, I think that’s when you start seeing them as opportunities.

[01:04:07.04] When you start tying that to your own career development, and realize that the act of solving this is actually going to increase your 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.” I don’t know if you follow this fellow Jocko; he’s well-known… Basically, you’d say “I lost my job”, and he’d say “Good. Because now you have time to go find a new job.” Maybe a better job. 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. Whatever it might be, speaking from a man’s terms. That seems kind of like that - you need somebody who’s more on the positive side, and not the negative side when they think about things; rather than see them as problems, it’s an opportunity.

It’s a very interesting point. My thought on this is I think you’re right; I think some people 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.

Here’s a personal example. 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. You can be concerned about things, but you can’t be worried about things.” He said he struggled with that himself also, because he took a lot on, and it started to weigh him down, even after he left work… And I think there’s something about that.

Even coaching - I’ve coached some folks who did use the “problem” word more often, and also didn’t think about the solution towards using better language, and you can see a different 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, and 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 a perceptive, but maybe I’m just critical. So I find that a lot of things I will 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 lots of things with “Here’s the problem.”

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’ve actually tried to change my language that I save to myself (and to others) to say “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. 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 “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”. 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…” [laughter]

Maybe…

[01:07:57.13] 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 it problems, they’re actually just things that need to be overcome in order to head in a direction, so they really are challenges… Anyways, it’s just interesting that the idea of thinking of a problem as an opportunity–

Yeah… I think it’s interesting how you discovered that though, because that’s essentially the habit loop. 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’re like “I wanna change that habit about myself. When I say the word ‘problem’, I wanna catch that. Or when I feel compelled to say the word ‘problem’, I wanna catch that.” And the new routine your run instead is not to say the ‘problem’, you say the word ‘challenge’. So now the reward is more positive. You still get the similar, same reward of 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 your saying “Here’s the problem with that.”

[laughs] Yeah, that’s true.

Which I can actually appreciate now. Hearing the playback of the psyche of Jerod on that, I can appreciate that so much more. It’s interesting. And Dave gets to witness this in real-time.

Some of this is actually a result of being a podcaster, because a lot of people do not have the pain and anguish or the opportunity 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 our shows, and a lot of times I hear myself talk and I’m like “You know what - you say ‘problem’ a lot.” Maybe I wouldn’t have picked up on it otherwise… So it’s just a fringe benefit of podcasting.

That’s great. And 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.

Yeah, for sure.

“What am I saying that’s being misinterpreted…?”

Even that point of like worry versus –

Worry versus concern.

Concern. Yeah, it’s weird how these little things… It’s just a word, and it’s a throw-away a lot of times; you don’t even maybe know that you’re casting it in that way because of an inner feeling. But having that pointed out to you, then it’s like what’s the prince in the pea, I don’t know that old fairy tale about the there’s a pea in the bed, and you feel it like a boulder; it’s this tiny little thing, but it feels like a boulder. Once you get it pointed out to you - whether it’s a friend, or a mentor, or a significant other - these are helpful things for us to be self-aware, and then shift and change, and hopefully improve over time.

So identifying opportunities… We’re probably running up against our time here; I don’t know if we wanna 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.

Peer organization is one, and stakeholder communication - it’s probably two sides of the same coin. Peer organization is 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 communication is 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 works) and that you’re really eliciting feedback about the solution from folks around you.

In a lot of cases with engineering actually the stakeholders aren’t product; it’s actually a lot of times 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. I think that’s the result of having done this very concertedly now for about a year.

[01:11:55.12] 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 bit off more than they could chew. Every problem you can work on for years, you can probably work on forever; it’s 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 small increments. So there’s a lot of framing… That’s a difficult one to work, 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 in application. 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 to get that feedback and elicit it, or else you’re never gonna progress.

Well, I know that this is a deep topic, and in some ways, as you’ve said before, highly opinionated; you’ve actually been down the road to 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?

Good question. The article I wrote is opinionated about the methods. 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 no to do… So there’s definitely other ways to do this, and other ways to achieve this.

Also, if you change other parts of the process. 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. So it is opinionated in that way.

I will say - and I’ll probably be proven wrong by history in future times - that the generative culture is a pretty objective concept. I like the term, rather than empowered culture, because it describes the output. 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 for 1) your time today, covering this with Jerod and I in 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. 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 Jerod and I can have a basis to dig deep into Dave’s ideas, and hopefully shed some light on some changes you might wanna do in your organization, or when you look for your next job, or when you look for your next thing; some insights into some new things you can consider when you decide that next career move, or that next team you wanna join, or if you’re in a current team now and you’re thinking “Wow, this is terrible. Well, we’ve got a pathological person above us, that’s why it’s terrible”, and some opportunity to change. That’s what I really hoped to get from this. 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 I had a lot of fun.

Awesome. We did, too.