Skip to content

Search the site

The Big Interview: MongoDB CIO Mindy Lieberman

On going from academia to CIO; learning from hyper-growth Cisco (“make sure you are part of the team that is tackling the thorniest, ickiest, hairballiest problems in your organization”), being blown away by the first browser, and ‘build versus buy’

The Big Interview: MongoDB CIO Mindy Lieberman

Mindy Lieberman went from post-doctoral research scientist, to sole engineer in a startup, to Chief Information Officer at $19 billion-by-market cap MongoDB. The Stack joined her to discuss the unique challenges of running corporate IT at a technology company, the evolving role of the CIO, speaking up, and staying sharp in a very fast-moving world.

Q: How is the CIO role evolving and what are the unique challenges of being a CIO at a technology company rather than traditional industry?

The heritage of the CIO itself is definitely evolving. Traditionally, you got to CIO because you were in charge of infrastructure; giving out laptops and hanging up wireless endpoints. That is no longer the case. Today you get to CIO because you are at the intersection of business and technology. 

[At a tech company] when you have innovation and software coming out of sales, of customer support, clearly of engineering, you have to think very critically about what should be bought versus built. You've got to enable the business, but IT is a G&A [general and administrative] function.

The TCO of any system has to be top of mind… 

I have a fairly sizable organisation [of] technologists and software developers. They are incredibly innovative. So the idea is to build the right things. The two things I always keep my eye on are ‘do I have the right people, and am I working on the right projects?’ If I have both of those things true, 80% of my problems are solved. Because first of all, from a CIO standpoint, I have to have a business-aligned roadmap…

CIO roles do vary quite notably. Tell us about yours… 

My remit, I'd say, is traditional. I've got the corporate infrastructure, as well as all the business systems. The place where the line is drawn, [is not] having [responsibility for] infrastructure for the product; that is where Product and Technology take over. My chief counterparts are the business unit leads from the other departments, including engineering.

So that is the remit; that plus the data warehouse.

We’re always interested in how CIOs and CISOs interface. How do you?

Security rolls up through the CTO. [But the CISO and I interface to] think about security in terms of infosec, product security, operations and response and align on what technologies we need to have going forward. 

For example [the CIOs office helps ensure] we've secured the company by reducing sprawl, by ensuring that we've phishing-resistant MFA in place; by making sure that there is good education; ensuring that we've got the best telemetry on these laptops… The CISO and I develop a joint project roadmap. We resource it together. We report to each other about what residual risk we still have; align in what we tackle, and then we go after it.

Tell us about your career path to CIO? What’s your background?

I started as an academic, because I loved solving hard problems. But I realized, after nine months of my post-doc, that there was this thing exploding called the Internet. I saw my first browser while I was sitting in my colleague's office in Lawrence Livermore National Lab

I thought ‘this is going to change everything; I'm in the wrong spot!’

“I quit and went to my first three-person startup. We didn't know what we were doing; I was the sole engineer on the product, but I learned a tonne. [I went to] Berkeley Systems where I was doing product development and writing core libraries, and from there I first joined Cisco, and I really cut my teeth [across] every position on the map. 

See also: The Big Interview: Dinesh Keswani, Global CTO, Nomura

“When I joined Cisco, we were roughly 5,000 or 6,000 people, and by the time I'd left it was up to 100,000… I took note of how we scaled, how we were organized, how we communicated, how leadership communicated, how we selected projects; and I've taken a lot of Cisco with me.

From there [after nine years] I've had the privilege to work for some really marquee companies: Salesforce, Zendesk, Okta, Peloton – that was a labor of love! I went from being a tech mom couch potato into <flexes muscles/> so that was a great four years and that was quite the ride. 

Yeah, let's just rewind to your time at Cisco. It sounded like you’d learned a lot of lessons from being at a company that scaled so rapidly. What key takeaways did you take to MongoDB in terms of “I've seen this in the past. I don't want to do this”, and “I do want to do this!” 

The first key tip is to push decisions down in the organisation as much as you can. You want to create independent pods who don't have to manage dependencies And you want to have an appropriate framework for being able to push decisions down. Because if you bottleneck with decision making at the top, your company is not going to be as fast as it can.

[I liked at Cisco that the] CIO had business units, reporting to them directly as opposed to having an interface through an applications person. That's the structure I've got right now. I may end up changing it in the future. But I do like that I'm very close to everything that's going on…

What brought you to the CIO role at MongoDB?

I deeply respect the product. As a technologist, I want to know that I am working with something that is respected, that has growth potential. 

I like the addressable market. I like the product market fit. But what led me to take the job was the culture of the company; the quality of the team. One of the values we have is to be intellectually honest… I think that's something that MongoDB as a leadership team excel at; getting the issues out on the table, talking them through, deciding and moving.

What achievements to-date are you most proud of?

First up leveling the team. I needed to make sure that we had the right people that were working on the right things. There was a bunch of debt that we had to attack. We did not necessarily have the best planning process so that we were misaligned with some of our stakeholders. 

We also had teams in places that were too small, and so we had operations clobbering projects – it's better if you can separate those.

As a CIO how are you deploying AI?

One of the beauties is that my team is responsible for the internal AI technology program. This I think is where the rubber meets the road. 

We are leveraging MongoDB, which has great vector search capabilities as well as trying to use AI to solve tangible business problems. And we've got a very long roadmap of use cases where we're going to do that. 

So I am both just delighted to be leading that team. And I'm really grateful that we've got such a meaty remit to go ahead and attack.

Talking of intellectual honesty, I interviewed a senior leader this year who said glowing things about generative AI with the camera rolling, then over coffee later flagged the company-wide unreasonable expectations and poor outcomes. What have your experiences been?

[We started] trying to figure out what the stack is, and I think we validated internally that a RAG architecture is where we want to go. 

One of our more successful deployments is what we call CoachGTM, which is a tool for the sales department, and it's a way for the Go To Market teams to be able to ask questions about historical deal information; about what documentation we have internally; about how we answer certain customer questions. It's been a real resource.

Another real win has been an AI tool that has been developed for our Technical Services Department that helps answer customer queries.

In the roadmap we're about to release internally we have our MongoGPT, which is a generalised search bot. We've got a long roadmap having to do with being able to answer HR-specific questions [too]... 

What have been the challenges when it comes to getting RAG accuracy up? My conversations suggest that the first 70% is easy but then… 

That is true. I cannot actually offer anything beyond what my peers are experiencing. We have had to inject a human to verify the answer before we roll it out, making sure that it's fit for purpose before we expand it.

I don't think anybody feels like they’ve really cracked the code and been able to fully experience the productivity gains that we think are there. I really believe if we keep expanding both the unstructured data that's in the enterprise and the structured data. I think we're gonna make magic.

How as a CIO do you stay up-to-speed? Whether that’s tackling technical “skill fade” or adapting your skillset as a leader?

I think it's something that every C-suite person struggles with as your organisation enlarges. I'd say it's a combination of a) focusing on basics and b) making sure that [you allocate time to] developing yourself. 

I do that through a combination of CIO events, or just research. I decide very specifically how much I want to spend on internal projects, on networking, on developing people, or just with my peers, making sure that we've got the right processes and doing temperature checks. 

What advice would you give to a younger you?

I'd give myself two pieces of advice: The first is don’t worry so much about career growth; worry about making sure that you are part of the team that is tackling the thorniest, ickiest, hairballiest problems in your organization – because the more are seen to be doing that repeatedly, the more your career growth is naturally going to take care of itself. 

The second thing is, speak up even when it's uncomfortable to do so, and especially when it's uncomfortable to do so; because you have to train yourself to be part of the conversation as opposed to an onlooker. 

As a technologist, I know that 50% of the people in my company are probably introverts, and they are less inclined to speak freely than others. But it's a muscle. You can learn to develop it. And it's worth developing.

Join peers following The Stack on LinkedIn

Latest