Engineers define the end-to-end how for the what, where how is an end-to-end technology decision.
The core of our engineering culture stems from granting engineers complete control of the “how” of our product. By the very nature of building a highly technical product spanning statistical and large data processing features obfuscated from the customer, we felt the need to ensure the engineers building those features are supported and enabled to make the necessary technology decisions end-to-end.
To start, every month our CEO Bilal outlines the “what” or high-level objectives we’re hoping to hit as a company. These have included goals like validating a market hypothesis to reducing hosting costs by 30% to closing a specific large enterprise customer. The engineer then constructs the “how” - ideating on features and functionality that can enable that higher level objective. Some of our most impactful ideas, from Cindy’s exports generator to Scott’s statistical experimentation features have emerged through this modality.
The engineer in turn takes a high level feature description and scopes out the parts that would need to be built; selects appropriate libraries / APIs to be used; and project plans. It’s important to us that team members be a part of the why and how, as it’s an important facet of fulfillment in engineering, as well as success in product by tightly coupling engineering to customer objectives.
Moving forward in a complex product landscape requires an amazing team and great communication.
In fostering an environment where engineers own technical decisions end-to-end, we believe the person closest to the problem knows it best, so engineers will typically own creating their own designs and execute on them. We have to move fast in an early-stage startup, and design decisions are thus adapted quickly by customer feedback on daily basis.
This necessitates an environment where we can ideate, debate, and construct new ideas on the fly every day. Having an ML driven product with enterprise customers, we have to quickly respond to customer feedback and marry domain expertise from different team members in statistics to distributed systems to product. Communication is key to enabling these cross-functional projects to succeed efficiently.
To enable this, we establish tight feedback loops and communication frameworks from the very beginning. We brainstorm all our agile plans on whiteboards. We diagram data schemas and system architectures. And we document everything - literally Eric our CTO takes notes on standups, weekly plans, while our COO Grant documents and shares every customer meeting in Slack. This is necessary to ensure each team member has the context and institutional knowledge to make independent decisions as they build end-to-end functionality.
Actively Practices Inclusion
Open communication only works when coupled with respect and inclusion.
During meetings, everyone gets the chance to speak, uninterrupted. We believe teammates should show respect in how they communicate and listen, and that is critical to ensuring inclusion. To reinforce this, we timebox each team member’s discussion to 15 minute increments - ensuring quick and cogent responses while ensuring time for everyone to speak.
Inclusion to us also means accepting and celebrating every person as a whole. As a small team, we have the luxury of knowing one another well, and understanding each others’ perspectives. When someone first joins the team, we often ask a deep question to get to know them - i.e. “what’s the music genre to describe your life”. We unearthed some truly wonderfully weird quirks in the past… like how Bilal really likes Adele and Taylor Swift.
We want each new hire to feel at home at ClearBrain, and help make ClearBrain their home too. Kind of like how Cindy incepted the office with Dungeons & Dragons… and now everyone has an elfish secret identity now. Or how Eric’s girls are often in the office leaving fun irreplacement contributions to our walls (like heart drawings in permanent ink).
We understand that people have their own lives, and we want to support whatever lifestyle you have. We work long hours, but not necessarily in the office. Eric leaves at 4:30PM every day to pick up his girls from school, but he also codes from 9PM - 1AM regularly after they go to bed. We work hard, but we also work smart.
Customer Comes First
Our mission to build the first truly self-serve AI platform for growth marketing relies on exceptional customer empathy.
ClearBrain’s customers are growth teams at large, fast-growing consumer apps, and services with very large amounts of first-party event data (think: terabytes). Our mission is to multiply their data science capabilities by allowing them to build and iterate on machine learning models in minutes, not weeks, and all without code. When we succeed, we save our customers huge amounts of human effort by automating data syncing, feature engineering, model updates, user scoring, and creating and updating smart audiences every day or week for them.
We are always thinking of our customers. Grant gives a customer overview every week to share learnings and case studies from customers and prospects. We share all of our customer meeting notes in Slack. An engineer at ClearBrain will be present at one or more customer meetings every week, to see see first hand how our work is being used and capture new potential product directions. Case in point, we once had a customer thoroughly critique our UI which inspired Theo to proactively revamp our visualizations for 2 weeks straight.
The majority of new features we build for our product are motivated directly by customer feedback. We meet with our customers several times per month to assess how they’re using our product and diagnose latent needs. Often times, we’ll build things they haven’t directly asked for, but have observed them doing manually in the context of our product. When we approach feature development, we approach it from a perspective of what most effectively solves their problem rather than what shiny new tech to use. We prioritize functionality over complexity.
Committed to Personal Growth
We grow together as a team and push each other to learn and improve every week!
When a person joins ClearBrain, we give them a Rubik’s Cube. Not with the expectation they immediately solve it (though, Theo can solve it in under 25 seconds) - but as a symbol that we hold learning to be fun and rewarding.
An engineer’s first week at ClearBrain is front-loaded with learning. We have codelabs to ramp you up on key parts of the code base. We have deep dives into statistics and data engineering. We give an overview of the product, roadmap, and customer use cases. Eric Siroker commented that the onboarding was more intense than his first weeks at Google.
And no matter where we are currently at in terms of skill level, our expectation of ourselves is that we are raising that bar over time. We hold biweekly brown bags to discuss high-level technical topics, teaching each other on topics ranging from statistics to new languages. Once, the team spent an afternoon learning how to code in React, enabling every engineer to contribute better to our frontend. Employees at ClearBrain are also encouraged to attend conferences, having attended Spark AI Summit and o11ycon in the last year.
We think it’s not just important from the practical perspective of sharing information needed to build our product, but also to help each member of the team level up their technology skills. Plus, given our product’s focus, we never stop (machine) learning!
“How can I improve?”
This is the question we all ask one another in our regular and peer 1:1s. In these more personal settings, it's easy to discuss what is going well and what can be improved, in all directions. For example, our CEO Bilal does all of his 1:1’s with 3 questions: What’s going well? What can be improved? What’s top of mind?
From an engineering standpoint, there are ample opportunities to solicit and give technical feedback. Code reviews and weekly sprint reviews allow team members to share what they have been working on and get feedback from the team.
Finally, we get feedback from our customers and incorporate what they say directly into our product on a weekly basis. Our Friday Customer Updates cover our prospect pipeline, trends in the market, and of course, how customers have seen success with our product. We care deeply about customer feedback and make sure every team member hears it.
We build pretty cool tech, not by choice but by necessity of the customer need.
From the ground up, we built on a vast, data lake model using modern, scalable data science tools: Apache Spark (scala), high performance and fault-tolerant Go servers, and AWS lambdas all managed with CloudFormation and deployed with continuous integration. Our frontend is built on Google Firebase, and heavily uses GCP cloud functions, and we are currently building frontend in React JS. It’s important to note that we don’t chase novelty. We chose technologies because they’re the best tools for our customers’ job.
The problems we are facing are challenging even for world class data science teams. There are a lot of subtleties and irregularities in raw data, and managing predictive models at scale with a fast-changing product and user base is challenging. We work continuously with data science advisors to find creative new ways to solve modeling problems.
On top of the usual problems of scale and data science, we at ClearBrain build tools one layer of abstraction up. Rather than parsing each data set one-off, we engineer features for common data schemas across many customers, and have built a data transformation description spec that allows us to iterate on schemas without changing a line of code. Rather than build each model for a specific use case, we take on the challenge of abstracting away and assessing how to generalize machine learning for every company.
EQ > IQ
We value empathy over intelligence.
Building an inclusive culture around collaboration and communication requires empathy for our customer and respect for our teammates. If you have an ego, you won't fit in. We want everyone on our team to feel safe and included during this startup journey, and we work hard to protect that.
This is reinforced throughout our company practices. We have strict bands for salary and equity and believe parity between employees by experience is important. We don’t negotiate (much), and will pass on candidates if they push us beyond parity. We’re in this for the long haul, and want to be fair to all employees over our lifecycle, not just those optimizing for short-term gains.
And this extends to product development and our overall framework for decisions. We all strive to do what’s best for the customer. If there’s a new feature we’re evaluating, or technical architecture decision we have to make, we always evaluate what’s the quickest way to realize or validate value for the customer.