Zac Townsend

This morning was my final data collection for a randomized diet experiment I have been participating in for the last year. Here is a graph of my near-daily weigh-ins on Withings:  

(This started as an email to the Standard Treasury team to summarize the many conversations that my cofounder Dan and I had with them over lunch, dinner, coding, and a ton of product discussions. The team thought it made sense to share it publicly.)

I often get asked to tell the story of Standard Treasury: Why are we building it? What is our vision? How did we come to this thing over all others?

When asked questions like that one, I think it can be easy to fall into simple narratives or platitudes: we are revolutionizing banking, and have been, since day one! I'm not exactly sure what that sentence means, and nothing worth doing actually comes in a flash of genius. Certainly not by folks like us, who have always gotten on in the world through persistence first, and smarts a distant second.

The bigger problem is that I never have the time to tell the folks who ask the questions all that is on my mind, so I ended up telling them bits and pieces. This [blog post] is designed to tell much of the story although I still haven't captured it all by any means.

The Underbanked and Engineering Financial Operations

For me, the genesis of Standard Treasury was based in the two experiences I had in the year before founding the company.

The first was when I was working in public policy and civic technology in New York City and Newark. Particularly when I was working for Cory Booker and staff in Newark, I became curious about underbanked people — or the problem of financial empowerment as it is sometimes called. I talked to a ton of people about their use of payday lenders and check cashers. What I found was surprising to me (in my ignorance): most underbanked people or small business owners are familiar with banking products, their use, and their relative value over the options they were using.

So, why didn't they use banks? The answers fell into one of two buckets. The first is that they wanted lending products they couldn't get, since the banks considered them too much of a risk. The second was that banks just wouldn't offer them other products even if they had nothing to do with lending. I found this second answer rather perplexing, so, I went to talk to a bunch of banks. What they told me was simple: it cost money to maintain bank accounts — serious money — and if you weren't going to cross-sell customers something, it didn't make sense to bank them.

That surprised me. The more research I did with banks, the more I realized that it was their legacy technology that led to their cost structures. Cost structures that prohibit them from banking some people. In essence, there are folks that banks don't market to and avoid banking because the banks' business models makes those people unprofitable customers.

The second experience was when I was working at Stripe. I won't go into a huge amount of detail here — I try to be careful about my nondisclosure requirements. Having said that, financial operations is a serious engineering challenge at Stripe (see CTO Greg Brockman's Quora answer and the section on financial operations). While working there, I got to see, firsthand, how difficult it was to operate in systems, protocols, and technologies that were designed and built in the 1970s.

Starting Standard Treasury: Commercial Banking API

Standard Treasury started because we experienced the difficulty of working with banks firsthand. Way before the company started, Dan and I had been thinking about why ACH is flat-file driven, slow, and seemingly from a different technological age. Having worked on issues of the underbanked, I realized the real-world impacts of legacy technologies, and working at Stripe highlighted how much of the credit card system was driven by similar technology. The same ideas were highlighted for Dan when he was working on pre-paid cards and stored value.

Standard Treasury was born.

We were focused on the problems we knew firsthand, and used the cases we understood best from our friends. In the early days, we talked to nearly one hundred folks about their banking experience. Some were running small companies, others were the treasurers of Fortune 500 companies. They all said roughly the same thing: "The technological interfaces around my commercial banking experience are terrible and limit my capabilities." Many mentioned Twilio, Stripe, AWS, and Heroku as models of what they wish their banks would be: technology platforms providing services.

From that, we started working on a white labeled commercial banking API platform. This first product was clear to us: companies, big and small, want to build financial functions — primarily on information about their accounts and cash payments — directly into their applications. In the coming months, we will finally be able to see the result of all that work as more than our Make Believe Mutual demo site: after a series of proofs-of-concept we have the option to launch our first, full production platform.

Developers, with a bank account at the bank in question, will be able to go to developers.[bankname].com and use an API platform, developer portal, and SDKs in half a dozen languages to interact with their bank accounts programmatically. Hopefully, a number of our other proofs-of-concept projects will convert into full production platforms with some of the biggest banks in the country and around the world.

Taking Steps Beyond V1.0 of the Commercial Banking API

From there, some product expansions in commercial banking will be inevitable: more information reporting, more cash payments, liquidity management via API, and other banking functions like foreign exchange and lending against receivables (factoring).

The most exciting thing that we've built, however, is an OAuth service that allows commercial customers — some of whom will have no idea what an API is — to use the bank's authorization service to delegate access to the API to third-party developers. With that service, developers will be able to build apps that access their financial information and cash payments, just like Facebook Connect allows granular, secure access to the social network. We hope that folks like Xero and Intuit will build apps, but we are starting to get to the real goal here: allowing developers to think of banks as platforms.

Broadening the Vision

In investor meetings and in candidate pitches when we got into YC, we made the idea of Standard Treasury bigger by abstractly focusing on the idea of bank software being broken. We did not really know what that meant. It was a hard-to-unpack intuition from the state of online banking, rather than something we really understood in particular. Something was wrong. We would find it, and we would fix it.

Over the last year, though, we have learned a great deal about the particulars. We have picked the brains of bankers; fund managers; treasurers of big corporations; startup founders working on finance; startup founders trying to avoid finance who, nevertheless, touch it more than they'd like; executives at our competitors; academics; journalists; experts and leaders from card networks and credit card processors; folks concerned about financial access like the Gates Foundation, Cities for Financial Empowerment, and Omidyar Network; and many more. I read the Financial Times and books on obscure parts of the financial system every day. Dan and I also went through Silicon Valley Bank's and MasterCard's joint product accelerator, Commerce.Innovated, and the NYC FinTech Innovation Lab where banks choose the companies in the program which they are going to mentor. The banks that chose to mentor us were Goldman Sachs, Credit Suisse, Morgan Stanley, and Deutsche Bank, who have been very helpful in highlighting areas of expansion for us.

In that deluge, several things became clear. First, we learned that bank software is a very big market. Even bigger than the number I made up with some back-of-the-envelope math for my YC Demo Day pitch!

Second, we learned that the market is dominated by large public companies that no one in Silicon Valley is aware of, much less really competing against. Banks, almost universally, have bad things to say about the technology and the pricing schemes of these vendors.

Third, we learned that API Banking is much more than a cool feature for banks to have for corporate clients: anywhere that customers interact with their banks is a place that a bank might imagine a well-built API. Banks have approached us about building white-labeled API platforms for lending, sales and trading execution, broker/dealer settlement and exception handling, prime brokerage, card processing (acquisition and issuing), custody accounts, fund administration, retail banking, private wealth banking, repo and other money markets, trade finance, know your customer and anti-money laundering procedures, risk management, and more. (What keeps me up at night is the possibility that we're passing up opportunities by not scaling much bigger, much faster.)

Fourth, we learned that as we build interfaces for external customers to access legacy systems, banks are facing internal and external pressures (e.g. stress test requirements) to build cross-functional interfaces for their own use. Some of the biggest pain points that banks face is talking to their own internal systems.

Fifth, we learned of this platform's potential impact on the world. Every week Dan and I get referred to folks who are starting financial technology companies or not-for-profits. None of them want to be in our business, but nearly every one of them would be able to make their work easier, faster, and better if banks used our products. Despite all that is happening in fintech, there is a lot of pent-up developer and technological potential — potential that would actually help banks, which their unwieldy technology keeps them from enabling.

Banking Today and Tomorrow

There are two types of common innovations happening around financial services: tools that provide some gateway into the financial system, but abstract it away (like Stripe, WePay, Plaid, Spout, WealthFront) and shadow-banking alternatives to a common financial product (Lending Club, OnDeck, Upstart, LendUp, ZestFinance).

We are doing something different: we are working to build the next generation financial infrastructure by building products, interfaces, and developer tools directly.

No matter what changes will happen in the next 10-20 years in finance, we believe that: (1) Banks are here to stay. Banks will exist in the future. The center of the financial system will include banks. (2) Banks need 21st-century technology. (3) Standard Treasury is uniquely positioned as a Silicon Valley startup focused on banking infrastructure to sell to that need.

Enabling the Next Generation of Commerce

So why does all this matter? Well, partially, it matters because I already have friends who are building mobile apps for underbanked folks that are built directly on abstractions that we're helping them with. That really matters to me; it's a huge part of what originally got me into this business. But beyond that, at a more abstract level, we care about building the financial infrastructure because banks are at the center of commerce.

Sometimes, it is easy to think that banks are an end unto themselves and all they do is extract wealth through speculation or innovative wizardry to screw their clients. They do far more than that, too.

Financial and payments systems — including the money markets, foreign exchange, credit cards, ACH, CHIPS, FedWire, debt markets — are all designed to facilitate trade. However, trade is hampered because, although we've entered the Internet age, the technology at and between banks is often in the Sputnik age.

Standard Treasury aims to improve the ways that companies and households do their financial business. We hope to enable developers of all types to build the next generation of tooling on top of banks. We want to improve the ways that clients interact with financial institutions; financial markets; financial market utilities; and payment, clearing, and settlement systems. We build systems to increase global trade, global commerce, and maybe global GDP.

That is an audacious goal and comes with a core thesis: if we improve interfaces inside banks, between banks, between banks and customers, between banks and (technologically sophisticated) resellers of financial services, and between banks and other counterparts, then we can change the very nature of trade and commerce. We can reduce friction. We can lower transaction costs: both the literal costs of transactions and just the pain that exists in the financial system. Ideas that were impossible become possible. Businesses that didn't make economic sense suddenly do. People that were unbanked before suddenly become bankable customers for someone.

Our goal is to make it easier to run businesses — online or off — in the United States or around the world. And as we serve as a data, abstraction, and tooling layer between different banking systems and between different parties that are doing banking, we become a permanent feature of the banking system. That last part is good for us and our investors, sure, but I hope it's also good for the world.

What's next

Through Dan's prodigious marketing and sales efforts, we have come to own a lot of "mindshare" around API banking. That ownership allows us to dream what I've written above: to build the coming generation of financial infrastructure.

We have also done something that is nearly impossible: we are a seven-person company that is being paid by a bank for a product that is loved by nearly everyone we've shown it to. Tons of feedback, yes. Tons of feature requests, yes. But our potential users, nearly universally, loved its execution and, perhaps, more importantly, its potential.

Thank you, all of you, for helping to take this crazy idea and make it a reality.

A conversation seems to be slowly starting about mental health and Silicon Valley, or at least mental health and starting one's own company. And in a more serious fashion than "you'd be crazy to do it". Sam Altman on Founder depression started the conversations. TechCrunch continued by noting that We Need to Talk about Depression (which also has a good list of links to other similar articles) and Founders on Depression.

In my earlier post, Founders and mental health I wrote primarily about the range of mental health issues that founders can face. We should remember that depression isn't the only manifestation of mental health challenges.

Many people emailed me, talked to me in person, and even wrote a Quora question on one particular thought from that post though: that lots of startup founders I know have experienced some trauma in their past and that that trauma is often a strong factor in their motivation. Sometimes that trauma is a root cause of depression or anxiety or motivation, sometimes it is just present and something to deal with, and obviously sometimes it doesn't exist at all.

I thought I would explain the idea a little more though.

Over the last year I have found that most startup founders had some deep personal trauma in their early lives. Not all people but more than I might expect. Glen Moriarty, the founder of 7 Cups of Tea, and I have discussed it at length but it has also come up with many folks both inside and outside the YC community. It's a topic that someone resonated as something to talk about when you're stressed out and bonding late after one of YC's Tuesday dinners.

The trauma theory made immediate sense to me as I have made a similar observation about many, if not most, of my friends and classmates at Brown. Either they had screwed up childhoods and were motivated by that somehow, or that had intensely attentive parents and were trying to live up to expectations. Either way, I did not find many settled content geniuses who found their way there.

There is a fundamental difference between schools and startups though: in one you know the goalposts and in the other you don't. At school, you are told what targets to hit for success while startups are much more chaotic and kinetic. To me, the idea that some deep, often traumatic, motivation is a powerful catalyst for success, made all the more sense in the world of startups. You have to really want it for whatever reason.

And that reason is often something from one's childhood.

Perhaps I shouldn't use such a broad brush to paint so many people with so common a set of neuroses. It's certainly not the case that everyone that succeeds in life has trauma. (And not all trauma leads to success obviously). But I wouldn't doubt the predictive power of the idea either. As I talked with new friends in YC, throughout Silicon Valley, and beyond about deeply personal topics the theory seemed more accurate. Or at least I had more data supporting the idea. (Although this could all be a selection bias).

In my case, my parents had me when they were incredibly young and promptly got divorced. I lived with my mother, an alcoholic, until I was ten. At that point, we had gotten in so many drinking related car accidents together, that my step-father was asking for a divorce and child welfare agencies demanded I move to live with my father. I didn't see my mother again for eight years.

You know, perhaps if my startup succeeds my mother-of-1997 will treat my ten year old self better? I'm partially joking and partially not.

Dan, my-cofounder, his father died when he was one. His mother was in a coma for some time and had to learn how to talk and walk again. Hopefully his father will be proud of his first billion dollar company.

Time and time again, there are similar stories that come out from co-founders I meet, mostly because I can be candid about my background and this theory. Some with less intensity perhaps but no less motivating to the individual. Some with a lot more intensity but with less motivation. I don’t necessarily feel empowered to share their specific stories here but they're often there, serious, and touching. The speed and positivity with which folks, many profoundly publicly successful, respond to this idea further suggests that it hits on some truth about the startup community.

Ultimately, I spent years of my college life in a path of depression, crisis, and then renewal that have made me stable, happy, and sure of who I am. In many ways I am fortunate that that happened so early in life and not when the consequences of my errors affected many people beyond myself. But at other times I wonder if I lost a little something. Something that people who haven't faced down their demons still have. After all, I was amazingly productive and won many collegiate awards in 2007, all the while self-destructing.

This is correct in the sense that what I do now is no longer compulsive (i.e, unconscious). I was succeeding out of an unconscious drive or push. Now that I have awareness, I can see that I still have this same drive and push, but I can choose where to focus it. It isn't compulsive now.

A number of friends and many people who emailed me after the last post asked me about my experiences through depression and therapy. That write up will be my next post.

Last week Sam Altman wrote about Founder Depression. Catherine Shu followed on, among others, with a candid telling on TechCrunch of her struggles with depression. I applaud them both.

Many startup founders I know aren't depressed though. They are anxious.They are on the spectrum of anxiety disorders. Real existential concern about whether they'll make it. Whether they're doing the right thing. Whether they'll raise money. Actually that last one isn't anxiety: strictly speaking anxiety is generalized and unfocused fear. A lot of people who are running startups fit that bill though, they have terrible unspecified fear (of failure). You can get pretty far down the anxiety spectrum and just seem like a founder who cares. That is dangerous.

Highlighting depression is useful but also limiting. It can demarcate people who have had certain problems without highlighting others. I believe our community — Silicon Valley, Y Combinator, startup founders, or all ultra-high-functioning professionals — should be having a conversation about mental health more generally, about the sources (sometimes quite dark) of our motivations, about pathologies, about depression, about anxiety, and about other problems. Or, at least, be more comfortable having those conversations privately.

I know founders who are on the depressive spectrum too, which can range from the blues to deep clinical depression. I have a history of depression myself. I have not had a serious depressive episode since I took a year off from college and invested in intensive therapy, but most people don't have that luxury — or they are not comfortable taking that much time given how taboo mental health can be. I remember when I was in the depths of my depression spending eighteen hours in bed with a dreadful sense of melancholy. That's a serious case — I couldn't have run a startup when I was depressed — but depression hits people in different degrees. Someone who seems fine often isn't.

Depression and anxiety are just two examples of the challenging mental health that startup founders can have. Anxiety and depression are often described as opposites, which is too simple a story, and they need not be opposites in our mind. Either can be dangerous and destructive. We need to talk about both. The names of anxiety and depression can sometimes just obfuscate things more: We need to talk about much more too. I know a few (medicated or not) bi-polar founders. I know a few diagnosed with OCD.

No matter the diagnosis or the name, founders can feel isolated by their mental state. They can feel alone, which can make them more depressed, more anxious, more obsessed or whatever. But whatever your particular problem is, I promise you, other people have it. People in the community have gone through it. Many people have gone through it, in fact.

Over the last year I have also found that many startup founders had some deep personal trauma in their early lives. Glen Moriarty, the founder of 7 Cups of Tea, and I have discussed this idea at length and it has come up with many folks both inside and outside the YC community: startup founders insatiable motivation often comes from trauma.

We are all unique but most of our problems are not. Startup founders are so often a community that helps one another with introductions or advice. I hope that in time we can all be as comfortable talking about our mental health. That we could be as comfortable giving advice about our depression or our anxiety as we are about fund raising.

I might write a lot more about this soon. I don't know. Some of my friends, colleagues, and investors have cautioned me against being too public about my own history and my own traumas, but any founder should feel they can contact me, if no one else, whether they're depressed or anxious or something else (or use 7 Cups of Tea).

Banks have a nearly one-size-fits-all product model which leaves value on the table. For instance, when a bank releases a new online or mobile banking system, it will often be an identical system, with the exact same interface, for all clients of a particular segment. But oil companies like Chevron have different banking needs than do retail companies like Home Depot, even though they may be the same size. This type of mass standardization and lowest-common-denominator mentality applies even more to the retail customers — usually there are just two online and mobile banking options: one for normal customers and one for private wealth clients.

Technology that is new to banking is ushering in an era where mass customization is feasible, safe, and profitable.

Banks of all sizes have spent the last half-decade cleaning themselves up in the wake of the financial crisis. They have been implementing new requirements from the European Banking Authority, the United States Consumer Financial Protection Bureau, and other regulators, as well as adapting to Basel III and other new capital requirements. Many have built new risk management and compliance frameworks in response to sector-wide malfeasance.

Now, though, banks are refocusing themselves on growing top-line revenue. Many banks have organized new teams focused on revenue growth through “the innovation agenda” and “customer experience”. Technology is understood to be a potential driver of the sought-after revenue growth. One such technology will be “API banking” – a concept that, though it seems to have achieved buzz-phrase status, represents a new and revolutionary way of thinking about bank services and how to deliver them to customers.

API refers to the Application Programming Interface: the standards and protocols which allow outside software developers to build applications on everything from Apple’s iOS platform to Facebook’s social graph. This technology and the attitude of open development that goes along with it are now second-nature at Silicon Valley’s leading companies. Apple, Facebook, Amazon, and others capture the imagination and skill of tens of thousands of software developers through an open platform and simple profit-sharing.

With their new compliance and risk management systems, banks are now positioned to open themselves up just as technology companies have. They can build similar platforms for innovation and customer-facing customization. These financial innovations will not be used to obscure risk (as most innovations of recent years have done) but rather to improve how customers, both commercial and retail, experience banking.

We are entering an era of technologically customized banking. Trusted risk-and-regulation-sensitive financial institutions will provide the core financial services via APIs. Then they will leave many of the last-mile implementation details to trusted partners and software developers. Millennial bank customers could have their customized mobile banking with special tools focused on paying down their student debt, while Boomer customers would have an entirely different online banking suite, which could be focused on either building up or spending down their retirement, depending on individual circumstances.

Developers, and the technology that they bring, can make the unprofitable profitable for the platform provider. Just as it might not be profitable for Apple to build and then acquire customers for a variety of bird-focused games — Angry Birds, Flappy Bird, Tiny Wings, et al. — it is also not profitable for banks to build the skill sets necessary to acquire and optimally serve every potential customer. With API banking, specialized third-party developers can profitably provide services that banks couldn’t afford to build, by giving both banks and the new developer companies access to swathes of the banking market, including the underbanked.

As in the Apple App Store, bank clients will be able to find and experience banking in the manner that makes the most sense for them, in a co-branded and protected environment. Customer satisfaction increases with a more personalized user experience, and revenue increases as banks are able to target and display their offerings more precisely.

Crédit Agricole and Deutsche Bank are the only major banks with APIs and app stores in the market right now. But APIs are one of the best and most talked-about ways to increase top-line revenue in the face of decreasing fee and interest income. Many banks are working toward releasing their own this year.

Amid this renewed focus on innovation and customer experience, using APIs and the mass customization they foster is just the first of many lessons that banks will learn from technology companies in the coming years.

Republished from BankInnovation.Net.

“The skill of making and maintaining Commonwealths consisteth in certain rules, as doth arithmetic and geometry; not, as tennis play, on practice only: which rules neither poor men have the leisure, nor men that have had the leisure have hitherto had the curiosity or the method, to find out.” ― Thomas Hobbes, Leviathan

Jack Gavigan wrote a blog post yesterday titled "What would a disruptive bank look like?" Read it. It is well worth the time.

I basically have the same blog post written. I actually also have the same blog post written as a detailed fifteen-page business plan ready to pitch Marc Andreessen. I outline the technology needed in a bank, the product offerings and their rollout, the legal structure I'd use, the capital structure, relevant bank regulations. Ah and therein lies the rub.

Regulation. I know I am supposed to be a big, bad startup entrepreneur who spurns restrictions of all kind. Particularly those restrictions put on me by the government. But that's just hard to do in this case since you need a license to operate.

Banks don't often fail. They don't often fail because there are real limitations on who can buy a bank and how one can run a bank in the US. Those two ideas – hard-pressed to fail and deeply restrictive operations – are two sides of the same coin.

So, how does that manifest directly for the bank-running entrepreneur?

1. Maddening capital and other ownership restrictions;
2. Deep restrictions on personnel and hiring;
3. Writing a initial seven year business plan and sticking with it for seven years; and,
4. Deep restrictions in the operations of a bank.

The key problem of restrictive category number (4), and why I walked away from spending so much time on building a bank, is that regulators artificially restrict a bank’s growth rate. The number one historical indicator of a shady bank is rapid, radical growth. Very good lawyers, regulatory advisors, and current regulators at the FDIC, Fed, and the FFIEC have all told me that any new bank would be restricted from growing more than 25% a year. Is that enshrined in law? No. However, latitude and discretion is.

25% a year. A good startup grows 25% a month for years.

I think you're left with four choices then:

1. Figure out how to bring technology into the banking sector in a high-margin, fast-growing way (that's Standard Treasury);
2. Build a bank and hold it for a long-time or buy an already big bank (despite all I've said, several investors have approached us about this);
3. Build a bank someplace in the developing world that has less restrictive laws and then port it back to the US later (ready to talk when you are Marc); and,
4. Avoid banking, per se, altogether. Build out different parts of banking like lending (Lending Club, SoFi, Capital Access Network, On Deck) and payments processing (Stripe, bitcon startup du jour).

Last year, I shared our story of applying, our application, and some advice on the YC application. Now that the Winter batch is in full swing and the application is open for the summer, I thought I would share our story of going through YC and nine lessons I learned in the process.

I have had a lot of trouble writing a post about going through YC. It was one of the best and most productive experiences in my life; it was also one of the most difficult and stressful experiences in my life. As I have attempted to write, I've faced some difficulty in avoiding both what could be a boring recitation of facts that are widely known and a sensationalized portrayal of the experience.

YC left me more scared and yet with more optimism and excitement than any other three-month period I have lived through. YC is hard. You're stressed out. You're underslept. You think your company is on the verge of collapse (and the companies of some of the people around you are). The partners' advice is brutal — brutally honest and unvarnished in its delivery. YC is relentless. Difficult. Stressful. Thrilling. Unforgettable. Worthwhile.

The best metaphor for YC is a slow-cooker. Every week YC cooks a meal for fifty companies (now seventy) in a bunch of slow-cookers. That's all it takes: time, heat, and a pressing deadline for delivery. Sometimes you throw all the ingredients in and get a good dinner or a good company. Sometimes it's crap. No one seems quite sure beforehand which it is going to be.

If I ever found another company I would do YC again. Well, if they’d have me.

Lesson 1: Do YC if you can. It's worth it, but it isn't easy. (I promise the other lessons are more surprising!)

But let’s go back to the start.

If you get into YC, they call you the same night as the interview. The phone call is brief: do you want to accept the offer to join YC, and can you do an introductory talk on Wednesday in Mountain View? We said, "Yes".

Orientation

The orientation involved two parts: one where Paul Graham (PG) talks and one where Kirsty talks. This may change now that Sam Altman (Sama) is YC's president, but the gist will likely be the same.

PG condenses the most important lessons of YC into about two hours. It's a dizzying talk, even though most of what he says are in his essays. The most important piece of advice is to "start now". The day you get into YC you can start going to office hours, and you're told when Demo Day is. In effect, YC is on, even if the dinners don't start for a few weeks. Get working. There are a fixed number of days between acceptance day and Demo Day. Anything you do before Demo Day you can use to impress investors on Demo Day. Anything you do after Demo Day still matters to investors, but it likely won't matter until much later.

Kirsty Nathoo spends the second half of the day describing the basics of corporate setup. She goes over all of the associated paperwork, the YC investment, the YCVC notes, and advice on what to spend money on. It was a fast, expert primer on corporate law, corporate finance, startup financing, benefits, payroll, and more.

Part of being a startup founder is learning tons of stuff which you might not be comfortable starting with. That's what's great and what's challenging. One thing we learned early on is to embrace all the learning: being a startup founder is about constantly doing new things outside your comfort zone.

Lesson 2: Be comfortable doing anything. Learning anything. Working on anything. Most parts of founding a startup are unglamorous. Like talking to your lawyer about how to get the best strike price on your options for your employees. Or making sure that payroll taxes get paid. But that's what a great company is: a thousand carefully, but quickly, made decisions.

Moving to Mountain View

YC recommends that you live close to YC for the duration of the batch. They say that this is because they’ve found a high correlation between startups that attend YC events and those that succeed.

It’s also the case that there is a lot less to do in the Valley than in San Francisco if you’re young and childless. You will work more. Part of PG’s advice is to do little other than code, talk to users, sleep, eat, and exercise. That advice is much simpler to follow when you’re living in Mountain View; there is only so much you can do on Castro Street.

Lesson 3: Avoid distractions when starting a new company. Find a way to build and do little else. Go to the wilderness — by which I mean Mountain View — if you have to.

Dan and I lived with Kai and Claire from True Link Financial in a small house that has passed from YC company to YC company for a few years. Claire and Kai have become some of our closest friends, more broadly. They’re both amazing people, dear friends, and quite well-rounded in their interests. They also became reviewers and supporters of our work, with a much deeper understanding of working in fintech than most of our other friends.

Living with another team with whom we grew so close was critical for us. Otherwise, I think we would have torn ourselves apart. I'm not sure it’s necessary for everyone, but for two guys from New Jersey anything else would have led to a steel-cage death match.

Dan and I spent a huge amount of time together over the summer, but one rule we had is that we spent Saturday apart. We needed that time.

Lesson 4: Don't give up all human contact — just most. Do what it takes not to murder your co-founders in their sleep.

Idea iterating

We spent most of the first few weeks trying to figure out what we were going to build. Whether this is what YC meant by "start now" could be up for debate.

We were trying to figure out — in the abstract — what our business model would be. We spent most of this time just talking to businesses about what they found annoying in dealing with their banks.

In order to think through this, Dan and I walked around the same block in Mountain View several hundred times.

Over the approximately six weeks between orientation day and Prototype Day, we iterated through six ideas in sequence while talking to nearly a hundred potential customers: APIs for commercial banking (what we applied with), WealthFront for businesses, near real-time cross-bank settlement, financial reconciliation support, building a bank from scratch, and API gateway for commercial banking sold to banks. Given his experience and passion, Brent was most interested in the platform ideas.

The details of those business ideas, except the last, aren't so important to the story, but the process was helpful. We were not building anything — which I don't recommend — but we were making use of lots of potential customers to figure out what they would pay for and what their pain points were in the interface between their businesses and their banks.

Almost everyone we spoke with said: (1) we don’t like our bank, (2) we want a technology-forward bank, and (3) we want working with our bank to be as simple as working with new payments companies like Stripe, WePay, Balanced Payments, etc.

And then we just got lucky.

Our product

Starting in October 2012, about six months before we incorporated and eight months before we started YC, Dan and I had been talking to banks about an API for ACH. Our plan was to connect a bunch of banks and then have a cross-bank same-day settlement system. We were talking to J.P. Morgan, Capital One, Wells Fargo, Silicon Valley Bank, City National Bank, Citi, et al.

Then, while we were endlessly flailing around in circles in Mountain View, several of those banks came back to us and said that they wanted an API gateway. Would we sell the experience we were describing to them as a white-labeled or co-branded experience?

We were in the bank software business. Our first product was an API platform-as-a-service for commercial banking.

Lesson 5: Always be willing to iterate and always, always, listen to someone willing to pay you for your product. Paying customers are hard to find and they're often right.

Prototype Day

Prototype Day is one of the best days of YC. It's like a mini Demo Day. The order of the companies is randomly chosen and every company has a few minutes to present. It’s early on and you still don’t know most of your batchmates all that well. Prototype Day lets you learn about what everyone is doing and a little bit about every person in your batch.

The partners tell you not to prepare. However, we found preparation to be focusing, and we chose to put together a presentation. We used that as an exercise to figure out how we would pitch our idea and company to a large group of people.

After each presentation, PG tells the company's founders some of the things they did wrong. It's useful, although it's best not to be randomly chosen to go first or second. It's your first introduction to how investors might react to your pitch.

Prototype Day ends in a vote. Every founder gets to vote for two companies, then the vote is tallied, and the top ten companies are announced. I can't find any of the published results of any past Prototype Day, so I don't want to give any results, but we did fine.

Dinners

YC hosts a dinner with a prominent startup founder (or Ron Conway) every Tuesday evening. The talks are interesting — more inspiring than informative. A frequent theme is how to not get screwed by your venture capitalists. YC dinners are off-the-record, so I won't share any of the details of the talks we experienced, but they're enjoyable.

The most significant value of the Tuesday dinners is that it's the one time each week when YC turns into a co-working space. Companies arrive hours before dinner. You have many of your office hours for the week, you chat with Kirsty or the Levys (YC's two lawyers) about a random question you have, you catch up with everyone in the batch, and you get as much user feedback as you can get in the hours before dinner starts.

Lesson 6: Set deadlines for yourself. Always have something to fight towards, even if it's not concrete. Measure your progress even if the measurements are artificial.

The dinners are weekly milestones. Most people work their butts off all week culminating in Tuesday. Report back. Rinse. Repeat.

The Batch

One of the most important aspects of YC is that they fund companies in batches. And not just so YC can have dinners with good speakers. Batchmates make fast friends who stick with you long after YC is over. Dan, Brent, and I each invested in several companies in the batch!

You go through an adventure together. Batchmates are always willing to offer help with a product question or support you when you're down (and there will be times when you're down). It's hard to come out of Tuesday dinners without feeling energized because you've gotten that emotional lift (and competitive spirit) from your batchmates.

Office Hours

There are now seven different types of office hours. The regular and group hours are the only ones that happen frequently, so I'll describe them.

In regular office hours you meet with a partner for ten to twenty minutes. You talk about the progress you have made in the last week or so, discuss the particular problems you're facing, and ask any questions you have. In our batch, each company selected a partner or two as its primary partner(s), but now I think they assign one of the full-time partners to each company. We chose Geoff Ralston, who was perfect for our personalities: direct, to the point, and no-BS.

Group office hours happen every two weeks. Our group partners were Paul Buchheit, Kevin Hale, and Kirsty. Group office hours are like regular office hours, except they're public and shared. Each startup takes a turn giving an update and interacting with the partners. This is useful because it allows you to see the problems that others are facing (and also how they solved them!).

Selling Software to Banks: Slow Weekly Progress

Selling big, complex software to big, conservative institutions is hard. It is slow. During our YC batch we almost always thought we were just a couple of weeks away from having a deal: next week we will sign a deal with bank X, we said. We said that every week. We told investors that. We told YC partners that. We told friends that. We believed it. We were wrong.

Now that we have signed proof-of-concept deals that we are only now negotiating into definitive agreements, I can say with confidence that we were naive. We didn't know how enterprise sales worked. Experience has educated us. Harsh experience.

However, I think this made us look bad to YC. In retrospect, we were like boys who cried wolf. PG has said that the best way to tell which startups are going to make it is to look at their weekly progress. We did a lot every week: tons of meetings with banks, product and security reviews, etc. — but I am not sure any of it looked like progress.

Lesson 7: Every YC company (every company!) is a shitshow in one way or another, even if you often think it's just you. There's power in realizing that that's OK. It took many of our batchmates too long.

In December, I voiced my concerns about crying wolf to PG in an email when he asked about our progress (I think he emailed the entire batch). He said:

Don't worry too much. Deals of this sort are always slow.

If I were in your shoes, I'd focus on sales of whatever type I could get. As soon as you reach breakeven, everything changes. Slow customers are no longer fatal once you're profitable; they can decrease your growth rate, but they can't kill you, and if the market is big you'll eventually get big.

Deals of this type are slow. All enterprise sales are slow. YC was amazing, and I tell all my friends to apply, but it is also difficult for companies like ours - companies where a small number of large deals define them. Those types of companies may be on the path to success, but they aren't like consumer companies that can show that desired week-over-week growth.

It is an expectations-versus-reality disconnect. What is possible for other companies was never possible for ours. Yet YC holds up a mold for all companies to fit into. As YC grows and includes more enterprise companies, I'm curious to see how they manage that challenge.

Fundraising Too Early Before Demo Day

YC tells you to avoid doing it in the first two months. We did it too early. It was a mistake. In fact, we screwed up our entire fundraising process. Three friends told us that normally people who mess it up so badly can't recover; we somehow still raised a healthy seed round. I'd say we fucked the whole thing up, except we did end up with millions of dollars. If I ever find the time, I'll write another post on what not to do, but YC is right: don't raise money until you're ready.

I think that the ideal time is likely about two weeks before Demo Day; at that point you may or may not feel ready, but you're going to have to be so it's time to start acting like you are. People ask on Demo Day how much money you've raised, and the answer shouldn't be zero. But if the answer is that you closed the round (or that you got too many "No"s, too early), then that might be just as bad.

Lesson 8: Take advice. Sometimes your friends and advisors are right even if you think they must be wrong. Don't go with the crowd but try to do the right thing for your company at the right time. We didn't have the confidence to refuse introductions and meetings with big VCs until we were ready.

Rehearsal Day

Roughly a week before Demo Day you have a Rehearsal Day where every company goes through their initial pitch. Every company presents, there is a vote at the end, and you get in-stream advice. In fact, this time PG will just interrupt you with advice. This is the beginning of a week long sprint that culminates with Demo Day.

You have to practice this presentation so much that, despite its being scripted to the word, down to the second even, you sound perfectly natural. This proved not to be a strong point of mine. I can give good, if not great, off-the-cuff presentations — in fact, I relieved my stress by giving everyone else's presentations (sometimes in a joking tone) and helping batchmates come up with new phrasing, new ideas, new ordering, etc. But getting down the exact wording that I agreed to with PG? That took me all week.

Demo Day

The night before Demo Day is Alumni Demo Day in the same venue; I did not do well. I felt like I spent every single waking moment between that and our presentation on Demo Day practicing. I walked to the Computer History Museum from our Mountain View house giving the presentation to myself over and over and over again.

I think the first time I gave the presentation perfectly on stage was on Demo Day itself. It was a good time to peak.

When not presenting at Demo Day, you are surrounded by investors. It's ten solid hours of answering questions, discussing valuation, and trying to close some deals.

It was exhausting. It was exhilarating. But that's YC for ya.

Lesson 9: Enjoy yourself. Building a company is exhilarating, even if it's exhausting. You are building something through grit and persistence, so it's best to have some fun while you're doing it.

Thank you

Thank you to those who helped edit and advise me on this post — my co-founders, Brent Goldman and Dan Kimerling; my batchmates Aaron Feuer, John Gedmark, Glen (Professor) Moriarty, Claire McDonnell, Jake Heller, Nathan Wenzel, Patrik Outericky, and Maran Nelson; and the best-damn-proofreading-friend there is, Kate Brockwehl. I am always in debt for her countless suggestions of great value: and for all the present semicolons.

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.

The number one way that startups in Y Combinator fail is through founder disputes and divorces. It often turns out that people cannot work together or one of the founders can't really work on startups at all. So picking who to work with is one of the most critical things you can do to ensure that your startup will get through the early stages.

Y Combinator applications just opened for this summer's class. It seems like a good time to talk about how Standard Treasury's co-founders knew each other and laid the foundation for sticking together, raising a seed round, launching a product, and building a good team.

My two co-founders and I know each other in much different ways that basically mirror the two ways one should find co-founders. With Dan, we have been friends for over a decade. We have discussed founding a company together for years. We know each others habits, strengths, and weaknesses inside and out. We knew we could work together.

With Brent, we knew each other for only months before we started working together and we were constantly assessing whether we could work together, figuring each other's style out, and ultimately deciding we could be partners carefully and over time. We vetted each other in-person and through friends and professional contacts. We came to know we could work together.

If you're going to found a company with someone, I'd suggest having one of these two stories: old friends or careful decision. I have never seen anything rushed or careless work out well for the startup or the team. I have never seen it work out just because folks can agree on an idea. Startups are more hectic and trying then that. In that way, the story of how I know Dan and Brent can be instructive to the ways one should know and vet their partners.

This is the first of two posts on building our team at Standard Treasury. The second post will be on our first three engineers. Building a team is the most important priority of a startup. With a great team, one can get through most troubles. With a bad team, even the best startups can fall apart.

Two Argumentative, Balding Friends from New Jersey: Dan and I

Dan and I met at Harvard Summer School in 2003. We were not instantly best friends. I remember quite vividly the first day of our first class, Introduction to American Government. Dan was then quite similar to how he is now, at least in this one respect: we met because he walked into the classroom and, without any compunction, began introducing himself to every single person in the room. I found it strange then and although I still find it strange now, I at least can see its utility. It is why Dan focuses on business development at Standard Treasury.

I was particularly annoyed though, when I showed up to my second class, Introduction to Political Philosophy, and there Dan was, introducing himself to everyone in that classroom as well. We were the only two students who took these same two classes.

Despite whatever feelings I might have had that first day, in retrospect, it seems obvious that we were going to have a full and long-lived friendship. We were both from New Jersey, and then, as now, we have a mix of tough-guy go-fuck-yourself, sarcasm as humor, insatiable curiosity, intellectualism, and ambition.

I have this theory that lots of founders have childhood trauma (or, at least, difficulties), that motivates them towards the implausibly difficult task of building a startup.[1] A part of my deepest friendships come from a common, shared understanding of something difficult: in Dan's case, the tragic death of his father and serious injuries to his mother in a car accident when he was an infant, and in my case, my mother's alcoholism and disappearance from my life for ten years.

The important point here isn't the particular personal details of our childhoods, though. As Dan and I got to know each other that summer, we bounded over our similarities in affect, goals, and histories. We spent a lot of the summer together, studied together, explored Cambridge and Boston, and became good friends.

Harvard ended but geography kept our friendship alive. We only lived thirty minutes apart in New Jersey. We would hang out, from time-to-time, throughout our senior year, and like all teenagers of that era, we spent a lot of time chatting on AOL Instant Messenger.

It's hard to understate or understand the intensity of our friendship from there on out. We went to different colleges in different time zones. We saw each other maybe twice a year in person. But Dan was among five or six friends that I talked to nearly every day (and I feel bad that I don't have a reason to write blog posts about them all!), and one of my closest friends.

We usually simplify our friendship by referring to the month we spent together in India in 2006. It's a good synecdoche. I had a fellowship from Brown in the summer (I think I successfully had them pay me, to do what I wanted to for every summer), and Dan was traveling on to Nepal and Tibet with a UChicago group. We visited Delhi, Agra, Jaipur, and Varanasi together as poor college students. We got very sick together, rode elephants together, visited the Taj Mahal together, got lost together. It was fun, but, at times, stressful. We learned a lot about our friendship through that sort of travel. We figured out, I think, that we could work together.

After college, Dan moved to San Francisco, I moved to New York. We pursued what appeared to be quite different career paths. Dan in tech, me in government. But we're both passionate about many subjects and my interests moved closer and closer to data science and civic technology over time.

Dan and I had spoken many times about founding a company together. Whether it was the naive thoughts of two sixteen year olds or the more mature (I hope) reflections of two old friends separated by thousands of miles, it has been often in our minds. So, when I decided that I wanted to move on from the Mayor's office in Newark, NJ, I decided to pursue my interest in technology more directly, by moving out to San Francisco, working at Stripe, and being closer to my old friend Dan.

That inevitably lead us to applying to YC, getting in, and starting Standard Treasury.

Being old friends is one model of finding your co-founder but another is meeting each other through trusted friends and deciding you can work together after getting to know each other quite intensely. That's the story of working with Brent.

Bringing on Brent: Third Co-Founder and CTO

The cornerstone of our team at Standard Treasury is our third co-founder and CTO: Brent Goldman. He joined Dan and I during Y Combinator. He came highly referred from a friend (and many others), studied computer science at Caltech, and worked at Facebook on Platform for four and half years.

If you know Standard Treasury today, you know Brent. Brent and I work together on every product decision, as PM and EM, while Dan sells banks.[2].

Dan and I were first introduced to Brent in February 2013. A friend told me that Brent and Dan were his two smartest friends and that they were both thinking about starting companies.

When we first met, Brent was kicking around some great ideas and, in fact, had another potential co-founder he was working with on them. Dan and I had thoughts about Standard Treasury (then without a name) in ways that were much like our original YC application, which was filled out around the same time.

But, when we met in February, we were all casual. We hadn't incorporated Standard Treasury. Dan was still at Giftly, I was still at Stripe, and Brent was working with another co-founder. It seemed then that the timing would not work out well for the three of us to work together, although we all ended up liking each other a good bit. At the time, I remember being pretty sure that I would be at Stripe for four years!

Despite Brent’s immense interest and experience in platforms, in these early days we were just feeling each other out (and aligning calendars - including a month-long trip to New Zealand). Brent tried to sell us on some of his ideas, but Dan and I knew what we wanted to do as YC had already offered us a YC interview on the idea. I'm not sure we could sell remaking commercial banking well at the time — it is boring to the uninitiated.

What we found, though, was a lot of group chemistry — what we've come to call "founder chemistry." Our skills complemented each other, and ideas were flowing. The only issue was that we didn’t know each other and we didn't know if we could work well together long-term. Founding a company together is like a serious relationship and this was just the first date.

Over the next couple of months, as Dan and I left our respective jobs and got in to YC, Brent, Dan, and I met up every couple weeks to expand on our ideas, swap war stories, and discuss philosophies about what kind of company we wanted to run. Over time we realized that we could work together, and that we could found a company together.

So we joined forces.

Brent fills out our skill sets and together we're all well-complemented. I often joke that on almost everything (technical skill, financial knowledge, desire to talk to investors, ability to write clearly, attention to detail, etc.), that between the three of us, two of us are always at opposite ends of the spectrum, with the third acting as the mediator. It works well — it's just the right level of tension and conversation between us.

Most importantly, Brent puts engineering excellence above almost everything else and has the experience in shipping code and mentoring engineers to back it up. He's instituted a thorough code review process, sets the technical direction, and works with everyone to build sustainable, maintainable systems.

But, despite his perfectionism and attention to detail, he's also a pragmatist who will do whatever it takes to get things done — whether it's re-prioritizing or cutting features, accumulating technical debt (the right kind, with a sound plan to pay it off), or leading the charge to the long hours necessary to meet a tight deadline.

Brent is a force multiplier for engineering productivity and has infused our company with the engineering-focused culture we always knew we wanted. We lucked out in finding the right co-founder to help us build it.

Growing the Team

Just as we were formalizing our relationship with Brent, we finalized two more engineering hires. They are both dedicated and productive, and both snapped to the engineering culture Brent wanted to build. Then Brent brought in an old colleague from Facebook to fill out the core team. It's been the six of us together until our first new hire last month. We've found that we not only have an amazing team but one that is very cohesive.

In my next post I'll talk about how to find a team, what kind of team one needs to build for a successful startup, and how we did it at Standard Treasury.

[1] I even have a half-written, unlikely-to-be-published blog post on this topic, and how much I validated it through my dozens of close friends in YC. It is a hard thing to write about because it's deeply personal and it opens you up to a common line of attack: well, I had or have it worse.

[2] The division of responsibilities and founder relationships is another planned post.

This morning Simple sold for $117M to BBVA. It's great news for the team, and I think it's going to be great news for retail banking.

Simple had amazing potential but also ran into many problems and difficulties caused by being built on top of Bancorp, not owning their own rails, and starting on the retail side. Simple could never build the infrastructure they needed for the product they really wanted to ship because what they have is not a bank account as people understand it. BBVA will change that.

We chatted with Shamir for awhile in Standard Treasury’s early days. Simple walked down the path of trying to get a bank charter but never followed through. It was partially timing — they were looking into buying or becoming a bank at the worst time possible — and partially that they did not build the company's capitalization to allow them to go down that path.

Also, looking at their history, it seems like they didn’t become a bank because along the way, at every step, it appeared to be the wrong choice — why build infrastructure when seemingly there are off-the-shelf options? But when one looks at the course of the company in aggregate and all the trouble they had with their service providers (I think they restarted their integrations three times), it would likely have been easier for them and better for their customers (not to mention their shareholders) if they had gone down the bank route.

It also seems like Simple never considered starting with the business-and-commercial side of banking. From the start (according to Josh’s blog post) they were focused on retail. We think starting on the other side is the right strategy to build a large bank. That’s why Dan and I have written a step-by-step product plan for a commercial bank.

Let me talk about what I see in the idea of building a bank. (Bear in mind, though, that this is not a likely outcome for Standard Treasury).

Building A Bank Directly

Everyday I read the Financial Times because it is wise to study the ways of one’s customers. But it can be depressing. With the headlines focused on bad bets, fines and settlements, price-fixing, and inquiries into malfeasance, it can be hard to focus on what I think of as the positive power of banking. To me banking is not about capital markets, investment banking, "the one percent", or high-frequency trading. Banking's true potential is not even seen in a better retail product experience like Simple. Instead, banking is about making commerce simpler and easier for businesses and consumers alike. It’s about empowering calculated risks and enabling trade in all its forms.

I want to build a bank with the simple mission of making it easier to do business - easier to be a business and easier to be a customer of businesses. Build a bank that had that simple creed at its center and you would make different product decisions and different hiring decisions than most banks do today.

This is not a casual interest of mine (although it’s a side interest to the business I am running now). Standard Treasury builds software for banks. That is the first approximation I can get to making the world I want inside the sanity and capital bounds that most venture capitalists seem to operate under.

We need a small — technology driven — bank.

Dan and I have chatted with former and current regulators at the Federal Deposit Insurance Corporation, the Office of the Comptroller of Currency, and the Federal Reserve. We have also chatted with lawyers and bankers in the business of buying and forming banks. There is no doubt that building a bank is hard. It is the ultimate schlep. But it is possible. Every conversation seems to start with people thinking we're a little bit crazy. Every conversation seems to end with an agreement that our dream is not only possible but desirable.

I won't publish our full step-by-step product plan but I do just want to talk about what a bank run like a technology company might mean in the abstract.

Bank As Startup

One key and obvious idea to anyone who works in technology is that banks have way too many people working for them. As Dan reminds the Standard Treasury team and all our customers, the banks that will survive in the future will be those that are most able to alter their cost structures.

One senior banking official recently told us that banks are likely to go through the same type of restructuring that the airlines went through in the 80s and 90s. They had large costs and outdated ways when the money was easy. But when the well dried up and airlines had to remake themselves, many airlines simply died. Well, now, the easy money is drying up for banks, This is the moment to build the Southwest Airlines of banking.

Without focusing in on capital markets, a new bank could defeat banks on product, technology, segmentation, and customer acquisition. The bank could do this with few people (mostly engineers) and a lot of software. This is because today’s business customers don't want to talk to their banker and rarely need a branch. They want to be able to trust their bank, to feel like the goals of the bank and their goals are one, and they’d like a great product experience with a customizable and open ecosystem at its core.

What does this mean in reality? It means the elimination of the physical (“wet”) signature and the start of instant risk determinations, easy to use but powerful tools to manage money laundering and customer identification requirements, and dynamic offerings targeted to the needs of the customer, with simple user interfaces and transparent pricing. In short, the anthesis of today's banking experience.

(Notice that banks are one of only two retail categories where you walk in and cannot find a list of products or their prices. The other is healthcare.)

The Problems

Regulations. Politics. More regulation. Acronym soup. Capital requirements. Passivity requirements. Etc. I won't bore you with the details but this isn't for the faint of heart. I think that most venture capital is ignorant to the nuances of just how complicated (and expensive) this gets, and just how quickly.

We have had a lot of these ideas floating around for awhile as have others, and as we participated in a recent Twitter conversation and after today’s sale, I wonder if maybe someone is willing to take the jump with us.