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 refactor legacy code. It takes a while, and then, weeks or months later, we have code that is much more robust and allows us to move faster.
When refactoring code, we start as small as possible. Change things as small/fast as possible.
Managers and organization design aren’t code. Is it possible to consider refactoring before we change everything?
Thinking about Refactoring
If you’ve ever taken over someone’s code, you spent a lot of time reading it. (Well, I did.) Even before I knew about agile approaches, I spent a bunch of time creating unit tests and system tests so I could know that as I fixed/added/replaced code, I hadn’t introduced any problems.
Tests are small safe-to-fail experiments. In code, I can see running, tested features. Code is deterministic. (Well, my code was.)
People are not deterministic. (Thank goodness!) People have emotions. They might will react in ways we don’t expect.
When I think about refactoring code, I think of these techniques to manage the process of getting to cleaner code:
- Work with others to test/explain/uncover assumptions in the code. (Work in public.)
- Work small. The smaller the area of change, the easier it is to refactor.
- As I work, add tests to verify I’ve changed the code in a way that makes sense. I don’t want to have to recover the changes.
As I refactored and added more code, I worked in these ways to create cleaner code:
- Create habits that allow me to write clean code.
- Create leading indicators so I know I’m doing the “right” thing, or at least the right thing as I know it now.
- Write small chunks, test it as I proceed, and check it in.
- Keep the code clean.
If you’re wondering, this is how I write books.
Refactor Management?
If we think about “refactoring management,” how can we work in public, make small changes and verify we’ve done something reasonable?
To me, this is about creating small, safe-to-fail experiments.
We can and should expect mistakes. People aren’t perfect and they are not deterministic. If we can expect and forgive mistakes, we can make it safe to work in public, make small changes, and verify we’ve done something reasonable. That culture helps managers learn how to serve the people and the products.
I wonder if the first thing we do is to create safety for managers who serve by running experiments that expose their vulnerabilities. For me, this is about changing the reward system for managers so their pay doesn’t depend on them acting in the same way as they always have.
Can we reward managers with normal pay, no bonuses? If we do have to create a bonus, can that bonus be tied to flow efficiency and collaboration to release products faster? (For me, quality is built into speed. The cleaner the code is, the easier it is to go fast.)
As a senior manager fights for reasonable pay, the managers and the teams can collaborate to create some leading indicators or tests that they can assess every day:
- Reduce the need for a single person to make decisions. Identify the decisions one person makes, regardless of whether that person is an architect, a manager, or a project portfolio manager. How can we note if a single person decides on anything? Maybe ask the team and the manager to report on the number of times they make decisions alone. We want to reduce that number.
- Reduce management decision lag time. How can managers learn if their decisions are correct if the time to make decisions is so long?
- Possibly “measure” the amount of learning for the team and the manager. (I don’t know yet how to measure this. This might be how many times we mob/pair. It might be Communities of Practice, or a lunch-and-learn. Right now, this is an easily game-able measure.
- Possibly measure the number of times team members need coaching in how to offer/receive feedback and coaching. Agile/product teams need the leadership skills embedded inside the team so the managers don’t get trapped into controlling actions.)
This is my first draft, my safe-to-fail experiment. There are other measures that might work better.
Product Organizations Require Behavior Changes
I’m talking about changing the behavior and culture of the organization. This is not something you can do as part of a two-day class, or as part of a “change initiative.”
One of the largest behavior changes is the need for collaboration at all levels of the organization. Teams collaborate together. Managers collaborate together, for the good of the teams, for the managers’ decision-making, for the product decisions, and to manage the project portfolio.
Notice that I didn’t say to reorganize everything. We don’t even know the hypotheses to create yet. More on that in the next post.
Here are the posts in this series:
- Project Work vs. Product Work (I didn’t realize I’d started this series.)
- Product Orientation Requires Technical Excellence
- Designing an Organization for a Product Approach, Part 1
- Designing an Organization for a Product Approach, Part 2
- Defining the Manager’s Role for a Product Approach, Part 3
I’ll update the other posts with all the links as I complete the series.
| Published on Java Code Geeks with permission by Johanna Rothman , partner at our JCG program. See the original article here: Possible Changes for a Product Approach, Part 4 Opinions expressed by Java Code Geeks contributors are their own. |
