Why building an IDP for Series A companies doesn't make sense

#devops #programming #cloud #startup

CTO of a Series A company? Before reading on, just give yourself a quick pat on the back. What you and your team have done so far is no easy task, so fair play to you.

Realistically though, the work is far from done. Many scaling and growth decisions lay ahead and probably more questions than clear convictions.

You might be tempted to preemptively adopt tooling and processes, positioning your engineering team for the potential growth to come. In this piece we’ll explain why you are more likely to succeed by doubling down on what brought you to this point over adopting new processes or fancy Internal Developer platforms.

Setting the right foundations

Series A companies are exciting environments to be in, usually a reasonable influx of new faces join the company, processes are increasingly standardised and overall, there is a progressive company-wide maturity that is starting to take hold. The instinct to mature the engineering org is understandable but nonetheless ill placed.

No level of maturity or sophisticated tooling can compensate for a lack of Product Market Fit (PMF). Validating PMF across markets should be top of mind at this stage above all else. Elusive as it may be, your best chance of achieving it is staying agile, delivering rapidly and maintaining tight feedback loops.

The idea of planning for future scalability might be appealing, especially with the buzz around platform engineering and the availability of ready-made internal developer platform (IDP) solutions. However, it’s crucial to understand why these options might not be the right choice for you right now. Let’s delve into the reasons why an IDP isn’t the change you think you need.

What is an IDP?

An IDP is a self-service layer build on top of your organisation’s infrastructure, that enables your developer teams to deploy and manage applications without the need to have in-depth infrastructure knowledge or relying on the help of traditional infrastructure engineers. It aims to provide consistency, automation, and speed by standardizing workflows and environments as the organization grows.

Think of an IDP as an internal product maintained by DevOps or Platform engineers, who essentially serve their own customer base, your development teams. To understand why adopting an IDP might be counterproductive for a Series A company, it’s essential to understand why IDPs emerged in the first place.

As companies expand, so do their engineering teams. In large enterprises, maintaining code quality, keeping up with infrastructure requirements and sustaining deployment velocity is hard if operations teams can’t keep up. IDPs were designed to remove reliance on traditional operations teams, to rely on a platform that actively evolves to fit their needs.

A few assumptions are important to point out here:

You have the resources to maintain a completely new product (the IDP). You probably don’t.

You have already scaled the engineering org and now need to optimise it. You probably haven’t and don’t need to.

What should Series A companies care about?

Before going on about the types of tools and processes your shouldn’t care about, let’s take a more proactive approach and focus on things that will actually move the needle.

The right team

You need a group of people who can run themselves, have the expertise to automate infrastructure related tasks and are open to working in flexible and not overly standardised structures. They should be the ones who propose changes and implement them as needed.

Finding and validating PMF

By the time you are at a Series A level you have surely caught the scent of where you might find PMF. Do not let up, ship fast and communicate intensely with your target audience to validate your market assumptions. There is no reward in finding a gap in the market alone, you have to occupy it. Maintain development velocity to increasingly occupy the gap you have identified.

Staying agile and flexible

The engineering team, like all teams within the company, should be unequivocally aligned with one primary objective: enabling the business. The engineering team sits at the centre of a short but tightly knit feedback loop which includes sales, feature ideation, feature development, deployment, and gathering feedback. Ideally, the sales team is working flat out, and customer service is maintaining close contact with customer. For the engineering team to keep it’s end of the bargain, it has to stay flexible and agile, ready to respond quickly the other teams inputs.

Focusing on customer facing products only

Even though we’ve mentioned this before, it’s important to emphasise that an IDP is a fully-fledged product that needs to be created, maintained, and evolved to meet the changing needs of internal developers over time. Focusing on an internal product like this can detract from the attention and resources needed for your customer-facing products, which ultimately bring you in closer contact with PMF and customer satisfaction.

Building the right culture

This is a point that should not be overlooked. Regardless of your company’s stage, evolution is always and ongoing dynamic. A culture of alignment, healthy communication principles, and a focus on shared goals is the bedrock that must serve as a base for the discussions about architecture, tooling, and process definitions which enable said evolution. Collective buy-in can only happen if a meaningful shared culture exists.

What should a Series A CTO not be thinking about?

It’s not un-common to hear people report having learned more from their bad managers than from their good ones. Why might that be? Because knowing what not to do can sometimes be more important the the opposite.

Don’t maintaining internal products

Any time spend not addressing requests from your product and sales teams and hopefully your customers is time wasted.

Any time spend that doesn’t involve delivering a better experience than your competitors is a mistake.

Avoid large engineering teams

Just because the rest of the company is growing doesn’t mean the engineering team has to expand at the same rate. Those who praise the magic that can be harnessed by keeping engineering teams small are on to something.

At this stage, as you may be bringing on your first DevOps engineers, ensure they integrate into a compact, developer-focused team with a single leader to avoid unnecessary managerial layers, allowing for open communication and quick decisions to be made.

Forget about perfection

It’s not news to you that shipping quickly and continuously improving over time is the best way to build a product that eventually wins market share and meets customer expectations. Why would scaling engineering teams be any different? Trying to implement an Internal Developer Platform too soon runs contrary to those principles. There will be a time when you will build one out but let that process happen iteratively in a gradual manner. You have others things to worry about in the meantime.

You are on the right track

Reaching a Series A funding round is not the end goal for anybody, you have a lot of room for growth. PMF is more than likely not locked down and occasional engineering bottlenecks should be dealt with on a case by case basis. Now is the time to double down on the strengths and keep on improving you capacity to identify your customer and increase user satisfaction.

There will be a time to look inwards and improve internal engineering processes, and IDP might make sense in the future, but at this moment in time your limited engineering output should be laser focused on staying lean.

Implementing internal products that don’t directly enable the business too soon have the potential for dire consequences. Approximately 35% of series A funded startups fail before Series B, a lot is at stake.

No need to worry though, you have made it this far, don’t give into platform engineering FOMO, put you head down and keep doing what you’ve been doing, because it’s working.