51 - 100 employees
11 - 25 engineers
$25m - $50m funding
Series a

WHAT WE DO Atrium is a well funded San Francisco startup, founded by experienced entrepreneurs, that seeks to empower individuals, managers, and teams to make better-informed work decisions by helping them harness the data they create in their day to day jobs. One way to think of it is like Fitbit or Strava, for staff and managers.

Historically, helping staff and managers understand that they are working on the right things, and doing so effectively, has required lots of manual instrumentation or torturing enterprise systems to provide the requisite feedback loops.

We believe that by using the activity that organizations engage in day to day in systems like email, calendar, chat, CRM, help desk, version control, ticketing systems, and more, we can help make the previously invisible, visible, in much the same fashion that sports teams analyze and drive feedback loops of game time performance. By doing so, we can help individuals be the best professionals they can be, and managers be the coaches and enablers they would prefer to be.

As the economy turns to one primarily built on knowledge work, where the effectiveness of creative workers will drive economic success, an employee success solution of this variety has the opportunity to be as category defining as Workday.

AtriumHQ photo 1
Active Roles

Why join us?

  • We are building something huge, to make people happier in their jobs. Join us to change the way people work.

  • We are a talented, curious, authentic, and aspirational group. Join a team that you will love working with every day.

  • Funded by well-respected investors (First Round Capital, Charles River Ventures). Join a team that has the resources to be set up for success.

  • Founded by an experienced team of entrepreneurs and engineers who worked together through to a successful acquisition.

Engineering at AtriumHQ

Engineering team and processes

We have a flat organizational structure, but the areas of focus for our engineering team are loosely grouped between backend/platform, web application, and mobile application. While all 5 of our engineers occasionally touch all parts of the codebase, and participate in architectural brainstorms and code reviews across the stack, the majority of coding for a given engineer happens within one of those 3 spheres of influence.

Our team operates on two week sprint cycles and quarter long product planning cycles. Our CEO (and head of product) kicks off each planning cycle by gathering ideas from each member of the team, in addition to collecting input from customers, prospects, lost deals, etc. He then works with product, engineering, sales, and customer success to force rank prioritize 4 sprint’s worth of new/enhanced feature work from the long list of ideas. The 5th sprint is a usabiility focused sprint, where we execute against the top usability issues in our product to make sure the user experience and “cleaning up after ourselves” is always a priority. The 6th sprint is an engineering driven sprint in which each engineer has the freedom to plan their own sprint, generally focusing on engineering efficiency and scalability, but occasionally just working on what they find most interesting.

We start each sprint with a sprint kickoff lunch meeting and end each sprint with a retro to ensure we are addressing issues as they arise and celebrating successes. Most features are owned by a single engineer, but for larger projects that involve significant backend and frontend work we will split the project between two engineers. All project have a product owner, although that person could be the CEO, a product manager, or the lead project engineer. depending on the complexity of the feature and engineering preferences. Our UX lead owns the design for all features where new designs / interaction paradigms are necessary.

The product team will hand-off with documentation ranging from a single Jira ticket to a thorough product spec with accompanying prototype, depending on what is needed / desired by engineering. Product heavy features have an initial kickoff meeting to ensure alignment, and architecturally complicated features have an initial design review meeting.

We use a Git rebase flow and PRs for version control and to conduct code reviews. Engineers are empowered to deploy to production frequently.

Technical Challenges

A major ongoing technical challenge is how to condense a huge wealth of information into concise, relevant, and immediately actionable information. The technical challenges we have are driven by product needs - either primarily in terms of improving our ability to efficiently slice and dice and organize data. This requires an efficient and extensible architecture (our codebase), stable processes for consuming new data and generating the necessary analysis (our data pipeline), and good tooling to distribute and visualize this information (our clients and API). A second major challenge is that we don't create our own data - we consume data from external sources and systems of record and businesses, especially larger ones, often customize their own data sources extensively. What this means is to have an accurate view of the world, we're always discovering new ways in which people catalog and structure information that we then need to consume and integrate with our existing data pipeline. This leads to a lot of intricate data modeling and SQL to represent these complexities.

Projects you might work on
  • Anomaly detection is the bread and butter of our system - given a multitude of different metrics, we figure out what's worth looking at and why. One of our earlier projects was to figure out how to deduplicate between different kinds of behavioral anomalies to present the most valuable and actionable information to the end user. An example anomaly is an individual having an unusually low number of meetings scheduled in a week or sending an unusually large number of emails relative to their peers. Because we deal with data for entire organizations, it's possible for us to identify redundant anomalies, e.g. we could identify outlier behaviors for an individual AND for that individual's team. What's interesting is that the team could be appearing anomalous explicitly because of the behavior of one individual (imagine someone closing an unusually large multi-million dollar deal), so then we had to figure out what's more valuable information in this situation - the broader team anomaly, or the specific contextualized anomaly for the individual? There are numerous flavors of similar problems that we ultimately solved with a unified technique for outlier detection; we would use the concepts of outliers (either outlier measurements or individuals) to select the most valuable information to display. This system is now used in many places throughout our code base to provide an easy and efficient way to prioritize the highest signal data.

Tech stack
Spring MVC

Working at AtriumHQ

OUR CULTURE: We move fast and are willing to take risks, question assumptions, try new things, and learn from the results. We understand that we can’t make our users more successful in their jobs without understanding their needs. We expect transparent, intellectually honest, open-minded, and empathetic conversations with each other. We work efficiently and effectively together, so we can build and maintain fulfilling lives when we are apart. We support creativity and don’t micromanage, and in exchange, we expect high integrity and results.

Perks & benefits
  • Workshops/Conferences
  • Maternal/Paternal Leave
  • Team Activities
  • Generous Vacation
  • Health Insurance
  • Beautiful Office
  • Flexible Hours
Our Team by the Numbers

External Links

Interested in this company?
Skip straight to final-round interviews by applying through Triplebyte.