Disclaimer: This is not a tech blog or something to ‘copy and paste’ into a Confluence page. There may even be some mild attempts at humor. I’ve been involved in helping people purchase Enterprise software solutions for the last 10 years and I’m sharing my experience here for anyone who is new to trying to implement change from the ground level. Most software engineers have a tendency to stay in their comfort zone (demos, PoC’s, Infosec requirements) for as long as possible and assume that the business discussion comes at the very end. If you have ever uttered the words, ‘Let’s just get through the PoC first and then we’ll worry about the commercial discussion’, then this blog is for you.

IDP’s are a hot topic at the moment. With the increase in complexity around applications, environments and services, the job of a Devops/Platform/Infrastructure Engineer is simply becoming more demanding and tedious. This isn’t just an engineering efficiency problem, it’s a developer experience problem. And this means it’s a developer churn problem. If you’re scaling, you’ll probably be seeing that good CI/CD practice is not enough anymore. In fact, it can have an unintended, negative impact. It’s the ‘continuous’ part of CI/CD that makes keeping up with changes so challenging and unscalable. Manually updated content (spreadsheets, Confluence etc) are no longer an option in this environment.

Unfortunately, there’s no end in sight to this. There is no completion to this wave. It’s only going to grow more complex and the job just gets harder. And with every developer’s ‘fingers in the dam’, it leaves little time and space to ensure an efficient and thorough management of the engineering standards to maintain such a mess.

Maybe not everyone is for people management and that’s OK. It’s possible the world would be a better place if more people had this self-awareness before rushing into leadership roles. But who doesn’t like things like ‘benefit of the doubt’, freedom, autonomy, a pay rise even?! It took me a long time in my own career to realize (or admit) this but how we are perceived within our organization has a direct impact on our satisfaction and even happiness.

‍

In this blog, I’m focusing on IDP’s in particular but the approach can be used for any tooling you might wish to see implemented within your engineering org. Let’s use the framework of that effectual individual we spoke of earlier to look at how to affect change within your org (and maybe even earn some of that lovely leverage while you’re at it!):

‍

1: Recognize a critical gap

Gaps can be easy to spot if you have moved jobs from somewhere with a higher standard of engineering. But if you’ve already been there for a long time, you’ve just graduated or you’ve come from somewhere with a similar level, then it’s not always easy to recognise if there's an actual technology gap, as opposed to a general ‘pain in the ass’. Here’s a pointer: if colleagues are regularly complaining about an inefficiency within their role, there’s a good chance there is a technology gap. How do I know there’s a solution for this on the market? Because there’s a solution for everything these days. The start-up community has never been more vibrant and it’s where you’ll typically find the world’s best tech talent. These are people you want to be engaged with.

If you’ve opened this article, you already know what an Internal Developer Portal does. But there is a big difference between ‘knowing’ and ‘articulating’ this to leadership. I’d strongly recommend reading this Ultimate Guide to IDP’s white-paper that will bring you up to speed in this space. It contains a section listing the problems an IDP solves and you can reverse engineer this to how it affects your own org.

2: Suggest an alternative solution with research and facts to back up your opinion

If you like, you can choose to include your leadership in a search for vendors. Be prepared that this will diminish your chances of seeing this through though as impetus will run out on their side with BAU tasks. Your best bet is to do this yourself and take full responsibility until a solution is ready to be spoon fed to your management. This will also reflect a lot better on you.

And if this appears somewhat sycophantic, it’s not the intention. From my own experience, one of the biggest blockers to affecting change is the sentence, ‘but we shouldn’t have to’. Sometimes if we want to make changes from an ‘Individual Contributor’ position, we need to play the politics game, just a little. This might mean looking at what is important to those who hold a budget.

With IDP’s (and most engineering software) you’re essentially looking at 3 options: 

• DIY
• Open-source
• Proprietary

DIY

If resources allow, constructing an IDP from the ground up offers unmatched customizability. However, this route is resource-intensive and takes substantial time to bear fruit. If you have the engineering power and the time (a few years), this is an option but most of the market don’t have this.

Open-source

Open-source is where an engineer’s heart tells them to go. Built for technologists, by technologists. And it’s free!

When you go to research Internal Developer Portals, you’ll be led in the direction of the likes of Gimlet and Backstage which will look good for round 1 of your research. With a good service catalog and integrated documentation, it may fit the bill (did I mention it’s free?). By the time you’ve got to Reddit for round 2 to see what Backstage users have to say, you may not be so sweet on the idea. You’ll read commentary around ‘out of date’ documentation, portability issues (for example if you are on Mac m2 instead of linux etc), requirements to set up your own environment and others. As my old mate Otto Von Bismarck said,

“Only a fool learns from his own mistakes. The wise man learns from the mistakes of others!”

When something is free, you can always get your case across. Why? Nobody cares. It doesn’t affect anyone’s budget. No painful conversations with procurement or finance, no business cases for VP’s Engineering, just download it and go. It sounds so easy. The only problem is: Nobody cares. If there is no investment, there will be no effort. The act of contributing towards the deployment of a tool that will not benefit their immediate OKR’s would be seen as nothing but a philanthropic effort. And if there is no spend, there is no spot-light from upper management to ensure its success. Simply put, there is no skin in the game and it’s doomed to failure. 

I spoke to an engineering leader a couple of days ago who’s team had implemented Backstage some years ago. When I asked him what they thought of it, he simply replied, “It’s just there. No one uses it.” When pressed, he readily acknowledged that it could have been of benefit but because they were scaling, they could never dedicate the time to making it work. And now, having gone through a hyper-growth period, the problems that led them to deciding they needed an IDP in the first place, are ten-fold.

Of course, this is not to say that the open-source route is an open and closed case. If you can make the case for man-hours to develop this properly and see it to its full value, you might just get the Service Catalog you’ve always dreamed of. But if this is the case, leadership is required to step in. And you’ll need to make an even more aggressive business case for the return of engineering man-hours required to set up and maintain the solution. Why does it need to be more ‘aggressive’? Because it’s more expensive, far more expensive. 

Wasn’t that the whole reason you wanted to avoid proprietary? The need for a business case and the expense?

Proprietary

So if you’re not going with open-source, then you’re going to have to speak to a sales person pushing something down your throat, make the case to finance (or make the case to give to your boss to bring to finance) and all the other politics and BS involved in ‘getting anything changed around here’. It can simply seem like too big a task to even begin. It might make you long for the idea of developing plug-ins in node JS with Backstage.

But if you’re lucky, you might actually find a useful vendor that could help you with this. Don’t get me wrong, the majority will still choose to ram their product home, ‘handle’ every objection, and ask you about your weekend in an over-familiar tone. The game is changing though and any successful SaaS sales org will know that the best way to win business is to provide value from first engagement, right the way through the vendor/customer relationship. 

A few tips when exploring technology vendors:

• You’ll get pitched at and sometimes this is OK. Just because you're dealing with a sales person with poor communication skills, doesn’t mean that the product is not up to scratch. Push forward and if they offer no value, you’ll be brought in touch with a more technical Solutions Engineer, who you can normally choose to deal with for the validation of the product if the salesperson is too irritating. 
• Look out for good sales people. That’s a thing? Yes. They are the ones that are looking for red flags from the first conversation and they often sound more reluctant to move things forward. They may also want to ask some direct questions about budget timelines and purchasing processes. You may not know the answers to these but don’t be afraid that they are jumping the gun. They are sales people who have seen enough deals fall through for them to realize that there are a lot of reasons why a deal may go south, other than simply failing a technical Proof of Concept. They are trying to protect their own time but also by extension, your own.
• See what you can get out of these guys if you find them. A lot of the time, they’ll have templates for internal business cases (document explaining the value of proposed product) or at the least the means, content and expertise to make one for you. Yes, this is just a tool to help them close deals, but if it helps you get what you need and you can impress your boss at the same time, who cares!
• Align your goals with the salespersons (or Account Executives as they are usually known in the SaaS business). Make peace with the fact that they are trying to sell you something. As long as they can help you prove value (which with an IDP should bring you 10X the value of whatever you’ll be paying the vendor), then their personal interests should not be a concern to you.
• Don’t get frustrated if you can’t speak to a technical person straight away or if you can’t get a free trial without speaking with someone first. There is a cost to all of this for the vendor and in a world of bots and tire-kickers, they need to have a first line of qualification and this should be respected. You wouldn’t push to go to a medical specialist without first being referred by your GP and this is no different.
• Be prepared to say ‘no’. It’s an easy word, just 2 letters. I’m from a country that hates saying the word ‘no’ to people and I had to learn this myself. It’s easy when you get used to it. Salespeople are used to it and deal with it every day. And if they are chasing you because you have been ghosting them for fear of avoiding the dreaded ‘no’, then this is on you, not them. Do as Nancy Reagan says.

3: Validate and build a business case

If you're smart, you’ll push this back on the vendor. They will have all of the content and expertise to position the solution as well as possible and it’s in their interest to do so. They’ll be happy to white-label this for you and you can take the credit.

You’ll likely perform a Proof of Concept and you should be really careful when selecting your success criteria for measuring the success of a PoC.

The most critical thing to remember is that there is a budget-holder or top approver in place and the decision will ultimately lie with them. You need to make this person aware of the PoC and make sure that there is a path to them signing off on this. All of this has to be done before you begin any PoC, otherwise you are risking a massive waste of time on all sides.

The budget-holder will always be concerned about costs but if there is a water-tight business case for saving engineering man-hours, this is how to make your case. You may not care about it, they may even not care about it, but this is what’s required to get through finance. It’s a cold fact of life but whatever you purchase, you have to be able to show a financial return (or man-hour return which can be converted into financial return). Finance does not care about things like engineering churn or developer experience and you shouldn’t hate them for it. It’s not their job. If you want to convince stakeholders, you have to play the game and if you’re going to play the game, these are the rules.

When starting the PoC, you should set it up with success criteria and a method of measuring those success criteria which effectively make the business case itself. If you do this properly, it will be a fact-based business case with evidence. These are hard to argue against, even from finance as you are using their own tool to beat them.