Many software teams struggle with ever growing cost of change, and technical debt that risks overwhelming them.
It’s always interesting to talk with folks and understand, how the system and incentives created this state.
Often I hear from software engineers that management doesn’t give them permission for (or doesn’t prioritise) work such as tidying, refactoring, testing, observability.
Blaming management in this way may be accurate in many situations (they are indeed probably accountable for the system that created this outcome). However, the problem with blame is that it tends to short-circuit further thinking. How could the system be improved with the influence and control you do have, perhaps with minimal authority.
But what about from the management side? I often hear from engineering and product managers that they’re unaware, or learn too late, that folks were accumulating debt. It becomes visible when teams are no longer able to achieve goals.
Management has a bad reputation in the tech community. I’ve been very fortunate to work almost exclusively with managers who genuinely care deeply about the people and teams they support; who want what’s best for them in the long term.
And yet, it’s still common, with the best of intentions, to create systems that result in unsustainable software development, and lots of technical debt.
How does this happen?
The risks are not very visible. If managers were given the option of twice as much this month, in exchange for nothing for the next 6 months, they probably wouldn’t take it (perverse incentives like annual bonuses notwithstanding). Would that it were so simple.
The decks are stacked against sustainability. It requires active effort from managers to combat the natural incentives.
Here’s three practical ways you can help as a manager.
Converse; don’t Coerce
Get Curious
People will always want more than you’re able to achieve. Meaning we’re often starting from a position of saying no to lots of things that are very valuable; it’s faster to identify opportunities than it is to win them.
Most people don’t want to give bad news. Most people don’t want to hear bad news.
This sets us up for miscommunication.
<Manager> we need to do X this week
<Maker> Ok [unsaid: I’m going to risk a production outage by skipping testing]
If sufficient trust exists then it’s possible the risk will be vocalised, but the manager has not invited this feedback. Nor have they provided enough information for the maker to form their own opinion on the merits of the risk.
It’s an instruction. There’s no curiosity as to what the impact or tradeoffs are, which shuts off thinking.
It encourages risks. Some might infer an unsaid “…whatever it takes”. This could lead to taking risks such as skipping normal safety, or working long hours
It’s informationless. It’s a blanket “we need”. It doesn’t say what the value or tolerable costs are. The recipient has no information to make good judgements themselves with.
Things get a little better with even the slightest bit of curiosity.
<Manager> can we do X this week?
<Maker> I think so [unsaid: cutting corners]
* next week *
<Manager> can we do Y this week?
<Maker> I think so [unsaid: that means they’ve decided not to clean up the debt from X]
At least the manager is now making it clear that there’s some degree of choice, although the power dynamic might make the choice seem illusionary.
It’s a closed question. The manager’s likely to get yes or no answers. They’re not showing curiosity about the consequences of the team making X or Y happen.
The manager is still asking the team to do things. Having to ask a team to do something is often a sign of a bug in the organisation. An organisational smell.
What’s stopping the team self-organising to the most important work? What information were the team missing to help them spot that X&Y were more important? What skills or perspectives are they missing to be able to make the best choices?
Use Open Questions
Things improve further if we ask open questions:
<Manager> what would we drop if we tried to do X this week?
<Maker> well we were planning on implementing the actions from last week’s post mortem, if we postponed those we might be able to do X.
or
<Manager> on a scale of 1-5, how risky would it be to release X this week?
<Maker> Hmm, probably a 4, we’d not have any time to test or do a canary deployment so we’d lose our usual safety nets
Here the manager has asked open questions, and solicited information that might help make better decisions. Even if the manager then asks the maker to do the same thing, the risks have at least been taken more intentionally.
Prefer information over instructions
What if we didn’t ask the team to do X at all?
<Manager> I’ve learned that we could close a $n deal if we can ship X this week.
<Maker> Hey that’s more than the total cost savings from what we were working on, let’s do X instead.
or
<Manager> I’ve learned that we could close a $n deal if we can ship X this week.
<Maker> Hmm, but if we rush we risk breaking the service. Last time this cost us $10*n
However, this is somewhat optimistic. Even with all the information, people often have recency bias and eagerness to please. The power dynamic between manager and maker often exacerbates this.
Incentives conspire to eliminate slack time that would be used to keep development sustainable.
Combining Curiosity and Information
<Manager> I’ve learned that we could close a $n deal if we can ship X this week.
<Maker> Hmm, that sounds like a lot, I can get it done
<Manager> How risky is it on a scale of 1-5?
<Maker> Probably a 1, we’ve still got time to test it carefully.
<Manager> What things are we dropping that we’d otherwise be doing?
<Maker> Oh we were going to refactor Y as changes in that area are slow
<Manager> Oh I thought Y was done months ago
<Maker> We shipped it months ago but have since noticed the design trips us up and we never have time to fix it with all these urgent opportunities.
<Manager> How much time has it cost us?
<Maker> More than it takes to ship X just this month
Here the manager and maker have built a much richer understanding of the situation and tradeoffs. They are much better placed to make a decision than if the maker had simply been asked to ship X.
Encourage Healthy Habits
Team habits can help people escape the trap of needing permission from unsupportive or oblivious management. You will probably be unsupportive or oblivious at some point. Unintentionally coercing people is so easy.
You can counter this by encouraging your team to adopt habits that will resist your efforts to coerce them into doing the wrong thing.
If your team practices TDD then you’d have to break a strong habit to encourage people to release a feature without tests.
If your team habitually drops everything to bring the build time down every time it creeps above 5 minutes, then they’re more likely to do the same even if you’ve asked them to deliver a feature.
If your team habitually prioritises work based on cost of delay, then they’ll likely ask you questions to find out the value before jumping on it. Even if you have omitted the information in your request.
Habits are hard to break. This can be a good thing. The right habits can add resistance to the forces that conspire to create creeping loss of sustainability.
Celebrate Sustainability
If you publicly appreciate internal improvements you will signal for more.
If your only questions about the work are inquiries about when it will be finished, you’ll incentivise unsustainable working.
If your promo process only recognises features and customer impact, you’ll discourage sustainability.
Do you celebrate with the team as much when they halve their deploy time, as when the ship that flagship feature?
Do you thank folks for taking extra days to refactor and clean up the code?
Do you ask “how much more could we simplify it?” or “when will we be done?”
Do you ask “what if tried doing less?” or “how can we do more?”