When I began working at Tulip Telecom in Mumbai in 2011, my world was BGP, OSPF, MPLS, and enterprise WAN incidents. My responsibility was clear: understand what had failed, restore service, and avoid creating another problem while fixing the first.
More than a decade later, those same habits still shape how I design cloud and enterprise solutions.
My career has taken me from network operations and mobile packet core environments to cloud platforms, managed services, project leadership, and international solution consulting. Looking back, the transition was never a clean move from one profession to another. I did not leave engineering behind and suddenly become an architect. I gradually became responsible for a wider part of the outcome.
That distinction matters to me. This is not a story about collecting job titles. It is a story about how my questions changed.
Learning to see the complete path
My early years in network engineering taught me to think from end to end. When an enterprise customer lost connectivity, the problem was rarely solved by looking at only one device. I had to follow the path, understand the routing decision, check the dependencies, examine recent changes, and consider the effect of any action before applying it.
At the time, I was focused on incidents, availability, and service-level commitments. I was also learning lessons that would later become central to architecture: assumptions are dangerous, dependencies matter, and a quick fix can create a larger problem somewhere else.
The technical foundation was important, but so was the sense of responsibility. Behind every alarm or ticket was a customer trying to run a business. Restoring a route was not the final objective. Restoring the service was.
That difference between fixing a component and protecting an outcome stayed with me.
Scale changed my perspective
My next major learning phase came while supporting telecom environments for Vodafone India through SRA OSS at Cisco Systems. The systems were larger, the integrations were more complex, and the effect of failure extended far beyond one enterprise connection.
I worked around mobile packet core infrastructure and the systems supporting it, including routing, DNS, AAA, charging, monitoring, security, and data-center platforms. In an environment like that, no technology operates alone. A network issue can appear to be an application problem. A storage or compute constraint can affect service performance. A small configuration change can influence many connected systems.
This experience widened my understanding of infrastructure. It also taught me that technical depth alone does not resolve complex situations. Large incidents require people from different teams to build a shared understanding quickly. Vendors, operations teams, application specialists, managers, and customers may all see a different part of the problem.
The engineer who can connect those perspectives becomes more valuable than the engineer who protects only one technical boundary.
When my career later took me to Hanoi and into roles with CMC Telecom and Viettel Networks, the scope continued to expand. I worked across capacity, performance, automation, security, global IP networks, multi-vendor platforms, and infrastructure migrations. I also moved closer to compute, storage, virtualization, and hybrid cloud environments.
Cloud did not feel like a departure from networking. It felt like the next layer of the same journey. The familiar questions about traffic, segmentation, latency, resilience, security, and operations were still there. The difference was that I now had to answer them across a complete platform.
The real transition was not a promotion
The most important change in my thinking happened when I moved from core network engineering into project management and managed services at Viettel Networks.
As an engineer, my natural instinct was to identify the technical problem and begin working toward a solution. In project and customer discussions, I learned that starting with an answer can be a mistake. Before proposing technology, I needed to understand the outcome, the users, the constraints, the ownership model, the delivery risk, and what success would mean after deployment.
That was a difficult but valuable adjustment. It required me to listen longer, ask better questions, and resist the urge to prove technical knowledge too early in the conversation.
My work began to include service design, cloud consulting, partner coordination, service-level governance, 5G use cases, and connected platforms. I was working with sales teams, developers, project managers, operations teams, partners, and customers. Each group had different priorities, and none of them could deliver the complete outcome alone.
This period taught me that architecture is not only the design of technology. It is also the alignment of people, responsibilities, decisions, and operating processes around that technology.
A strong diagram can still lead to a weak solution if requirements are unclear, responsibilities are fragmented, support teams are unprepared, or the design cannot be delivered within the available time and budget.
Cloud widened my responsibility
Moving into cloud product work at Viettel Solutions brought the earlier parts of my career together. Networking, infrastructure, operations, customer consulting, project delivery, and product development were no longer separate areas. They became different views of the same platform.
I contributed to hybrid cloud initiatives, worked with AWS and Azure partnerships, supported private cloud development, and helped shape solutions for enterprise customers. The work covered migration, infrastructure as code, security, networking, service design, documentation, training, and adoption.
This was where I learned the difference between knowing cloud services and designing a cloud solution. A service catalogue can tell you what is available. It cannot decide which workloads should move, how identity should be governed, how networks should connect, what level of resilience is justified, how recovery should work, or whether the organization is ready to operate the result.
Certifications across Cisco, cloud platforms, project management, and service management helped me structure my learning. I value them, but they were maps rather than destinations. The most useful learning came when real projects forced me to balance security, cost, performance, delivery time, skills, and operational complexity.
My networking background continued to be an advantage. Many cloud discussions eventually return to fundamental questions: Where does the traffic flow? Which identities are trusted? Where is policy enforced? What happens when a dependency fails? How will the team observe and recover the service?
The technology changed. The discipline of thinking end to end did not.
What solution architecture means to me now
Today, I advise customers and design solutions across public, private, and hybrid cloud platforms, private 5G, e-government, smart-city and IoT initiatives, and broader enterprise IT services.
The work is increasingly international, involving teams, partners, government organizations, and enterprise customers across different regions. Every market has its own priorities, regulations, operating maturity, commercial realities, and expectations. A design that works well in one environment cannot always be copied into another without careful adaptation.
My role is no longer defined by knowing every command. It is defined by asking the right questions early enough to influence the outcome.
What problem are we solving? Which constraints are fixed and which can be challenged? What must the customer operate after delivery? Where are the technical, commercial, and organizational risks? Which option creates the right balance of capability, security, resilience, cost, and time?
I have come to see architecture as the practice of making those trade-offs visible. The architect does not remove every constraint or guarantee a perfect answer. The architect helps people make a clear, responsible decision with a realistic understanding of the consequences.
What I would tell a network engineer making the same transition
I would begin with this: do not treat your networking background as something you must escape. It can become one of your strongest architectural advantages.
Keep the engineering depth that taught you to troubleshoot, trace dependencies, understand failure, and respect production risk. Then expand outward deliberately. Learn how Linux, compute, storage, virtualization, identity, security, automation, observability, and cloud services connect to the network. You do not need to master everything at once. You need to understand how the pieces influence one another.
Build complete, small solutions instead of studying technologies in isolation. Deploy an application, connect it to data, secure it, monitor it, automate part of it, and design how it will recover. Document your assumptions and explain why you selected one option over another. This develops architectural judgment much faster than memorizing product features.
Look for opportunities to own a small outcome from beginning to end. A migration, landing zone, monitoring improvement, recovery design, or service integration can all become architecture experience. Define the requirements, compare options, identify risks, ask for review, support the implementation, and examine the result honestly afterward.
Join customer and business discussions whenever possible. Learn to hear the problem before presenting the technology. Practice explaining the same design to engineers, operations teams, security specialists, commercial teams, and leaders. The diagram may not change, but each audience needs a different explanation of its value and risk.
Study delivery and operations as seriously as design. Cost, governance, ownership, service levels, documentation, support, and change management are not administrative details. They determine whether the solution will remain successful after the project team leaves.
Finally, do not wait for the title before practicing the work. Write design documents. Lead reviews. Present trade-offs. Mentor someone. Coordinate a small cross-functional initiative. Build evidence that you can make and communicate responsible decisions.
The move from engineer to architect does not happen on the day of a promotion. It happens gradually as other people begin to trust you with a wider outcome.
What I would tell my earlier self
I would tell my earlier self not to measure progress only by the number of technologies I knew.
Technical knowledge matters, but the ability to select, connect, explain, and operate technology creates the larger impact. Knowing when not to add complexity is also an architectural skill.
I would start practicing communication earlier. Writing a clear design, asking a precise question, listening to a customer, and explaining risk without unnecessary jargon are not soft alternatives to engineering. They are part of professional engineering.
I would also accept sooner that growth often feels uncomfortable. Moving from a role where I could rely on technical depth into situations involving customers, commercial decisions, incomplete requirements, and cross-functional accountability was challenging. It was also necessary.
Each stage of my career added a new responsibility without removing the previous one. Networking taught me to understand the path. Telecom taught me to respect scale. Operations taught me to design for failure. Project delivery taught me to align people and outcomes. Cloud taught me to think across platforms. Consulting taught me to make trade-offs clear.
Together, those lessons shaped the kind of architect I am still becoming.
Still an engineer at heart
More than a decade later, I still approach architecture with the mindset of a network engineer: trace the dependencies, expect failure, protect the service, and make decisions based on evidence.
The difference is that the path I follow now runs through technology, operations, people, and business outcomes.
I did not leave network engineering behind. I carried its discipline forward, expanded my perspective, and learned to take responsibility for more of the result.
That is what my journey from Network Engineer to Solutions Architect has meant to me.