Technical Management: An Ops, DevOps, Dev Journey
The Shared Reality Psychological safety is the foundation of high-performing teams. It enables learning, fuels experimentation, reduces burnout, and keeps great people engaged. Without it, teams go quiet — and quiet teams don’t innovate. It is not a property of individuals — it is a climate that teams build together, with each interaction. The AI … Continue reading →
Quality Assurance isn’t Quality ‘Ensurance’ It has been so confused by many people I’ve worked with that I’ve come to dislike the term. Too many just don’t know what Quality Assurance means. I’ve had talks at various times in my career with people in QA or doing QA work. They express their frustration about how … Continue reading →
I recently read this blog post on tech debt https://kellanem.com/notes/towards-an-understanding-of-technical-debt. I had a strong reaction to it, both positive and negative. The author was arguing that it ‘doesn’t exist’ or ‘rarely’ exists, and the term is overloaded. I agree the term is heavily loaded, but not necessarily overloaded. His breakout is insightful. He points out that lumping ……
In a highly interrupt based business such as IT, it’s no surprise that no matter how hard I try to estimate when a project will finish it can be later than original estimate more often than I like. I think it’s the main reason Kanban style boards are popular for IT and Operations. Instead of … Continue reading →
In The Phoenix Project’s Second Way of Amplifying Feedback Loops, I found it hard to wrap my head around how to approach it. This is one way to get a grip by analyzing the feedback loops you have today and leverage that into options for making new ones. Poka Yoke or mistake proofing is an approach … Continue reading →
There are a lot of parallels between the Toyota Kata and basic system diagnostics that I use every day. System diagnostics always starts with questions. What do you expect to be happening? What is nominal (normal function)? What is the actual condition now? What is preventing the system from reaching nominal? Observe carefully, get data. … Continue reading →
So change management is often called the deployment process for a SAAS (Software as a Service) site. The language here may be different in your organization, but I bet you’ll find it familiar. I have a perspective shifter, a conceptual tool towards DevOps thinking. Perhaps a tool in the Phoenix Project 2nd Way. Insist on a simple vocabulary … Continue reading →
I don’t see agile as the main driver from development onto operations/IT and I’ve seen that mentioned recently in a couple of places. I have a different perspective on the pressures from which DevOps thinking arose. I was thinking about the issues of DevOps a long time ago, just not by that term. Long ago (in … Continue reading →
Does Ops (Operations), QA (Quality), CS (Customer Service) sit with PM (Product Manager) and Eng (Engineering) in design? If not, you aren’t insuring you can reach single piece flow, nor insuring adequate feedback loops are established. That ultimately means you aren’t designing with the end in mind and you’ve left out parts of the whole … Continue reading →
Remember the section in the book where John cleans up goes to see the CFO and interviews him in what seemed a very simplistic way, but thru which he and Bill gained a large amount of driving information they’d never considered in the past? Well, since I’ve recently moved positions I reread the section and … Continue reading →