Gene Gendel, Organizational Design Consultant, Agile/Lean Coach and Trainer
Gene Gendel is an Organizational Design Consultant, Agile/Lean Coach and Trainer. Almost 15 of his 20+ years of his professional experience – Gene had spent working with companies of various sizes and lines of business, trying to help them improve internal dynamics, organizational structure and efficiency. Gene engages at all organizational levels: senior- and mid-level management, teams and individuals. In his work, Gene uses various methods, tools and techniques to strengthen learning by others and to ensure that others gain autonomy after Gene “coaches himself out of the job”.
Gene is a proud member of the small community (less than 100 people worldwide) of Scrum Alliance Certified Enterprise Coaches (CEC). Today, he is the only CEC who resides in NY State. Gene is also one of the co-creators of Team Level Coaching Certifications (CTC) program for Scrum Alliance.
AUTOMATED EPISODE TRANSCRIPT
[00:00:01] You're listening to Scaling Up Services where we speak with entrepreneurs authors business experts and thought leaders to give you the knowledge and insights you need to scale your service based business faster and easier. And now here is your host Business Coach Bruce Eckfeldt.
[00:00:22] Are you a CEO looking to scale your company faster and easier. Checkout Thrive Roundtable thrive combines a moderated peer group mastermind expert one on one coaching access to proven growth tools and a 24/7 support community created by Inc award winning CEO and certified scaling up business coach Bruce Eckfeldt. Thrive will help you grow your business more quickly and with less drama. For details on the program visit eckfeldt.com/thrive. That's E C K F E L D T.com slash thrive. .
[00:00:57] Welcome everyone this is Scaling up Services. I'm Bruce Eckfeldt. I'm your host and our guest today is Gene Gendel and he he is an Agile consultant coach. We're gonna talk to him a little bit about organizational design about his experience in working with companies to change the way they work to be more responsive more customer focused more iterative in the way they operate and deliver with that. Gene welcome to the program.
[00:01:21] Bruce thank you for having me. It's a pleasure in your podcast. Let me be quick and sure I'm not so great at introducing myself. Go ahead go ahead. But I will say just a few things that I so yeah my my hometown my home base is New York City.
[00:01:37] This is where I left. And this is where most of my actions take place this whereas most of my clients I have to travel the world and have been pretty much all over the globe a lot over the United States. My niche as an organization design and consultancy system dynamics training coaching adaptive learning agility those are a buzzword that usually gets turned off and that's how people associate my name with what I do.
[00:02:08] But I try to tone down terminology as much as I can because lately has been dramatically overloaded overused to some extent overused overloaded you know really fine.
[00:02:18] So I said let's do it let's let's start with a couple of things. First let's talk a little bit about what we mean by agile what we mean by lean so you know when you know again these terms get thrown around a lot and kind of mean I think a lot of things different people what do they mean from for you.
[00:02:34] Like when you talk about an organization being agile or being lean. What does that mean.
[00:02:40] Well let me let me put it this way. So I try to strike that term agile from my dictionary and I made that decision a few years back when I was privy to the history of the term agile as we know it today.
[00:02:54] In fact not too many people know but back in 2001 when the Agile Manifesto was written a bunch of guys that got together in number in Utah they contemplated what they should really call this thing that they're about to launch. I think the word adaptive was as equally was given an equal opportunity at that time.
[00:03:14] And I'm not going to digress to say exactly why the word agile has been chosen over the word adaptive. But as long as. So just to be clear the word adaptive was the original precursor that was the original candidate. And we ended up with the word agile. And the reason why the word Agile is less pleat pleasant to my ears is because a lemon person does not really perceive it well it's not a lemon person's language your lingo unless someone comes from sports athletics or military they don't really understand what a shooter really means when they say adaptive that's a little more a household term and it's easier to understand. So for me a litmus test for anything that is labeled as agile would be. Well can you also call it adaptive. This is what makes sense. If the answer is yes then I like it. Then he probably is no wonder that agile rightfully so. But if you just lost sense that means you probably were misusing their what agile and if you will go back to Wikipedia it was nothing but a wimp light footed acrobatic unless and very very adaptive. It's like almost think of it being able to turn on a dime for a dime without breaking a leg. Know if you can do that going like 60 miles an hour and then turn on a dime for a dime and I'd break your leg that that makes it pretty adaptive if you took you forever to do it or if you had to spend a lot of energy or something something happened along the way.
[00:04:39] I mean it wasn't a cheap move for me. Yeah. So you walked out of that. That's the way did that. And then you also mentioned the word lead to me. I mean I can go back to lean thinking the reason they probably talk a lot for a long time about this leaning is something that makes us like a waste free or waste conscious. And when I think of lean development lean companies I think of you know a very very lean steak with very little fat to it and lots of protein. So to me lean is where where we really don't overburden ourselves overwhelm ourselves with excessive cumbersome stuff and this stuff. In the form of practices tools protocols disciplines roles responsibilities artifacts etc etc. etc.. So that's really my definition of will. And of course in order to be agile in order to be adaptive a person or an athlete or a machine has to be lean. Yes because if we carry too much too much extra body weight then our ability to turn on and off our dime would be so much lower. So that's how a marriage is.
[00:05:47] You know I like it. Yeah I think that's an important point or clarification or reframing of that original term in terms of adaptive because I think a lot of people least my experiences a lot of people kind of go into this or think about OK well when we want to learn how to be agile and then once we learn we're done. And I think that kind of misses one of the tenets of of lean agile which is you've never really done a constant pursuit.
[00:06:14] And it's a journey and one of the things I've seen more and more often than not I wish a dead end is when actually it comes from senior leadership of some of many companies. When are we going to become agile. It isn't a binary switch overnight is a journey that may take months or years and just by setting that tone alone actually leads to lots of lots of dysfunction in system gaming because everyone's to call it you know call it a win. We have become agile. We've done we never done.
[00:06:45] That's a lot can be hard for some folks that want to check the box so they want to know if they want to write one check but get them the whole way and it's it's not really how it works.
[00:06:55] Interesting so. So let's talk a little bit about from an organization point of view.
[00:06:58] So philosophically you know that the idea of you know turn on a dime for a dime. That makes sense when it comes to actual organization adaptability. What what are the some of the things you look at or some of the things that your helping a company with.
[00:07:13] To be more adaptive.
[00:07:15] Well as a coach so I try to not be the one to when I enter a company. I try not to lead off with a statement such as I would like to make you more adaptive. Well I would like to make you more agile because there just rubs off the wrong way. As I mentioned that there's so much terminology in and come analogy hijacking and they're all just I'll just I'll just tripped a wire at hello.
[00:07:39] So I would typically walk in with an ambition to learn what a mission is to learn what a company is like from a standpoint of organizational design reporting structure and the first thing I would typically ask for Could you please give me a blueprint of your organizational structure orchestrate an org chart is a very good indicator what what a company what a company would look like. Many many people out there even some coaches out there maybe less less versed people they think that they can walk in and change organizational culture at how low they actually focused on the wrong thing because I actually leverage a lot. Well I Love Greg Lauren and some other agile evangelists out there actually. Craig says this is one of the llamas laws of organizational behavior culture follows structure. You're following on the wrong thing will get us to the wrong place. It is the structure organizational design and structure. That's the first primary indicator of everything. It's the I call it a first degree variable the defined system dynamics. When did and that once we understand what a structure is like we can kind of figure out what our culture is going to look like.
[00:08:49] It's funny when we had this I spent a lot of time on the on the technology side and agile.
[00:08:54] We used this phrase of show me how your teams are structured and I'll tell you how your code is structured in that that the code structure will mimic how the organization is set up and how you know how control and how fiefdoms and how boundaries between departments are are designed like that will end up impacting how the software system is designed. And I think the same is true for many parts of organizations like how you choose to organize people or impact a lot of things about how that organization behaves.
[00:09:26] Finally say this because what you just described is actually what I think back in 1967. Mel Conway defined as a Conway's Law organizational systems. Yeah. Is there is a direct blueprint of organizational structure.
[00:09:41] So when we say or structure women teams of course Wright's team is quite that ill defined that a code base then a system they built. There's going to be also ill defined. We're going to have that 80 20 perimeter problem we've got you know 80 percent of the system are doing 20 percent of the thing but we're spending so much time building things that are not necessary.
[00:10:02] So I totally wholeheartedly agree what we just set in structure is ill defined. So we'll be a code base and I think a guy well so I respect a lot. Bob Martin Yeah Uncle Bob Uncle Bob Younger Bubba you when he talks about clean coitus he rest with you. Q refers to team structure. As well I mean you know your cricket teams will produce crap.
[00:10:23] Yeah. So how so walking into an organization you asked for the blueprint. You see the blueprint. What are you looking for. Like what. What are you noticing or observing and what that blueprint looks like.
[00:10:33] Well I use the. You know I usually whisper to my own head my own Europe the flatter the better the flatter the better.
[00:10:42] And I don't always expect to see a complete flatness but what I do like to see is an organization that's conducive of waste removal effort could be done internally by themselves or maybe it help of an organizational design consultant such as myself if I walk into the company and I get a blueprint of an OK chart of an org chart it has a you know an apex structure that is very very monolithic very very convoluted very cumbersome organizational design. To me it's a good indication that this structure has a lot of waste has a lot of challenging processes tools norms protocols relationships and it's just a very very very difficult very difficult object to work with. So I always look for that possibility of future flatness. And again it's a journey. It isn't something that could happen overnight. So I look for those indicators reporting lines. How many people report into you how many people who is doing what what you know how many single special roles we have.
[00:11:49] How many govern how much governance how much command control how much condescending potential condescending top down behavior behaviors we should ask back those things that can actually fish out from just looking at the org chart again.
[00:12:03] No we don't look for complete flatness because authors need to have senior leadership that it's not it's not it's not totally flat but there's a difference between having you know a pyramid that has this unified base.
[00:12:18] Yeah white base vs. a very narrow base and super tall. If these super tall structures we know that they have been built to optimize local optimize many unnecessary roles processes and tools.
[00:12:31] What we need is really local optimization versus organizational system global optimization and that's what we look after. If we see a lot of local optimization for roles responsibilities single specialty single function roles. This is an indicator that this organization is very not agile and very not lean.
[00:12:50] And now the flip side of the planet work for us today.
[00:12:53] But whereas I'm curious is there any is there any organizational pattern that you see in our org chart or an or a blueprint that you look at and you would walk away from that you would say this is just not fixable or what we need to just start over versus doing incremental change against the.
[00:13:10] If I look at the org chart and how low and if I see it looks overly complex and overly cumbersome that's that alone is not a turnoff for me and that's not a push away. It will make me less optimistic and more skeptical skeptical is if people that have invited me are also expected to treat the org structure as a factor that is not challengeable.
[00:13:33] That's the. Unwillingness to change.
[00:13:35] Yeah. If there is if there is no willingness to change if they would like to treat their org structure their organization as this today as a factor something is not going to change. And if they expect us to work around and about to do the bare minimum so that someone can check the box. I would usually step back and say look there's so much I can do right. If you I like bringing lots of analogies in my training and in my conversations from a construction industry from health and therapeutics and from medicine and I would give something like this I would say look you're asking me to help you let's say to drop 200 pounds at the same time you're not willing to change and shake your head if you don't exercise you know what I'm going to tell you but you know I go exercise you don't want to go on a diet you do not want to do anything that will bring you to a better state and you just want me to work with you on your superficial appearance. And if that's the case then I will be disservice and you and I will be actually breaching my own internal personnel working ethics and I would push away from the table.
[00:14:37] Now I get it. So the cycle that you mention a couple of things before I wanted to dig into a little bit. So you mentioned waste in a process and you mentioned local versus system optimization. What are those things mean. I mean it's sort of you know educate our listeners share a little bit about what I mean by that. Thanks.
[00:14:53] Yeah sure. So I'll probably start with a local versus sort of a global optimization because this usually once you learn it it's hard to unlearn it and start seeing it pretty much everywhere.
[00:15:04] So imagine a single specialty role. Let's take a system architect I know a senior system architect that hasn't really coded you know for the last 20 years maybe not ever. No. They have only there's some people that have managed you know.
[00:15:19] Without ever put a lineup I've seen them.
[00:15:22] Oh yeah well and then let's imagine this. So this person is local optimized to to to to create work to create. Let's let's fast forward like let's look at scrum as one of the most commonly used agile frameworks that person would be solely optimized to create lots of lots of backlogged items or stories as we call them in a backlog that are specific to architecture. Guess what. They said these are not cross cutting cross functional user stories. These are component types architectures a component is a component size user stories that have end user stories that Component Type chunks of work. So locally this person would be doing the best he or she can produce many backlog items that architecture centric and work against them and there will be over the business there will be super busy doing a great job not just architecture from a local perspective they are doing really well from a global from a system perspective from a standpoint of a buying customer. If I was a product owner if I was a buying customer I would prob ask a question What the hell are you working on you're working on architecture that is 6 7 months out now. I mean not even needed today so we can think of some other single function specialties that could be potentially drafted into the same couple for real estate. You are you a designer only you're the only optimised to develop groovy and that we could go you know months and months out but we will not be really talking to business year or two back in logic. So I spent part of a by customer wondering why you're working on stuff that is low priority to me. Yeah it could take a B.A. take a business sandals they write the R.D. agile bodies or they write the actual stories business analyst stories that are you know for five months out by the time we get to those those bids have probably decommissioned and went elsewhere. So there's no one to interpret this work but there were very local optimists when they did this in the first place.
[00:17:16] Yeah oh yeah I'd sometimes use the analogy and maybe a little facetious but I use the analogy of know moving deck chairs on the Titanic. You know if you're if all you know how to do is move deck chairs you know when the ship is going down you're just going to start moving deck chairs really really fast because you need to feel busy you know because you sense urgency but if your scope if your purview is so focused and in a local situation you know that's not going to help the overall situation but there's nothing you can do like if you're stuck in a local optimization scenario that's right and it's funny.
[00:17:49] This is because you know there's a there's a fundamental difference between a system output and system outcome.
[00:17:55] And these guys are very keen on having high at put in their work day. They're trying to be super productive in what they do. But the ultimate outcome is actually not so high.
[00:18:07] And now when we're married to it's really what really I'd like to know whether that's a that's that's a new one for me I'd like that output versus outcome.
[00:18:15] Yeah comics but really what really brings your return on investment highs you know it's something that really puts food on the table. It is like what teams are focused on velocity only the rate of output and when you know leadership keeps asking this question what's the what's the velocity what's the velocity what's that that's paving the roads the system gaming and inflating your estimates and just going after high velocity what's the output in the tail on the tail end of it.
[00:18:42] What's the business impact could be very low. Yeah. So we don't want to grow just fast. We want to go in the right direction.
[00:18:48] Yeah I always I have the story from back in my sort of development days. We were doing a backlog development meeting with a bunch of senior exacts and we were kind of talking to the business process and we came out with all these stories and you know we're all excited seeing this big backlog within a week's worth of work. It was like you know looking great. And then one of our developers was questioning this whole kind of process it was it was shipping box there was this element of shipping books. And they kind of looked at the system as a well we could just we could just do a make a file. We could just export this as a tax file and just send it to email to decide and once a day they could just upload it to their system and they would basically get the same thing done and all the senior exacts looking as the saying yeah let's just do that. And we wiped out you know you know one hundred and fifty points development that we were trying to integrate these things because by really thinking what was the output that was needed. Like we're focused on trying to get output like we will. We wanted stories we could deliver. And you know instead of just thinking the outcome what was the outcome we want it we just wanted an updated record once a day to be able to ship the box and I mean from my point of view it was kind of frustrating because we had you know was probably a hundred fifty thousand dollars a development service.
[00:19:52] We wiped off the table. But you know you know that's that was just as good. It was just as good if not better than doing all this technical work. And so that whole thing of velocity we kind of spent you know six weeks with output you know with with generating stories and generating code and delivering points but not really thinking about outcome or if you really think about outcome we've we got to outcome much quicker by just taking a different path. And so I think I think that's that's often the case in. On the development side of when you get a stock in the output mode and not thinking of the outcome mode that's good. So I just want to talk a little bit about you know outside of technology when we think about this for really any kind of process or any kind of service based business there are already really any business but purely service businesses.
[00:20:37] If you think of your the work that you do that the things that you do to deliver value to customers whether you're a law firm or an accounting firm or marketing or you do environmental engineering you're producing reports. I mean this is that same problem comes up like if you have someone who is you know is an expert or a single you know single focused expert in a particular part of the process that they will often look to create value in their little step but that will make the overall delivery of value to the customer less efficient because of this local local optimization for versus the global sort of system throughput optimization and I think that's something a lot of a lot of companies struggle with when they don't have a clear view of what the overall process looks like and they're just looking at it particularly when they have management metrics in place to force Bill ability you know output focused measures around management performance management.
[00:21:35] This can really become a problem. So I've see companies where a particular department is highly productive they produce a whole lot of output but it creates havoc for the rest of the organization.
[00:21:44] I don't know where you've seen this so I can very painfully what you just said Let me explain why the document giving him a chance our first I'm going to play backwards a little bit.
[00:21:55] A bad performance measurements and about individual performance and all that. You know 50 year old way of incentivizing and encouraging individuals to work hard and and well that is just you know so all that that must go so many companies these days just stepped away from this approach. There is so much literature and so much documentation so much research and analytics behind not doing performance management the way it has been done for the last 40 50 years you know people are still in a tolerant mindset.
[00:22:29] The ball is still in in the you know McGregor ish way of pushing down on people and analytics dangling a carrot in front of their nose and trying to make them work hard. And that's art.
[00:22:42] So that whole thing just will just you know makes it I think it makes my blood boil. Of many people but not too many people yet speak about it out loud. Yeah. So that's that I think you know the question was about you mentioned about local optimization being seen not just in product development. Yes that's very true. Like one one of the biggest ironies of my recent experience. But also you know I could roll back years a few years back more often than not I would have to interface with someone who thinks who would think that agile who would think of Scrum or combine being designed only for software engineering. Now truth be told scrum was originally created for product development and for software development however it has gone so much broader and wider than just software engineering. Like if you look at Columbine for instance you know it started from theater production system. You can roll back decades and decades before software engineer engineering was even you know as big as we know it today. So if it does not have to do only with software engineering it could be so much more. And it could be in marketing we could see agile work agile type of work in marketing in construction and in H.R. and in procurement in vendor management pretty much anything we put our finger on we could you know we can scrutinize the what people work from a standpoint are you being adaptive in the way you have been working are you local optimizing just for the benefit of your local little group or you're this specific individual. Are you optimizing for the overall outcome. So that's just so I've seen it plenty. And what what strikes me often is the people saying well if they they're not in software engineering space you've done that in product development space then this not does not apply to them.
[00:24:39] I always use a simple analogy If someone does construction work in their house and they've never a construction crew comes on site that is specialized in everything from soup to nuts plumbing carpentry masonry and decorations roofing and every worker on that crew can do something more than just his or her single specialty. Wouldn't that be better if you need to do demolition and you've got a 10 man crew. Guess what everyone can do it. If you want to do plumbing and there are three people that are experts in plumbing or two and two or three are good at plumbing. Then you just have extended your capacity from three to five. Yeah that could be so and we'll talk about funding or budgeting as that as a homeowner. Would you rather pay incrementally to your crew. Maybe every few weeks and see what they have done for you so you can course correct and make sure you don't spend your money on things that are not maybe necessary. Or would you rather sign on there. So w with them that you know speaks about you know seven months our deliverable and they don't let you back in seven months and then they come back to your home and they've put a sink in the middle of the guest room. Now that no they don't. Those analogies I usually use and this is so I can very strongly associate with those cases where people saying well agile isn't for us because we're not in software generally.
[00:26:09] True. Yeah exactly. I mean it's interesting I think the more you know when you pull back to kind of the principles and the ideas and techniques around agility and then you can start applying it to basically anything. I mean I always joke I I have my wife you know gives me my you know all the all the things that she wants done around the house and I give her a stack of index cards and I have put all you know each thing on an index card. Then I tell her roughly how long it's gonna take me and then I have her prioritize it. And I it's just like I've applied agile principles to managing my marriage on the week because because it works because it works.
[00:26:43] It goes like You know I'm happy to do anything you know you tell me what's most valuable you tell me what order is I'll tell you you know roughly how many hours I have or how many points I can get done you tell me which ones I'm going to start at the top and I'll do as many as I can. You know it's and it's at it's it's the basic principles it's just applied to a very different context but so. So let's talk about the other one which was waste. When we talk about waste I mean we're not talking about trash and garbage around the office here. When we talk about waste inside process or inside you know how an organization runs. What are we looking for. What are the different categories and how do we identify them.
[00:27:18] Well you know if we are really strict about waste you know how we define waste anything that is not like how we can use it we could probably use software software development as an example although I'd rather not based on what we just said because not just software development. When we talk about Agile it's not just software development but here's an example with software development we could argue that it can but work in code is a waste. But some of this is unnecessary waste right. You know like for instance the backlog and backlog items and acceptance criteria and practices around maintaining the backlog like product backlog refinement or sprint planning we can consider those as wasteful because in the end your customer does not consume those. Anything that does not translate into a tangible deliverable that a paying customer piece for could be potentially considered a waste. However there's some of it is so unmet so necessarily inevitable.
[00:28:18] So a nexus. So we have to deal with it now and it will become a throwaway in the end but we need to get through it. So so what we'll look for we'll look for those patterns.
[00:28:27] Those in cases where we see a lot of residual unnecessary cumbersome waste that is by far more excessive that minimal I could use an example of. I think you mentioned metrics just a few minutes ago. I believe that metrics just are as good as the people the people that produce them and people that consume them. So if we produce garbage metrics if we produce something that's either misleading or it's not easier to consume. Not only is it wasteful it is also harmful. We could call us let's look at the good old business requirements document you know the BRT or something that's very having monolithic if we're really price that document line by line and we could potentially extract maybe you know 25 to 30 percent of it that is that could be translated into functional specification into working code. The rest is fluff. The rest is stuff that is necessary to look to document and to make the document look good. That's wasteful. And of course we can digress into roles and responsibilities. This is actually more sticky and more challenging than people think. But it's necessary to talk about these things. Why. Because we're talking about local optimization. Yes what if we have a team of seven. Doesn't matter what they do but whether they develop products or services or they they sell or they market or they procure something else. If out of these seven people only two or three people are actually doing tangible meaningful work that translates into a deliverable. And the other few are there to maybe collect metrics or create reports or create statuses or do stuff that is unnecessary. Now we're now we're seeing waste not only in in artifacts. Now we see waste in processes and perhaps in. I'm off the rolls. So this is where organizations. And this is actually a sticky part because when we start talking about waste in roles and responsibilities. Any organization that has a lot of the latter will become natural defensive because that actually goes back to one of the alarms lots of organizational behavior. Organizations are after him I'm paraphrasing.
[00:30:41] Organizations are local that optimized to protect status quo or of a first and middle level management says yes. So it's not necessarily management. It's not necessarily a person who is in a management position although it's oftentimes the case you know it is people that sit in this middle tier call the frozen middle people that sit in the middle and they kind of did their benefit it's from when things become stale and things come idle when there was a lot of waste. There was more stuff to work on right. Think we can think of an elephant or rhino. It grows it consumes more food as it consumes more food it becomes bigger as it becomes bigger. It comes it means more food. So it's a positive feedback loop. It's a vicious cycle. So we're having more waste. We have we need more people to work in that waste. Once we have more people then we need to create waste to get them busy.
[00:31:36] No exactly. I think that's the problem when organizations focus on keeping everyone busy that often ends up creating a whole bunch of inefficient a whole bunch of waste and processes just because people need to look busy. If that's the if that's the organizational culture if that's if that's how people get married.
[00:31:53] That's right. You know we're busy and you know we're working hard and then that's just you know doesn't cut it right for me at least it doesn't cut it.
[00:32:01] Because working it's not we don't want people to work hard. We want to work smart.
[00:32:06] We want them to gain a lifestyle back.
[00:32:08] We don't want him to do you know run five miles in the wrong direction on a tangent and you know go another three miles in a different direction. So they actually do trail. I get there the period some janitor is so happy.
[00:32:24] Yeah but I think you know what I'm alluding to actually going in the right direction. Yeah. You realized early enough that you're not going in the right direction.
[00:32:30] You have to change the course. Yeah. And that's what next. That's right.
[00:32:34] Rule number one you find yourself in a hole is stop digging. It doesn't help to dig faster. This has been fascinating. I mean I think there's lots we could discuss about applying this in different areas but I think this is a really good discussion around adaptability and you know why we kind of think about or help companies with agility and thinking about lean Gene. If People want to find out more about you and the work that you do what's the best way to get that information.
[00:33:03] So I tried to try to keep it very humble and keep it low but people probably could Google me and I have a Web site I call that not for profit Web site and you know what is going on but it's off collecting a bunch good from Shawn I would guess it's just after success that there's a plenty of artifacts that bill a blog there is there are thousands and thousands of articles some recommended books some of these RSS feeds there's some pretty cool stuff you can people can find and of course through their Web site they can find me they can find that link and they can just you know just google for my last name my first name I don't try to hide I'm out there but Oh but you URL in the link to your profile on the show not here.
[00:33:56] So people can click through but there's a great discussion there's probably a couple more episodes we could do in getting into all the details and the organizational chain side of it and how organizations change and what they struggle with. But I think is a great discussion around just agility and adaptability and that was really helpful. I really appreciate the time.
[00:34:14] Oh yeah yeah. I'm happy to be here and then thank you for inviting me.
[00:34:18] You know I like you said it right. We just scratching the surface.
[00:34:21] We're talking about 50000 feet year and there's so much more to if we start peeling back all of these topics we're going to discover a lot lots of great stuff. Yeah it's been a has been fascinating for me to have a discussion with your person. I thought it would be useful to your listeners as well.
[00:34:40] Yeah. And we'll we'll skip two more episodes we'll get into those that are important.
[00:34:44] Definitely definitely. Thanks again. Thanks Bruce. Well we'll be in touch.
[00:34:50] You've been listening to Scaling up Services with Business Coach Bruce Eckfeldt. To find a full is a podcast episodes. Download the tools and worksheets and access other great content. This is a Web site that scaling up services dot com and toll free to sign up for the free newsletter scalingupservices/newsletter.