Gary Cohen, owner of Practical Agility, discusses his journey from software development to organizational design, emphasizing the importance of aligning incentives, fostering cross-functional collaboration, and focusing on customer outcomes. He highlights the need for continuous product discovery and learning to improve efficiency and effectiveness in product teams. Cohen also addresses the increasing demand for rapid organizational changes and the potential impact of AI on product development. He advises leaders to create group goals, provide autonomy to product teams, and maintain strong customer relationships to drive better outcomes.
Listen: YouTube, Spotify, Apple or wherever you get your podcast
Show Notes
Practical Agility website - https://www.practical-agility.com/
Gary's LinkedIn - https://www.linkedin.com/in/garyacohen/
Agile methodology - https://en.wikipedia.org/wiki/Agile_software_development
Festival of Org Design - https://organizationdesignforum.org/
Team topologies book - https://teamtopologies.com/book
Dynamic reteaming book - https://www.heidihelfand.com/dynamic-reteaming/
Fast agile scaling technology - https://www.fastagile.io/
Teresa Torres - https://www.producttalk.org/
David Sacks template - https://www.functionly.com/org-chart-templates/post-seed-round-saas-startup-template
Transcript
[00:00:00] Tim Brewer: Welcome to the Org Design podcast. My name is Tim Brewer. I have Amy Springer joining me today. We have somehow got a matching Org Design podcast t-shirts on, and we are lucky today to be joined by Gary Cohen. Gary is the owner of Practical Agility, specializing in product teams and helping them structure to achieve continuous delivery. Gary, welcome to the show. Thank you so much for joining us today.
[00:00:27] Gary Cohen: Thanks for having me, Tim and Amy. It's a pleasure to be here.
[00:00:31] Amy Springer: Kick us off, Gary, we would love to know your own story. How did you end up thinking about org design, even if you didn't know it was org design? Give us a snippet of your journey.
[00:00:44] Gary Cohen: Yeah, so I have a pretty technical background. Started off as a software developer. Eventually got more responsibility in terms of trying to coordinate others and leadership positions. First in engineering and then expanding out to QA and product, and at that point, you have to figure out ways to help your teams work efficiently and work effectively. And, I had a little help, probably about early 2000s, I was working at a software company and the leader there of the development group. He was studying, I think he now has a Ph. D. in organizational design and he was very big about how you cultivate culture and how you incentivize people and the importance leadership, and so that was my entree into the importance of that and learning informally some of the things that are important related to how organizations function, and when you're trying to change ways of working, around that same time, got into the wave of agile ways of working and lean and things like that. So you need to understand how change management works, but not just for individuals, but also within the organization and how, incentive structures drive certain behavior and if that's perpendicular to what you're trying to achieve in the new ways of working, you'll see the friction and the resistance there. Then it was later on that I started to really study and learn about the Galbraith model and things like that, and then more recently just been, very fortunate to hang around other folks who, also have big organizational design backgrounds, and so then they gave me reading lists and, just planted ideas in my head and so try and incorporate that when working with clients.
[00:02:41] Tim Brewer: Gary, that's awesome. Firstly, we love software developers, for those software developers listening in and we know we've got a lot of them. I think there is some kind of connection between software development and thinking about your organization structure and the rhythm of work. Maybe some questions. When you're talking to leaders in organizations or maybe product leaders and engineer product product teams that can often have different disciplines in, how do you know, like what, when you don't put the right, org design pieces in place, what symptoms do you observe and how do you help leaders see that the problems that they have are org design problems or sift them out, and so actually that's a, you got a people problem going on versus you've got a structural issue or some other issue impacting the design of the organization.
[00:03:34] Gary Cohen: Maybe this is oversimplifying it, but, I think, the first thing that you see is, if leadership isn't happy with the outcomes that they get, then, that's my end to "okay, what outcomes do you want?" You're not getting them. So something in the equation needs to change and usually it's a combination of things. In general, there are some organizational design. Things that probably need to change. There's probably some people, things that need to change, both in leadership and on the front lines, and then sometimes it's technology, they just don't have the right technology or the right skill sets, and then it's a development issue. But always the first thing is what, what aren't you getting? What's the problem? What's the pain? That you're feeling because, I'm not usually coming in from scratch where it's company just starting out and they have no structure and we need to put structure and how the teams work, how do rewards work, what kind of people are we looking for, generally, I'm coming into an established place, so they have their whole history of what they've been doing and what they value and what they reward and what they recognize, they have their interaction patterns of how information flows, workflows, both within a team and then across team boundaries and they have a formal org structure, they, but then they have the informal org structure, which is how things actually get done. And so it, it's a matter of what's the pain or what are we trying to accomplish, and then it's okay, what things, based off of what we know about how orgs work, what things could be impacting that, and then trying to move from there and address those particular points.
[00:05:29] Amy Springer: Gary, you mentioned, "how things are actually getting done". Software development teams were the really early movers into how we're operating as a modern organization. Can you give us some examples or some stories of where you saw or have experienced where there's a formal structure and then there's where things are actually getting done.
[00:05:52] Gary Cohen: I've definitely seen probably more the norm than anything else is that things are usually arranged functionally, so in the software development world, You'd have a group of engineers, who report up to an engineering manager. You have a group of QA folks, or maybe not so much these days, traditionally you have QA folks and they roll up to a quality person. You have your product folks who roll up to product management. Maybe you have UX and that role rolls up to UX. So you have to be careful because by default, if they each have different leadership who each one different things, and if they view, if they have different incentives, that reward different things, it's tough to collaborate together, and structurally you want to create that, but even when that exists, where you have different silos, in the formal structure and you have different reward systems, sometimes you can get teams to work cross functionally and they figure out ways to work that are best for the company and the outcomes that they want. And that's usually like one level of maturity like we see in software companies is are people acting as silos or are they working cross functionally? And then I think there's also if you widen the scope a bit and so I work with a lot of product companies. And so you have customer support and then you have sales and implementation folks who are out with customers and it's really important that even though those are in different parts of the organization that you do have the regular conversations with them. If you're doing agile stuff, you can invite them to sprint reviews or whatever, but even if it's in the kitchen or in the office for those who actually go in the office, which isn't as many people anymore is, understanding what are the problems that each of you is facing, what are the challenges? Some of my best friends were the customer support folks who they're the ones closest to the customers, they knew Hey, that last release wasn't very good and this is what you did to the customers and so having a good relation, they weren't saying it as " Hey, you're to blame", but " Hey, this is something you should know". And what I found is that when people express, The desire to go across organizational structures and work for the benefit of customers, usually working for the benefit of customers, can be a unifying thing. Sometimes it's more like, Hey, this is the corporate goal, but quite honestly, customers are more inspiring, doing it for the customer, more inspiring than hitting a goal.
I think when you have those relationships, you get different perspectives, you wind up with healthier organizations more positive results all around rather than just, Hey we put out our release, and now it's somebody else's job to go deal with the customers. I think those relationships are really important because. Otherwise you're operating as separate pieces and not as a cohesive whole.
[00:09:09] Tim Brewer: Gary, if you're a leader listening to this podcast and you have some form of product team, you're building hardware or software or widgets, maybe even manufacturing, what is the thing that any leader can do or what do you see the thing that you would give the most common advice to a leader, maybe if you're not even in helping them with a change to say, Hey, look, this one thing or two things or three things are going to help you have a better, more productive, better outcomes in your organization. If you just did these things what would your everyday advice be to leaders in product organizations?
[00:09:42] Gary Cohen: Yeah, a couple of things. So one is to align incentives, create group goals, cross functional goals and incentives so that everybody is incentivized, to be aligned and to work together. Along with that is incentivize outcomes, so maybe it's customer retention or some something that is not just put out this feature. I think that's important because the next thing I'm going to say is, it's great when you can learn to give, your product team some autonomy to give them the problem or the outcome that you want to achieve, and then let them figure out the how that's going to happen.
One of the big problems we have in product organizations is that 80 percent of the features that we create and put in our software are either never or rarely used by our customers, and that creates all sorts of problems. Yet most of the conversations I see between leaders and product teams, but whether it's product development or both is more, are you going to deliver? This list of features, which may or not be, may or may not be the right features. And are you gonna deliver it on time? Which is more of a efficiency against plan. When really we should be continuously doing product discovery and learning and delivering value incrementally.
It's actually much more efficient that way to if we're clear on what the outcomes we want and, we can work with customers, understand their problems and then say, here are several different ways in which we think we can solve this problem. We know that this particular solution rests on these critical assumptions. And some of these critical assumptions were not very sure about. So let's how do we quickly test those out and find out whether or not they're valuable. Do they resonate with customers and not just in a prototype, but right, like actually create some working software and see if it what customers actually do other than what they say. And, by doing this, we number one, we kill ideas that aren't going to work out for us, if we can kill them faster, then we become much more effective in our product development. But I think there's a lot of, you have to make space for that and create psychological safety for the product teams, because I think we're all used to, "Oh, we're going to do some analysis upfront. We know what features we need to build. And then we're just going to go build them", and then we focus in on that. So I think, given our records not very good, if only 20 percent of the features we create are good, are useful to folks, then let's spend some more time looking at that side of the how do we learn and how do we figure out what to do rather than trying to twist the wheels of efficiency on the delivery and even more.
[00:12:53] Tim Brewer: Yeah, that that's really good advice.
[00:12:56] Gary Cohen: I know it's, we're at the beginning stages of people thinking that way. So it'll take a little while to get leadership to feel comfortable with that approach. That is the future and that's how we're going to differentiate ourselves as product organizations, and especially when you think about We don't know exactly what impact AI and Gen AI is going to have on product development, but I think it's probably safe to say that it will help us put out software faster. Which means that we really need to focus in on what are the right things to build and how to differentiate ourselves when anybody can go throw something out there. And so I think that's where the differentiation is going to be going forward.
[00:13:43] Tim Brewer: Gary was at the Org D esign Festival, had a really good time there, and one of the themes that we heard about, or when talking to other participants, people on the podcast is how the demand when their organization or their clients are coming to them saying, Hey, I need to reorganize the team. Maybe we're launching another product. Maybe something around us has changed. And the demand's gone from, Oh, we've got six to 12 months to go through this planned change of structure or the process of discovery and change. And now they're going, "Hey, we need to make this change in two months or six weeks", and with much more compressed timeframes, what are you seeing happen to the need and expectation for change in organizations? Is it different to what it was 10 or 15 years ago? And what do you see AI's impact, generative AI or machine learning or whatever it is impact on the product organizations. Are you seeing them become, I know you deal with agile in software. That's where that word emanated from you seeing the need for organization structures to become a little more fluid. I'm really interested to see how you think about the future of future product teams over the next five to 10 years with, Some of the big shifts that have been happening.
[00:14:59] Gary Cohen: Yeah, so definitely seeing compressed time frames and just the rate of change, whether it's change in technology, change in the market. Obviously, AI is a big thing now. So the better, the more you're able to adjust and change quickly, I think that will be a competitive advantage. And a lot of that, there's a lot of thought that's gone into that. There's books have been written on team topologies and dynamic reteaming. And then there's another I don't know if you want to call it a framework or methodology or whatever, but it's called fast agile scaling technology but that's all about working with. Bigger teams where every two to three days they get together and self organize into different little mini teams and figure out what are the high priority items they need to go deal with and so they're, I'm not saying that's necessarily the right thing for everybody to do, but it just shows that where you're seeing the innovation in structures is on being able to change more dynamically who you're working with and what the structures are. So now with AI, I think it's lowering the cost to put out software. It helps in efficiency with lots of other things, too. But, if it lowers the cost of doing it you're going to see more people doing it. And therefore, I think it raises the bar on what customers will expect, and if you want to differentiate yourself so that puts more pressure on the, how do we learn, how do we learn the things that we need to learn? Like we need to really understand the customer's problem or, in the marketplace and understand it better than anybody else. And we have to continue to spend time there. Like traditionally we would think about a problem. Oh, okay. We need to come up with a solution. And then we go work on the solution, but I think looking for approaches where you, stay in both the problem and the solution space is really important. Some of those things Teresa Torres talk about in, she's got a book continuous discovery habits and she's focused on the product discovery end. But I think there's a lot there that both, both in that and in the fast agile thing that I was talking about where things evolve, things are constantly evolving and you have to be, you can't go off of the static plan and you can't have these long time frames. You have to continuously see what's going on and then adjust.
[00:17:33] Tim Brewer: We do strangely cause we're a software company. We started life with a lot of friends in software. So we have some of the highest interest templates, org structure templates are a software company, like David Sacks puts out thoughts on the whole of the structure. There's a guy from Google we've had do a little bit of work around teams, like very large teams and how to manage bigger, more complex projects in org structure. So this is, this has been really good. I'm really stoked. We had someone more product organization orientated. It's been really good.
[00:18:02] Amy Springer: probably saw a lot of nodding from us. Yes, we understand.
We feel those things.
[00:18:09] Tim Brewer: Gary, tell us a little bit more about Practical Agility, what are the type of organizations and leaders that come looking for your help? What are they typically experiencing to say, "Oh, Hey, I need someone to help me go through or reshuffle the team". I know you talked about outcome, but is there something practical, someone would know that they're a good fit for the type of work that you do?
[00:18:31] Gary Cohen: Yeah, I work mostly with product organizations like, product companies doesn't have to be the product organization, but product and engineering certainly is my original background. But sometimes it's just organizations who want to go from, working on projects and they want to think more like value stream, more end to end process and think of those processes almost like a product, so we have customers were delivering some sort of service, and how do we optimize that? So it could be like cycle time, right? Things are taking too long. So how do we optimize it? How do we do a better job of using data? Not just the machine learning data, but just the how do we create hypotheses? Like we're going to invest in creating this feature, we think this solves the problem and so how do we get in the habit of, creating a hypothesis for that? Coming up with metrics that we can use to test it, and then build that instrumentation in and then to have the discipline to, use that to say, "Hey, are we moving the needle in the right way?
Or do we have to, go look for something else". Sometimes it's just about working cross functionally. Sometimes it's just about change management. It doesn't have to be a software organization. We want to work differently, and so what sort of changes do we need to do both in the organization or, working with leadership to like, how do I communicate my message? How do I communicate a vision? So those are, some of the reasons people come to me. There's also, potentially if people are looking for a fractional leader like engineering or product, things like that. But, I think organizational change and especially, within product organizations is the sweetest of the sweet spot.
[00:20:22] Tim Brewer: You're definitely riding an interesting wave with software becoming so prominent in the last bunch of years, and I'm sure you see so many organizations that are traditional becoming software organizations or adding a software product capability, to the mix with online.
Thanks so much for joining myself and Amy on the Org Design podcast. We'll add to the show notes some of the links and details Gary talked about, if you follow his author link you'll have all of his details there, if you're interested in the type of work he does.
Gary, thank you so much for joining us today and have a great rest of the week for the audience, we'll see you all next time.
[00:21:01] Amy Springer: Thanks Gary.
[00:21:02] Gary Cohen: cool. Thanks, Amy. Thanks, Tim. Appreciate it.
