Radical candor: polite persistence
This is a story about how I compromised on our core value of radical candor, which cost us precious engineering time.
One of our core values at Cozero is radical candor. Radical candor is the idea that the willingness to repeatedly enter uncomfortable situations to speak the truth benefits everyone in the long run. The opposite of radical candor is ruinous empathy, i.e., staying quiet to spare others' feelings.
Radical candor is one of those principles that sounds great on paper. Still, consistent practice is challenging since most folks want to be perceived as kind. Internalizing that staying critical even when not asked is the ultimate feat of kindness is not easy.
What follows is a short story about how I failed to stay radically candid, which set our tech organization back.
—
Shortly after joining Cozero, I started questioning our microservices architecture, which exhibited signs of a "distributed monolith" anti-pattern. All services talked to the same database; we consistently deployed all services simultaneously, and there was no versioning. The list continues. This anti-pattern meant we derived few benefits from having the microservices architecture but all the disadvantages. Convoluted inter-service calls, slow local developer experience, long CI times, and a hard-to-manage Kubernetes cluster made quick progress hard.
Within my first weeks, I raised this issue with my peers. No one seemed to directly disagree that the current setup is costing us a lot of time, but I did hear a lot of reasons to keep things as they are:
- The team invested much time into the architecture; changing it could be demoralizing.
- At some point, we will need firm boundaries between growing teams; the microservices architecture will facilitate this.
- We need more time to shift the architecture.
After hearing these arguments a couple of times, I didn't want to be the most annoying person in the room, and even though these arguments were not that convincing to me, I disagreed and committed.
In the following months, we worked on several significant projects connected to the microservices architecture:
- Migrating from Kubernetes to AWS Lambda-hosted microservices to ease maintenance.
- Introducing New Relic as the endgame observability solution.
- Migrating to a new secret management solution.
These projects were large undertakings, in no small part, as they needed to account for the microservices architecture. We had a lot of "things" to migrate. Regardless, we shipped all these projects, meaningfully improving our overall setup. 👏 to the team!
Fast forward a few months, and we're discussing the biggest endpoint we can target next on the tech side. Again, the discussion twists towards the microservices architecture. Magically, we decided to migrate towards a more monolithic architecture (with some caveats) within a conversation that spanned less than twenty minutes. 🤯
For the past few months, we have been migrating to a modular monolith architecture, hoping it will make the overall backend setup more appropriately scaled to the size of our service and engineering organization. We're pretty pumped about it!
To me, this is a bitter-sweet pill as it became clear that if I were just a tad more annoying after joining Cozero, I would have likely managed to build a stronger coalition and push for an earlier migration successfully.
In practical terms, an earlier migration would help us save a lot of time, as doing it ahead of the Kubernetes → Lambda, New Relic, and secret management migrations would make them significantly more straightforward and less resource-intensive.
What's the lesson from all of this?
Next time I push for something, I need to clearly separate "concerns" from "disagreement." If no one disagrees, keep at it, even if it can feel uncomfortable.
Hopefully, this can be a good reminder that core values don't exist to gather dust in a Notion folder somewhere. They are something to pick up when making difficult trade-offs and use when you're unsure which path to take.
Jan K. - Tech Lead