What Worked, What We Got Wrong: Dustin Lucien, COO of Betterment

Dustin Lucien, COO of Betterment, speaks to entrepreneurs at AWS Startup Day.

Launched in 2010, Betterment is the country’s largest independent financial advisor with more than 278,000 customers and over $10 billion in assets under management. Though it started with only a small core team of mostly engineers, Betterment now has north of 200 employees. At Startup Day in New York City, COO—and former head of engineering—Dustin Lucien looked back on the initial years of Betterment and the startup’s technical, operational, and cultural hits and misses.

WHAT WORKED

• Building a monolithic application

“In the beginning, when we had very few engineers, we were able to move a hell of a lot faster building a monolithic application rather than starting with microservices. It allowed us, for example, to defer distributed systems problems.

A secondary effect was that it promoted a culture among the engineers of full-stack thinking and a full-stack approach. As an engineer, you own the experience for whatever you are building all the way through. You connect directly to the customer, which is vital when you are a team of five to seven engineers. It also gives you time to build a real understanding of your business domain.”

• Creating areas of ownership

“You want people to feel responsible for the ultimate quality of what they are building. We fostered that by assigning clear areas of ownership, again within that full-stack approach. Our full-stack teams owned everything they needed to solve a business problem and carry it all the way through to the customer. We didn’t create the distinction of front-end or back-end engineers. Rather, you were part of a team that had responsibility for say, sign-up customers, or 401(k) customers, or tenured customers, from beginning to end.

Creating that ownership not only further develops domain expertise in the business and systems, but that ownership also engenders a sense of responsibility within the team, even after the last project ships. Finally, having areas of ownership promotes the development of leadership and mentorship from the beginning. My career is closely tied to my area of ownership, and the impact I am having on the goals of the company.”

• Leveraging Conway’s Law

“Conway’s Law (named after programmer Melvin Conway who first introduced it in 1967) says: ‘Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.’

How we designed our systems was driven by how we thought about our business. Our teams were independent of each other; they were vertical, and they were full-stack. That guided and drove how we built our monolithic application. The advantage of that is it aligns teams to business needs first, not technical structures. The disadvantage is it means you are going to be eating your monolith for a long time—but for us, the pros outweighed the cons.”

WHAT WE GOT WRONG

• Building snowflakes

“Initially, we collocated iron, which we didn’t own. Everything was a custom setup and configuration. We even had customized WordPress installations. Everything was a work of art; it was technology for technology’s sake. We were building snowflakes.

In hindsight, the rule is: build things that differentiate, borrow things, grab things off the shelf that don’t. For example, security is not going to differentiate our business, I have to do it well, and we do it exceptionally well because we rely on frameworks that have been developed by security experts with very strong opinions on building those frameworks. Similarly, I am not going to out-innovate Google, Microsoft, or Amazon on speech recognition. We’ll innovate on how we use it, but I am going to grab the highest-level abstraction off the shelf and use that rather than build my own custom version. No snowflakes.

This might sound boring to certain members of the team who would like to build everything, but you have to set the tone for everyone that comes into the company and then the culture won’t question it.”

• Using Objectives and Key Results rather than telling our story to employees

“You’ll have success and you’ll grow, and you will need to align your company to your decisions and provide the right context for the decisions you made. We’ve all read the blog posts; you’ll choose an Objectives and Key Results (OKRs) framework to get the job done. We did, and it didn’t work out very well—not the first time, or the second, or the third. The thing we learned, is that you still have to be good at telling the whole story of your company. The whole is greater than any part.

We naively thought that writing this elegant framework was going to take some of the work off our plate for inspiring the organization. It didn’t.

People don’t like looking at metrics every day, and they don’t like running while they are looking at their toes. You have to inspire. Focus on the vision, and tell the story. We still rely on OKR’s, but it is not the mechanism for sharing business context or for sharing inspiration, it’s for measuring objectives.”

(This article has been edited for length and clarity.)