James Russo

James Russo

Engineering at Brex

Fullstack engineer who knows nothing about design.
Example: this website.

Bored Hacking

From Unicorn to Decacorn: 16 Lessons Learned at Brex

68.calendar
July 18, 2024|
9 min read

I’ve spent my last four and a half years working at the then unicorn now decacorn Brex. Joining back in January of 2020 a lot has changed between myself, the company, and the world. Over my time at Brex, I’ve seen or experienced:

  • Rolling out career ladders, working towards a staff engineer promotion, and moving into management
  • Onboarding hundreds of engineers, resulting in the growth of the company from under fifty engineers and three hundred employees to over a thousand employees
  • Surviving three different rounds of layoffs, and countless numbers of re-organizations
  • Moving from a product engineer helping to build and launch Brex Cash, to an internal platform tech lead focused on developer productivity for a rapidly scaling organization, back to working on product as an engineering manager helping to re-launch our Bill Pay product integrated into our expense management software

I’ve experienced a lot of changes and growth over the last few years and written down the following learnings. A majority of these learnings I initially started writing down back in 2023, with the final few being written more recently in 2024.

Writing is important. This is true for so many reasons. It allows you to share context, create consensus, process your own thoughts, learn from others via reviews, make decisions asynchronously, strategize iteratively, keep decisions for posterity, and so much more. Writing too much can however slow down and bloat decisions. To avoid this, use the right document framework/template for the type of decision.

Always be open to pivoting. Of course, constant pivoting leads to thrash (which I touch on more later) but the confidence to pivot direction at any company stage is important. There have been a number of decisions at Brex that at the time seemed right but after some time became clear that they weren’t correct for the company. No matter how large Brex has gotten, the leadership team hasn’t been afraid to change direction when needed.This is a good reminder that even when you have found product market fit there are still pivots that you will need to make on your journey, and it’s important to not go down the wrong one for too long.

Transparency makes everyone feel like they’re “in the room.” Early on, Brex was so transparent with employees that we would even review our P&L at company wide all hands and allow folks to ask questions about it. This really allowed us to feel like everyone was in the same room when certain decisions were made. The reasoning for decisions was clear because the leadership team was honest with us on the why. While the level of transparency has decreased over the years, it’s important to note this is a privilege and it is something you need to handle with care in order to keep.

Early employees set direction. Early culture and employees are the most important resource. When I joined Brex, it seemed like everyone around me was so smart and talented. There were a few engineers who I could have sworn would have been senior engineers if we had titles at the time but were only new grads out of college. As many others have probably experienced, I had imposter syndrome and felt like I was just lucky to be there. I wanted to learn from these engineers and handle the level of work they had with the same quality or even better. Early employees uplevel the next generation of talent and set the standard for delivering high quality impact.

Infrastructure can be a differentiator or detractor. Brex was a fairly early mover in the corporate credit card startup space, with not a lot of platforms and SaaS offerings to pick from to build their product. While this is no longer the case today, it meant Brex had to build a lot of card payment processing infrastructure in house. Today, this is a massive differentiator for Brex because we have a direct integration with Mastercard and can build out local card issuance and acceptance that our competitors can’t. However I think a detractor that Brex suffered from early on was building too much of our internal platforms and infrastructure tooling. Our devops tooling and developer productivity tooling was very bespoke and custom, which ultimately created a larger maintenance burden for us and required teams of engineers to support. We’ve started to move away from this though and opting to buy instead of build for the right price and when it’s not a differentiator for Brex.

Company growth leads to personal growth. As the company grows, issues inevitably arise. These problems create learning experiences and opportunities for the people willing and excited to work on them. These are problems that folks at other companies may never see, or may only see after working there for many years. Growth in the company generally also leads to new teams which allows you to try something new, or if you want to manage gives you opportunities to manage and grow up the manager ladder.

Say yes until you have to say no. At a high growth company, there are always new challenges that come up, much faster than at other companies. For high growth individuals, these challenges open up a lot of opportunities for growth. Say yes to as many opportunities that interest you as you can. These will rapidly accelerate your career and allow you to grow outside of your team projects. However, it’s important to be aware of your bandwidth. Know your limit and learn to say no when you are fully resourced. If you don’t, you run the risk of letting down others and yourself.

The “why” is always important. It should always be clear why you are proposing something and what the effect of its impact is. When challenges and problems run rampant at a fast scaling company, it’s common for people to be constantly proposing solutions. However the why and the problem are the most important thing to agree upon before jumping into solutions. Similar to starting a startup, it’s important to hone into a problem, and not create a solution in search of a problem. Spend time on defining the problem succinctly and getting alignment on the problem, its impact, and the priority of the problem.

The right idea may not be your first idea. A lot of folks get stuck on their initial solution or idea and find it very hard to keep an open mind. It’s important to always make sure you’re thinking through all the tradeoffs of multiple approaches and optimizing based on what the company or team needs now. Convince yourself and others of the decision you are proposing. Utilize rubrics, decision matrices, and other frameworks to compare different solutions. Be proactive and willing to adjust your decision docs to include this information when needed. This is a good way to build alignment and settle arguments. There were many times going through this process where the conclusion changed my initial thought process.

Empathy is important both for your customers and your coworkers. Just like you need to be open to the evolution of your ideas, it’s important to be open and understanding to your customers’ and teammates’ thoughts and ideas. The best employees and engineers are those who are empathetic and can put themselves in others’ shoes. Really understanding the customer and their problems leads to building the best solutions. Really understanding your peers and managers leads to building alignment and arriving at the best solution for the company, which may not always be the most “optimal” solution for another company.

Take time off so that you don’t get burnt out. This is important for any company, but especially at rapid growth companies where there’s always more work than you can complete and there never seems to be a great time for vacation. For rapid growth focused people or those really bought into the company, you can often push yourself to work more and more. But it’s important to be able to step back and take time off to recharge. As in many things, it’s a marathon and not a sprint.

Moving quickly leads to more repetitions. The faster you are able to move the more repetitions and practice you can get in. Your own throughput and velocity is what allows you to grow. The quicker you move, the tighter your feedback loop. The tighter your feedback loop, the quicker you can learn from your experience and mistakes. The feedback loop is critical to your growth, and not growing hurts yourself and your trust with others.

Context helps you move faster. The more context you can grow, the quicker you can make decisions. Context is key. What this means is the ability to hold historical knowledge: why past decisions were made, what worked, what didn’t work, what other teams did, and why something is the way it is. The best engineers are able to gather context and hold it. They are proactive in seeing what others are doing, learning about why something is the way it is, and using this knowledge to help themselves, and others, move quicker. They need to spend less time in ideation and can quickly move to solutions when the problem is agreed upon. When teams have multiple individuals like this, they move rapidly and complex problems are quickly resolved via group effort. These teams execute rapidly and have a clear shared mission, vision, and priorities. Groups where everyone can hold a lot of context in their head are 100x teams. 2024 additions

Keep it simple and iteratively think about the UX always. “Keep it simple, stupid!” (KISS) and “you ain’t gonna need it” (YAGNI) are age old adages in software engineering. These recommendations lend themselves to building iteratively. Smart engineers, especially those from larger companies, tend to over-engineer solutions, adding complexity from the beginning. Overengineered complexity will ultimately need to be undone and require large refactors or migrations to fix later on. Starting as simply as possible and iteratively building may generate incomplete solutions, but can generally be added to iteratively instead of relying on large refactors and migrations which are more costly. Incomplete solutions are generally alright as long as you can think through the edge cases and enumerate as many known unknowns as possible which can be iteratively improved.

Good APIs > platforms. When people refer to platforms, most of the time they really just need good APIs. Platforms can lead to overgeneralization and complexity that once again are hard to iteratively add to. Building platforms and focusing on platformization from the onset generally lead to ideal systems in theory but rarely in practice. These systems will generally be advertised as ready to support numerous solutions, attempt to quickly onboard other teams, and often not meet the requirements. This leads to additional complexity, slower velocity, and worse developer experiences. Focus on building simple APIs with great developer and user experiences. Abstract as much complexity as possible and meet existing customers expectations. Slowly add in additional optional functionality, keeping the main UX of the API simple.

After 4.5 years at Brex, my most important realization is this: almost everything comes down to ruthless prioritization.

It leads to better execution and quality. Having an agreed upon single list of priorities is how you ensure you are focusing your resources on the right thing and avoiding doing too much. Working on too many things at once leads to slower success and exhaustion. Everything being a priority is the death of a startup, because it can lead to overworking on the wrong things or never completing the highest priority work well enough. Quality will suffer when there are too many priorities, and quality is key to retention and avoiding churn when there are competitors in your space.

Priorities should be agreed upon at every level of the organization, from the company all the way down to each team. If something isn’t on the priority list, it can’t be prioritized. If something new is added into the priority list, you can shift resources to tackle it without just adding in more work. Resources are finite and prioritization is how you use those resources wisely.

The additional important thing to think through is not causing thrash by constantly changing your top priorities. Constant thrash is also death. Ultimately priority is set by product strategy which should always be clear and set on the order of 12-24 months if not longer. In addition to product strategy, there are other inputs to priorities as well to keep in mind – such as impact, customer demand as well as the size of the customers, but I won’t focus on those in this post as there’s a number of other great articles that already go into more detail on it. Prioritize ruthlessly, and resource based on that prioritization list ensuring it is done well with a high quality.

While I don’t necessarily think a lot of these ideas are novel, I’ve tried my best to succinctly write them down as they relate to my experiences. Many of these items could turn into longer blog posts in the future. Of course, these ideas may not resonate with all – just like how this type of fast paced environment isn’t meant for everyone, and should be thought through before jumping into it.

Once again, I’m incredibly lucky to have gotten an opportunity to work at Brex. Working at such a fast growing company allowed me to quickly grow over these last 4.5 years and gain knowledge that may have taken quite a bit longer to cultivate. The number of problems we quickly experienced and had to solve led to many learnings and the rapid repetitions and high throughput approach allowed me to quickly practice these learnings over and over again.


© 2024 James Russo. All Rights Reserved, Built with Gatsby