DigitalOcean’s New CTO Doesn’t Do Process for its Own Sake (But She Has a Process) – InApps 2022

In June, the rapidly growing DigitalOcean cloud provider hired seasoned exec Julia Austin to lead the company’s engineering and product development, in the role of chief technology officer. Her previous experience in bringing order to the other fast-growing companies — notably Akamai and VMware — would seem to be a great fit for DigitalOcean, which wants to step up the rate at which it is expanding its cloud services for its 700,000 customers. Last month, the company just launched a block storage service, the first new service under Austin’s purview.

The company lured Austin away from Boston (at least part time) where she spent the last few years as an advisor and to early stage companies, and where she still is a faculty member of Harvard Business School’s Entrepreneurial Management Unit, teaching product management.

We caught up with Austin in DigitalOcean’s New York headquarters, where we discussed DigitalOcean’s first strategic roadmap, the value (and misuse) of process, and the challenges in building a diverse workforce.

What was it about DigitalOcean that you found appealing?

When I joined Akamai, it was a big transition for me. I had been in IT administration roles before that. But when I came to Akamai, there was a lot of fast growth and lack of organization. They were literally patching the internet all day, all night. The company had about 50 employees when I interviewed there pre-IPO. By the day I joined, I was like employee 216. So they were hiring like 30, 40 people a week and there was zero process.

So we implemented a process back then that was reminiscent of Agile, right? So this was 1999. So Agile didn’t even exist back then. We actually came up with a weekly experiment process, and I figured that out that it was reasonable to actually push code out there.

At VMware, it was a very similar story. [The company] had about $600 million in revenue at the time, but it had never gone global. It never had a team outside of Palo Alto. They didn’t know how to run distributed engineering teams. They were just getting to the point of developing a product portfolio.

So now flash forward to DigitalOcean, it was the same kind of scenario. I really didn’t have an interest in meeting these guys in the beginning. [Cofounder] Moisey Uretsky had reached out to me to the Techstars network. So I came and met them, and I was like, “Damn it! It’s the same thing again.” I joked that it was like Akamai and VMware came together and had a baby and made DigitalOcean.

They convinced me. We were just building what we call the core complete offering, and we have all these things that we wanted to build on top of it. These guys are amazing, and I feel the energy.

You’re saying there’s still a lot of growth to happen there.

There are a couple of things. We have our core group of customers, the developer who wants all the levers and knobs and wants to manage and manipulate their environments. Our vision is to continue really to give them great tools to manage their environments.

The other side of it is moving upstream into the business class users who would say, “We just want to run our business, and we don’t want the overcomplicated. We trust you guys. Tell us what environment we need.”

So that’s really the vision is [to] enable those customers, the customers who want something that’s secure and performant and reliable. They have tools. They have the dashboards and graphs and things that they need, but they really just want to run their business and just know that DigitalOcean makes that possible in a really simple way.

So how will you continue to distinguish your approach like Amazon’s, which offers a lot of low-level services that admins have to tie together?

That’s at heart an engineering problem, right? We are still building those tools for the system administrator who wants them, but we’re keeping it managed and not over the top. We’re not going to have you scroll over a product page and see 47 different possibilities of what we could do with their product. That to me is just not reasonable. You want to play with the memory. You want to play with the CPU: We want to give you the abilities to do that, but we don’t want it to become an a la carte situation where it’s complicated.

I also do think that there are parallels to the VMware days. We used to worry that the data center operator would feel like they were going to be unemployed every time we announce something new at VMware. Instead, they would walk out like, “I want to be a hero because I’m just going to just do it so much better and so much smarter.” So I want to take definitely from that experience and as we start to envision our products.

You said that you brought to Akamai a sense of building processes. Where did that come from?

I came from an IT background so before there; I was at Partners HealthCare, which was a startup. I was hired to help implement PeopleSoft across the organization. They also wanted to build a component for adjustment time inventory. So I got to partner with their software development team. So that was my first exposure working with a real software development team in the Valley on an actual enterprise application.

So I got a chance to understand how we do a release process. When I came to Akamai, I drew a little bit of that experience but also was working with a very smart dynamic founder. I’m used to doing quarterly releases, and he was like, “No.” I said, “Monthly?” And he’s like, “No.” I said, “Okay, I’m going weekly. That’s as low as I’m going.”

I learned if you have too much process, it just weighs everybody down.

So that was a great experience. What I learned there, I then carried forward to VMware and now, here, is you don’t do a process for the sake of process. You do process where it adds some sanity to what you’re doing.

I worked for a manager who was at Motorola, and he literally would walk around this three-ring binder. He was like, “This is our development process.” Like really? Who’s reading your three-ring binder? We don’t do that.

It’s having the “what” and “why” clearly articulated and easy for people to find and see. I’m putting in a very straightforward stage release process, which I’m putting in now, here. It’s the standard product management 101 stuff, doing a whole discovery phase of the unmet need of our customers, but doing that quickly so that we can get a minimum viable product (MVP) out as quickly as possible and test it. Which for DigitalOcean, is new.

Your MVP should just be basic enough to say, “Okay. Now, we understand where we’re getting traction.” I mean there was an MVP of droplet at one point, right? What did the droplet [DigitalOcean’s basic virtual machine] need to be the start of what it would become? So with block storage, we went through that process again. “Okay. We’re going to build this new type of storage. What architecturally do we have to learn? What, in terms of user experience, do we need to learn?” and those kinds of things. Get it down as fast as possible.

Learn from it. Don’t go out there and just say, “Let’s see what happens.” Like actually go out there and say like, “These are the things we hope to learn from this.”

I personally love being a program manager. I like nurturing people and mentoring them and I like getting things organized. But we have a lot of women who want to just be engineers and they will move up the technical ladder and not necessarily be managers.

And know what to do with it. So a good example is what we did with block storage right away. Based on what we saw with adoption, it became really clear within a couple of weeks so it’d be a good idea to make San Francisco the default location instead of New York. That was based on seeing user activity. That was something that we thought might take longer to make happen but didn’t.

So what I’m trying to put in place with this team is, “Let’s go in with our eyes wide open the processes of why we’re doing what we’re doing? How we’re going to implement it? What do we hope to learn from it? And then what are we going to do next?”

We just created our very first roadmap here at the DigitalOcean, which is exciting. So what are we building and why? We are rationalizing the roadmap and then being really clear what the incremental improvements need to be and what our launch plans are for new things. We try to make it rational but also one that allows us to keep moving and having velocity without breaking anything because we are running a live system.

So that’s the process that I’m putting in place. And again, I learned if you have too much process, it just weighs everybody down.

So I ask the question, “So what are we trying to solve for here?” Because I think some energy got so caught up in this little widget or this little bell. We should know what we’re trying to achieve, not just a check log that says, “Done.”

DigitalOcean uses a lot of open source technologies, and the company has open sourced some of its own. How do you decide how much in the way of engineering resources to devote to open source work outside the company?

Everybody asks that question. I don’t really think about it in terms of percentage of resource time that goes into managing our contributions or what we’re pulling and managing. I care more about that we have a good process that makes us as nimble as possible when we do it.

So that’s part of my objective this first year is getting a little tighter [and] be more clear about what are we releasing into the open source community. If it makes sense, if it’s well aligned with the strategy of the business, if it helps us continue to influence those code bases, obviously, I want to make sure that we invest in that. But I don’t have like an algorithm or something that says some percentage of engineering resources should be on open source.

Is diversity an issue you grapple with?

Yeah, forever, yeah, definitely. So diversity in general as opposed to gender, I mean.

So one of the things I think a lot about, especially for women in tech, is the development of the individual contributor versus the push to management. Women in particular — and there’s lots of research on this — tend to be multi-taskers and nurturers, to the point that we get pushed or gravitate towards manager or program manager type of roles.

I personally love being a program manager. I like nurturing people and mentoring them, and I like getting things organized. My brain is actually wired to be that way. But we have a lot of women who want to just be engineers and they will move up the technical ladder and not necessarily be managers.

There’s research that was done in Carnegie Mellon about this. Women will tend not to move up in the organizational chain in the technology side unless they have role models, and women are already there. That’s a really hard Catch-22. And I would say it’s not just women again. It’s also any kind of diversity: It’s really hard to get diverse leaders in more senior roles in the technical ladder.

I’ll ask some of the younger women in my team, “Where do you aspire to be? Where are you headed? What’s going to limit you?” In some kind of way, if you want to keep moving up that stack, I can get you in the right direction.

Now, I’m not their direct manager, but I want to get a pulse. “Where is the pulse in my organization? Do they feel like they have that mobility?”

So when we think about overall diversity and organization, I don’t just think about, “We’re diverse. Good for us.” I look at where we diverse and in what roles are we diverse.

Have an environment that’s friendly and comfortable for who you’re trying to attract into your business. Tap into talent pools that aren’t just the obvious tier one colleges or the obvious big player companies.

The talent doesn’t have to be pedigree. I mean that’s the lovely thing about tech I think is we are now becoming less discerning. If you have real tangible proven experience, you’ve actually built software, you actually shipped things that customers love, [then] I don’t really care what your degree is. I just want to know that you’re talented and capable.

Digital Ocean is a sponsor of InApps.

InApps is a wholly owned subsidiary of Insight Partners, an investor in the following companies mentioned in this article: Unit.