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) co-founded Meraki, a wireless company later acquired by Cisco for $1.2 billion in 2012. With the knowledge acquired through growing this bootstrapped start-up from idea to acquisition, the leadership team was able to make the right choices early on in founding Samsara: get products into customer hands quickly and ask for feedback, actively listen to customers, and continue to hire insatiably curious, talented people. In just 3 years, we’ve scaled the business from a handful of sensor data points from a customer in South San Francisco to over 10 billion sensor data points per year from over 5,000 customers around the world. And, as our leaders are always building Samsara for the long term, we recently announced a Series D round (valuing the company at $1.4B) to continue to invest in developing innovative technology that our customers love. If you are 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.

We are growing fast.

In the past year, Flexport opened offices in Atlanta, Chicago and Hamburg. The volume we’re shipping has increased at such a pace that we purchased warehouses in Hong Kong, Los Angeles and Shenzhen -- we even leased our own Boeing 747!

We achieved this growth with just 50 engineers, something we attribute to a carefully designed product cycle that syncs strategically with the business. To keep up with demand growth, engineers move fast.

When you join Flexport, you ship code on your first day. You build our product and design flexible, high-quality solutions. To help you understand the broad scope of our mission, you will 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 will consist of people from operations, sales, marketing, product, design and more. This will be a great opportunity to tap into the cross-functional knowledge of your starting cohort!

We move fast and (try not to) break things.

Gem is growing incredibly quickly: we’ve gone from 3 to 20 employees, outgrown our office three times, and increased revenue 10x — all within the past year. That growth is thanks to the velocity with which we operate: taking calculated risks, saying yes to crazy ideas, and building and shipping quickly are all hard-coded into our DNA.

Sometimes, moving fast means getting creative on engineering. From scraping the public web, to reverse-engineering private APIs, to diving deep into inner workings of Chrome Extensions, we’ll build what it takes to move fast.

When it comes to product, we know there’s a tradeoff between building fast and building right, and we think we’ve found a good balance. As we build new features, we sprint to an MVP to get something in the customer’s hands, then iterate based on feedback from a core set of users. A tight feedback loop ensures that we’re always building the right thing and not burning our efforts towards the wrong goals.

On some days we deploy multiple times a day.

We value pushing an MVP out to get customer feedback before committing to full feature development. We’ve deployed all of our current features as very rough MVP’s first and then built them out more thoroughly only if it looked like customers actually wanted to use that feature. All of our engineers including interns ship on day 1.

We’re building a product that has never existed before, which means we have to keep learning from our users in order to to keep iterating.

This is why we often create micro-teams of 2 or 3 people, who will work on a specific feature or task, and we regroup every 2 weeks to gather our thoughts, re-prioritise, and create new micro-team combinations to keep on experimenting and iterating. We monitor the impact of the videos we produce and combines that from the video creators to help define our product.

We also pride ourselves on the cutting-edge technology we have build, and that means we have to keep moving quickly, by pushing the state of the art in machine learning and speech processing, so we won’t be left behind by much bigger players.

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 more quickly we can launch a feature, the more quickly we can learn and better steer ourselves in the right direction.

At Intercom we think slightly different and operate by a more robust core value: move fast and optimize for the long term.

Intercom moves quickly, and engineering is at the heart of that fast tempo. We acknowledge in our cultural values that we need to temper this pace to ensure that we maintain the high bar of quality we desire and to avoid being frantic or rushed.

To do this we spend a lot of time getting to the essence of the value of whatever it is we’re working on, trying to cut the fat rather than cut the corner. We’ll aggressively scope features and always fight complexity. We look for simple, well-focused solutions that are free from the complexity that will slow us down over time.

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.

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.

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

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.

Although only four years old, 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 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 tend to ship a major feature about once a month.

We’re a small, agile team moving very quickly. We collectively decide what to build, and once we’ve decided what to build, there isn’t a lot of red tape or obstacles. We believe in our mission: to defeat mass surveillance and protect our users’ privacy. We’re motivated to fulfill the promise of our project and deliver for our users.

We've recently shipped:

• Voice and video calls
• Voice messages aka voice notes
• Improved user verification process
• Muting
• Blocking
• Support for sending any file type as an attachment
• Improved onboarding
• Profiles
• Copy and paste of attachments
• And much more...

We’re building on a constantly shifting foundation (iOS/Android) in the fastest moving industry on the planet, and we owe most of our success to the speed at which we operate.

The reason we have been so successful in taking over the deep linking industry is our ability to ship quickly and beat our competitors to market. We eliminate bureaucracy and empower our engineers to make impactful decisions and make mistakes along the way. Everyone who joins is shocked by how quickly we launch products and how quickly we move. We have launched four enterprise quality products within the last year and a half. We don’t always nail it the first time though, we’ve also built other products that didn’t quite work out - we learned something and moved on.

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.

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.

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 know that the only way to approach perfection is to ship early and often.

Before building anything, we figure out—as a team—if it’s the highest priority work we can do. If it is, we come up with the “minimum remarkable product,” a concentrated, testable version of the idea that can be built in a week. Unlike most other iOS companies, we ship a major new app version every week. (In fact we shipped 39 big releases in 2018). If we what we’ve built works, we iterate on it. Each MRP is a building block towards the next evolution of our product.

Our grid interface is a good example of this. When we first launched, sites didn’t scroll. They were fixed 3x5 grids with text, photos, and links. Now you can make a site with as many pages as you’d like, 13 different blocks, and infinite grid sizes.

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 day by day, week by week. We don’t have 6 month roadmaps. Instead, we learn quickly and use that knowledge to figure out the best way to accomplish our goals.

This kind of work environment isn’t for everyone, but for people who want to move fast, learn quickly, and increment towards perfection, it’s addictive.

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.

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.

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

We are small but mighty with only 4 engineers. Sometimes, we surprise even ourselves.

At a fraction of the size of some of our competitors, we have been able to build more products and more quickly push new features. Despite our size, we have already started to outpace our sole designer. Being well-rounded engineers using agile processes, we’ve truly created tremendous momentum. Our next hires will see entire projects through from ideation to execution, and experience the satisfaction of delivering a product used by many. Whether you’re a new CS grad or have a decade of experience, there’s a place for you here. Tweet, email, or drop by our office.

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