Building Relationship, Trust, and Credibility When Coaching Leaders | Gary Cohen

0 comment

In this episode, Gary Cohen shares insights on coaching leaders in organizations on agile principles and practices. Gary is a software development leader and an agile coach/consultant. His specialties include software development leadership, agile development and product management, agile mentoring/coaching, business process reengineering, consulting, and mentoring. He is a strong advocate for continuous improvement, emphasizes the importance of feedback across all aspects of the organization, and is passionate about empowering people within the organization. Gary holds several agile credentials, including Certified Scrum Master, Certified Product Owner, ICP-Agile Facilitation, ICP-Agile Coaching, and Path to Agility Practitioner. His multifaceted skills contribute to building effective and adaptive software development teams and processes.

Takeaways

  • Understand the business outcomes leaders want to achieve and align agile practices with those goals.
  • Cross-functional teams are powerful and important in achieving the benefits of agile.
  • Learning and adapting are key features of agile, but they may contradict fixed schedules and roadmaps.
  • Develop internal champions to sustain agile practices within organizations. Building relationships and trust is crucial in agile coaching.
  • Giving frontline employees a voice helps build trust and credibility.
  • Agile metrics should be used as a guide and guardrails, not the end goal.
  • Measuring value in non-monetary terms can be challenging but essential.
  • Agile coaching is evolving towards more cross-functional teams and a focus on outcomes.
  • Focus on delivering value and being valuable to others, rather than titles or compensation.
  • Develop emotional intelligence and self-mastery as an agile coach.
  • Courage and transparency are important when coaching leaders.
  • Continuous learning and curiosity are key traits for agile coaches.
  • Join agile coaching communities and events for further learning and practice.

Connect with Gary

Connect with Vit

Timestamps

(00:00) Intro

(05:07) The Importance of Coaching Leadership on Agile Principles and Practices

(07:56) Essential Agile Practices for Leaders

(13:49) Establishing Trust and Credibility with Leaders

(15:50) Understanding and Communicating with Leaders

(19:50) Sustaining Progress After the Coach Leaves

(25:22) Overcoming Resistance from Leaders

(33:35) Using Agile Metrics

(40:34) Upcoming Trends in Agile

(47:57) Advice to Younger Self

(50:11) Final Lesson from Coaching Leaders

(54:06) How to Contact Gary Cohen

Transcript (Edited by Vit Lyoshin for better readability)

Vit Lyoshin (00:01.408)

Hi there. Welcome back to the Vit Lyoshin Podcast. The next episode with Gary Cohen. Gary is a consultant and organizational change coach. He works with leaders of organizations to help them create better software products. And back in October 2023, I went to the Agile DC conference and you were speaking there on one of the topics that was very interesting to me. You spoke about how to work with leaders in organizations as a coach. So that was fascinating and I got a lot of information out of it. I actually bragged about it at my work and tried to get people to use some of it and like motivate some people, like, hey, this is how it should be done.

But I have some follow up questions for you and things like that. So I invited you and said, well, maybe we can record this and broadcast to more people. So that would be great. So, before we start, I just wanna give the floor to you for a little bit and introduce yourself and maybe a little bit of your background. I know you were in the leadership roles yourself and maybe that somehow influenced how you work right now with leadership.

Gary Cohen (01:26.376)

Yeah, sure. Well, thank you. Thank you for having me on. I really appreciate it. And yeah, so my background’s, I don’t know, maybe a little bit different in the sense that I didn’t start off as like a scrum master or things like that, that my career was started off very technical. I mean, I started writing code in high school on my Atari 800, which kind of dates me.

I studied computer engineering at the University of Michigan and got a master’s degree from Penn. And then I was a developer, a tech lead, an architect, manager, working at a consulting company in Northern Virginia for many years. And then I moved up to Philly and did a little internal IT at financial institutions. And then for the last, or for most of the last 20 years, I worked for software product companies in the Philly area.

Eventually, I was leading the engineering and product groups. So that’s kind of my career arc before I became a coaching consultant. But in terms of the agile part of it, that just kind of came in the middle just by coincidence. At the beginning of those 20 years working for product companies, I was introduced to Agile by Bob Schatz, who some of you may know he’s a certified Scrum trainer and agile coach, but at the time he was VP of development at Primavera systems. I didn’t report directly to him, but I joined in on the fun and started utilizing agile practices in my teams. And then as I moved on to other companies, it was very helpful to introduce agile ways of working at those companies.

I was using agile coaching, I was using agile leadership, but not for the sake of being agile, but because I thought it was the best way for my teams and organizations to develop great software products. So when you combine that with organizational design best practices, we’re able to create high-performaning teams and a great collaborative culture.

And so in the middle of the pandemic a couple of years ago, I decided that instead of running engineering and product organizations, I could help others to improve their organizations and work with them to deliver better product outcomes. And so that’s sort of how I got into the consulting and coaching. I got lucky in the sense that pretty early on, I got the opportunity to work with Google as one of my first agile coaching clients. We were able to do some great things, reducing cycle times. But anyway, that’s kind of how I got to where I am today.

Vit Lyoshin (04:24.704)

I see. Okay. So my first question would be, why coaching leadership on agile principles and practices? Do they not know this already?

Gary Cohen (04:38.664)

So that’s an interesting question because even like five, or 10 years ago, I would say that many leaders do not understand agile principles, right? And part of your job was to educate them. I would say in the last few years, it’s hard to find a leader who hasn’t at least had some exposure to agile, but maybe the way that they interpret it or the way that they’ve been taught it may lead them to lead in one way. Oh, this is going to help me hit my schedules more reliably, which may or may not be true, but that’s not really the biggest positive impact you can have with Agile. And so then it’s kind of working with leaders is to kind of point them in the right direction so that they understand that we can do a lot of things with agile can help you do a lot of things, but what is it that you most want to or need to accomplish? And then let’s talk about how we get those things done.

Vit Lyoshin (05:56.704)

Okay, I see. Because yeah, the reason I’m asking is I sometimes see people who step into Scrum Master role or project management role and they struggle a little bit because like, but my boss doesn’t understand this or that. Why do I have to teach my team and also teach my boss all the benefits and how to do things and so forth? So that’s why I’m asking why to do that. And that makes sense basically. We need to get everybody on the same page so everybody understands what’s going on.

Gary Cohen (06:31.432)

Right. Having said that, I think the end goal is not to necessarily do agile by the book. The goal is we have a set of business outcomes that we’re trying to achieve and trying to deliver value to our customers. And so just want to make sure that we don’t get too focused on the frameworks or the like, oh, well, the Scrum Guide says to do this. Right.

And while, well, you know, while there’s lots of good stuff there, that may not, you know, that may not always be the right way to go. And so you have to figure that out in the environment that you’re in.

Vit Lyoshin (07:15.488)

Right. So are there any beneficial or essential agile practices that any leader should know about?

Gary Cohen (07:28.992)

Yeah, so I think two things that I think are worth pointing out. So one is cross-functional teams are very powerful and important. And I think that’s a crucial part of getting a lot of the benefits out of Agile, right? You eliminate silos, you reduce handoffs, so that helps your flow. And then, If having everybody having improved in a shared context for what you’re trying to accomplish and benefiting from multiple perspectives, I think, you know, results in better solutions and better outcomes. But the other thing that I frequently want to go over with leaders is that learning and adapting are features. They’re features of these ways of working.

The truth is that that is in contradiction to having a fixed schedule or a fixed roadmap and managing the delivery of a specific feature set and a specific timeline. And yes, you can use Agile to do that within a fixed schedule roadmap to achieve greater predictability or better delivery capability.

And that’s all good, right? And leaders want that. But what I try and point out is that you’re missing out on the biggest benefits of Agile, which is getting to the right things to work on and the right things to produce much quicker than kind of our all-in, we know everything that we should be doing approach that is most prevalent today. And that also means that we’re missing out on the benefit of killing early on efforts that won’t get us to the business outcomes we’re hoping to achieve, right? And that saves a tremendous amount of money and makes it more likely you will hit those outcomes. So those are two big things there.

Vit Lyoshin (09:44.096)

Yeah, this is great. I like the second one a lot, which allows them to pick and choose the most priority things, the most important things that will move the needle and not everything and all the wishlists and nice to haves and everything like in old days and waterfall or whatever. So yeah, that’s great. If they understand that and lead the teams to do that and allow them to do that, that will be great.

So let’s talk about some of the specifics of this approach, how we can work with leaders, and how can we start this process by getting together with them, and what will be the first step basically in the process of getting to work with them.

Gary Cohen (10:32.392)

So the first thing I would ask, you know, when you’re working with leadership is what is it we’re trying to accomplish? Right? And, you know, so we want to be more agile, right? We’re bringing you in, you know, either internally or externally, you know, because you’re an agile person or whatever. And it’s like, okay, but why do you want to be agile? Like, what are the business outcomes you’re hoping for? What is it that you want to change? Right?

And why and what’s the end tie-in with better employee experience, better customer experience, faster delivery, more profitability, whatever the case is, and understanding that this is what they want to accomplish, right? Setting up and understanding where you’re at today in terms of those measurements, so that you can tell whether you’re moving in the right direction or not. And then I think at that point, you want to come up with a set of initial focus areas because you can’t change the world in a day. And so again, we kind of talked about prioritization before, and it’s also about building credibility.

So, If I come in and, they want to accomplish this huge thing like reducing our cycle time by 50% or whatever, right? And they expect to do it in the first three months. Well, that’s not likely to happen. So if I set those expectations with them, they’re going to lose trust in me pretty quickly, right? So I have to be honest and transparent about what’s going to happen when we start working on some of these things in the initial focus areas and what they’ll start to see. They might see some slightly different behaviors before they ever see changes in the outcome. We might want to start just with one or two teams because we’re trying to figure out what works in this particular organization, in this particular environment. And then once we refine it a little bit,

and we start to get success there, then it’s easier to take it to other places. So things like that that help you build up credibility with the leadership is important.

Vit Lyoshin (13:08.128)

Right, okay, great. So, then are there any best practices or anti-patterns for how to partner with leadership, like building this trust that you mentioned, and credibility, how to better understand their needs and things like that? Any tips there?

Gary Cohen (13:28.872)

Yeah. So I think, I think first of all, you need to talk to leaders or speak to leaders in a way that will resonate with them. And I think that you know, I hang around with a lot of agile coaches and agile people and we have our way of talking, right? And, and the terminology that we use, or even the focus, we tend to be very detail-oriented, very focused on process.

And leaders, a lot of times they’re thinking about outcomes, they’re thinking about risk management, they’re thinking about profits or growth or budgets or things like that. And so the more that we can speak to them both in a language they understand and also talk about the outcomes or the things that they care about, right? The more engaged they’re going to be, and the more likely they are to be interested in what you’re doing and to give credence to what you’re doing. Because if they can’t understand what you’re saying, best case, they’re just going to block it out, right? And ignore it. The worst case is going to be like, who is this guy? And why is he here? Right? And, you know, kind of run the other way when you walk down the hall.

So you want to establish that pattern of talking in a way that they will listen and be engaged. So that’s probably the first step.

Vit Lyoshin (15:10.464)

Okay, yeah, that makes sense. I like this a lot. It could be a little bit challenging for some people to figure out that language, especially if they’ve never been in this role, right? So you have to do your homework, you have to maybe even talk to your boss or talk to any leader and say like, what exactly are your goals and what do you try to achieve with this? And maybe if I understand this better, I can help you with this.

So communication and collaboration have to happen to figure it out, right?

Gary Cohen (15:44.36)

Right. And so a couple of things on that. So number one, you can try and put yourself in their shoes, which may be hard if you’ve never been in a leadership position, right? But if you have, then certainly that’s a big benefit because you can rely on your experience there.

Number two, you can observe how other people talk to them in meetings, especially if they’re other leaders or executives or somebody who you know just has a lot of influence in the organization. Maybe they’re at your level, but they seem to have a lot of influence. See what they’re talking about, right? And pick up on that. And then third, I guess, you can always talk to some, like get a coach or something like that who does have that experience to help you work through some ways that you might start to communicate with executives.

Vit Lyoshin (16:44.48)

Yeah, I was about to mention that relying on your peers or maybe somebody who’s a senior or somebody who’s just been longer in the organization and that person may know their leadership style or their preferences and how to work with them. They’re all different. We’re all people, right? And we all behave differently. We all have our other priorities and our personalities. So just having a little empathy there and learning how to work with other people will be a huge help.

Gary Cohen (17:16.072)

Right. One thing, I mean, you’re very right, like everybody’s different, but one thing that seems to be very common among executives, is they don’t have a lot of time and they don’t want to hear long detailed answers, at least until you’ve caught their attention. So you give them the answer first, this isn’t my recommendation. And then as they start asking questions, you can get more into the details. That’s not totally universal, but pretty universal with leaders.

Vit Lyoshin (17:50.496)

Yeah, and I also tend to think that people in general, in leadership roles, tend to not like when you come to them with problems. They also want to see like, okay, if you have a problem, what we can do about this? Or if you’re complaining about something, what can you offer us to fix it?

Gary Cohen (18:11.112)

That is very true, although I’m going to put a caution out on that. And this is something that I would coach leaders on, if you tell people to only come to you with solutions, right? Then you’re missing out on a lot of feedback. And yes, I totally understand. I did not like it when people would come to me with every little complaint and this and that, right? But as leaders, like number one, maybe try and empower your teams and your folks to solve some of their problems, right? By giving them some autonomy and just giving them some general guardrails and letting them go at it. But like, if you lose that line, that communication line, you don’t know what’s happening out on the front lines and everything. So as a leader, that’s dangerous, but you’re absolutely right that many leaders I’ve had that said to me many times. I probably said it to people a lot. It’s like, don’t come to me with problems, come to me with solutions. But really the answer is to be careful what you ask for.

Vit Lyoshin (19:24.926)

Right, there has to be a balance in this and some room for people to still be able to come with problems and expect their leader to help them. Yeah, that’s great. Okay, so when we get to know them and we know how to operate and work with them and the process is going, and let’s say you establish some sort of new process and things are going well. How to sustain this with them? How to make sure that it continues for a longer time? Does it have to be passed on to somebody within the organization to keep an eye on this? How does it work after the coach leaves basically?

Gary Cohen (20:11.88)

Yeah, I mean, I think as a coach, especially as an external coach, you want to work yourself out of a job. I mean, at least the best ones should, right? And even as an internal coach, maybe you want to move over to a different part of the organization eventually, right? Or to, you know, a higher level or whatever the case may be. So in all those cases, I think part of your job is to develop internal champions. People on the front lines and in all parts of the organization who have an enthusiasm for improving the ways of working, who want to have autonomy and decision-making, and who believe in working across functional teams and things like that. And a couple of things.

So number one, as you said, if you can develop those internal champions, then as soon as you as a coach walk away, everything doesn’t just stop, right? It continues on, right? These internal champions believe in continuous improvement, whether it’s in retros or other means. And so you could go away for a year, you could go away for whatever, right? And you come back and you might not, hopefully, you don’t recognize a lot of stuff because they’ve continued the change process and continued the improvement process.

But it’s also important even as the initial transformation is going on, because if you start off working with a couple of teams, and you develop internal champions on some of those teams, then when you start to work with additional teams, first of all, you’ve probably started with the ones that are most excited about these new ways of working. And so you didn’t have any problem getting them to try new things. But then as you move on, you’re starting to get to some of the people who are a little bit more skeptical or have more questions or whatever. And one of the things they typically think is, well, that’s not going to work here, especially if you’re quoting, you know, like directly from a framework, well, this is how we do a daily standout, right? And this is, right. And so that’s why it’s really good, like as an external coach, even if I’m really flexible about that stuff and talk about co-creation, they’re going to view some of the things that I’m saying with a little, still a little bit of skepticism. I’m not sure that can work here, right?

But then if I can have like an open space or a lean coffee or whatever sort of meeting on a regular basis with people who’ve already gone through this, like some of the initial teams that I worked with, some of those internal champions, the new folks can bring their challenges, their problems, their doubts to these meetings. And, instead of just me answering their questions, they have their peers whom they trust, and who they know.

Hey, this person works here. They’re a really good engineer, really good at this or that. And if they’re saying like, yeah, we actually had a lot of success doing this, right? And maybe we did it in a slightly different way, but this is what we found. We tried this, and that didn’t work, but then we tried this and it did work, right? All of a sudden those other people are sold a lot more because it’s somebody they trust, somebody who they know is really good and who’s worked in that environment.

And so it makes your job as a coach a lot easier. So those are two really good reasons to develop those internal champions.

Vit Lyoshin (24:11.392)

Yeah, we actually have something like this in our organization. We call it an agile community of practice. It’s a pretty common term, right? And we basically have a whole bunch of different initiatives on agile training and how to spread the word and how to help each other if we need help in any regard, like estimation or standups or whatever else. And we kind of help each other.

Some people are more vocal than others, but it helps. It’s a great suggestion and an external coach establishes something like this and gives a kind of like a playbook or whatever it is, how to deal with issues, how to self-organize, right? That’s what Agile is about, like self-organize, figure out the issues or identify the issues, figure out solutions, implement them and you will be good to go.

So another one is about resistance. Some leaders maybe if they’re themselves on board and like okay I need help I need somebody external hire let’s say I don’t know for 12 months for example help me with this problem. That’s one thing they are already on board they work with you everything is fine. What about if somebody’s like okay you have a problem, I’m gonna hire a coach for you to work with you and fix all your problems. And that person is just, why do I get this now? What happened with my performance or what? So how do you establish a relationship in this type of situation?

Gary Cohen (25:57.64)

Yeah, I’ve actually been through that situation. They’re like, why are we being punished? Which didn’t make me feel that great, but that was only the first time we met. So hopefully I didn’t feel that way as we went on. I mean, there’s a couple of things.

So first of all, it really helps if whoever is bringing you in has been honest and open with the folks you’re going to be working with. Not like, hey, you guys are doing great, but I just like, maybe you can try something different, right? That people just don’t understand why they need to change. And change, there are a lot of reasons why there’s change resistance and many different reasons.

But one of the biggest ones is because you don’t understand why you need to change. If you’re getting good feedback from managers and on in performance management ratings and things like that. Why do I need to change? I like the way that I work and right. So if the leaders aren’t being honest and transparent with them, you need to sort of nudge the leaders to be a little bit more honest and transparent with them. Or you have to be very creative and figure out ways to maybe help these folks realize on their own what some of the shortcomings of their approach are. And maybe that’s using metrics, right? Like, well, everybody else is cyclical. And I don’t mean it this way. Like, you don’t want to make them feel bad. But it’s like, can you say, like, how long does it take to go from ideation to you know, delivering something to customers, right? And whatever the answer is, you can say, do you, you know, are there ways in which we could improve this? So, you know, to try and get them the feedback that they’re not getting from the leadership that, you know, but I think the other thing is not coming in and saying, hey, guys, starting tomorrow, you’re going to be doing things differently. That doesn’t work very well.

I think it’s more, all right, I’m going to share with you some ideas of things that people in other places, things that they found helpful, especially if we’re worried about cycle time, then here are things that they do to reduce cycle time. And I’ll even give you some ways in which they accomplish this. But then we’ll have a conversation about which of these things you might want to adopt or experiment with, which things you just want to experiment with directly from the Scrum Guide or whatever, and which things you’re not quite ready to, but maybe you’re willing to try something similar, slightly different, and then move on from there.

Vit Lyoshin (29:23.776)

Yeah, overcoming this resistance is always a challenge. It was developers, with middle management, with leaders, with everybody. So it’s definitely something I work myself on because I get to work with some people like that sometimes. And it’s just harder than it needs to be. It’s not always.

Gary Cohen (29:52.04)

Yeah, well, from our aspect, it’s harder than it needs to be. But I mean, they’re people, right? And right, this is our business is about working with people and helping people find new ways of working. And so if they’re feeling something, I know we pose it as, oh, well, they’re resisting, but it’s not like them. They’re just reacting to a situation, right?

And so whether it’s not understanding why they need to change or maybe not knowing how to change, right? That’s another big source of change resistance, right? They’re afraid of losing something if they change, right? And maybe showing them how, well, maybe you might lose something you’re familiar with, but you might get something even better, right? So it’s figuring out what’s causing the resistance and then dealing with the underlying issues as best as you can. But yeah, if it was easy, right, they wouldn’t hire us, right?

Vit Lyoshin (30:55.776)

Right. And we wouldn’t be talking about this now, right? And I think it’s also coming back to the comments you made earlier about building that relationship with people and establishing trust, being empathetic to them, and not pushing too much and things like that will help too.

Gary Cohen (31:21.064)

Right, and again, you’re building trust with them just like you are with leadership is, you know, hey, I’m not here to rock your world, so to speak. And I’m here to be an asset and I’m here to help. And, you know, the other way that you can build trust with people on the front lines, you know, especially if, well, I mean, regardless of whether they’re showing signs of resistance or whatever, is give them a voice.

So when I talk to them about changing and they’re like, well, if we want to be better, then we need to fix this or fix that or whatever. And they’re frustrated because they can’t get their opinions up to leadership, let’s say. Well, guess what? You as, especially if you’re an external Agile coach, or any kind of coach really, you have the magical power of being able to move between levels of the organization a little bit more easily than others do. And so, if you become their cheerleader in a sense of helping leadership understand some of the challenges that the folks on the frontline are facing, and then you can get some sort of result from that, like the leader then talks to the team about things that the team had wanted to change or at least to discuss, all of a sudden you’ve built credibility with the team and they see you’re not necessarily here to impose things on us. You’re here to at least try and make things better, make our experience better, make our products better. We may not always see eye to eye on things, but at least we’re going to keep an open mind when you suggest things.

Vit Lyoshin (33:22.016)

Yeah, that’s great. You mentioned something about metrics and I’m a huge fan of metrics. I always try to advertise it and tell everybody that we got to set up this dashboard or we got to collect this and that metric to understand better the performance, the throughput, or whatever. Are there any basics that you suggest to teams to establish when you start coaching them. Maybe it’s a new team that is forming, or maybe it’s a team that’s been working, but they don’t necessarily follow any of the Agile frameworks. They’ve just been doing it, kind of like just keeping the lights on. Any tips or suggestions on the metrics to start with?

Gary Cohen (34:12.008)

Yes, well, first of all, be very, very careful. Metrics are very powerful, but they can be used as a tool. They can also be used as a weapon. And so I think anything that helps the team that can be kept within the team, right, fair game, just make sure that it is actually going to help.

Give guidance to the team about either improving or getting closer to some sort of outcome that they’re shooting for. But remember, metrics themselves aren’t the target. They’re just kind of a guide. And the two best ways I like to see metrics used is number one, as a way to know where to ask questions. Right, so if I see a metric value that looks kind of off or different than we expected, then let’s talk about it. Let’s not say, you know, okay, that’s the end of the world. Our metric went this way or that way. It wouldn’t tie compensation to it or anything like that. But just, okay, this wasn’t what we expected. What’s causing this? Like, is it a one-off thing that caused the metric to move? Or is it something fundamental that’s changed and that we need to address right away, right? So it’s a good way of starting that conversation and asking those questions. So it helps you be aware and curious.

The other thing about metrics, I think, is if you want to use them as guardrails. So we know that we don’t want to go below this mark or above this mark, right? And, if we do, we need to immediately sound the alarm and take some corrective actions. So metrics are helpful that way. And even as a leader, if you want to give your teams more autonomy, you can use metrics like guardrails that way too to say, hey, as long as you keep within these guardrails on these metrics, you guys decide whatever you think is best, right? If you start to go outside of these things, then we need to have a conversation about how to move forward.

Vit Lyoshin (36:58.016)

Yeah, that’s great. And that’s exactly how I try to use it. Just to bring it up to the team and say like, hey guys, this is what happened. Let’s just do a little analysis. What’s going on and see if it’s a bigger problem or if it’s just a one-off, if it’s one-off, whatever it is, it’s life, things happen. So that’s great. And quite honestly, I try to use a lot of different measures, a lot of different things.

So, I have something for everyday tracking, like how the sprint goes, for example. And then we also have just overall, like, well, we call it performance, but it’s like just to see trends over time, what happens, how things progressing.

Gary Cohen (37:44.36)

Right. And that gives the team information and feedback. And so that’s good. When it goes beyond the team it may not be so good. And it’s also not good if the team starts optimizing just for that metric and loses sight of the actual outcomes they’re hoping to achieve. So that’s where you have to be careful.

Vit Lyoshin (38:05.088)

Yeah, this is just internal for the teams. It doesn’t go anywhere. It’s just internal for us to use it in the retrospective or just in general to have it.

Gary Cohen (38:17.544)

Right. And one of the things, like in the Agile world, we tend to focus a lot on delivery and delivery efficiency. A lot of our metrics are designed for that, which is all great. The issue, though, is we don’t ask a lot of questions about, whether we are working on the right things. And so it seems like we should be spending more time on that.

Vit Lyoshin (38:39.956)

Exactly.

Gary Cohen (38:47.048)

And then we can tweak the efficiency dial on the delivery side. But at the end of the day, we all are working together to achieve some sort of business outcome. And so let’s not lose sight of that. And so I think that’s the big thing is don’t lose sight of why you’re here. It’s not because of the metrics. Metrics are a tool, but not the end goal.

Vit Lyoshin (39:10.048)

Yeah, it’s challenging to measure the value the team produces. For some products, it may be easy when it’s tied to revenue or growing user base or whatever. But when maybe it’s a non-profit or government or something else, when it’s not tied to money or it’s not tied to something that you can count, it’s really hard to figure out what really the value is, how to measure it, right?

Gary Cohen (39:41.416)

Although every organization has some sort of mission, right? And so like, for example, I’ve done some work with like state governments, for example. And so in their hiring process, they may want to make sure that all the citizens of the state have equitable access to job opportunities and things like that. So if that’s their mission, then tie, right? Tie your measurements around that. It’s not always easy, but there’s usually a mission there somewhere.

Vit Lyoshin (40:13.024)

Yeah, that’s right. If you dig deeper, you can definitely find the value, and how to measure it. 

So let’s switch gears a little bit. I have just a few questions in general on agility and where it’s going in the future. If you see maybe any… Well, there are obviously some new trends that come out, especially in the last couple of years. But any of those new upcoming trends you think will change dramatically anything about how we do agile practice today?

Gary Cohen (40:49.128)

Wow, that’s a loaded question. So I mean, I think that there are certain things. I mean, right now, the trend is maybe starting to swing towards less specific dedicated positions. Like I think certainly there was a point in time where, oh, every team should have a dedicated scrum master, right? And you have people whose whole career is being a Scrum Master, right? And that might continue in certain circumstances, but I think we probably should consider that, you know, maybe that it’s like the trend seems to be more towards moving agile skills into all positions, right? And rather than have separate, you know, Scrum Master positions, you might have a developer on the team or a QA person or whoever takes on most or all of the responsibilities of Scrum Master on the team, right? We want self-organizing teams and things like that. But that just, you know, so I’ve seen that that’s possibly going to continue to happen, but that just reinforces the tie yourself to business outcomes, business values, not to like the Agile mantra, and you’ll still be using your Agile skills, you’ll still be providing value. So that’s one thing, but I think there’s going to be more of a focus on outcomes and less on process, right? More of a focus on cross-functional teams.

And what I really hope, and like I’m pushing for, I don’t know that this is actually going to happen, but is getting people to be more explicit about what we don’t know and what we need to learn as we’re trying to roll out a product, a project, what have you. So rather than that plan that says, OK, this is exactly what we’re going to do, think of it with a product and you’re trying to find market fit. We don’t know how customers or certain customer segments might respond if we added this feature or did this or that, or we don’t know if a particular regulation is going to kill our idea. And so then it becomes more about how do we quickly validate or invalidate those assumptions. And to me, that’s like a big area where we can really improve the outcomes and actually do it more efficiently than we do today.

While I’m talking about it and hopefully other people are talking about it, I know, like, for example, Teresa Torres has a book called Continuous Discovery Habits. And, you know, like she’s focused mostly on the product discovery side, but I think a lot of the things that she talks about in there are really important, like that we should be focusing on to drive better outcomes, right? And, you know, so opportunity solution trees, having a continuous discovery process as well as continuous delivery, and having them feedback on each other. Like, to me, those are areas that we haven’t really fully explored yet, and I think we’ll drive much better outcomes going forward.

Vit Lyoshin (44:35.764)

Yeah, I totally agree on the second point, but just to comment on the first one you mentioned about Scrum Masters and the teams becoming more cross-functional, which also means all this facilitation, all these techniques to run retrospective or whatnot, getting passed to developers. Or maybe the agile coaching role is merging with the Scrum Master role or things like that happening. That’s for sure. And teams, some teams or companies moving away from having a Scrum Master and product owner, they just have a product manager and the team around this person and they kind of start trying to do development. So there are a lot of different variations that happen.

But my personal opinion as a Scrum Master in my current role, I always try to teach my teams to be, if I’m not there if I’m gone on vacation for two weeks, nothing will fall apart and they can continue running. Everything works well. And I keep telling them, my goal guys, for you as a team is when I’m gone, you still do whatever we do right now and you’re as efficient and effective as you are today. So kind of my personal goal for all teams I work with.

Gary Cohen (45:52.52)

Well, it shows me that you’re really good at what you do, right? And I think that… So people like you who are… Who kind of can have an impact and a value, and then you can step away means that you can go help in other parts of the organization, right?

Vit Lyoshin (45:58.674)

I hope so.

Gary Cohen (46:22.376)

And tackle even bigger challenges, right? And that’s certainly a path that if you’re just about like agile and performing these certain ceremonies, you’re going to have limited value. But if you can tie practices into better outcomes and not just at the team level, but begin to work your way up to the product level and then organizational level, right? There will always be a lot of demand for people like that, right? No matter what you call yourself or whatever, right?

Vit Lyoshin (46:57.984)

Right. Yeah. And the second point is about merging or getting to work between discovery and delivery. I think it’s essential that this feedback loop has to happen. It can’t be separate anymore. And I see sometimes when organizations have this when one team is doing discovery and the other team is doing delivery and they don’t always on the same page and it becomes a little bit cumbersome.

But if it’s the same team doing all of that, then it’s like that’s a perfect situation. At least I hope so. 

So, there are a lot of years you spent and steps you went through in your career in different roles and everything. If you were to look back and give some advice to younger self, what would that be?

Gary Cohen (48:06.928)

Well, the industry is so much different now than when I started back in 1990. Some of the things may not be relevant, but I think the following things are probably still relevant.

I tell myself, my younger self, learn how to deliver value and to be valuable to those around you, especially the ones that write your checks, but to everybody, right?

Always be curious. Understand the why, continuously learn, and ask lots of questions.

Be yourself. I mean, be the best you can be, but don’t try and be somebody else because you’re not. You’re not going to be them. You’re going to be you. But definitely, learn. Use other people as models and figure out what they do well.

Understand that progress isn’t linear. Right? Your career path isn’t necessarily linear, straight line up. And that’s okay. And it may even be beneficial.

And then finally, don’t worry about your titles or more compensation. I found that if you take on more responsibilities, then the titles and the compensation will follow. And also, don’t be constrained by your title or role whatever you call yourself, whatever other people call you, find ways to be useful, right? And if you do that, you’ll always be in high demand.

Vit Lyoshin (49:45.632)

Yeah, I really like that one about not worrying about the title and just taking more responsibility and everything else will come. Yeah, that’s great. That happens at any level, in any position that can happen. Yeah. All right.

Do you have any other most valuable lesson you learned while you were coaching specifically for leaders, coaching leaders that you can pass on?

Gary Cohen (50:13.852)

Coaching leaders. I mean, we covered a lot of them, but I think you, I think you have to have a certain level of courage and you have to be very transparent. And it’s a tough balance there, right? Because certain people, not just leaders, but leaders, If you come on too strong at first and tell them something they’re not ready to hear, that may be your last day on the job. So you want to get really good at learning to read the room and to see how people react and see body language and tone of voice and things like that. But I think in order to really do your job, especially if you want to work at the organizational level, you need to have a certain level of courage and a certain level of transparency, both of which are right scrum values. So I did read the scrum guide. I just don’t tell leaders that all the time, but.

Vit Lyoshin (51:27.282)

Yeah, go read it as well, right?

Gary Cohen (51:29.384)

No, but I mean, and I just think like that, for me, reinforces like those are important values, both as team members, but also like if you want to work with leaders, you know, like to be a really good change agent, especially going to be a change agent type of, you know, coach or whatever, you have to be prepared. Like I think in order to do a really good job going into work each day, you may not know whether you’re going to get promoted or whether you’re going to get fired. And I mean, that’s an exaggeration, but the point is, like, if you want to move the needle, then you can’t, like, avoid saying difficult things sometimes. You just have to figure out the right way to say it, or maybe say it, maybe don’t say it, maybe ask questions, ask questions that will get the leaders to think about.

Maybe I need to reframe this or think about this a little bit differently or maybe help them become more self-aware or maybe just show them data, right? Show them data and then they can come to their own conclusions.

Vit Lyoshin (52:42.048)

Yeah, it sounds like a lot of psychologists there that coaches have to learn and apply in their job in terms of reading people, in terms of being empathetic to people, and just learning how to speak without being offensive or being able to tell feedback in a certain way that doesn’t offend people and just present it nicely. So it’s really a skill that has to be there. Yeah.

Gary Cohen (53:15.528)

Yeah, you can call it emotional intelligence. Also, if you look at the Agile coaching growth wheel, in the middle of that is self-mastery, and sometimes that gets overlooked, but in some ways, it’s maybe the most important thing to develop.

Vit Lyoshin (53:19.582)

Right. Yeah, coach can also hire a coach for themselves, right? Yeah.

Gary Cohen (53:40.136)

That’s right. And I’ve heard some pretty smart people say that every coach should have a coach.

Vit Lyoshin (53:47.072)

Yeah, to look at yourself in the mirror or to look at yourself from the side and compare. Yeah, that’s great.

All right, well, we covered a lot. Thank you very much for your time. And before you go, I just want to ask if you’d like to share any of like contact details, how people can reach out and follow up on anything or get to, you know, get to connect with you.

Gary Cohen (54:12.296)

Yeah, definitely. So there are two main ways that people can reach out to me. So one is my website, which is practical-agility.com. And there I have lots of blog articles on there and information, and you can schedule a free introductory meeting or whatever.

And then the other, it’s pretty easy to find me, it’s on LinkedIn. And there I actually have a free newsletter there too on LinkedIn. So if you want, you can subscribe to that.

But either way, feel free to reach out and start a conversation.

And then the one other thing I’ll just give a quick plug for is last year I started an Agile Coaching Dojo Meetup. It’s called Philadelphia Area Agile Coaching Dojo, not a very creative name, but the bottom line is that it’s a free venue that provides a safe place for people to practice their agile coaching skills through a dojo format with different scenarios. And it was inspired by Bob Galen’s book, Extraordinarily Badass Agile Coaching. And it’s virtual, so people don’t have to be from the Philly area, and we get lots of people from all around the world to join us. So we do both a monthly lean coffee and a monthly dojo with practice sessions. So if anybody’s so inclined, that’s another way to interact with me and also to interact with fellow natural coaches.

Vit Lyoshin (55:53.504)

Okay, great. I should come to those sometime.

All right, great. Thank you very much. And I hope we talk again. Thank you. Bye.

Gary Cohen (55:58.408)

Yeah, please. It would be great to see you.

Yep, that sounds good. Thanks for having me a Vit. Bye.

Leave a Comment

* By using this form you agree with the storage and handling of your data by this website.

About Vit Lyoshin

Hey there! I'm Vit Lyoshin, and I've been working with technology and cool software stuff for a long time. Now, I'm hosting a podcast where I talk to really smart people who know a lot about making software and managing products.

This podcast is all about helping you understand the tech world. I'll have interesting guests who share ideas that can make a difference.

Subscribe to hear cool stories and learn new things. Your thoughts are important to me, so let me know what you think about each episode.

Thanks for joining me on this fun journey!

Newsletter

Sign up now for the future Newsletter! I'm not sending anything yet, but I'll keep you informed when I launch the Newsletter.

Newsletter

Sign up now for the future Newsletter! I'm not sending anything yet, but I'll keep you informed when I launch the Newsletter.

©2023 Lyoshin LLC. All Rights Reserved.