Unqork founder and CEO Gary Hoberman took a rare route into entrepreneurship, spending decades coding and overseeing enormous budgets on Wall Street (his former position was executive vice president and global CIO for MetLife) before launching his own firm. In his view, it was the best possible preparation to position him and his company, a no-code application platform, for success.
In this interview, Hoberman describes how his background inside large enterprises has made them easier to sell to, and he offers guidance for other startups trying to land enterprise contracts. He also explains to enterprise buyers how to invest wisely in startup technology, and he discusses several advantages, drawbacks, and pointers for operating within a large company.
Let’s begin with the obvious: Moving from Wall Street CIO to startup founder sounds like a dramatic shift. Why did you choose that path?
GARY HOBERMAN: I like to describe it as jumping out of the C-suite, from the corporate jet to Zone 5 of United, where carry-ons aren’t allowed.
I began my career on Wall Street, literally straight out of business school. I was drawn to the idea that technology was almost magical, that it could fix things. You could instruct a machine to do something and it would comply, and I felt there was no more thrilling place to deploy that power than the flow of money on Wall Street – the exchanges, the trading, all the operations where a mistake is serious for a business. You can’t afford to be wrong.
So I turned that into my challenge: How do you really solve those problems?
And in one sense, wherever I worked, that is what I was doing. I was fixing those problems. But in another sense, it always stayed inside one group and function, or one division, or one company. So even though it was fulfilling to do what we called “intrapreneurship” – building something startup-like inside these 200-year-old companies and building the conviction that processes could be improved – I left corporate life because I came to see that there is no light at the end of the tunnel unless you create it.
As a CIO, I would be sent out to the West Coast. I would meet the CEOs of all the large-cap tech companies and sit with them in their executive briefing centers in Seattle and California and hear what they were building and where they were headed. We would also meet with venture funds and listen to portfolio pitches. And all I kept hearing was that software was still being built the way it had been since punch card machines. Yet all around us, we praise the scale of cloud computing, infrastructure, security, and databases.
More important, 80% of my spend – and that was $1.2 billion a year – went to what you’d call “just keeping the lights on.” The projects you were working on were end-of-life projects. “Oh, Microsoft’s going end-of-life for something new. Great, we’re going to spend a million dollars to fix it – or 10 million, or 100 million.”
At the same time, the remaining 20% – the new, flashy things that move the company ahead – was being built with custom code. All that did was create legacy code. The moment it moved into production, we instantly labeled it legacy and it was no longer new. It had to be supported and end-of-lifed just like everything else. That was my epiphany.
Politics are a huge force inside some organizations . . . don’t underestimate the organisms within companies that exist to defend and preserve the status quo.
You brought up “intrapreneurship” . . . Now that you’ve experienced both sides, I’m curious how closely a big company can really imitate the startup experience, or whether enterprises should simply accept what they are.
I agree with you to some extent. A bank is a bank. It’s not a tech company, even if you employ more engineers than Microsoft. But the reality is that I personally don’t think centralized innovation makes much sense. Innovation is something everyone should be thinking about how to do, and doing within their team and their function.
For instance, at the peak of the 2008 financial crisis Citigroup stock fell sharply, and we needed a way to innovate. I remember going to the CIO and pitching, “We need to create a lab for innovation in the building. People need to walk through it and see it, and feel that there are still things being built and created.” I was given a budget one-tenth the size of what you needed, and we built what we called the Rethink Inc. lab. It became the place where we would innovate, and we achieved a great deal.
But to succeed, you had to understand the politics happening around you, which is very different from the startup world. At Unqork, there’s no politics, no bureaucracy, no BS.
Politics are a huge force inside some organizations. And for anyone building companies, don’t underestimate the organisms inside companies that are there to defend and preserve the status quo. I’ve seen it from the outside in, and I’ve seen it from the inside out, and some of the stories would probably frighten you.
Changing subjects a bit: What are some things B2B startups need to understand in order to sell to large enterprises? How do you get through the door? And once you close a deal, what are some traps to avoid?
Maybe it’s because I really understand the enterprise, but we decided we had to begin with Tier 1 customers and Tier 1 problems. Tier 1 customers are the Fortune 100 and Fortune 250. They are your largest, biggest, most difficult customers to win. They put you through 1,500 questionnaires on compliance and security, and they’ll come perform on-site checks. Tier 1 problems are usually the problems that no one lets you touch. They’re the problems that only custom code has been able to solve, because no software package can.
And I would recommend that approach for any startup, because the reality is that if you get the platform working and find product-market fit and features for Tier 1 customers and problems, everyone else downstream is easy. Every other industry is easy, and every other problem you could throw at it becomes easy. Instead, many companies start with the simple problems and then say, “OK, we’ve built something simple, now use it for your complex problems.” And it doesn’t work.
We wanted to be able to walk into a customer meeting and have an answer when someone says – and someone always will say it – “Who are you working with that is bigger than us and more complex than us? And what use cases have you done that are more complex than what we have here?” Because they’re going to be skeptical of you as a startup founder and your team.
I think that’s essential to get started in a way where you deliver value, instead of doing what I would call pushing software licenses like drugs. A lot of companies are just pushing a license with no value, and it’s hurting organizations. I would encourage everyone building companies to sell to the enterprise: Focus on the value you help them create. Let them see the value and experience the value, because that’s how you’ll succeed.
And if a deal isn’t a good fit, saying no can be a smart business move. You don’t want to be trapped, or boxed in to doing something that’s easy but doesn’t add much value.
What’s going to happen in the real world with your client is there’s going to be a job change. . . . And when that client’s project suddenly matters less to them and gets pushed to the back burner, your business is out.
You mentioned that skepticism that large enterprises often have, so what about the reverse? What do enterprises need to understand as they try to work with a startup?
The one thing I know doesn’t work in enterprises is when there is no sponsor or commitment, or nothing you can tie to genuine business value. We tell every customer, “Just give us a challenge. What is the hardest thing you can imagine that you need an engineer to actually code?” If you’re a startup working with a large enterprise, and it feels like a project is going nowhere at all, you’re probably right.
The opposite is that businesses need to apply technology to real problems. Every business has to treat every technology project as a business case. You are investing this money, and you expect a return. One study found that 93 percent of large technology initiatives launched in enterprises fail to deliver any value, which is insane.
So when you’re working with a startup, give them something meaningful – something that, if and when they succeed, creates real value for your shareholders and your company. Don’t do it halfway. Don’t just dip a toe in the water to see at all. Because without knowing whether it works, where do you take it forward from there as a sponsor? How do you help them push it forward?
Your point about having a sponsor or internal champion seems exactly right. How important are those types of relationships?
I had one potential investor who said, “Choose one client, stay stealth, get it into production, and then move on to your next client.” And what I can tell you from the corporate world is that is the absolute worst advice anyone is going to give you ever.
Why is that? After all, it makes sense on paper. But what is going to happen in the real world with your client is there is going to be a job change. There is going to be reprioritization, re-budgeting, cuts, regulatory concerns – outside forces you have no control over. And when that client’s project matters less to them and gets pushed to the back burner, your business is out.
We started with five concurrent clients in all different industries, so that we understood all their needs. It also mitigates risk because you’re not dependent on a single change in the company.
In the startup world, we need more people who know the pain and suffering that’s happening in the enterprise world.
Given all of this, what’s your advice to someone starting out as an engineer and trying to decide between the startup world and the enterprise world?
The number one thing I’ve learned is that you have to wake up and enjoy what you’re doing. You have to feel passion for what you’re doing, whatever that is.
In the beginning years, though, I would definitely say to work hard. It doesn’t matter what you’re doing. My first job was debugging someone else’s code. There is nothing more boring than that, but the truth is that I learned how to be a great engineer. I learned how to make sure it’s actually coded correctly. You also need to experience things to know what to build, and to know what you enjoy.
Don’t be afraid of going to a big corporation and making a difference there and being excited about that. I would say that in the startup world, we need more people who know the pain and suffering that’s happening in the enterprise world. You need to understand that to be able to fix it. I started this company not to compete against large enterprises, but to empower them to succeed and get out of their own way. And I always have that experience in my mind.