I’m in the midst of collecting the management myths into three books. The series is currently titled “Make Modern Management Easy”. The first book is Practical Ways to Manage Yourself. I was thinking of starting with managing the organization issues. The way organization attempt to “manage performance” and do/do not manage the project portfolio has […]
I listened to The Ultimate Metric: Identifying the Right Problems to Solve. The guest, Janelle Klein, said: Technical debt is not a loan I thought that was brilliant. She went on to explain that when we talk about “debt” managers think they have dials to manage the debt. Uh oh. Wrong. When managers think in
I’ve been thinking a lot about planning recently. Many of my clients want to create long-term plans, based on data with short validity, even for products in a high state of change. I suspect the first question is how much change do you need in your product, not how good your information is, or how
I’ve been working with several managers at organizations large and small, who want to capitalize their software “earlier.” These managers have some strongly-held beliefs about the people: People are resources Resources can multitask on several projects at a time If “headquarters” does the difficult work, you can move the “grunt” work to lower wage areas
Several recent clients want help with these problems: Estimation isn’t accurate. Because the estimation isn’t accurate, management can’t predict when they can release anything. Managers can’t manage the capitalization (a way to move from expensing software to capitalizing it). Teams can’t seem to ever deliver a finished feature. The work in progress everywhere is quite large.
I’m catching up on my podcasts and just listened to Seth Godin’s Akimbo episode about honest signals. (Do listen.) It’s about the signals we send that are honest or dishonest and why we might choose one, the other, or both. I started to think about the management signals we send, especially in an agile transformation.
I’ve been thinking about my clients who’ve had success moving from a project-based/resource-efficiency organization to a product-based/flow efficiency organization. They had these things in common: A senior person made it safe for the managers to create experiments. They created very small experiments (either managers or teams, or together). The senior manager often asked a question
How do we move from a project-based organization towards a product organization? There are at least two systems of work we need to change: The management system and the culture of management How the teams work and their team culture. I’m not sure it’s that simple to explain. There might be more systems I don’t
How could we organize if we want flow efficiency? We would reward managers by their span of service instead of control, part 3, stop organizing by function, and move to something that looks like a product-based organization? My transforming idea for this question was to think about the organization as legacy code. We understand how to
This series is about how you might move to a product-based organization. Part 1 was about how when we organize by function, the recognition and rewards might prevent a successful agile transformation. Part 2 was about one possibility for moving to a product-based organization. Before we get to who moves where, we need to consider the manager