Open communication is part of our day-to-day life at Rune.
At the most rudimentary level, we practice open communication by having open document standards: anyone can see the work of any other department. This extends all the way to the executive team’s weekly agenda and notes.
More importantly, we set the expectation that concrete, explainable reasons must back our decisions; this goes double for leadership. We have a company-wide all-hands every week and engineering has an all-hands every two weeks where leadership provides updates, and we raise topics for discussion ranging from things that affect our work/life balance (e.g. moving our daily production deploys so that east coast folks don't have to be online too late) to our process (e.g. how we want to use Asana).
Technical planning is done on shared documents open to everyone, so that architectural decisions and discussions about them are transparent. If we introduce tech debt, it should be a conscious choice, and every engineer should know why we made that choice, and how/when we plan to address it.
At weekly meetings for each stack team (backend, mobile, frontend), the agenda includes "emerging issues" - a space for everyone to bring concerns about problems they feel are creeping in under the radar. These are issues that cause (sometimes subconscious) anxiety in us, and making it safe to make that a shared responsibility – and not wait until it's a tangible problem – is something we value greatly.
We also practice frequently bringing up topics around our emotional health, stress levels, or even concerns about the future that can sometimes be hard to put precisely into words (like how we plan on preserving our values as we grow). For example, instead of a "what are you doing?" check-in in Slack, we have an optional prompt based on a mindfulness exercise: "As I start the week, I feel ___. The body sensation I'm most aware of is ___". We set an expectation that leadership is allowed to show vulnerability, to admit when they are feeling stretched, or worried about meeting a goal, or disappointed in their own performance. Every staff meeting begins with a Health Check where we report both on our own and our teams' mental health.
Every six weeks we have company-wide retrospectives. In the past, team members have felt comfortable sharing their feelings when UI designs change too often, when we've lost a team member, when our process has holes AND when it starts getting in the way, when OKRs don't provide any guidance, when deadlines aren't realistic, when expectations aren't being clear, or when we're exhausted with Zoom fatigue and need to set some boundaries.
We work as much with other company functions as we do together.
At Rune, we deeply value learning from one another. Our Product and Engineering teams work together on every project. Features have kickoff meetings where Product starts by walking engineers through the conversations they’ve had with stakeholders, whether it's patients, clinicians, researchers, or business partners. We hear the user stories and pain points. From there, we arrive at requirements together, so that everyone feels it's feasible, the scope is acceptable, the motivation is understood, and the solution is maintainable and valuable to as many different stakeholders as possible.
When working directly on data, which is often, engineers work hand-in-hand with our Neuroscience team as well. We learn about not just the structure of datasets, but also the semantics of the data and how it will be used to answer questions about the patient’s state and health.
While we value our heads-down maker time, it’s almost impossible to work alone at Rune. We have many deep technical challenges, but not the kind that can be solved well by going to a dark corner for months to tackle alone, because so much of the knowledge you need to solve them correctly lives with other people. We are not just implementing a solution to a problem – we're actively figuring out the neuroscience and data science day-by-day alongside the biggest research and clinical labs in the country, and even abroad. As new discoveries are made, we are right there too, supporting them with technology, and implementing their techniques for the entire community to make progress together.
We are all very chatty on Slack, we jump on Zoom calls when needed, and rely heavily on Quip to document everything clearly in writing so decisions and details are not lost in chat or in-person calls. While half the company is in the SF Bay Area, we're also very conscious not to ever make our remote peers feel like second class citizens.
Committed to Personal Growth
It is important to us that every engineer sees their path forward, not only at Rune, but also in their career overall.
Some folks haven't quite figured it out, and that's ok. We try to help by making it very feasible to be able to change teams, change what part of the stack you focus on, and what kind of technology you're exposed to, until something resonates with you.
While we're still on the smaller side, we have an internship program and engage every year with university career fairs. We encourage everyone to participate in the community, and will sponsor engineers to represent the company at public speaking events and in underrepresented communities. We also pair every engineer with a mentor from the senior staff, who helps them advance at their own pace to take on more responsibility and harder projects.
We're tackling some very hard technology at scale and complexity that many other companies aren't facing. That said, if you’ve never worked on these systems before, it’s not a barrier. Rather, we focus on hiring people that are committed to improving and learning the best way to do things, not just the fastest. We teach others how to design architecturally before we ever hit code, how to address scalability both on paper and empirically, how to predict and mitigate failure modes and security concerns, how to think about the infrastructure supporting your code, how to make responsive and interactive data analysis tools in the browser, and how to create mobile applications that are hyper aware of users affected in very different ways by neurological conditions such as movement, depressive, or compulsive disorders. If this sounds interesting to you and you’re excited about learning more, we’d love to hear from you!
Actively Practices Inclusion
Two of our core founding values are "Self-awareness" and "We're all in it together."
We're not only tackling hard technical challenges, but also working with the foremost communities and institutions in neuroscience and neurology to help bring about completely new therapies and modes of patient care based on data. It's going to take every viewpoint, every background, every way of problem solving, and every person to truly break new ground.
We work hard toward a recruiting process that doesn’t rely solely on inbound applications (which is inherently biased toward overrepresented groups). Rather, we strive to engage and reach out to underrepresented candidates and groups that may not discover Rune otherwise.
We work hand-in-hand with People Ops to regularly review our resume screening, phone screening, and technical interview structure for bias or other ways we can improve. For example, in technical interviews, we try to address pressure-bias by giving applicants a choice between a bring-along code challenge they can complete on their own time, or a white boarding session where there's problem solving on the spot.
Being a hybrid onsite/remote team also has its challenges. All our meetings are hosted in a remote-friendly format, with everyone on video conference regardless of whether you're sitting next to each other or a thousand miles away. We rely heavily on collaboration apps for white-boarding and note taking so that everyone can access the same information to the same degree, and have a say in conclusions and action items.
Self-awareness is the value that allows us to be better at these things. At all-company meetings every quarter, we talk about our inherent biases and how the assumptions and labels we grew up with don't apply to everyone. Little things such as asking how candidates and employees self-identify help us be better at providing a psychologically safe environment at Rune.
Asking questions and regularly gathering feedback is core to what we do.
Rune was founded with the mission of addressing questions in neuroscience and brain disease that haven't been answered. If the answers came easy, we wouldn't exist. While our engineering team is collectively familiar with much of the technology we use, there's no real blueprint past that.
Even when Rune was barely a year old and less than ten people, we instituted regularly scheduled one-on-ones and quarterly performance reviews. We wanted each person to always be clear on how they're doing, eliminate any surprises, and understand what the next step up in their career at Rune looks like. For things that affect the team, anyone can raise discussions at our engineering all-hands every two weeks. Every couple months, our company-wide retrospectives are also an opportunity for anyone to bring up what works and what doesn't at the edges of the engineering team, so our cross-department collaboration is never a source of friction.
Our development cycle is also very fast and continuous (see Continuous Delivery below). We don't have a name for it, but we've taken the concepts of fast iteration and tight feedback loops from Agile, while doing away with the ceremonies around Sprints. Outside of the engineering team, our peers in the product and neuroscience teams put everything into use right away, and let us know immediately how our work is solving problems, and what direction is next. We deploy to production daily, and use feature flags, so we can run experiments and ask early adopters for feedback before we get too far ahead of ourselves. These tight feedback loops ensure we’re building the strongest product possible.
High Quality Code Base
We don't write throw-away code.
Every day, more and more patients, clinicians, and researchers rely on our data APIs being available, our algorithms processing continuously, and every point in between being 100% secure.
We measure thrice, and cut once. We require an architectural design document for every feature we build, together with a risk matrix to help predict things that can go wrong. We also require code leaving a branch to be production ready, which means it comes with tests and a monitoring strategy. It's more work, and it does mean it takes a little longer until we write that first line of code, but when we do, there are no surprises and it more than makes up for the time spent up-front.
In terms of the staples, our team actively uses and gate merges on peer-reviewed pull requests, lint and static analysis checks, unit tests, and integration tests. We invest heavily in CI/CD automation, 100% of our infrastructure is peer-reviewed code, and we <3 observability!
All this isn't to say that we don't have tech debt. However, our team's approach is to have tech debt that we choose consciously and strategically as we design each feature. Each quarter, we allocate 70% of engineering hours to new feature development and 30% to our internal needs.
We release to production every single day with no downtime.
We invested heavily in automation from day one, so now all it takes to deploy is to approve and merge a GitHub pull request. Our staging environment is continuously updated every time anyone merges their branch to main, so our engineers can test their changes within 10 minutes against a full replica of our production environment.
Feature flags play a big role in helping us stay safe while moving fast. No matter how large a feature, we implement it in parts and wrap it in a flag so we can enable it just for ourselves and our friends in the product team. While our code never touches servers unless it has sufficient tests, uncovering unknowns in an environment where it's safe to make mistakes is what, at the end of the day, keeps our promises to our patients and users.
Researchers and clinicians from some of the leading neuro labs and hospitals in the country count on us to ensure their work helps everyone affected by brain disease. We've built Rune on the soundest principles of infrastructure and code management so we can bring them the data they need.
Each feature has an engineering champion.
At Rune, we've organized ourselves into Durable Teams. Whether you're focused on Patient & Clinician Experience, Analysis, or Core Platform, you're there side-by-side in every standup with champions from the product and neuroscience teams.
There's plenty of tasks that take one engineer a few days or less, but anything bigger or anything that requires cross-stack collaboration puts us in collective gear. During early discovery and ideation, our Product folks bring home the user research and put together user stories decorated with engineering’s final say on feasibility and scope of work. When we're all on board to build a given feature, everyone jumps into a Kickoff meeting to get up to speed on what problem we're trying to solve and for whom. Each feature has an engineering champion that knows the ins and outs of the project, what it means to be "done,” and the technical vision for future iterations.
For example, when we built our mobile integration with the Apple Watch, there was a limit on how much we could unit test in a CI environment. We did our best to design and build against documentation. Our mobile lead got the entire company engaged with our TestFlight build to generate data from different watches while doing different activities, and we discovered a lot of edge cases. As we slowly rolled out the app, we discovered even more anomalies. We knew we needed to bring reliability up to the expectations of our clinical and research users, so we connected our engineering lead with the actual beta testers, and even collaborated directly with the Apple team that had built the Watch kits we were pulling data from. As an engineer, you’ll play an integral role in driving projects forward and make an impact from day one.