Bringing Development In-House Requires Selling the Idea to Management

Table of Contents

Introduction

Hello.

When I think about modern software development, there are several things I believe software engineers should aim for:

• Build modular software that is easy to change.
• Write automated tests based on the test pyramid and continuously maintain quality through CI/CD.
• Adopt cloud-native architectures that can scale with usage and provide the availability the service needs.
• Minimize the communication overhead between business and development teams, creating an environment where they can make changes quickly and repeatedly test hypotheses.
• And so on.

I consider these ideas very important in modern software development.

Building software with high internal quality and establishing a development process that supports continuous improvement can increase the potential for future business growth. It helps us deliver value to users faster, prevent incidents, and recover quickly when incidents do happen. I believe creating that kind of environment is essential.

But when we try to make it happen within an organization, knowing what is technically sound is nowhere near enough. We also have to figure out how to sell its value to management.

It Is Difficult to Express the Value in Monetary Terms

The reason this is difficult is fairly clear: the value of the practices I mentioned lies in the potential for future business growth.

Making software easier to change can speed up future development. Adding automated tests can reduce the risk of changes. Bringing business and development teams closer together can increase the number of hypotheses they can test.

These ideas come up frequently at conferences focused on developer productivity and in discussions of Agile and Scrum. Markets change rapidly, so software development needs to support fast, repeated changes as well.

But when someone asks, “So how much more money will we make?” the explanation suddenly becomes much harder. I feel this is especially true for services that have already undergone substantial development and acquired users, or systems that have been running for many years.

When we propose a new development structure for those systems, the discussion tends to turn to questions like:

• “How much does development cost today?”
• “How much will it cost under the new structure?”
• “Which option is cheaper in the end?”

Of course, examining costs is important from a management perspective. But the discussion we really want to have goes beyond simply reducing development expenses. We want to decide what development capabilities the organization should possess as an investment in future business growth.

Outsourcing and In-House Development Cannot Be Compared on Cost Alone

I have long believed that companies should ideally build the capability to develop their own products in-house.

In Japan, I think the culture of outsourcing software development remains deeply rooted among companies whose primary business is outside the software industry.

Outsourcing itself is not inherently bad. For development that is not core to the business, using external partners can be a very reasonable choice.

However, arrangements built around contracts for delivering specified work tend to create strong incentives to “build what was agreed upon, within the agreed time and budget.”

As a result, I feel that internal quality, which should receive continuous investment, is often pushed aside.

When a company depends on outsourcing without having engineers of its own, it may also lack the ability to properly consider the non-functional requirements it should own or assess whether a vendor’s proposed design is appropriate. Development can then proceed with poor internal quality.

I have personally encountered code like this many times.

Code written with almost no attention to readability. Unused code that remains in the codebase indefinitely. Dependencies so tangled that merely determining the impact of a change takes substantial effort. Systems without automated tests, requiring manual testing after every change. Products that need improvements to increase profits, but whose poor internal quality has already robbed the team of the agility to make them.

My experience working with such code has convinced me that building an in-house development capability is extremely important for increasing the potential for future business growth. Companies need to adopt modern software development practices and establish a structure that lets them take control of development.

But there is a difficult issue here: the costs of what an external vendor has been building and what we intend to build in-house cover different things.

At one extreme, outsourcing fees may cover only the work needed to deliver visible functional requirements as quickly as possible.

Building a serious in-house development capability, on the other hand, involves many activities: automated testing, CI/CD, improving internal quality, setting up development environments, developing people’s skills, building domain knowledge, and cultivating a development culture.

Both may be called “development costs,” but what those costs include can be completely different.

If we compare only the amounts without explaining that difference, we end up hearing, “We brought development in-house, but it isn’t that much cheaper.”

Yet the work being done and the goals being pursued are different, so a simple price comparison cannot tell us which is better. In a sense, that is only natural.

One is the cost of building features. The other also includes an investment in the development capability needed to keep creating value in the future.

To properly account for the return on that investment in decision-making, we need to translate this distinction into terms that people outside engineering can understand.

What Engineers Want to Convey Differs from What Management Looks At

I think these ideas are relatively easy to communicate to engineers, product managers with engineering experience, department heads with similar backgrounds, and CTOs.

Software engineers generally share some understanding that ease of change matters, automated tests matter, and business and development teams should work together. That makes it easier to reach an understanding without discussing specific monetary amounts.

But when I take the same discussion to business leaders without engineering experience, marketing teams, or executives and board members without technical backgrounds, it suddenly feels much harder.

Of course, these are smart people, and they can often understand the general idea. But when it comes to making a management decision, the questions become:

• “Exactly how much will this cost?”
• “How much can we save?”
• “What will change as a result of this investment?”

From the perspective of management decision-making, that is understandable. Management is responsible for deciding where to allocate limited resources, so monetary considerations cannot ultimately be avoided.

That is precisely why engineers need to translate their reasoning appropriately to support sound decisions. We cannot simply explain what is technically correct. We have to explain how it affects the business.

I believe this is crucial to moving the organization toward the development structure we want.

Some Arguments Resonate with Management More Easily Than Others

In my conversations with management, security has been the easiest example to explain.

A cyberattack might expose personal information or take a service offline. Responding to an incident might tie up many employees. The company might lose trust, affecting future revenue as well.

These consequences are fairly easy for management to picture because the losses caused by security incidents are readily understood as business risks.

I also think developer productivity and infrastructure cost optimization are relatively easy to communicate. For example, we can use a tool such as Findy Team+ to continuously measure developer productivity, make development lead times and output visible, and see how much they improve. Or we can optimize infrastructure and measure the reduction in monthly running costs.

These discussions are close to measurable numbers, which makes them easier to explain.

On the other hand, statements such as “We will reduce communication overhead by having business and development work closely together,” “We will pursue product-led growth,” or “We will accelerate business growth by testing hypotheses faster” suddenly become much harder to convey.

In fact, I believe these are even more important. The fundamental value of changing the development structure lies in increasing the potential for future business growth.

But because this is an investment in future growth, it is difficult to express in concrete monetary terms. How important something is does not necessarily match how easy it is to explain.

We Need a “Sales Strategy” for Management

If I had to describe the ultimate goal in one sentence, it would be this: bring business and development teams closer together, speed up the process of testing hypotheses, and accelerate business growth.

But simply taking that statement to management rarely leads to a decision.

In a project I am currently involved in, we are therefore taking a gradual, bottom-up approach. First, we involve product managers and engineering managers and work through the details: how to explain the proposal, how many people the new structure needs, how much effort it will require, the specific costs, and what will change compared with the existing structure.

Next, we discuss it with the business leader and check which explanations make sense from the business perspective. Only then do we take it to management.

Seen this way, the work feels very much like sales. We are selling management on the value of the development structure we want to lead: how it benefits business operations and how it can maximize return on investment.

It is less about persuading everyone with a single presentation and more about involving stakeholders one by one, adapting the level of explanation to each audience, and gradually building support.

Changing an organization from the bottom up requires persistent communication with a wide range of people.

It also requires substantial preparation: documents, estimates, evidence behind the numbers, and well-organized technical explanations.

And we need to change our language depending on whom we are speaking to. Among engineers, “We want to make the software easier to change” may be enough. For management, we might explain it as, “Making the software easier to change will shorten the time it takes to bring new initiatives to market.”

“We want more automated tests” becomes “We can reduce the effort required to verify changes, increase release frequency, and lower the risk of incidents.”

“We want to improve internal quality” becomes “We can limit the growth in the cost of adding features and keep developing the product as the business grows.”

That is the translation we need to do.

Engineering Management Requires the Ability to Translate

Engineers are technical specialists, so unless we pay attention, we naturally speak in terms that other technical specialists understand.

But if we truly want to establish the kind of development we believe is right for the organization, that alone is insufficient. We need to understand what matters to our audience and translate our ideas into their language.

If management focuses on financial figures, explain how the proposal affects those figures. If a business leader focuses on revenue, explain how the development structure contributes to business growth. For product managers, explain it in terms of the speed of testing hypotheses and flexibility in executing initiatives. For engineers, go deeper into internal quality and the developer experience.

Even when we are explaining the same idea, the language needs to change depending on the audience and their responsibilities.

I am facing this very difficulty myself as I work to steer organizational decisions toward the structure I believe we should have.

At the same time, I am realizing just how necessary this work is. Without going this far, we cannot build the development structure we really want.

Writing good code is not enough to create good software. Knowing good development processes is not enough either.

When software development is part of running a business, we must secure the budget, people, and organizational structure required to make it happen. That means explaining the value to management, earning their support, and enabling them to make a decision.

From that perspective, engineering management seems to require some kind of sales strategy for gaining management support for the way we want to develop software.

Translate sound technical reasoning into language that the audience can use to make decisions. Involve stakeholders, build the supporting evidence, and explain it repeatedly.

I believe that making good software development possible requires treating all of this as part of engineering.