Developer enablement – the role of planning

In a previous post, I wrote about: Why developer enablement is a crucial part of DevOps. One key takeaway from that post was that:

We want to structure our organisation in such a way that each team can take full responsibility for their deliverables. The team should own the entire life cycle: Planning, implementing, building, testing, deploying, monitoring and supporting.

Recently, I have been thinking a lot about the first part of the life cycle above: planning. In particular, I have contemplated why different companies have very different needs when it comes to planning.

Planning proportionally

In general, we plan before we do something because there is a cost associated with doing the wrong thing.

It’s not the end of the world if you forget to buy milk¹, so most people don’t spend that much time planning their grocery lists, but if your 20-storey-building-project fails you might bankrupt your company or someone might get hurt. Hence, it is understandable that some extra thought is required before you start the project.

The amount of planning we do should be proportional to the cost of failure.

The cost of software development

So what about software development? Is it costly to do the wrong thing?

I say: No!

When you do software development right, the cost of failure is low. But I would also say that if you do software development wrong, the cost of failure is very high.

The cost associated with software development is pretty much only related to labour cost.² Maybe you need a license for your IDE, an office chair, a computer and an ergonomic keyboard; but in relation to a developer’s salary all of these expenses are miniscule. Granted that your company’s main source of revenue comes from selling the software you develop, this implies that the best use of a developer’s time is to ship code to paying customers. All other activities that the developer partake in should aid the developer to achieve this. Furthermore, the highest priority for any non-developer in the organisation should either be related to selling the product or help the developer do their job.

As long as we deliver valuable software, money spent on labour will be money well spent, but the opposite is also true. Money spent on developing something that ultimately has no value to our customers is really costly and a poor use of resources.

What is valuable to our customers?

This is the million dollar question – literally. Somehow we need to figure out what our customers want. Luckily, there is a very simple solution to our problem: We can ask them! Unluckily, it is often difficult for a customer to describe their wants and needs in a way that is directly translatable to source code. This means there will likely be a bit of trial and error, before we get things right.³

Best case scenario, the developers simply talk to the customer, ask them what they want, implement a first iteration of their interpretation of the request and then show the customer what they’ve done. Together they iterate their way to a solution and the famous feedback loop is born. The quicker they iterate the sooner the feature will be implemented and the sooner the customer’s money ends up in our account.

How this relates to planning

Enter: Planning sessions attempting to predict the customers’ wants for the upcoming 3 months.

If the short feedback loop, where developers tightly integrate and communicate with the customers, is the desired way of working, why do so many companies force loads of processes and planning sessions down their developers’ throats? I believe many companies over estimate the cost associated with shipping the wrong thing. They believe that getting the feature perfect – the first time – should be their highest priority and that the customer will be mad (or even lost) if we fail to do so.

Unfortunately, many companies are right.

If we ship the wrong thing, receive negative feedback from the customer, and it takes a long time to ship an updated version of our software, the customer will be mad. Faced with this, many companies dig their feet down and it becomes more and more important to ensure every delivery is perfect, which naturally takes more time, which costs more money. With fewer releases and longer in between, the developers have fewer opportunities to touch base with the customer and understand their needs, so we better make sure every release is well planned out and packed to the brim with new (hopefully) valuable functionality.

But I believe that the opposite is also true. If we ship the wrong thing, receive feedback, and have an updated version of the software in the hands of the customer quickly they will be appreciative. A happy customer is a paying customer.

Instead of spending time planning and discussing what we think the customer wants to pay us for, let’s iteratively implement our way towards their needs together.

How this relates to developer enablement

Let’s summarise the developers’ role in the company:

1. Do your best to understand what the customer wants.
2. Modify the product accordingly.
3. Deliver the product to the customer.
4. Listen to the customer’s feedback.
5. goto 1

The job for the rest of the organisation is – as we discussed above – to ensure that the above steps go as smoothly as possible.

1. Maybe you have a sales department and a support organisation who do all the interaction with the customers. Does this hinder your developers from understanding the customers’ needs?
2. Do you impose inflexible architectural requirements on your devs, have long lead times to get developer resources and locked down systems that make development a pain?
3. Is your delivery process full of manual and error prone steps, making it difficult, scary and slow to distribute your product?

In order to maximise the amount of time our developers spend building revenue generating software, we need to minimise the amount of time they spend planning and struggling with processes. We must do everything we can to help our devs deliver the software to our customer, as this is the only way to learn whether we are doing the right thing.

Developer enablement must focus on removing hurdles and making it easier for developers to do their job. If you are not enabling your developers you are spending money on something that is not contributing to increasing your revenue.

---

1. OK… if you ask my wife, I might have forgotten to buy milk a few times too many and she is getting really annoyed with me; but that’s beside the point. ↩

2. If you need to make purchases in order to develop your software, this statement can start to fall apart. Maybe you need a HIL-rig mimicking a gearbox in a car, or a huge server for training ML models, costing several developer salaries… I hope you agree that even though cases like these exist, they are not recurring expenses for every feature. ↩

3. If we have a high cost associated with prototyping, having constantly changing requirements (or at least changing interpretations) will make it expensive to work in tight collaboration with the customer. We really need to make sure we’re not spending too much on something our customer will discard. Good thing source code is free and the only cost for producing it is the time spent hacking away at our keyboard. ↩