Build it and they will come. That’s the idea, right? But you may have realised, perhaps through a process of failure (we hope not), that that’s not a reliable way to guarantee an audience.
This is how it’s likely to go down - your organization needs to evolve, so the platform team is tasked with building an IDP (internal developer platform) that will streamline, optimize, and rationalize your software development process. But wouldn’t it be great if you could guarantee a successful platform before you went to the effort? Of course, it’s possible that you’ve already gone to that effort, and are now sitting there, wondering why no one is using the platform your team worked so long and so hard to build. But let’s hope that you’re actually at the starting line asking some hard questions, and not at the finish line, wondering why you didn’t.
All parts of your developer self-service platform have a role to play in promoting the usability of the platform itself, but not all of them play the same role at the same point. Let’s look at them one at a time.
Automation - Once your users see how much easier automation can make their jobs, they’ll be queuing up to use the tool, but it requires a certain level of trust to make the first move. Automation will be a decisive pull factor, but it will come later. There are other, more important factors for getting the ball rolling in the right direction.
Self-service - a truly self-service platform will help hugely when it comes to people choosing to use it. Being able to self-serve and not rely on others for help and permission gives people a big dose of confidence and levels up productivity, which in turn does wonders for DevEx. That’s not to say your platform should be a free for all. There are limitations and restrictions. The difference is that they’re pre-determined with skill and built-in so they’re practically unnoticeable.
The platform - the actual platform your users will be interacting with is the real make-or-break aspect of the plan. It’s also the part that can cost the most (in time, money and effort), and the part that underlies our other assumptions - the internal platform will revolutionize the ability to self-serve and the potential for really nifty automation, but only if you get it right and people will use it. So focus all your attention here - it’s a tall order, and it’s easy to get wrong.
If we had to boil this article down to one piece of advice for the creation of your internal developer platform, it would be to: focus on the DevEx. With the growth of platform engineering, hybrid cloud, and automation, it’s easy to get caught up with some pretty ambitious objectives, but the only one that matters when it comes to an IDP is quite simple - the dev is your end customer. Max out the DevEx and the users (and evolution) will follow.
Max out the DevEx - focus on making your IDP the best environment for your end customers (the development team) to do great work and have a great time doing it. To do this, especially if platform engineering is a new concept in your organization, you need to make sure that the people around and above you understand that the devs are your end customers, not the product. If you’re struggling to see how you can do this and also remain accountable to your executive team, take a look at this article. It will show you how to create KPIs that truly reflect what you should be held responsible for.
Build for purpose - this one is a no-brainer, but when there are a lot of spoons in the pot, it can get lost in a mire of opinions, inheritances, and ill-advised professional interests. How so? The idea of an IDP probably isn’t new. There may be traces of previous plans, tools that were trialled, and ideas that were considered and discarded, some or all of which may resurface during the planning of the new platform. Don’t let strong opinions or easy options knock you off course - your IDP needs to be perfectly aligned with the needs of your current team, for the challenges of today (and tomorrow).
Employ professionals of usability - if you were building a product for an external audience, you wouldn’t even consider unleashing a tool that had no usability auditing built in - so why would you unleash such a beast on your team? Make sure UX plays a central role in the development process or ensure that your 3rd party tool has a rock-solid UX foundation. No, Cycloid’s UX team didn’t pay me to add that, but I’ll be sure to draw their attention to my complimentary words!
Lessen the donkey work and remove complexity - we’ve already mentioned automation and how it comes later in the process to win fans and admiration, but that won’t happen spontaneously. Make sure the intention to lessen repetitive, boring, but necessary work is a central part of your platform. Taking full advantage of IAC will ensure you’re in a great position to use ready-built tools to take on some of this burden, like Cycloid’s Quota Management, which does what it says on the tin, or Stacks and Stackforms, which simplify the process of creating new environments, and Cloud Carbon Footprint, which allows true sustainability of both energy and spending without your devs having to always keep one eye on the bottom line.
Make it truly self-service - this is another point we’ve covered, but it should be of primary concern, especially as it can be difficult to ensure when you’re DIYing your tool - you need to make it truly self-service. If you don’t, you’ll miss a huge proportion of the objective - and the ability to hook your audience. The problem here is that although most people acknowledge that self-service is a great thing, it’s actually pretty hard to provide through entirely internal development - or at least, requires a lot more work. By outsourcing some of the development process to a 3rd party tool, you can focus on the specifics of your business, while entrusting the bells and whistles to people whose only job is to make your people’s lives easier.
Sustainability is a drum we beat long and hard around these parts. The world is changing, and on multiple fronts, it's no longer feasible to allow a culture of excess to thrive in your organization. But by "excess", we're not talking about generous employee benefits or even a no-limits funding buffet. We're talking about a company-wide tendency to spend too much (time, effort, money) on things that just aren't returning the investment or, worse, actually damaging to the future of the business, human capital, or environment.
One of the primary things that the development of an IDP absorbs is time. It's a recurring topic, and one that we tend to find clients aren't really aware of. That's why we have developed an IDP timeline, to show people exactly how long it takes to bring a self-service portal to life.
Take a look...
That's why, on average, it takes a whopping 3 years for platform engineering to be able to show a positive impact on the business.
Why should you care? Your IDP will be no exception. It will take a long time to build - even more if you decide to DIY it. Add that to the other sponges - money invested, the tendency to over-engineer, the people-power required - and people actually using the portal you built becomes an absolute imperative.
If you manage to make your IDP in a rational, optimized manner - congratulations! Now you must see if your devs are interested in using it. If they are, your IDP's impact will be felt far and wide. If they're not, it will be - by definition - an abject failure. No one will use it and it will make zero impact. So building an IDP isn't one big ask, it's two. And it's an intimidating prospect. We hope you're ready for the challenge. We are - and if you'd like a little help, all you have to do is ask.
This article is part of a larger series on sustainable platform engineering. Check below to see what you've missed - we'll add them as they go online.