Solving intricate technical problems and building elegant solutions is why many of us fell in love with software delivery. But those in charge of planning do not often share this affection in the same way. So if you want to make dramatic improvements, you’re better off forgetting the technology and focussing on the benefits.
I recently attended my first CITCON. For people not familiar with this group, they run open format conferences for enthusiasts of continuous delivery. There they discuss practices of automating and technically improving software delivery. Among other things, their passions include automated inspections, continuous integration, automated deployment and continuous testing.
While there I met many talented people dedicated to increasing the speed of software delivery and improving quality while they did it. But over the course of two days I was left with the perception that some great work is being done, but a lot more could be achieved.
In particular we talked about far-reaching improvements that had been made to automated build, deployment processes, refactoring code and test artifacts. But the greatest challenge was justifying to management why spending more time on these very technical activities was a good idea.
I began asking the same questions in each conversation:
- What do you tell your boss you want to do?
- What type of boss do you work for?
- What is your boss’s boss expecting of your boss?
- How much time would it take to get a measurable benefit?
It appeared that pushing technical change, or explaining technical strategies to bosses, just wasn’t working.
I suggested a different track.
Think about your boss’s pain points. Speak in language your boss understands. Stay out of the detail. Understand that simple adjustments can have surprising benefits. Use these to showcase your ideas.
So the conversation with your boss should go more like this: “I understand you need to speed up delivery. The last release was a nightmare. But I can help improve the process and quality. Can you give me half a day to show you how I can save twenty minutes/two days/two weeks (insert your context here) every time we build a release.”
It is rare of course for relationships and environments to be simple, and getting started requires investment; the right solution might cost some real dollars, and people are suspicious of things that cost.
But regardless of the situation, basic planning on how you are going to ask for investment can really help. Set out the pain points, set out the benefits and estimate the required effort. If you want to spend your boss’s money, you’d better ask in the right way.
I work in a consultancy influencing people to make sensible choices every day. There are trade offs, but you speak to different people at different levels and try to quickly understand the customer’s needs.
CITCON was an enjoyable experience, and I expect the ideas will become more and more mainstream until they become the default way build and deliver software. It is worth taking the time to sell these ideas, or your organisation will fall behind.
And it’s also worth attending the next CITCON.
I’ll see you there.
You can find out more at https://citconf.com