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 ship every two weeks.

As a startup, we work with a sense of urgency and are constantly making decisions on the fly. At our best, we ship a new feature every two weeks and we do this by planning carefully and cutting down on the non-essential. As engineers, we’re able to move quickly and focus all of our energy into coding because there is very little bureaucracy at Peerspace. We are able to focus on getting features and products into the hands of our customers as quickly as possible, which is incredibly rewarding!

As a company, we’re open to shifting our focus on a quarterly basis. If the current plan isn't supporting the business, we pivot. This means that product and design will often collaborate with engineering to finalize feature definition the week before the sprint it’ll be shipped. Not only do we fail fast and then fix, but we’re also re-evaluating and reprioritizing based on new information we get. For example, both features that have been on the back-burner for some time and features that are in the early stages of ideation can become the next top priority.

Our instant book feature is a great example of our fast-paced environment. We had a goal to ship Instant Booking before Thanksgiving 2018. In order to achieve this, we strategically divided the engineering work between scrum teams in a way where we could easily come together once work had been completed. We were able to ship the feature weeks ahead of our goal, which had immediate impact on the company and allowed us to start on the next features earlier than anticipated.

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.

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.

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

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.

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.

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

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

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

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

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.

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

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

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.

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!