Productivity on a small team

For our next installment in our series on what it takes to build a broker-dealer from scratch, here we share the composition of our team and how we split up the work, along with some introspection on how we’ve been able to launch our business so few people. Previous installments include: obtaining a broker-dealer license, and a breakdown of vendors and partners.

When you work at a large company, you are a cog in the machine, and probably most of your time and energy is spent just trying to stay in sync with the other cogs. You go to meetings, you write emails, decisions are made by committee, tasks are assigned. Process, bureaucracy, politics, performance reviews, and comp talks. It’s certainly not all bad, and if you had great teammates and a great manager, it can be amazing. But it is probably not efficient.

There are plenty of challenges at a small company as well, but you do get to control your own destiny, and it is possible to be incredibly productive and capital efficient. This post describes the team that we have assembled at Proof, how we work together, and what we all do.

There are of course many different approaches a company can take in terms of team composition — this is just one data point — but we hope it paints a picture of the magnitude of work involved and illustrates that it is possible to build a new broker with a lean experienced team. It is also worth noting that our team at Proof looks quite different from our team around the time of launch at IEX: Proof is much smaller and much more concentrated in technology and research. In the early days at IEX, we all wore multiple hats, but at Proof we take it to another level.

This post has two parts:

1. Key efficiencies: how our team is able to be so productive with so few people
2. The actual breakdown of the various work items across the team since we started

Key Efficiencies

Experience

With just one exception, every person on our team is a genuine expert in their core job function. Not only that, but we have already built one successful broker from scratch (IEX started out as a broker-dealer before it became an exchange). Between our team, we have built multiple OMS/trading platforms, execution algorithms, quant models; we have navigated regulatory approvals and examinations; we have evaluated and engaged with countless vendors. Pretty much every time we are doing something new at Proof, someone on the team has done it before, or at the very least seen it done by close colleagues, and we have a good sense of what to do or what not to do from that prior experience. There are of course many benefits to having a pipeline of junior talent, which will certainly become more of a priority as our business grows, but for now while we are in pure build mode, assembling an experienced team has been key.

Full context via frequent asynchronous communication

One of the greatest benefits of having a small team is how easy it is to keep everyone in the loop. With only seven people all in the same (physical or Slack) room, everyone can hear and see everything that’s going on, and it still isn’t too overwhelming or distracting to keep track. Also we are an extremely transparent company, both inside and out. There are no secrets, so everyone has the full context to complement each other’s work and not duplicate efforts. In terms of specifics, we have very few real-time internal meetings: we do 30–60 minutes all-hands sync ups over Zoom twice a week, and beyond that, I spend maybe a few additional hours a week on internal calls. Everything else is asynchronous communication over Slack, which works well without breaking up everyone’s day with disruptive meetings.

Individual responsibility / streamlined work

At a larger company, there are very few ultimate decision makers, and an inordinate amount of time is spent getting approval from higher-ups or communicating across teams. At Proof, each individual is trusted and empowered to make decisions within their domain. That means for any given task or project it is typically one person who owns it from start to finish. For example with a tech project, it is a single person who determines requirements, architects the design, writes the code, tests, iterates, verifies that it’s working in production, and troubleshoots production issues. Others on the team may chime in on various aspects, and we do always help each other out with code review and additional testing. There are also some bigger projects that require input or work from multiple folks on the team, but in general there is one owner who drives the entire process.

This is not a perfect model for every company, but it works well for us. Having many gates and many sets of eyes on a given task is slower but it can also be safer, as there are more opportunities to catch mistakes and a lower risk of an individual’s blind spots allowing problems to go unnoticed. But the flipside is also true: for example when an engineer knows their work will be tested by a separate QA team, there’s less pressure on that engineer to catch every little bug, and they may get complacent or less thorough with their own testing. We have all worked places where developers had this mindset that others were responsible for testing their code. At Proof on the other hand:

1. Every individual knows the buck stops with them; we all understand full well the risks involved deploying new code, and we take full responsibility for the success of our individual assignments.
2. With everything we build, we do so with an eye toward resilience and safety. We know we’re not perfect, so we build many independent guardrails around our own and each other’s work to try to ensure that when issues do arise, they are not catastrophic.
3. Everyone knows what they are doing and has earned this great deal of trust and responsibility. When someone is unsure of a decision, they ask for input from others.

Having a single owner of each item does mean however that we are more prone to single points of failure. It takes a conscious effort to stay fully informed about each other’s work, and it helps to have overlapping skill-sets across the team when possible.

Well-rounded leadership

Not to toot our own horns too much, but Allison, Prerak, and I make a pretty good team. We are equal partners in the business, we each wear a lot of hats, and we try to always remain in sync. All three of us are quite well-rounded, and any one of us could perform any role in the company in a pinch — build software, set up tech infrastructure, conduct quant research, pitch clients, algo design, trading operations, vendor management, regulatory, compliance, accounting, HR, info sec, fundraising, you name it. We each have our relative strengths, but for any new task that pops us, usually any one of us can tackle it since we all have full context and full authority to make decisions. We work well together, and we have a great deal of mutual trust and respect. That is not to say we always perfectly agree on every little decision, nor that we’re always 100% sure what to do, but for the majority of tasks and decisions, usually one of us can take care of it without needing broader input. And when we are unsure, we just ping the others and usually come to a decision quickly.

Automation and tools

Over the past two months, Prerak has automated nearly every operational task related to running the system, from daily startup and shutdown procedures, to a playbook of queries and recovery commands that can be called upon to investigate, understand, and remediate a failure scenario. What would normally be many hours of manual daily work has been condensed down to a few minutes of manual verification that each of these automated jobs ran successfully.

Additionally, at any point intraday we have the ability to pull down a copy of our production or UAT sequenced stream for the day thus far. Within seconds, we can run it through our currently deployed code locally in debugger mode, and step through the code line by line. That means anytime we see unexpected behavior in production or in our test environment, we can almost instantly replay the stream, peer into the code, and see exactly what it is thinking and doing step by step. We have never had this ability anywhere else we have worked, and it is truly amazing. Beau introduced this functionality, and it has easily saved us hundreds of hours of debugging time already.

Finally, we use a handful of excellent modern off-the-shelf tools that make our lives easier, such as Datadog, Gusto, Brex, Clerky, Omnipresent, and Virtual Post Mail. See our post on vendors for more info on which tools have made a big difference to our daily workflow.

Breakdown of responsibilities so far

Now this next part is really in the weeds: how we have actually split up the work over our first two years as a company. Obviously no two teams are the same, and the unique composition of our team has led us to divvy up the responsibilities exactly this way. Hopefully this is at least interesting or helpful to other aspiring entrepreneurs to give a sense of the types of work involved in building a trading platform/broker-dealer.

Dan Aisen (CEO)

• Algo design and development (especially at the tactical level)
• Regulatory/compliance
• Sales and relationship management
• Vendor evaluation, selection, and contract negotiation (clearing, DMA, EMS/OMS, etc).
• Fundraising

Allison Bishop (President)

• Quantitative research: pre-trade model, volume prediction, impact minimization, distilled impact metric, etc.
• Algo design (especially at the macro level)
• Content
• Sales
• Culture and mission

Prerak Sanghvi (Chief Technology Officer)

• Technology: OMS, algo container, client gateways (EMS integrations), venue gateways, post-trade (clearing, CAT, OATS), risk checks, database, reference data, trading system infrastructure
• Technology vendor evaluation, selection, and contract negotiation (market data, network, database, etc.)
• De-facto CFO
• Technology and trading operations
• Risk management and information security

Beau Tateyama (Chief Software Architect)

• Technology: core messaging middleware, application framework and software infrastructure services, market data, algo container, trading system<>UX interface, infrastructure and devops, administrative processes (system start/stop, archiving of data logs, etc.)

Han Dong (Designer / Developer / HeadHANcho)

• Technology: customizable multi-view streaming UX for the trading system (frontend + backend), devops and auto-scaling infrastructure for web applications, public-facing tools (pre-trade tool, find my fills, etc.)
• Design: graphics, branding, and UX (website, logo, visual identity)

Matt Schoenbauer (Quantitative Researcher)

• Matt is the only junior member of the team. He joined us straight out of undergrad about a year ago. Matt assists Allison on her research initiatives, and so far he’s spent most of his time focused on our impact minimization model, our distilled impact execution performance metric, and TCA.

Brian Foley (Head of Sales)

• Brian is the newest member of the team, the only one to have joined post-go-live. Since joining in March 2021, Brian now leads all client outreach, business development, and marketing efforts, and Allison and I support him wherever possible.

Consultants

• Shannon Fitzgerald (Regulatory Ridge): Shannon is our outside regulatory consultant. She guided us through the broker-dealer application process, and she continues to provide ongoing regulatory support post-approval.
• Anya Cross (Cartana Consulting): Anya is our outside FINOP and helps us manage all things accounting, including many regulatory requirements.

Closing thoughts

We are proud of the team we have assembled so far, and we are excited to gradually add more folks who mesh well with our dynamic. On a small team, every single hire is critical: a great hire can be wonderfully additive, and a bad one can be hugely disruptive. We have seen both happen at past companies and that has made us cautious and deliberate, but also optimistic. We have also experienced firsthand the ubiquitous growing pains and drop off in productivity and culture as a company goes from a handful of folks to dozens or hundreds, so we want to do everything we can to stay in this magical early stage for as long as possible, if not forever.