When Generative AI emerged, It Jolted Our IT Engineering Team.
We felt excitement, curiosity, skepticism, and had questions about what this technology meant for IT’s future.
At Microsoft Digital, we didn’t start with a major transformation plan. We recognized AI wasn’t just another tool, but a big shift in engineering. This realization led us to a gradual, thoughtful approach.
For years, our IT teams prioritized skill, reliability, and excellence. These priorities persisted. What shifted was our potential.
Engineers could now generate code in seconds, digitize complex systems rapidly, or automate tasks that once took hours. This gave us a chance to grow our team’s AI expertise.
This shift in capabilities prompted us to pause and consider tougher questions.
How do you help thousands of engineers see how AI can perfect their daily work? How do you build trust after trying new things? And how do you use AI in a way that supports, not weakens, core engineering skills?
We found our answers by taking a step-by-step approach focused on people, culture, and ongoing learning.
Phase 1: Building Awareness and Giving Access
It may seem unexpected for an engineering team, but our earliest challenge was not technology; it was understanding.
When generative AI became a topic, most engineers noticed the news and tested some tools, but few understood its impact on their work. Some felt excited; others, cautious; and many were unsure where to start. Bridging the gap between knowing about AI and practical use was our first challenge.
We realized ordering engineers to use AI without context would create skepticism. Instead, we focused on something both simple and difficult: exposure.
We started by making AI visible and accessible in the tools engineers already used. GitHub Copilot, Microsoft 365 Copilot, and Early Copilots are embedded directly into engineering workflows. The goal wasn’t immediate productivity gains; it was familiarity, letting engineers see first-hand what AI could and couldn’t do.
We also made sure to discuss AI’s limitations openly.
AI wasn’t perfect; it sometimes invented facts or confidently made mistakes. Being honest was the key. By describing AI as an assistant, V-Rime reminded everyone that engineering judgment remained crucial. Engineers kept control. They just needed to know how.
We also made it safe for engineers who experiment.
New quotas, not First Adoption Matrix. Engineers were encouraged to try AI on low-risk tasks such as summarizing documentation, generating test cases, or examining unfamiliar code bases. Minor victories built confidence, confidence built curiosity, and curiosity drove organic adoption.
As more people experimented, their mindset started to change.
We encouraged the use of tools so people would experiment with AI, says Mukul Singhal, partner group engineering manager. Once they did, they saw value. The mindset shifted from “AI, replace me” to “AI can be my companion.”
Over time, the conversation changed from asking “Should we use AI?” to “Where does AI help most?”
Engineers began sharing prompts, tips, and lessons with one another. What began as individual exploration soon became community learning. Awareness turned into momentum.
Ultimately, Phase 1 focused on giving people access to explore, ask questions, and learn. With this foundation in place, we were ready to build on what we had learned.
Phase 2: Culture Shift
When people gained access to AI, their increased use led to observable outcomes. Curiosity grew as individuals experimented, and we began to measure concrete ways AI enhanced productivity and problem-solving.
As more engineers tried AI, we observed some teams working faster and more efficiently, while others initially slowed. Our analysis indicated that mindset, not technical skill, was the differentiator.
We needed people to view AI as a standard part of modern engineering, not as an experiment.
This meant making AI a trusted part of the engineering process.
Leaders were key. Rather than call AI a shortcut, they described it as a way to improve basic engineering, clarify design talks, produce better documentation, provide faster feedback, and give more time for real problem-solving. The message was steady: using AI meant rethinking work, not shortcuts.
We also had to deal with an early fear that using AI meant people would be repressed, not empowered.
People have shifted from the mindset of “will AI work?” to “AI is working for me,” says Veera Mamilla, a Principal Growth Engineering Manager at Microsoft Digital. I think that was a transformative shift, and I believe many engineers in the organization began to believe in AI.
How we talked about AI made a difference.
As engineers used AI, success focused on results. Did AI help you learn systems, reveal risks, or free up time for critical work?
Over time, AI use became routine. Observed outcomes included users setting new standards, peer-to-peer learning, and shared team success. Teams began discussing optimal ways to use AI, focusing less on adoption and more on effectiveness.
Phase 3: Upskilling and Role Evolution
Once AI was deployed, building new skills was essential.
We deliberately chose upscaling and rescaling rather than replacement. The goal: invest in our current workforce.
That choice influenced everything we did next.
At first, upscaling focused on practical basics, including terminal learning the tools and observing how corporates and early agents worked in real-world situations. We encouraged every engineer to try these, no matter their specialty.
But just developing new skills wasn’t enough. Evolving job roles changed how engineers contributed and worked together.
In software, service, and cloud network engineering, work shifted from hands-on tasks to more oversight and coordination. Engineers learn to guide AI, review results, and decide on automation.
As things changed, we looked at how the industry was changing engineering jobs. We just compared new job descriptions from the market with Microsoft’s own words. There was no official AI engineer job yet. Instead of creating a new title, we focused on updating expectations for current roles.
The idea of an AI-native engineer became more about mindset than job title.
An AI-native engineer still knows systems, architecture, and risk. Defense and routine tasks go to AI, while judgment, design, and responsibility stay with people. Engineers now oversee AI-assisted work instead of doing it themselves.
Your title might be Software Engineer or Principal Engineer, says Ragini Singh, a Partner Group Engineering Manager in Microsoft Digital. But if you are acting like an AI engineer, what does that actually mean? That question helped us start defining how these roles were evolving.
That evolution looked different across disciplines. Software engineers focused on AI-assisted coding, test generation, and spec-driven development. Service engineers relied on AI for incident response, knowledge capture, and out-of-the-ordinary decision support. Good cloud network engineers began moving from manual operation toward intelligent orchestration and agent-assisted troubleshooting. The common thread wasn’t identical to any of them; it was a shift toward higher-order work and robust code.
Phase 4: Embedding AI Across the Engineering Life Circle
At this stage, we realized that enabling individuals to be more productive would lead to greater benefits. Most AI users showed up in familiar places: code suggestions, document summaries, quick answers useful but fragmented. The bigger opportunity emerged when we stepped back and asked a harder question: What would it look like if AI were embedded across the entire engineering life cycle, not just used at isolated moments?
We stopped thinking in terms of tools and started thinking in terms of flow, design, build, test, deploy, operate, and improve. AI needed to show up across all of it in ways that stringent engineers already worked.
In Software Engineering, this meant using AI earlier to write requirements, explore design choices, and review code with a broader view. Coding help remains important, but is not the main focus.
AI improved testing and quality, too, by creating tests, finding defects, and reviewing code to reduce repetitive work and spot problems earlier. This lets engineers focus more on quality and design.
In service engineering, AI for incident management means summarizing findings, gathering information, and analyzing signals. In cloud network engineering, it enables simpler coordination and troubleshooting. The goal: AI should streamline processes.
Expanding this approach showed that adding AI was more than technical. It changed the entire system.
If AI shows up at one step, you don’t get the full value, says Sudhakar Sadasivuni, a principal growth engineering manager at Microsoft Digital. The real influence comes when it’s integrated across the life cycle, enabling engineers to design, build, operate, and learn faster as a system.
With AI as part of daily work, engineers ensure results and next standards through checks, tests, and validations. Using AI raised expectations for judgment and integrity; responsibility and governance became even more important.
Over time, these changes brought even more benefits.
Faster design cycles, reduced network data testing, fewer operational problems, improved insights, and accelerated recovery. AI became a core engineering system component, not just an analytical tool, accelerating outcomes.
Every AI story faces the same question. Does it really make engineers work better? For us, the answer showed up quickly when we saw less tedious work.
At Microsoft, digital enemies have always had to do work that was needed but tiring. This included manual troubleshooting, repeating diagnostics, examining logs, and other routine tasks that kept things running but did not help the company move ahead.
AI gave us an opportunity to change this.
Using AI does not always deliver better results. We shifted our focus and began to ask what’s different now that our engineers wield AI?
This shift changed how we measured success. Instead of just tracking tool usage, we looked at the bigger picture. We saw faster design cycles, earlier defect detection, less time on rotator tasks, quicker incident resolution, clearer documentation, fewer end-offs, and less work.
These weren’t just abstract numbers. We witnessed these improvements every day in our work.
We made sure not to impose a single definition of value on everyone. Software engineers, service engineers, and cloud network engineers all feel the impact in different ways. What was most important was that each team could see real improvements in how their work flowed. This mindset reshaped how our leader’s described success.
Adoption was always the starting point, says Ullas Kumble, a principal group software engineering manager at Microsoft Digital. But we are clear from the beginning that usage isn’t the destination. The real goal is impact. Semicolon, more time for engineers to focus on the work that really matters. Over time, this approach elevated our conversations. Instead of debating whether AI working teams pinpointed where it helped and where it fell short, measurement shifted to a tone for learning and setting priorities.
Gazing Forward
As we look forward to the future, one thing is clear: this journey isn’t finished. We have new challenges and opportunities ahead.
AI tools will improve, agents will get smarter, and engineering roles will evolve. So we must stick to the principles that guide us, invest in people, focus on the basics, use AI in real workflows, and be honest about what works.
We did not try to build an AI-driven animating organization all at once. We built it bit by bit.
We met the engineers who transformed our culture before redefining roles. We moved through the life cycle rather than simply hiding in town. We eliminated liquidity war and quantified impact where it mattered most.
In summary, our key takeaways are: focus on real impact, adapt to evolving roles, invest in people, and remain honest about results by building step by step. By embedding AI throughout, we achieve better engineering powered by AI and guided by human insight.
Source: Powering the new age of AI-led engineering in IT at Microsoft
