A technology decision can look perfect on an architecture diagram and still become a financial burden for the business.
That is why Mario Fedato believes every technology conversation should begin with the business, not the platform.
During a recent conversation on The Executive Outlook, he shared a career journey that began with curiosity and eventually developed into a practical approach to CTO as a service, cloud infrastructure, business growth, and technology leadership.
He was thirteen years old when his father brought a computer home. A technician installed it, but by the following morning, Mario had already taken the machine apart and started rebuilding it.
At the time, he was not planning a career in technology. He simply wanted to understand how the computer worked from the inside.
That instinct remained with him.
Over the years, he moved from building computers to launching his first company at eighteen, relocating to the United Kingdom at twenty, leading international technology teams and advising businesses across multiple markets.
His career has taught him an important lesson.
A technology leader should not begin by asking which product to sell or which platform to implement. The first question should always be about what the business is trying to achieve.
That principle now shapes his approach to CTO as a service.
What is CTO as a service when it is applied to a real organization?
He does not see it as an external technology executive who simply recommends software, approves budgets, or selects vendors.
He sees it as a strategic role that connects technology decisions with customer needs, business objectives, financial realities and long-term growth.
A CTO as a service partner must first understand how the organization operates.
What does the company sell?
What systems does it currently use?
Where is it losing revenue?
Which processes are slowing people down?
What level of performance does the business require?
How much can the organization afford to spend over time?
What happens if the technology decision needs to be reversed later?
These questions must be answered before an architecture is designed.
Many organizations begin in the opposite direction. They select a platform, build an infrastructure plan and then try to fit the business into that environment.
He believes this approach creates unnecessary costs and complexity.
Technology should follow business requirements. The business should not be forced to follow technology.
One of the first issues Mario sees in the current technology market is confusion around artificial intelligence.
Many organizations are calling automation AI.
A process may follow predefined instructions, move information from one system to another, or complete repetitive actions automatically. While valuable, that does not always mean the process is using artificial intelligence.
This distinction matters because businesses are approving AI transformation programmes without always understanding what they are buying, what information the technology will use, or what infrastructure it will require.
He also highlighted the risks of using public AI tools without understanding how sensitive information may be processed or exposed.
He referred to situations in Brazil where confidential legal information was entered into free AI tools before a judgement had been made public.
The issue was not simply the tool. It was the absence of clarity, governance, and informed technology leadership.
This is where CTO as a service becomes valuable.
Before adopting AI, an organization needs to understand the business problem, the data involved, the expected outcome, the security requirements and the environment in which the system will operate.
AI should not be introduced because it is popular.
It should be introduced when it offers a responsible and measurable way to solve a real business problem.
AI may dominate many executive discussions, but Mario believes cloud infrastructure remains equally important.
AI systems require computing capacity, storage, networking, data and reliable environments in which to operate.
In simple terms, AI has to run somewhere.
This is why decisions about cloud infrastructure cannot be treated as background technical choices. They directly influence the cost, scalability, security and future flexibility of an organization.
When asked about his preferred approach, he described himself as a cloud first.
However, he immediately added an important condition.
Each case is a case.
Cloud first does not mean placing every application and every dataset on a public cloud platform. It means considering cloud options while evaluating what the organization actually needs.
The right answer depends on the workload, business model, security requirements, performance expectations, existing systems and available budget.
What is cloud infrastructure in practical business terms?
It is a combination of computing, storage, networking, software services, data environments and security controls that support an organization's digital operations.
The technical components matter, but Mario’s approach begins with a more practical question.
What does the customer need to run?
Some organizations require services that can be accessed more easily through large public cloud providers. Others have stable and predictable workloads that may be more cost effective in a private environment.
Some companies need rapid scalability because customer demand changes frequently. Others need tighter control over sensitive systems and data.
The right architecture can only be selected after these needs are understood.
He explained that some businesses may require microservices and managed capabilities offered by public cloud providers. Other businesses may operate successfully through private cloud infrastructure. Some may require a combination of both.
This makes cloud strategy a business decision rather than a matter of personal preference.
The public cloud vs private cloud vs hybrid cloud discussion is often reduced to a technical comparison.
Public clouds are described as flexible.
Private clouds are described as controlled.
Hybrid clouds are described as the best of both.
In reality, the decision is more complex.
Public cloud platforms can provide rapid access to infrastructure, global availability, scalability and a wide range of managed services. They can be valuable for organizations that need to increase or reduce resources quickly.
Private cloud infrastructure can offer greater control, more predictable capacity and closer oversight of systems and data. It may suit organizations with consistent workloads or strict operational requirements.
Hybrid cloud allows a company to connect private infrastructure with public cloud services. Sensitive workloads may remain in a private environment while public platforms are used for additional scale, specialized services, or temporary capacity.
He has designed environments that connect private infrastructure with providers such as AWS, Microsoft Azure, Google Cloud, Oracle Cloud Infrastructure and Alibaba Cloud.
The choice should not be based on which model is receiving the most attention in the market.
It should be based on which model supports the business most effectively.
Security is also central to the cloud strategy of conversation.
Public cloud security is not guaranteed simply because an organization is working with a large provider. The provider may secure the underlying platform, but the customer must still manage access, identities, permissions, configurations, applications and data responsibly.
A poorly configured public cloud environment can create serious risks.
Private cloud security also requires discipline. Greater control does not automatically mean greater protection. The organization must maintain infrastructure, monitor threats, manage access, install updates, protect data and retain the expertise required to operate the environment.
The real security question is not whether public cloud security is better than private cloud security.
It is whether the organization has the right governance, controls, expertise and accountability for the environment it selects.
A CTO as a service partner should help define those responsibilities clearly before implementation begins.
The most commercially important warning Mario shared involves a cost that organizations may underestimate during cloud planning.
Data egress is the cost of transferring data out of a cloud environment or between certain services and locations.
It may appear to be a small technical detail during early planning. However, for organizations that move large volumes of data, it can become a significant operating expense.
When a company plans a public cloud environment, discussions often focus on computing, storage, databases, applications and performance.
According to him, the cost of moving data is not always given the same level of attention.
This can create a major difference between the projected cost and the amount the company eventually pays.
He described situations where organizations moved from private cloud infrastructure costing around ten thousand per period to a hyperscale public cloud environment where the total spending became three to three and a half times higher.
The environment may have worked from a technical perspective.
The financial model did not.
This distinction is essential for executives.
Architecture can be reliable, scalable and technically impressive while still being commercially unsuitable for the business.
A responsible CTO as a service partner must examine both the technical architecture and the financial architecture.
The question is not only whether the system can run.
The question is whether the business can afford to operate and scale it over time.
When cloud costs become difficult to manage, some organizations decide to move systems and data back to private infrastructure.
This process is often described as cloud repatriation or data repatriation.
It can be far more difficult than the original migration.
Applications may depend on cloud specific services. Large volumes of data may need to be transferred gradually. Integrations, security controls, networks, and operating procedures may have to be redesigned.
An organization cannot always switch off one environment and immediately move into another.
He has seen companies spend as long as two years trying to move away from an environment that no longer made financial sense.
This is why exit planning should be part of the original cloud strategy.
Leaders should understand the cost of entering an environment, the cost of operating within it, and the cost of leaving it.
They should also examine whether the architecture preserves enough flexibility to respond when business priorities change.
The fastest migration may create a very slow exit.
The least expensive option at the beginning may become the costliest option over time.
Mario’s approach to CTO as a service is not limited to infrastructure.
It also involves identifying where technology can support business growth.
One of the clearest examples came from a cloud company in Brazil where Mario held a senior technical leadership role.
The company offered many products, but sales remained limited.
He did not begin by creating another product.
He first reviewed the sales the company had lost during the previous twelve months.
This simple analysis helped reveal where genuine demand existed and where the company was repeatedly failing to convert opportunities.
The team identified an expensive database-related requirement that customers were struggling to address. They then built services around the problem, improved their dedicated server offering, developed database services and created private cloud products.
One of those offerings allowed resellers to build and sell branded cloud services to their own customers.
The company was no longer selling only servers and infrastructure.
It was helping customers build a complete service they could operate and sell.
That shift created greater business value.
The next stage of growth came from a place many organizations overlook.
The existing customer base.
He explained that companies often focus heavily on acquiring more customers while failing to understand the full potential of the customers they already have.
A business with thousands of employees may be spending only a small amount with a technology provider.
That does not mean the business has no further technology needs.
It usually means purchasing additional services from someone else.
By studying the size, structure and requirements of each customer, Mario’s team identified opportunities to provide more relevant services.
This approach did not require the same marketing and acquisition costs involved in winning entirely new accounts.
It requires better understanding.
Within two and a half years, the company grew from 12 million to 56 million Brazilian reals.
The result was not achieved by trying to sell every product to every customer.
It came from studying lost opportunities, identifying real demand, developing the right solutions and understanding existing customer relationships more deeply.
One of Mario’s most valuable principles is simple.
Find the customer before creating the product.
Technology companies often develop products because they believe it is innovative. They invest in building it and only later begin searching for customers.
He recommends the opposite approach.
Understand the customer first.
Identify the problem.
Study the financial and operational impacts.
Then create the product, service, or architecture around that need.
The same principle applies to cloud strategy.
A company should not choose a platform because it is popular, because a competitor uses it, or because a vendor presented an impressive architecture.
It should choose an environment that supports its applications, customers, security requirements, financial limits and long-term direction.
Technology should be the response to a business requirement, not the starting point of conversation.
Across the conversation, Mario presents CTO as a service as a discipline of asking better questions before making expensive decisions.
Understand the business before designing the architecture.
Study customer needs before creating the product.
Examine lost sales before chasing new revenue.
Review existing relationships before spending more on acquisition.
Calculate the full cloud cost before approving a migration.
Consider the exit plan before entering a new environment.
This approach brings technology and business strategies into the same conversation.
For C suite leaders evaluating public cloud vs private cloud vs hybrid cloud, that connection is critical.
The wrong infrastructure decision can increase costs, restrict flexibility, create security concerns and take years to reverse.
The right CTO as a service partner will identify those risks before a contract is signed, not after the invoices begin to rise.
Want to hear more conversations with leaders turning complex technology decisions into measurable business growth? Explore more interviews and executive insights on The Executive Outlook.
Listen in for business strategies and interviews with business experts to help you build a business and a life that you love.
About Us
