when relevant content is
added and updated.
John Cuttler just put up a common conversation on twitter. That is, the “no matter what you are wrong” conversation with management. John’s example starts with management asking what the problems are. The team takes time to create the three hundred tickets to address the technical problems. After a long delay, management says they can allow the team to spend 8% of their time to fix the issues.
The conversation death-spirals.
It’s a good thirty-second read; check it out for yourself.
This problem is so universal. It connects to my own experience — repeated experience. John says the “sad cycle” is “so predictable.” Jeff Kosciejew proclaims “I’ve worked at this company!” How is it possible the same terrible conversation has happened to all of us?
The conversations are so one-sided that they remind me of another pattern – the flip-flopping of position after a transfer. One day, someone is complaining along with me about how a rule is silly, makes no sense, and benefits no one. Two weeks later, after a promotion or transfer, they are telling me how we “need to follow the process.” I explain the issue fully and accurately using all my people skills, ending the sentence with “Does that make sense?” and the other person says “No, not really.”
When you see that kind of extreme change in behavior, something is going on. It could just be a new, scary boss with control issues. More likely, the incentives have changed. That is to say, what appeared to cost nothing to us (the line workers) suddenly has a cost for management.
My old mentor, Jerry Weinberg, was fond of saying that “things got the way they are for a reason.” Until we understand the reason and stop the cause, we’ll be doomed to repeat it.
Let’s talk about how things look to management.
The Management Perspective
Cutler mentions three hundred tickets that are about “cleaning up” code. Without the cleanup, forward progress will slow down. The more shortcuts we make today, the slower tomorrow will go. For the most part, these decisions are invisible to management. They do not represent a “feature” to the product owner. While a rare team can communicate what cleanup will do in terms of reducing regression-test cost, that is not what we are talking about today.
Those cleanup tickets represent the certain knowledge that the team will go slower, without any clear benefit. The team is basically asking “Can we please go slower?”
What rational manager would say yes?
What does it buy them?
Until you can answer that question, expect the answer to always be “no.”
It always amazes me when teams ask for time to fix things.
The first step is simple: Stop making new mistakes. Begin review of new code. Learn about refactoring and patterns. The team can do this in its discretionary time, and no one needs permission for it. If you can’t find a way to make that happen, just start mob programming, together, on a problem a few hours a week. Use that time to share keyboard tricks. This will force the team to standardize on coding style.
After that, clean the codebase as you work on it, and fix or automate bits of code the cause work-problems. The big projects, the CI CD projects, might need to be funded by a product owner, but they are easy to make a case for.
The case works like this: Unless we build this pipeline, expect development to continue to slow – and predict by how much.
Six months later, when management asks “Why aren’t we getting anything done?” you pull out the email. There’s your answer. Now can we fund that Continuous Delivery pipeline project?
Back to John’s story
Many of the examples in John’s story above seem “injected” by senior leadership. Feature bloat, Multi-tasking, “specials” and “Silver bullets.” Swamped shared resources. Extra time onboarding new hires. Unplanned work, fragile environments.
It might not be possible to fight all of these things. What you can do, however, is explain the consequences of the decisions. Here’s an example: “Yes, we could do these two projects at once. They are both estimated at three months. If we do them both together the best case is we get them done at about six months. Wouldn’t you prefer to have the higher-priority one done in about three?”
I submit in software we do a terrible job at this, then whine that those bosses just don’t get it.
What would happen if we focused on ways to explain these consequences and better defend out boundaries?
This blog post just doesn’t have enough real examples, so let me play doctor. Pick any example from John’s post in the first paragraph. Pretend to be a leader or manager “injecting” the dysfunction on the team. Leave a comment. I’ll role-play how to respond.
Maybe you’ll stump me. Some days, the system wins.
It doesn’t have to be every day.