The news is full of this “quiet quitting” idea. Supposedly, employees are doing just what the work demands and no more. That sounds reasonable to me. (See the blog post, It’s Time to Clarify Work Boundaries and “Quiet Quitting.”) I don’t see why people should do “more” than a day’s worth of work in a day. […]
The news is full of this idea of “quiet quitting.” That’s where people do just what the job requires and not more. Well, I have a contrarian view: Why do managers think it’s okay to ask people to do more? What is it about “more” that managers want? In Practical Ways to Lead and Serve
I started this series by sharing my status of too much WIP (Work in Progress). My WIP was making me slightly crazed and I explained how I worked to reduce it. In case you’re wondering, here’s my current status: 3 presentations still on the list (I completed 2, including the one I recorded). The online
I hate the fact that I let my WIP get this high—and I’m glad I’m working it down. (I wrote why I let my WIP get this high on my other blog in the post, What Would It Take for You to Fail to Success?) My status today: Finished one more presentation and need to
I’m halfway through this week of working through my too-high WIP. So far, I exposed my WIP and talked about how I planned to use continuous flow in Part 1. Part 2 was about cycle time and using Cost of Delay to make easier decisions. Today is about why I don’t use a real backlog
As I said in my Day 1 post, my WIP is too high. Here’s where I stand with my WIP: I completed one presentation, so I have 4 remaining I have some feedback on the book that I need to integrate. I want to address the next 3 chapters, because they’re the platform for the
As with many of you, sometimes my WIP (Work in Progress) is too high. When that occurs, I don’t use a backlog or create iterations. Instead, I use continuous flow. That’s because working in flow allows and creates ease in my development. This week, I want to finish these things: 5 presentations, one of which
I see too many teams feel frustrated because their managers say the work takes “too long.” (The team feedback loop is the inside of the onion for how agile the organization can be. See Multiple Short Feedback Loops Support Innovation.) The longer the work takes, the more pressure managers exert on the team and the
We’re pretty good at knowing when someone is a good fit for a technical role. But how do we know when someone is ready for technical leadership or management? That’s a lot more difficult, and that’s because leadership or management—at any level—is a different job than working in the technology. Here are some ideas based
Many agile teams and product leaders assume they can make many product decisions on their own. They do have some constraints, such as “this kind of customer” and “these kinds of problems.” However, as the teams work together and explore the product, they assume they can decide on the designs and architecture. Product leaders assume