Five Lessons from Building A Great Core Team at Standard Treasury

It is hard to hire people. It is very hard to hire great people. Our core team is amazing. I hope that by telling the stories of how we hired our team, haphazard as they are, others might get a sense of how to put together a good team.

Yesterday I told the story of how Standard Treasury's founders knew each other and today I am telling the story of hiring our first three employees. With that story I share five lessons learned about hiring: get your message straight, start now, do whatever it takes, be aggressive, and create a process.

I have talked to a number of YC founders that are at much later stages than us. They admitted they had a terrible time hiring at the beginning. They just didn't have access to top-tier talent. They didn't necessarily know at the time what top-tier talent was. Some didn't go to fancy schools and didn't have great networks. Some did YC when it wasn't what it is perceived to be now.

Once money is no longer your biggest problem, hiring is. They succeeded through grit, persistence, and a healthy willingness to fire people when they needed to.

We made offers to our first two hires before we quite finalized bringing Brent on as our third co-founder. As two only quasi-technical co-founders Dan and I have just gotten lucky at their quality and we have learned some lessons along the way.

I have a good sense of whether someone is an asshole or not, whether they can break out and plan tasks well, whether they get or are interested in our business, or whether they're completely full of shit technically. But, whether they can abstract classes well, can deliver high-quality software, can keep to our bank-imposed deadlines without sacrificing too much, or can write good test coverage...well, I'm flying blind other than that I know enough to ask the questions and see if my full-of-shit-meter goes off.

One thing we did have though was a great message. We have a big idea that scared most people away, and a network big enough to run references on almost everyone that came our way.

Lesson 1: Get your message straight. Think about how to message your company as much to candidates as you do to customers. We realized that Standard Treasury is potentially a big business but all the challenges were in relatively boring, if complex, topics like building against legacy interfaces and presenting unified APIs despite those crazy backends. We embraced the boringness and made it a strength: you can work on a big serious problem or with the others guys. To us, having a boring idea made it so the excited candidates were genuinely excited.

As one of my co-founder says, I know enough to be dangerous in all things, but it's clear to me that if you ran the simulation a thousand times, we likely wouldn't have gotten the outcome we did very often. We hired three great engineers to our core team without doing any technical screens.

The Infrastructor

One of those two initial offers was to Mike Clarke. Mike was in charge of infrastructure at Disqus, where he helped to serve more than a billion 'uniques' a month.

Mike and Dan knew each other from their days in Chicago (having been introduced by the great John Fox), but stayed in touch when they both moved to San Francisco. They ran into each other a lot, on the line for Senor Sisig (a food truck that's often on 2nd and Minna), and Dan would always say "When I found my company, I'm going to hire you!" Mike thought Dan was crazy. Dan had no idea just how good Mike was.

I looked through my emails and found that we started the conversation by Dan emailing Mike the TechCrunch launch article with the subject line: "Leaving disquess and joining Standard Treasury." Correct spelling wasn't critical to Mike.

A few long conversations later, Mike joined the team. Mike has ended up being the perfect early-stage engineer: a great coder, dedicated, thoughtful, fast, willing to take on anything, and with a skill set that has been critical to launching within banks.

Lesson 2: Start now. Always be recruiting. In the case of Mike this meant even before we started the company. You know who your best engineering buddies are. You know who you can work with every day all day. Start recruiting them even before you start your company. Maybe even years before. Recruiting takes time.

The Bank Integrator

Keith Ballinger proved easier to find, but, we were even less thoughtful about whether he had the right technical chops. We fell into him being a killer engineer. Keith worked for many years at Microsoft, including as an original core contributor to C# and .NET (although no one hates what it's become more than Keith) and then worked at a series of startups. He's our go-to expert on crazy enterprise software. He and I often handle all our bank integration meetings together.

Keith applied through Hacker News' jobs page along with a couple hundred other people last summer. Dan and I both met him once or twice. He seemed competent and didn't set off any of our red flags. We did a few reference checks that came back positive, but never did a technical interview. Then we offered him a job. I don't suggest that as a model for hiring employees.

Lesson 3: Do whatever it takes to find great candidates. Posting on job boards creates a lot of resumes and a lot of work. It isn't efficient but finding a needle in the haystack is worth it. Great engineers multiply your productivity and value exponentially, so spend time doing whatever it takes to find great people.

The Platformer

Last, but not least, Jim Brusstar rounded out our core team. Jim's the only one we hired who we knew was good — Brent had worked with Jim for years at Facebook. After Jim left Facebook to work as an engineering lead at Sidecar with his college buddies, he and Brent kept in touch. And when Brent told Jim he was founding a company, Jim was eager to learn more about the idea and meet the team. Jim joined thereafter.

Jim is the core author of our API infrastructure and is every bit as fanatical about code quality as Brent. Which makes sense, since he's the first person we hired based on knowing whether he was good or not — and he's been great. He keeps us all focused on the question of what will developers — and not necessarily our paying bank partners — want in the API. He's critically focused on building an excellent product experience and rounds out our core team perfectly.

Lesson 4: Be aggressive. Reach out to everyone you would love to work with. No matter how senior or junior. No matter how comfortable they may seems. You never know. Think through everyone you've ever worked and would like to again. Reach out to them as soon as you start your company. Some great candidates will jump, like Jim, others will take time but either way you're letting people know you're looking and you're setting people up to think of you when they do want to jump.

Hiring Moving Forward

Now, hiring is much more of a process. We've iterated through a ton of different technical questions and screens. With almost every candidate, we use the same process: a 15-minute intro phone call, followed by a 45-60 minute coding screen (usually on a call with a virtual whiteboard, but sometimes in person), then a 4-hour coding challenge / homework assignment, concluding with a 4-hour on-site interviews. The top of our funnel had hundreds and hundreds of resumes, we've done dozens of coding screen, we've had seven or eight full on-site loops, and we've made two offers.

Lesson 5: Create a process. Even at a small startup, process is important. We are inundated with applications that need to be sifted through and lunches with old friends. The only way one can manage it and feel like one is being fair and polite to every candidate is to create a process. A process allows you to move quickly, give people feedback, and seem like you have it together.

We've also been able to articulate, make known, and get a lot of feedback, on our values, which seem appealing to the types of candidates we find attractive:

  • Excellence. We are building a team of great women and men who work hard, have a passion for perfection, and don’t tolerate bullshit.
  • Candor. We practice internal transparency, and are candid about our finances, business development, and planning processes.
  • Quality. We build bank software - our motto is more “slow and steady wins the race” than “move fast and break things”. Our critical technical values are security, reliability, consistency, maintainability, and craftsmanship. We emphasize tremendous attention to detail and build software that lasts.
  • Collaboration. We use Phabricator and support each other with code reviews. We have a healthy culture of debate without argumentation.
  • Entrepreneurship. We encourage people to set their own direction. We are looking for senior engineers who can lead product decisions. All engineers are able to suggest, research, and lead architectural changes, contribute to, and suggest, revisions to our road map, and create new coding guidelines and have them enforced.

If those sound interesting to you, or if you're just interested in joining a place that (by sheer dumb luck) has a great core team, then check out our jobs site.