Software development in a non-SaaS organisation – taking your senior leadership team with you

It can be hard when you’re trying to drive digital transformation and colleagues think you (and your team) fix VBLOOKUPs. Being part of a small team responsible for digital products, when in-house software is not seen a business priority, can feel like a lonely place.  

So how do you bridge the gap in understanding often found between the software department and senior leaders and board members?  

Here are a few of the ways I’ve found that help. 

Start Small 

Sometimes you need to fix the VLOOKUP in that Excel sheet. Don’t be picky about the types of problems you can help with, especially If you’re just starting out. I understand you want to build a set of microservices to integrate all the company’s disparate business systems, or write a new mobile-first application instead of that cursed Access 2000 application that’s somehow still in use, but it’s important to start small. Gain credibility. Build relationships. Understand the pain points that users are encountering, as well as the wider business domain, to comprehend the real issues. This will enable you to address some low-hanging fruit. 

Understand business problems 

Too often I see developers rush in to build a solution that no one wants – we talk about ‘solving business problems through technology’, but chances are the business problems you’re trying to solve, won’t be by writing a new consumer facing app. My advice is look for where the manual processes are in the business. Create relationships with the key stakeholders and owners of those systems. Recommend ways to automate those processes, either through automation or low code solutions like Microsoft Power Platform, or even small (and I mean small!) APIs or microservices to integrate those systems. 

If you want to go big, get external help from a trusted partner who can work with you to speak in business domain language. This might be anything from finding a different way to say ‘API’, to spending the time working out the benefits to operational or capital expenditure your solution could provide.  

Find a hook for your agenda 

I once gave a catchy name to a difficult and unrealistic digital transformation project: ‘Global Data Portal’ – I’ve never liked the name (and still don’t), but it became popular. I used it to describe any idea that could improve data presentation for our customers, even if it wasn’t related to the project. This helped my team turn some ideas into beautiful products (that thankfully have better names).  

You can do the same by finding a simple and appealing name for your project that is not too technical (like ‘integration’, ‘data platform’, or ‘customer portal’). This will help everyone use the same language and understand the value of your project. 

Prioritise  

Now that you have a feel for the business problems, and found some hooks, make your priority list visible, visual and accessible to anyone that wants to see it. Make it clear what you’re working on, why, and most importantly, what you’re not working on.  

Find and agree a process for prioritising that isn’t ‘first past the post’ or ‘do whatever the loudest scariest person says’. Use research articles like this to explain the impact of context switching on cognitive load and developer productivity, and well documented capabilities like visualising work in the value stream to have the conversation around how you track work from request to production.  

Visualise technical debt if you need to, but ideally embed it as part of BAU and create an understanding with stakeholders that technical debt is something that’s constantly addressed.  

(While you can measure progress in your own way, it’s advisable to use industry best practices and maintain transparency. The image illustrates how the average shipping time for features in medical device software reduced from 60 to 10 days, increasing in consistency. This is crucial when lives could depend on it.)

Measure 

As with most projects, it’s crucial to measure and share your process. While there are numerous ways to gauge success, a good starting point is the DORA Quick Check tool, which allows you to compare your performance with other teams in your industry. Use resources like DORA and books like Accelerate, to adopt capabilities that enhance your agility and deliver more value frequently.  

Your senior stakeholders are concerned with speed of delivery of value to the customer. You can use many of these metrics as part of your narrative to the business explaining progress. Remember, the key is to select metrics that align with your business context and use them as indicators, not goals. 

Summary 

No matter what stage of leadership you’re at, you will need to use different tactics as you would for a SaaS orientated organisation. You will need to create closer relationships with people to understand the business domain, and then use that context to speak in the language your executives use.  

You will then need to visualise work in the value stream, and be transparent about your process and priorities, making sure that you can deploy work frequently whilst keeping change approvals as streamlined as possible. Lastly, you’ll need to find a measurement system that works for you to measure progress and celebrate success.  

Want to find out how we can work together to ensure software delivery is a priority for your business? Get in touch, I’d love to hear from you: mike.dent@waterstons.com