Engineering at Plus

Our mission is to enable anyone to make sense of their business data, no matter where it lives.

We’re building Plus for a customer that we know well. Our founders, Chloe and Dan, met as teammates on their first project as management consultants, where they spent a lot of time wrangling data from multiple sources to create presentations to influence business decisions.

The average tech company today uses nearly 100 different SaaS tools, and the thing we hear from customers over and over again is that people have too much data in different places and not enough time to make sense of it in order to make good decisions. That's why we created Plus: a tool to help anyone make sense of their data no matter where it lives.

As a team, we expect everyone to have a shared understanding of our mission and how their work impacts our customers. Every engineer participates in customer interactions and contributes to shaping product solutions. We believe that investing more deeply in product understanding enables our feature teams to operate with more ownership and autonomy, make better technical decisions, and deliver value faster.

We spend a lot of time talking to customers, and we try to understand their underlying problems rather than just taking their feedback at face value. Every decision we make is grounded in our product principles to keep it simple for the end user. It also allows us to rely on familiar concepts and work with existing collaboration tools and workflows. For example, that’s why we decided to focus on image-based “Snapshots” as a familiar and universal way to surface business information, rather than building data extraction tools that would require our customers to learn new paradigms.

We have an incredibly impressive team, but we demonstrate that with our work, not by talking about our resumes.

We’re proud to work with people who are talented, humble, and authentic. As an early stage company, we have significantly more options and constraints when making decisions. This means our challenges are inherently more multifaceted and ambiguous than those facing more mature businesses.

These problems raise the bar on the level of collaboration we need across our team and often require us to wear lots of hats (or at least try on new ones). For instance, in his first month at Plus, one of our software engineers, Zach, quickly ramped up on our code base and started making major contributions to our app. However, in addition to his engineering work, he also helped us iterate and improve on our recruiting process after going through it himself and synthesizing feedback from other members of the team.

People join Plus because they want to not only build a great product, but also build a great team, culture, and company from the ground up. We are looking for people who can put the team above themselves and who can admit to being wrong or not knowing an answer. We know that no one on our team is perfect, and we would rather work with imperfect people who are open to growth and learning. It’s important to us to build a team that works together to achieve exceptional things, which is why we look for great team players, not “10x engineers.”

We can count on each other.

As a team, we have a bias for context over control – we develop a shared understanding of the most important problems, and then give team members the autonomy to develop and validate the solutions. We hold each other accountable for outcomes, not hours spent. No one is watching over your shoulder to make sure you’re getting work done. You have the autonomy to figure out a work schedule that makes sense for you.

In return, we expect our teammates to own their work and deliver what they promise. Engineers keep the bar high on quality, security, and end-to-end customer experience, not just executing the tasks they are assigned. People who thrive here are able to remove their own roadblocks without waiting to be told what to do.

As a company, we want to empower people to do their best work and give everyone the tools, support, and resources necessary to achieve their goals. We strive to create an environment that removes as many distractions as possible, and an important part of that philosophy is making sure our team can come to work, focus on what they do best, and not worry about non-work-related concerns.

To help reduce anxiety around questions like, “Am I getting paid enough?” or “How much will my family’s medical bills cost?”, we pay top of market compensation for cash and equity, and we pay 100% of premiums for best-in-class healthcare for all employees and dependents. In our offer process, we are transparent and share the benchmark data we use to create offers so that we can try to minimize bias and help candidates and employees feel good about working here.

Everyone on the team also has a $500 monthly outsourcing budget to find creative ways to offload tasks that are not a good use of their time, like manually testing our “Snapshot” system on different business apps or getting new icons drawn for our web app. Our primary goal is to find people who are great at what they do and create a work environment where they can focus on what they do best.

Trust and transparency are foundational to how we operate.

We believe that everyone should have the context they need to do their jobs well, and that “how I’m doing” is a crucial piece of that context. We avoid leaving important things unsaid, which means we’re willing to have difficult conversations or give constructive feedback as needed.

Feedback is a part of everyone’s job, and we expect our managers and leaders to model giving and soliciting direct, actionable, and kind feedback. We try to quickly build trust with new team members, and we always assume good intent and competence in others.

As a distributed team, we invest in formalizing our communication and working norms to remove ambiguity. During onboarding, new hires create user guides that describe their working style and communication preferences. Our engineering team also co-creates and maintains a working agreement that includes norms like asking questions in public forums and discouraging information silos. Even if a question could be answered by one person, we default to a public channel, so the information can be seen by more team members, and the resolution of the question can be documented.

We prioritize experimentation and hypothesis-driven decision making.

When making a decision, we first ask ourselves whether it is a “one-way” or “two-way” door. At our stage, most decisions turn out to be more reversible than we think, and making that explicit helps us contextualize the amount of risk we are actually taking on. For example, we intentionally included features in our alpha product that won’t scale in a cost effective way because we want to learn and prioritize customer feedback early on.

We plan as much as is useful – usually a quarter or two at a time – but we are realistic about our ability to predict the future. We treat our plans and product goals like working hypotheses to be validated through shipping features and actual customer usage and feedback.

We want to build a team that is pragmatic, not dogmatic in our decision making. Sometimes we make decisions based on intuition. Sometimes we have to disagree and commit. And sometimes we turn out to be wrong and need to change course. At the end of the day, our goal is to optimize for the velocity of our learning rather than the percentage of things we get right on the first try.

We have a bias for speed over perfection.

Our biggest advantage is having a small, nimble team that can quickly respond to customer feedback, turn ideas into features, and execute on building an amazing product. We’d rather release a smaller iteration sooner, because we’ll learn more as a team about how to proceed.

As an engineering team, we break up our tasks and push up work early and often to maintain momentum. We'd rather see iterative in-progress pieces that may be messy, than no work at all. We try to not let individual PRs become too large, so that team members can review our work in a reasonable amount of time. Similarly, we aim to keep base components smaller so we can build on them for more complex functionality.

We are excited by problems that don’t yet have solutions.

As a startup, we don’t know the full scope of challenges we will face. Our team members have a range of different backgrounds and experiences, but we all share an appetite for learning new skills and developing new areas of expertise. Solving problems that are new to both us and the world is exciting and challenging, which is why we’re all bonded by a sense of optimism.

We want to hire people who can scale with the company and grow into technical and people leadership roles. We don’t know for sure what challenges we’ll be facing in 6 or 12 months, so it’s important that we hire for potential.

Whenever possible, we are committed to creating growth opportunities for folks on our team. We don’t have the structured career ladder of a big company, but we do have the flexibility to shape roles and opportunities around individuals. For example, we’ve crafted roles around generalists who want a breadth of experience and those with deep domain expertise. We are supporting engineers who want to grow into people management and those who want to focus on their technical expertise as an individual contributor.

We recognize that career paths are not linear or uniform because many of us didn’t take them. Our goal is to help you gain the skills and knowledge to further your growth and achieve your goals – whatever that may look like to you.

We want people to do their best work at Plus, and that means making work work for each person.

We are a remote-first company, and we’re open to global hires as long as they work in a U.S. time zone. Our founders are not co-located and we don’t have a “headquarters” office or implied hierarchy of geography. In fact, most of our founding team came from companies that were remote-first prior to 2020.

We care about results, not hours, which means our work naturally ebbs and flows over time. Sometimes we stay online later to unblock a teammate or a customer. In general, we want everyone on the team to maintain a sustainable and predictable schedule – whatever that means for them.

We aim to strike a balance between synchronous and asynchronous communication. We don’t have a meeting heavy culture and bias toward more deliberate written documentation. However, we ensure there is time zone overlap on the team to hop on a call to work something out rather than get buried in lengthy Slack threads.

Since we’re remote-first, we know we have to be more deliberate about spending time getting to know one another as people. We set aside time every week to do fun, thought-provoking icebreakers (“Aliens have landed on earth. Who do you call to represent humanity?”), and we do silly things like play board games and make wagers that end with us wearing banana costumes. Dan, our CEO and co-founder, shares some of his favorite ice breakers and more about how we foster a great remote-first culture in this blog. We also try to get together in person a few times a year and you can read about how we made our Seattle meet-up fun, productive, and inclusive here.

If any of this resonates with you, don’t hesitate to get in touch!