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

Our competitors are large banking institutions like Chase and Wells Fargo, which gives us an advantage as a small team of five. We have the ability to iterate and ship new products much faster than our competitors. 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.

Start-ups in general are fast-paced, but Samsara takes that to a whole other level.

We have been able to move insanely fast, in part because of our established and experienced leadership team, Sanjit Biswas (CEO) and John Bicket (CTO) who co-founded Meraki. With the knowledge acquired through growing Meraki, our leadership team was able to make the right choices early on when founding Samsara. Today, we’re excited to say that Samsara is #3 on LinkedIn’s Top Startups List for 2019! This is the second year in a row Samsara has been recognized as a Top Startup by LinkedIn, which looks at companies experiencing high levels of growth, employee engagement, and interest from top talent.

In just 4 years, we’ve scaled Samsara’s business from a handful of sensor data points from a customer in South San Francisco to over 10 billion sensor data points per year across 10,000+ customers around the world. In order to continue to fuel this growth and invest in developing new, innovative technologies, we recently closed a Series F round (valuing the company at $6.3 billion).

If you’re interested in being a part of the magic, please apply directly on our careers page and mention that you heard about Samsara through Key Values!

Take a tour of our fleet product here.

Our founders, Sanjit and John

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.

Get ready to roll up your sleeves, take ownership, work on exciting challenges unique to our marketplace, and have the time of your life!

We are all about getting shit done and making an impact, but that doesn’t mean we sacrifice long-term investments and quality – we of all people know, everything is about balance, but we err on the side of working quickly and making sure we deliver on the promise we made to our teammates and community. What is that promise? Our founder and CEO, Alyssa, put it best:

“I want people to remember they’re part of nature. I want to fundamentally shift our relationship with the natural world and start to respect the animals and the plants and the water and the soil, and to see ourselves as part of that whole. I want people to stop being so afraid of climate change. I want people to stop being depressed and sad and overwhelmed and anxious. I want people to get curious and excited about what they can do and start to see themselves as the solution and not the problem.”

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.

Flexport was founded in 2014 and became a $3.2 billion-valued unicorn in 2019 – with only 150 engineers.

In the past year, Flexport opened offices in Seattle and Philadelphia, bringing us to 12 locations and counting! The volume we’re shipping has increased so rapidly that we’ve purchased warehouses in Hong Kong, Los Angeles, and Shenzhen, and we’ve even leased our own Boeing 747!

We achieved this growth thanks to 150 engineers across four cities and three countries, something we attribute to a carefully designed product cycle that syncs strategically with the business. To keep up with the growing demand, engineers move fast.

When you join Flexport, you will ship code on your first day. You’ll build our product and design flexible, high-quality solutions. To help you understand the broad scope of our mission, you’ll participate in a week-long crash course on the fundamentals of global trade. Your onboarding class will be flying in from offices around the world and 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’re a fast-moving team in a fast-moving industry.

We never spend more than two weeks working on anything before putting it in front of real users and seeing how they respond. Jon built the entire tax product in two weeks and launched it on TechCrunch (the same day we got backed by Initialized Capital).

This can be attributed to (a) being focused, (b) breaking up large efforts into tactical tasks, and (c) shipping early, often, and regularly. The quicker we can launch a feature, the quicker we can learn and better steer ourselves in the right direction.

Our company is around 100 teammates, and we operate as a startup, where time-to-market is very important.

This doesn’t necessarily mean longer hours or nights and weekends – we don’t want to work with urgency or in an unsustainable go-go-go environment where our engineers can’t have room to breathe (see work/life balance section below!) – but the pace is still fast enough where we can experiment with interesting ideas and still push out new features to production in a timely manner to delight our members.

This ties into our data-driven culture (see data-driven section below!), where we have a quick ideation cycle to watch how our users interact with different ideas. Depending on the response we get from that data, our engineering team has to be fast-paced in order to line up with the findings and quickly deliver.

In terms of workflow, we have 1-2 week agile sprints where we work cross-functionally with other teams to complete a sprint cycle. We tackle projects iteratively and push code out live faster than the fintech industry norm, which is around 3-4 weeks. See the agile methodologies section below for more details on our workflow.

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.

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.

“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.

Even though we move quickly, we are careful in considering the technical debt we choose to take on.

Dev.xyz provides development support to all the businesses within the XYZ family. The needs of the various businesses we service change regularly so our team is able to react quickly to new situations. Every month is different, and each business gets busy around different times of the year.

There are two areas of business that we focus on. The first is our top level domain operation: we operate the domain extensions .xyz, .college, .rent, .theatre, and several others. The second is a large online marketing operation. We manage 100+ websites around the internet and we have built several robust reporting tools to support the large amount of data coming in through those sites. Most of the maintenance is compliance related (this is ongoing).

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.

Slow to production = Slow to market = An opportunity for the competition to beat us.

At a strategic level, Billtrust is comfortable taking big bets and incubating them as they evaluate them for success or failure. We set aggressive timelines for getting new products off the ground quickly. We’re careful not to constantly make “false starts” and jerk ourselves around; but if something is not working out we fail fast and move on, which we consider a strength.

At a slightly more tactical level, the challenges our customers are facing are constantly changing and they are looking to us to provide the solutions quickly. The pace of adapting to our customer/market is not counted in terms of years, but weeks. Newer applications and products are deployed upon sprint completion, i.e., CI/CD. Our teams recognize the importance of each feature and the need to get it into production with high quality. We strive to have an environment of under one day turn around, which means we should be able to start our day by identifying a fix/change/problem, spend the day developing, building, and testing the modification, then promote it into production before leaving the office for the day without impacting any users.

We are a small team so everyone has to demonstrate clear value to the team, and to the client.

On the engineering side, we get weekly requests from clients which need to be addressed quickly, with thoughtful strategy and implementation. We use Trello extensively and go out of our way to get the engineers’ feedback before starting a project. It doesn't feel frantic but busy with a sense of urgency. We get feature requests and bug fixes. Mostly feature requests. We usually say yes to feature requests with an estimated timeline. The big differentiator with our company is that we are users of our own product on the agency side, so we build ahead of clients. Almost 95% of the feature requests coming in are projects already in progress as we have internally asked for them, so we speak with credibility and sound cadence.

In order to grow fast, we had to quickly learn to make decisions on the fly.

This meant really focusing on the main value our product brought to customers: simple-to-use, visual-first communication and accountability tools. While we still aim to ship quickly (every two weeks on mobile and when it’s ready on the web), we have a better understanding of our users and are focused on cutting the non-essentials to make sure we are always delivering simple-to-use product.

When you meet Luke, you'll learn pretty fast that he has an eye for shiny objects, and we see this as a superpower and visionary tool we’ve been able to harness. As we continue to grow, we’ve built systems that allow us to tweak ideas and features quickly, without the team feeling like they are tackling never-ending projects.

While our product team is busy working on our mobile and web apps, our sales team is out at trade shows meeting with new and existing customers. They bring back lots of valuable feedback, which helps shape the direction of our product.

Below: Our sales and marketing team at an event educating high school students on careers in the startup world.

Founded in 2014, we’ve already become one of the biggest owned and operated home care businesses in the country.

We’re in multiple states and continue to scale quickly. But our growth can’t come at the expense of quality. Our clients and their families come to us in a time of need, and we need to provide them with the highest possible quality of care and communication. Despite our scale, we’ll always retain the software development tenets that we started with: iterative, fast-paced, and data-driven.

We were founded in 2014 in San Francisco. Below we proudly celebrate the opening of our new Austin office with an official ribbon cutting ceremony endorsed by Austin’s Chamber of Commerce!

One of the founding principles of Thread is we aim to move uncomfortably fast.

We prefer to ship MVPs and collect data, rather than have endless debates. We practice continuous deployment, and prefer lots of rapid, small releases. This allows us to instantly see feedback from users and how metrics are affected, which lead to a shorter feedback loop. It’s a lot easier to debug integration errors, and modular development is encouraged.

During Y Combinator we set weekly stretch goals, and we continue this practice today with every team setting their own stretch goals on a Monday and us celebrating (or commiserating) outcomes in our weekly all-hands each Friday. This doesn’t mean working more hours or typing faster. It means critically thinking through the issues to find the uncomfortably fast way of getting the core things achieved.

The consumer payments industry moves painfully slow, but we don’t have to.

We want to build a best-in-class P2P payments experience while making sure to keep our users’ personal and financial data secure. Because consumer payments is a heavily regulated industry, it tends to move slowly. That is changing thanks to a handful of new financial infrastructure companies (Plaid, Alloy and VGS, for example) that streamline data security and compliance in new and exciting ways. We can leverage these new infrastructure offerings to our advantage, to help us move faster on the product side while still maintaining incredibly high standards for data security and compliance.

Scrappiness and urgency are two of our company values.

Our team members have had previous experiences working at or founding startups, so we’re well aware that “fast-paced environment” has become a euphemism for “it’s crazy." Yes, the excitement and energy that make startup culture so special is certainly alive and well at Alto, but what we really mean by fast-paced is that you will be expected to contribute a lot and very quickly. We’ve built different products in a very short time with very few people, and we’re constantly pushing to ship new things. Alto thinks on the order of weeks, not months. As we grow our team, we’re looking for people who are energized by a sense of scrappiness and urgency.

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.

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.

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.

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 towards 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 crazy 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. At Range, 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 have to be agile and able to reprioritize quickly.

There are many external factors, not just engineering, that influence our roadmap, and we will always prioritize what the platform or customer needs. Quite often, those requests change on short notice and we need to reprioritize appropriately. It’s a competitive market, so we have to perform efficiently and be agile.

We’re growing rapidly; we’ve launched in the US, Japan, and most recently in the UK. We’re also planning to launch in the rest of the EU, Australia, and Canada, which means new businesses and new banks in each of these locations. With every passing day, we’re becoming more of a product company. While we have long-term roadmaps, our week-to-week sprints get adjusted regularly.

Our motto is “Ship Early and Ship Often,” and 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’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're outgrowing office spaces that we moved into less than a year ago (see our Chicago office below), and are on track to outgrow a few more. 😏 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, hit us up!

We expect a high level of productivity and output.

We often hear people say, “I can’t believe you accomplished Y in time Z with a team of only X people!” We’re proud of how efficient and effective we are, and want to maintain this level of productivity as we grow our team. To be clear, working in a fast-paced environment does not mean putting in maximum hours. If it did, Google would win every time because they can throw far more people-hours at a problem than we ever could.

Instead, fast-paced to us means (1) focusing on the right problem, (2) being clear-minded and thoughtful enough to find the most appropriate solution for the problem right now, and (3) pushing towards that solution as hard as you can. We consider any Pull Requests that have been open for more than a couple of days to be slow or drawn out, and we single those out during retrospectives to see how we can improve.

Our whole company is focused on one thing at a time, but that one thing can change rapidly based on the environment. A few weeks ago, we discovered we needed to implement a compliance program. We committed to figuring out what the program was, finding a consultant to help us, designing our product to fit it, and shipping it within those same 8 weeks.

Note: Our core work hours are 10am to 4pm, and outside of that people work when it suits them.

We move quickly both in both what work we take on and how we work.

We strive to be adaptable. We adjust quickly to new problems and make changes to the roadmap when we find projects that we think will have a big impact in meeting our goals. We’ve also switched to a continuous deployment workflow which enables us to push code every day. One thing’s for sure: we’re focused on removing barriers and inefficiencies to increase everyone’s velocity and productivity. The competitive spirit is alive and well at SportsRecruits.

We want to build and fail fast.

The way we operate is scrappy. High-quality code is important because as a burgeoning startup, we don’t get everything perfect the first time. We won’t always get all of the pieces of the puzzle. At a bigger company, you might have to wait until you have finalized designs or consensus from the team. Instead at Aero, you decide what you can do with the time you have to move the company forward.

Move north, if you’re supposed to go northeast, you can course direct. Some people have a lot of trouble doing this because they want to be assigned a ticket before executing. We want people who feel comfortable doing work and experimenting. If you have downtime, think of something cool you can do and build it. We’ll test it and see how it’s received. Don’t stop and wait for permission or for someone to define something for you.