Brex was founded in 2017, and in four years, grew into a company spanning three countries with over 700 employees.

During this time, we’ve grown from being a single corporate credit card product for startups to providing fully fledged card and cash management products with robust spend management features to customers across multiple industries. Many of our core financial products are complex and require time to get right, but that doesn’t stop us from moving fast.

Even as a (much) larger organization, we continue to innovate and innovate quickly. One of the best examples is Brexploration, a program that allows existing team members to devote an entire quarter to building a loved product as “founders.” Teams apply to the program and then spend three months working like early entrepreneurs and skipping existing company processes. Successful projects are then transitioned back to operating like a scaling product. Many of our most customer-loved products and features came from Brexploration, like Expense Management and Bill Pay.

Engineering at Brex also focuses on enabling Product Teams to execute as quickly as possible. Our Infrastructure Empowerment team, for instance, builds our infrastructure on top of cutting-edge technologies, tools, and best practices (Kubernetes, GitOps, Istio, etc.). We have adopted a microservices-oriented architecture, and are continuously releasing new software which enables fast iteration of our product.

We’re operating in a competitive space dominated by legacy incumbents.

Large banking and card institutions like Chase and Wells Fargo are slow-moving, which gives us an advantage as a small team to iterate and ship new products much faster. For example, while debit cards typically take 12 months to go live, we can do it in 3.5 months. Our agility as a small startup allows us to push code to production several times a day and make decisions without bureaucracy and red tape.

We have a bias for action, even if it means making mistakes along the way.

At Leapfin, we deploy daily, work in 1-2 week sprint cycles, and have a high sense of urgency. Decisions to act are always better than indecisions. Sometimes engineers who come from big companies are fearful of making decisions themselves because they’re so used to asking for approval. It’s the opposite here. When you come on board, it’s because we hired you for a reason and trust your expertise, and our expectation is that you take ownership over everything you work on. There’s no red tape to jump through (other than budget approval), so we all get things done fast. While this fast-paced environment inevitably means you’ll make some mistakes along the way, we view them as team mistakes, and always learn from them.

Move fast, ship, learn, and repeat.

Even as we continue to grow, we can’t afford to move slowly or make “safe” calls. We’re focused on building the APIs to power the next generation of intelligent applications. It’s an ambitious goal, so regular adjustments are expected as our products continue to mature. The roadmap isn’t always a straight path.

Being able to adjust and switch directions quickly is more important than hitting every KPI so we intentionally set aggressive timelines in order to make mistakes early and often, ensuring we’re constantly learning from our users, optimizing over time, and building for the long term. Our squad model enables this flexibility, allowing cross-functional teams to work independently to get things done. Engineers are even encouraged to move between squads, ensuring constant expansion of product knowledge and creating collective understanding around what’s being built across the organization.

Speed is our greatest weapon.

We will always prioritize time-to-market and always challenge ourselves to execute faster. While it’s common to hear that you will release code on your first day, we really mean it. Engineers on our team release to production multiple times per day and we tend to work on multiple projects within a single sprint. Sure, there's work that may take a whole sprint to complete, but we’re typically multi-tasking and keeping multiple plates spinning. Not only do we have many workstreams, but we’re also keen on not siloing anyone on a single project. To help stay focused, we regularly use single-week sprints as well.

At present, everyone on our team is a full-stack developer. While most people have front- or back-end preferences and different strengths, we encourage everyone to work across the entire stack.

We’re a small team, so we can quickly change focus and get behind a new problem on short notice and deliver in quick order. Our process supports a maker’s schedule, which we honor every day. To help facilitate speed, we also use CI/CD and have designed our technical infrastructure to bias toward frequent and fast deployments.

Our motto is “Ship Early and Ship Often,” – we have more than 10 custom Slack emojis for “ship.”

You join a startup because you want to make an impact without the red tape. We are biased toward action and know that the fastest way to learn is by doing (rather than just sitting around and talking about it). And we love doing.

We generally err on the side of speed over perfection, and love to ship early, then iterate. We deploy multiple times a day, and often rollout changes internally to our team first, and then after QAing, externally soon after. We have a pager system, but not a formal rotation. Currently, everyone jumps in when needed. We lean on straightforward engineering over intricate, or idealistic solutions.

We’re well aware of how much change Cameo will undergo in the coming months, so we’re being careful to protect our culture of shipping early and often while also introducing necessary processes to keep things organized and efficient. We know we're biased, but we think it's objectively an exciting time to join Cameo. If you want to learn more about us, contact us!

We’re growing fast and our revenue is doubling almost every year.

Demand for global trade is rising quickly, which means the need for better supply chain logistics is more important now than ever. Our business revenue consistently doubles almost every year. As a result, we’ve expanded our Makers Team to Shenzhen, Shanghai, and Amsterdam. We also opened offices in Vancouver and Copenhagen, bringing us to 14 locations and growing!

The volume we’re shipping has increased at such a pace that we purchased warehouses in Hong Kong, Los Angeles, and Shenzhen. We achieved this growth with 240+ engineers across five cities and three countries, something we attribute to a carefully designed product cycle that syncs strategically with the business. When you join Flexport, you’ll ship code on your first day. You’ll play a key role in building our product and designing flexible, high-quality solutions. To help understand the broad scope of our mission, all new hires participate in a week-long crash course on the fundamentals of global trade. Your onboarding class will consist of people from operations, sales, marketing, product, design and more. It’s a great opportunity to tap into the cross-functional knowledge of your starting cohort!

We are in an exciting and fast-paced market and love to ship.

Data is in demand right now. In this high-growth market, we like to make decisions fast and learn along the way. As a result, we've created a fast-moving team that thinks about how to reduce time on feedback loops and delivery.

To that end, our deployment pipeline moves quickly. We practice continuous deployment to our pre-production environment, work according to agile development principles, and promote the latest stable code to production at least once a day. To decouple deploys from releases, we make heavy use of feature flags.

That said, a fast-paced environment doesn’t require burnout. On the contrary, we can only ship as fast as we need to with a well-rested, energetic, and happy team. Mode’s leadership team sees value in people maintaining their lives and interests beyond the office.

“Move Quickly, But Don’t Rush.”

This is a core value at Handshake since we’re a rapidly growing startup and constantly evolving. We’ve doubled the size of our company in the past year and we continue to grow quickly. That’s why we place a huge emphasis on moving quickly without rushing. At the engineering level, this translates to building features in a timely manner. When there’s a high priority incident that needs to be dealt with, the team has to be able to act swiftly to make sure it’s resolved as soon as possible.

Our CI/CD system enables us to iterate and deploy quickly, but we always make sure that all features and bugs merged into production have accompanied tests to ensure high quality. What’s more, we stay up to date with technologies and openly discuss the tradeoffs between speed and perfection with each iteration. For example, managers adhere to the “60/20/20 rule” – our time should be split by 60% product development, 20% technical innovation, and 20% technical maintenance. So while we want to move quickly to develop features to enable our important mission, we also set aside time to address technical debt and innovate on our technologies.

As a company, we have grown very quickly. We just raised a $40M Series C and we’re considered the fastest growing education technology company in the Bay Area. Just over the past year, about 50% of our engineering team will only have been at the company for less than a year. Because of this fast-paced growth, engineering leadership is constantly iterating on and improving processes and methodologies to keep every team organized and high-functioning. For example, the manager of the Employer Engineering team received several points of feedback from the team’s bi-weekly retro meeting that the growing number of people was making our Scrum meetings run very slowly. Within a week, the manager worked with the PM, designers, and technical leads to reorganize the team into two separate Scrum teams, resulting in more highly efficient meetings and clearer delineation of responsibilities among engineers.

We are constantly innovating for our customers.

We try to push the boundaries of what customers expect a background check to be while remaining compliant and accurate. For example, we offer a white label applicant portal, allow other products to use our API via OAuth, and are using machine learning to predict how long a background check will take. We work closely with customers and applicants to identify real problems they face in their workflows, opportunities to increase their data quality, and ways to help them stay compliant. By taking smart risks, we are leveraging technology in ways that the industry has never seen before.

We work with a sense of urgency, but without the unnecessary stress.

Generally speaking – across all of the different pillars and teams at Amplitude – we try not to tie ourselves to arbitrary deadlines. Instead, we build, continuously release, gather feedback early and often, pivot when needed, and retire work when it’s stable. When we’re getting close to a deadline, we’re not afraid to push it back. While we are in favor of building quickly, we don’t want it to be stupidly quick!

In 2019, our team started tracking a company-wide metric: number of features shipped. We got pushback from various teams, created a working group, and two weeks later pushed out a new iteration of that metric: number of bets taken. Not only is this an accurate demonstration of how quickly we iterate, but it also captures our mentality and how we orient ourselves at Amplitude. It encourages us to create learning opportunities as quickly and as often as possible, and removes any expectation to ship things perfectly the first time around.

We’ve grown from 120 employees in early 2018, to roughly 470 in early 2021, and are continuing to add new members.

As a result, we’ve created fast-moving teams with a high degree of information flow that innovate around how to reduce time on feedback loops and delivery. Our development process focuses on a very short cycle where small changes are iterated on incrementally and delivered quickly. There’s very low lead time to make changes and we follow a dual-track agile development process, where experimentation and discovery are equally important.

We build, continuously release, gather feedback early and often, and aren’t afraid to course correct when needed. While there’s a high rate of change (from a DevOps culture sense), a fast-paced environment doesn’t require burnout. As Lena Reinhard, our VP of Product Engineering, puts it: we avoid burnout by keeping the bigger picture in mind and focusing on clear communication, expectations, and trust.

In 2020, we had 100% YoY credit growth and raised $215.5M in venture capital, and we have no intention of slowing down. Not only will we grow in number (we doubled our product and engineering organization in 2020 compared to 2019), but we’ll also accelerate our productivity. We shipped 100+ features and bug fixes last year (compared to 40 the year before) and we hope you’ll help us set a new record this year.

We’re a team of passionate problem-solvers.

We care most about delivering solutions that resonate with our users, not working in the latest technologies or keeping up with design trends. Our industry entrusts lives and livelihoods to us, and that forces very thoughtful product prioritization. Since there are so many moving parts and endless things we could be working on, we have to be really decisive about focusing on what is actually the most important for the business and end users, for our capabilities as a team, and for where we are today versus where we want to be in three months.

We also care about team efficiency and speed. To us, an extra-small problem should take an hour, not a week. Conversations around an issue can easily start in Slack and move to a call – we don’t wait for formal meetings. Because we can easily adapt our process to what will work in a given situation, we’re able to stay flexible and move quickly. It’s not uncommon for engineers to write code and ship the next day.

People who thrive at Honor enjoy working with others to solve complex logistical problems, care about strong, light-weight approaches that enable us to tackle the next big challenge, and are proactive in filling in gaps.

Always be shipping!

For us, fast-paced describes our deployment processes and how we like to “always be shipping” versus how quickly we change strategies. This is another aspect of ActZero that makes us different from your average startup: while we adapt to new information, our strategy is generally unwavering. We already have product-market fit and work quickly out of excitement. Everyone operates with a strong sense of ownership, which translates into urgency. The feeling is not panicked, but rather a calm assurance and eagerness to deliver immense value to our customers and change how security services are managed.

We employ continuous delivery such that every code change can make it to production in a matter of minutes. We measure and optimize the number of builds per day and the amount of time to deploy. We care deeply about eliminating the amount of time it takes for a developer to be productive. Our desire for automation and ML doesn’t end with the Security Operations Center, we also use these techniques to reduce wasted effort in building and operating our software.

We judge our pace through measurement. Urgency is reinforced through our Kanban development process. Each task should take <1 day to complete and we are vigilant about this fact. If a task takes less than a day to complete, every engineer should be able to ship one thing per day. Everyone therefore gets the opportunity to demonstrate concrete progress, day after day.

We have a bias toward action at BetterUp.

We build our product with a sense of urgency; we want to provide value to our members as quickly as possible. We are not able to confirm or reject our hypotheses and improve upon them until they are live and we want to do so as quickly as possible. Sometimes this means reducing the scope of a solution, but it never means compromising our standards for engineering or product excellence. We may start to build a feature only to realize that the experience is not good enough. In this case we would likely cut a secondary feature and ensure that the core experience is intuitive, snappy, and delightful.

In order to help us release early and often, we’ve built a strong foundation of comprehensive test coverage, regularly updated dependencies, and a constant effort toward minimizing technical debt. We release code to production many times a day and engineers are empowered to deliver their code when they see fit. Engineers are expected to do what it takes (test coverage, code reviews, manual testing, etc.) to have high confidence in the code they are releasing and are expected to own (and learn from!) any regressions, which are an inevitable part of software development.

Despite the pandemic, we doubled our revenue in 2020 and raised a $125 million Series D, bringing our valuation to $1.73 billion. We have a lot of exciting projects in the pipeline and are amplifying our reach by partnering with companies like NASA and bringing Prince Harry on as our Chief Impact Officer. If you’re interested in helping people strengthen their well-being and peak performance, we’d love to hear from you!

Things change quickly, and everything is balancing trade-offs.

As an early stage startup, we need to be able to adapt and switch courses quickly. Our philosophy is best described by this Eisenhower quote: “Plans are worthless, but planning is everything.” We value the process of planning, but don’t consider any of our plans to be carved in stone. We don't want chaos and disorder, but we also don't want to be rigid and inflexible. Striking this balance is something we actively and consciously work toward every day.

One of the biggest frustrations people have about working at early stage startups is how often things change. People need consistency and certainty, and change creates anxiety and fear, which, in turn, are shown to decrease productivity and creativity. So how do we reconcile these two seemingly contradictory facts?

The answer is that not all change is created equal. It’d be absurd if you needed four levels of approval to change what snacks you have in your office kitchen. Conversely, it’s going to be really jarring if you are suddenly told to drop all your work because a product line has been axed, without any explanation or foreshadowing.

The trick is to allow for some types of changes to be fast and fluid, while requiring others to be slower and more deliberate. Some changes should require nothing more than a quick chat, while others need a stakeholder meeting, and others need an all-hands company meeting. We make sure team members are informed and involved in decision making, which means we can tune plans dynamically and quickly without people feeling like they are being jerked back and forth. Dan, our CEO, goes into detail about how we approach change at Range in his post, Shades of Change.

We know that the only way to approach perfection is to ship early and often.

One of our core values is kaizen, which is a Japanese term meaning ‘continuous improvement.’ We believe in iterative progress over sweeping action and/or big central plans. To that end, in 2020, we shipped 48 iOS releases. And if/when it works, we improve on it. Each release is a building block toward the next evolution of our product.

At the beginning, we sat down every week and decided what to work on. We’re a bit more sophisticated now – we loosely plan a few weeks out, and then we take on important foundational projects that require more than a week to complete. But ultimately we still aim for weekly cycles, aiming to ship a release every week that may be staggered with larger projects, and still focusing on minimum implementations to test ideas before we invest heavily.

Our commerce tools are a perfect example of this – to begin, we broke it down into the smallest pieces possible. Bite size, easily digestible pieces. The first piece was so small, you couldn’t yet withdraw the money you made to your bank account. But, more importantly, making money on your site became incredibly easy. Then, we added bank integrations, inventory management, product variants, mailing addresses, shipping labels, order management, automatic digital product delivery, and most recently, dispute management. We shipped each of these one at a time, many with at least one follow up iteration to incorporate immediate learnings from creators.

Beyond our product roadmap, we give our engineers open-ended time and space – every fourth week here is a polish week, where engineers get to work on things they choose. After working on a feature for several weeks, engineers know best which corners got cut or where they would have liked to have spent more time on that might not have been critical at the time. A polish week is a chance to focus more engineering time where engineers know it’s needed. We fix bugs and pay down technical debt, but we also use this time to get more involved with other parts of the company, like product, design, and marketing.

We have a really big vision – to democratize the web. While it’s important to keep that in mind, we know that the only way to get there is week-by-week, day-by-day. We don’t have six-month product roadmaps. Instead, we learn quickly and leverage those learnings to figure out the best way to accomplish our goals.

This kind of work environment isn’t for everyone, but it is for people who love to move fast, learn a lot, and make incremental progress towards perfection.

We push to product 5-10 times each day.

We test things with our users (teachers and students) and we would always prefer pushing something in half the time over perfection since we know that most things we decide to build will be wrong. We can change strategy when needed, and there are no barriers to good ideas and confident ambitions.

We’re an action-oriented company of builders who enjoy rapidly iterating on new and existing ideas.

While venture capital typically moves at a snail’s pace, we’re the opposite. Our organization is composed of nimble, high-context teams that can operate autonomously without process getting in the way. We focus on what’s important and sweat the precise details that matter. This allows us to consistently ideate, validate, and execute on new concepts at a rapid pace.

Intrinsic drive, love of results, and a strong sense of founder mentality are traits commonly shared across the team. Nothing feels better than solving a customer’s (internal or external) problem within minutes of it being reported. We have a Slack channel called #v-product-feedback where people across the company post everything from bugs to copy suggestions, product improvement ideas, tooling improvement ideas, and more. Normally these get funneled into our product backlog, but sometimes engineers will jump in, take a suggestion, and drive a solution within the same day (or hour!) of it being posted. Talk about speedy!