What your manager says Vs. what they mean.

Software development: may the odds be ever in your favour.

The management team are struggling, they can’t get their development teams to deliver in the way that the business needs. They can’t seem to know how to get into the problem to get it solved. They’re getting pain from their management team, and we all know what rolls downhill.

The development teams are working hard, have the management team on their case and aren’t getting any credit for any of the good stuff that they are doing. They don’t understand why no one can see all the work that they are doing, and just getting grief for the stuff that isn’t happening.

Both sides are a bit miserable but desperate to find a way forward. They will hear grumbles on the rumour mill and obviously react to this.

I’d suggest we can sort this quickly with a fresh round of The Hunger Games, but apparently it’s “not a good way to solve problems” (thanks for the ‘attitude realignment’ from my line manager. Appreciated).

If we can’t battle it out, then maybe we talk it out.

Management says: Why is there technical debt? Why was it rubbish in the first place?

What is really happening: If any solution has a solid life span, then it has a technical debt. If it is raced out and not done in the way that is ideal, it has technical debt. If a solution is not re-engineered to handle system extensions and has large areas bolted on, it’s got technical debt. Time is needed to give your solution a longer life.

It will need updates, it will need time to engineer how it should be architected, it will need changes to be planned properly.

What you need to do is explain the benefits of working through technical debt and the risks of not being able to. Whether you explain this in terms of business benefits or what resource will be gained off the back of the work, that’s up to you and your business.

?

Management says: You did a proof of concept and now it’s rolled out, it just doesn’t work

What is really happening: It was a proof of concept, it did its job. Everyone saw it and everyone wanted it. Then you were told to put it into production. It was never intended for live use.

You have two options here:

Option A - You need to explain that POC are never designed for production use and purely made for exploration of a concept. You get time and resource to rewrite it for its intended use.

Option B – If this happens again, never write a POC under the illusion that it is going anywhere other than production. Spend the time and do it as if it’s going into production whenever you’re asked to bash something together.

?

?

Management says: What do you mean we have a toxic culture?!? There’s no barbed wire on the walls.

What is really happening: It’s possible they don’t care if you leave. It’s also possible that they don’t think that you’ll get anything better elsewhere so are happy to push you to your limit. Try once, explain once. Hope for change or at least someone taking it seriously. Then do your CV.

?

Management says: Projects go on forever and never close down.

What is really happening: Ahhhh, zombie projects.

The project starts and you know what you’re delivering, then scope changes, let’s be honest, it never reduces. It gets tested, more changes, repeat. You need better stakeholder management. Better business analysis or clear boundaries about the time dedicated to the project.

?

Management says: Why is everything full of bugs?

What is really happening: Bugs will happen, and all software will have bugs - especially when its new. You’ve got your team doing what they can.

There are a few things that you can look at here:

1.???? Is your manager hearing unfair feedback? Maybe there have been a few bugs but is the rhetoric aligning with the truth? Are you making an effort to make sure that communication on issues, resolutions and successes being heard by the business?

2.???? Are people not feeding back about issues? Get some communication out there about how to report issues.

3.???? Are there a lot of bugs? Can you look into what areas the issues are in the solution? Look for patterns (called defect clustering) and spend some time hardening that part of the solution and seriously look into introducing some automated testing.

4.???? Do they have enough time to handle their current workload and what is needed here? Track what time they are spending here and what is expected to see where you need to spend efforts.

5.???? Look into how fast issues are being reported and how fast your team is resolving them (good old DORA metrics). Is the time that is taken to resolve them longer than is reasonable?

Management says: What are your team actually working on at the moment? Are they just doing BAU?

What is really happening: This is a reflection of bad communication. Management has a responsibility to know what you’re working on, and you have a responsibility to champion the work of your team.

Go on the offensive; start singing the praises of the work that your team has done. Track how much ‘business as usual’ they are doing and make good news stories out of it.

You might not feel like tracking all the work done is going to be a useful exercise, but if you can’t quantify how much work your team is doing then how can you justify when you need a new resource?

Yearly updates, shoutouts for the team, monthly reports. Make it happen.

?

Management says: Why aren’t you doing new stuff?

What is really happening: They’ve been out; they’ve read, heard or learned about something that’s newer and working for other teams. They’ve brought it back like it’s a great opportunity and you’re not interested. I know that you care and they want you to care… but it doesn’t seem like you care. Not even a bit.

Explain your struggles, explain that you are interested, explain what you want to do to make the space to make this happen.

?

Management says: The team can’t pivot.

What is really happening: They are asking for changes or for new things. You’re either not engaging with their requests, sick of changing priorities, or so absolutely inundated that you can’t even consider them. It's really hard for management to not get any appetite from you to consider new requests. Maybe they are interested in agile and you can really get some changes in responsiveness, but that can mean a large change in culture is needed too

?

Management says: Why has the software only got half the features that we need? This isn’t going to work

What is really happening: The good old project management triangle. I want all the scope, in the timeline I want, with no more resource and at a high quality. Something had to give somewhere, and scope is the best one to crop. You don’t want everything done poorly, you don’t have the budget for more staff and the deadline wasn’t budging. ??

The main defence to this is to be very clear on the scope that is being cut. Make sure that this is clear across all the interested parties. No surprises. And if they aren’t happy when the communication comes out, then they need to flex on one of the other elements.

Sounds rough

This isn’t an exercise in nagging, it’s an exercise in perspective. If both managers and development teams try to see the world from each others’ view point then you can work together.

Can you work better? Of course you can, everyone everywhere can. But where should efforts be concentrated? Look at what is the loudest thing being shouted and measure how you are performing now, then look at how you can make the smallest steps forward to making it better.

Have a think. Get in touch! Emails to [email protected] and carrier pigeons to the Waterstons office in Durham.