I’ve been working at Carbonfact for close to 4 years. Two other people and I were the first hires. I got to build a large share of the initial systems. I’ve been involved in many business decisions, but I’ve mostly actively contributed to technical aspects.

I had to decide on a lot of things at first. What data warehouse to use, the internal data models, how to organize our Python code, our definition of self-serve analytics, and even seemingly mundane things like Pandas vs. Polars. There was a lot to do and it was fun. There were no pushbacks because there was nobody else to push back. I could just build what I thought was best. I even pushed to the main code branch, because nobody else had to review my code. There was always something to build as the startup garnered traction. It felt painless, in a naive sort of way.

The Carbonfact team is bigger now, and we have many customers that keep us on our toes. There are other people in my team, and I definitely don’t push to main – I did get told off several times! There are code reviews, design discussions, and more formal processes. This added friction is intended. It forces me/us not to rush into decisions, and do some thinking through. This quote from Brad Pitt in the F1 movie really summarizes it:

Slow is smooth, smooth is fast.

Anyway, I realized that building a startup means getting used to managing pain. Customers complain about existing features. Prospects are asking for missing features. People internally have very good ideas that they are advocating for. There is an internal interface revamp that is long overdue. Et cetera et cetera. There are more things to do than there is bandwidth. There are also several features that were shipped without much polish, and generate bug reports. There are caveats that we are aware, but which we purposefully delay on solving, waiting for when to become a bigger problem. This is all ok and normal.

You just have to be really good at triaging pain points that come to the surface. There are biases to be aware of. The most obvious one is that recent pains are freshest in memory. They get an undeserved amount of attention when it’s time to decide what to work on. But some pain points are only triggered once, and they never come back. Occasionally, it’s ok to ignore a pain point, and bet on the idea it will not come back. You need to be ok saying no to people from time to time. Sometimes you need to keep the wound open in order to collect more feedback. It takes great timing when it comes to deciding when to soothe a pain. You also have to manage expectations with customers and internal stakeholders, by clearly communicating on timelines.

A corollary to this point is that if you’re not solving pain points, you’re probably not building something people want. So it’s a good problem to have. You just need to be good at managing it. Because it is necessary that anything you work on goes through an initial phase of pain/frustration, before it becomes a beloved feature.

It really helps to be in a healthy and adult environment, where people don’t take things the wrong way. At Carbonfact we assume good intentions, and we try to share our good vibes with our customers. We are aligned on wanting to build the best product for the majority. We also want to cater to specific needs when it makes sense. But we are also ok saying no, in a kind way and reasoned way. I think we are quite good at managing pain.