Subject: Software development/delivery Antony Marcano's post (see https://lnkd.in/gnHDYEP4) started me thinking about some of the situations I've seen along the same lines. The question, "Why would you not want to?" is pretty puzzling to those of us who've experienced how much easier life can be if we line up the dominoes before we start knocking them over. It occurs to me the answer to the question may not be that people actually prefer doing things the hard way. Their work environment may be a factor. On a recent training engagement, during a preliminary call with client management to clarify the scope and goals of the course, I found myself having to guess at what they were asking for because the manager spoke in cryptic, roundabout jargon that didn't seem to mean anything concrete. Listening between the lines, I came up with an agenda that seemed about right, but going into the gig I was prepared to pivot. A lot. And I did. It was hard to get a handle on what the participants were looking for from the training. Walking through their process, a number of opportunities for improvement became evident. Yet, they insisted everything was fine just as it was. I tried to tease information from them by asking what problem we were trying to solve, so I could adjust the content for them. They kept saying they had no problems and everything was fine. At one point it dawned on me that they were terrified of the word "problem." That was when I realized their work environment was toxic. I asked them how they would like to use the training time, and they guided the rest of the course accordingly. They said they got some value from the training in the end. On another engagement, this time a technical coaching gig, management made it clear that transparency and psychological safety were key and anyone should feel comfortable raising issues and making suggestions for improvement. They abruptly let me go (in the middle of the night with no warning) after I shared information about the improvement goals with the teams I was coaching, following a working session with management. Management had not indicated the information was to be withheld from the teams. It was routine stuff about metrics and targets for improvement. I've seen a handful of places that were much worse than those examples, but not many. Maybe 3 or 4 really bad ones over a 48 year career. The basis of their problems isn't technology or process or tech practices or any of that. The problems arise because an inhumane work environment compels people to worry more about defending themselves than about getting useful things done. It's particularly bad in organizations that do annual reduction-in-force exercises in which a fixed percentage of staff must be laid off, no matter what.
Coach, Consultant & Co-Founder, RiverGlide - coaching and consultancy in achieving true agility | Fractional CTO, VRAIL - an AI Powered Entertainment Company | Advisor to Driven By Diversity
If this applies to you, help me understand... Why would you NOT want: ‣ A lead time to change: 15-30 mins. ‣ Less than 5% of the team's capacity to fix all new bugs. ‣ Deploying on demand, multiple times per hour. When you currently have: ‣ A lead time to change of 1-2 weeks? ‣ 20-30% of team capacity consumed fixing a subset of a still growing bug list? ‣ Weekly or fortnightly release trains? I don't mean, why can't you do it _yet_ I mean, why would you not want to? (Whether as an individual or as a company) Asking for a friend 😉