You don't need to be technical to lead your digital transformation

The question I was asked more than once

"But do you actually understand technology?"

I was asked that while leading the digitalization of processes at SINAES. I get it: my background is finance, not tech. The question makes sense.

My answer was always the same: I do not need to know how to code to lead a digital transformation. I need to understand the business, identify the opportunities, secure the resources, and create the conditions for the technical teams to do their best work.

That is not modesty. It is an exact description of what a good digital transformation leader does.

This article is for you if you run a company or a team and you feel that technology is someone else's territory. It is not. Digital leadership is not about code. It is about business decisions executed with modern tools.

What leading a digital transformation actually means

There is a common confusion: digital transformation is not the same as technology adoption.

Buying a new system is technology adoption. Transforming the way your team works, makes decisions, and delivers results using that system — that is digital transformation.

The distinction matters because it explains why so many technology projects fail. The tool gets purchased. Nothing actually transforms. The team keeps working the same way, now with one extra step: entering data into the new system.

What I did from a finance background

At SINAES I led several digitalization projects. Not from a technical role — from finance.

I coordinated a complete overhaul of the institutional website — UX/UI design and accessibility — working with the internal IT team and an external vendor. I implemented cloud backup protocols and cybersecurity measures for the financial systems. I built a document manager using Power Apps and Power Automate, including staff training. I transformed financial analysis and reporting with Power Query and Power BI.

Do I know how to code? No.

Did I understand exactly which business problem each project was solving? Yes. Completely.

That is what makes the difference.

The four roles of a leader in a digital transformation

1. Define the business problem

Not the technology solution. The problem.

"We need a new system" is not a business problem. It is a solution looking for a justification.

A business problem looks like this: "Financial statements are arriving ten days late because the consolidation process is manual and depends on three people working in separate spreadsheets. That prevents us from making budget decisions on time."

When you define the problem that way, every technology solution has a clear evaluation criterion. You do not choose the most modern system. You choose the one that solves that specific problem within your budget and timeline.

2. Secure the resources

Digital projects die for three reasons: not enough team time, not enough budget, or no executive decision-making when resistance appears.

All three are leadership problems, not technology problems.

Your role is to protect the project. That means:

• Securing the budget before you start, not along the way.
• Making sure key people have real, dedicated time assigned to the project — not "when they can."
• Being available to make decisions when the technical team reaches a fork in the road.

A digital transformation project without solid executive backing is not a project — it is an experiment that nobody will defend when things get hard.

3. Speak the technical team's language

You do not need to learn to code. You need to learn to ask the right questions.

The difference between a leader who frustrates the technical team and one who brings out the best in them comes down to the quality of their questions. The first set creates pressure without information. The second creates conversation with data.

4. Manage change with people

This is the most underestimated component and the one that kills the most projects.

The technical team can deliver a perfect system. If the team that is going to use it does not understand why it exists, does not trust it, or does not know how to operate it, the project fails.

Resistance to change is not irrational. It is a natural response to uncertainty. People resist because:

• They do not understand why the current process is not working.
• They feel the new tool is going to evaluate or replace them.
• No one involved them in the decision and they feel ignored.
• Training was insufficient or arrived too late.

Your job is to address each of those reasons before the system goes live — not after.

The five-step process for leading without a technical background

Step 1: Identify your most expensive process

Not the most visible one. The most costly — in time, errors, or delayed decisions.

Map how that process works today. Draw every step. Identify where the bottleneck is. Calculate how many person-hours it consumes per week and what the impact is when it fails.

That is your business case. No technology yet.

Step 2: Define the expected outcome before choosing the tool

What will be different when the project is complete? How much time will be saved? Which decision will you be able to make that you cannot make today?

If you cannot answer those questions with concrete numbers, the project is not ready to start.

Step 3: Involve the technical team in the diagnosis, not just the solution

Ask IT to understand the process before proposing technology. The best projects I have seen came from conversations between the process user and the technical person who would digitalize it — before anyone mentioned a specific tool.

Step 4: Communicate the "why" before the "what"

Before presenting the new system, explain the problem it solves. With real data. With the impact on the day-to-day work of the people affected.

"We are going to implement a document manager in Power Apps" communicates nothing. "Today it takes us four hours to find a contract. With this system it will take two minutes" communicates everything.

Step 5: Measure adoption, not just implementation

The project does not end when the system goes live. It ends when the team uses it consistently and without constant support.

Define adoption indicators: how many people used the system this week? How many documents were uploaded? How many requests were processed through the new channel? Without those numbers, you do not know whether the transformation happened or whether you just installed a system that nobody uses.

Are you facing a process that needs to be digitalized and you are not sure where to start? Schedule a diagnostic session and we will review it together — with a business lens, not a technology one.