Cory Delamarter runs toward flames. He can’t help himself—he must be where the action is.
He’ll help put the fire out, but really, he’s trying to figure out better ways to extinguish the flames. At Microsoft, Delamarter helps the company become better at responding to fires.
“The pragmatist waits until the exact moment you have to figure something out to fix it,” Delamarter says. “That’s a great definition of where I like to be in Microsoft. I can only look so far into the future, I can only get so pumped about something that’s not happening right now. I like it when we need it and we need it now, when there’s no debate.”
Delamarter is a program manager in Microsoft Core Services Engineering and Operations (CSEO), formerly Microsoft IT. He’s been chasing flames at Microsoft since he started working at the company 17 years ago. Delamarter currently manages a team of engineering program managers who run programs and deliver new features across most everything from networking, data centers, cloud adoption, security and privacy, custom applications, business intelligence, and data.
Delamarter also is squarely in the middle of an ongoing bid to adopt modern engineering practices and a growth mindset culture across CSEO and Microsoft. (Only recently, many years later, did he realize that his tendency to chase after exciting and edgy roles is a version living a growth mindset.)
“When I looked back at my career, I realized I was going through a transformation every two or three years,” he says. “Some new opportunity would come up, and I would want to try something new. Chasing after those opportunities kept me on my feet, kept me moving, and learning new skills.”
Every time Delamarter gravitated toward a job that got his hands dirty fixing stuff under pressure, he learned. He would then turn around and propel those learnings back into the people and the products he was working on—very much living the digitally transformed culture that Microsoft is rallying around.
A reinvention of self
Before Delamarter got his start at Microsoft, he worked in a religious university’s computer lab. Upon arriving here, his first job was to answer calls from IT pros who were not happy with their Microsoft servers.
“The joke was, I went from working at a private Christian organization where every meeting started with a prayer, to working in Microsoft IT where every meeting ended with cursing.”
Delamarter quickly realized he was in over his head, but that he liked hustling to figure things out.
“When I came in, I had no practical experience supporting things at scale,” he says. “At that point, the core Windows developers were calling me—they wanted to talk about the deeper nuances of the operating system. I had no idea what was going on, but my team gave me tools, showed me which direction was up, and I started to figure it out.”
These trials by fire taught Delamarter something new every time, which in turn opened new doors. This was the beginning of a pattern that would shape the rest of his career.
“Fast forward a year or two, and we had the first prominent worms break out across the company, SQL Slammer and Code Red,” says Delamarter about malware that spread to other computers by replicating itself. “Those were the two fun ones. In those moments, there was an opportunity for some of us to put in some extra hours, sleep in our offices, write some scripts that would automate detecting where we’d have problems, and that would automate quick fixes.”
Pretty soon he found himself working on patches, not only building the first ones that the company deployed, but also figuring out better ways to deploy them.
“Patches could be released at any time,” he says. “As an incident team, we said we would help land these fixes. We would push the envelope of automation. That was my first opportunity to stretch out of support to compliance automation role.”
Delamarter then turned that work into his next role, which was working on writing Perl scripts. These scripts would loop through all the automation systems they were building to automatically figure out which ones weren’t working so that they could be fixed or replaced. “Later, we wrote scripts that would do the deployment for us,” he says.
Getting involved in solving problems in real time meant Delamarter was starting to show up in war rooms where the chief information officer (CIO) and others were solving high-stakes problems as fast as possible.
“The fact that you had every organization pulled together into this conference room, this response center, where they were reacting to a crisis—this was pretty heavy stuff,” Delamarter says. “You would go into the room where you were triaging things with the CIO. You had this deep sense of connectedness with the entire company.”
The first major crisis Delamarter got to work on was the 6.8 earthquake in Seattle on February 28, 2001, quickly followed by the September 11, 2001 terrorist attacks on the World Trade Center and the US Pentagon. “MSN and MSNBC were streaming those attacks,” he says. “Those services were tipping over because of how much demand was coming to them. The crisis forced you to push your envelope more than you thought you could.”
Knowing what’s not right
Delamarter’s success started catching up with him, and he was invited to go work in a Microsoft product group.
The role required a lot of structure and planning around what he was being asked to build. “Product planners do major analyses and say, ‘here’s where the revenue is going to be at in two to four years from now—let’s go build that.’ I struggle with two- to three-year timelines. That’s where I didn’t fit into the Microsoft model. Those were probably my worst three years.”
Realizing that building Microsoft products over long periods of time wasn’t for him, Delamarter recognized that he belonged back in IT where he could help ensure products worked the way they were supposed to before they were deployed to the public. He loved the building part of his new job, just not how long it took for a product to come to fruition. (Now, due to the accelerated nature of product development, Delamarter believes he would be fine working in a product group because today they utilize fast-paced agile sprints and shorter planning horizons.)
“It was coming back to IT and getting that connection to ‘I’m solving problems,’” Delamarter says. “That’s the huge draw of a position in CSEO—you get to solve problems before the software is available to the public. This allows you to influence product groups, to help them be realistic about what they’re releasing.”
Delamarter returned to CSEO just when Microsoft made the commitment to go “all in” on cloud services.
“The team I was working on had just begun to adopt agile,” he said. “We were working on mature services, and we were automating everything.”
That led to exploring what was possible on Microsoft Azure. “Excited engineers started putting together automation to move virtual machines from on-prem to on the cloud,” he says. “We were creating all kinds of automation.”
Through a series of sprint cycles, Delamarter’s team was able to help its internal customers save millions of dollars by moving them to Azure. “We were helping them figure out where their spend was,” he says. “Every two or three sprint cycles, we were able to tell a story of ‘these many virtual machines deployed, these many millions of dollars saved.’”
Now, as a manager, Delamarter is teaching his team to race toward the flames, to be flexible, and to have fun doing it.
“Be relentless about understanding where the business is going, and don’t be afraid to abandon old tools and processes to get there,” he says. “Nothing is going to happen to you from trying hard to adapt and change. Think critically about what you do and make sure it connects to what your company is doing.”
For his part, Delamarter plans to keep going where the fire is the biggest so he can keep finding ways to help Microsoft (and himself) transform.