A little context
About
TLDR
Software engineer building scalable backend and data systems, with product intuition and customer focus. Wearing many hats and doing whatever needs to be done.
Professional
I'm currently a founding engineer at Terminal, building data infrastructure for high-scale ingestion from fragmented third-party APIs. I've also led projects including managed data replication, distributed data deletion, and automatic data reconciliation.
I've previously been an early engineer at Cohere, helping bring LLMs to production workloads. My primary focus was building and scaling our finetuning platform.
Personal
My full name is pronounced key-yawn mayr. My first name is Arabic and means "being" or "existence". I'm of Black Jamaican and Gujarati Indian descent, so naturally, I love spicy food.
I am gender non-conforming and use singular they pronouns. I also accept masculine (he) pronouns. I prefer not to make a big deal out of it.
When I'm not working, I'm usually:
- Reading technical content
- Exploring Wikipedia rabbit holes
- Attending tech talks and meetups
- Pretending I'm a professional chef
- Over-engineering side projects
- Running on mountains, pavement, or skis
Values
My values directly influence how I operate. They are not aspirational ideals, but patterns I have noticed in my own behaviour. I am happiest in company cultures that reflect these values.
Own the outcome
Finished work is not the same as valuable work. I care less about whether something shipped than whether it moved the needle. I stay accountable for the result, even when the work crosses roles or boundaries. I am willing to ruffle feathers when needed, though I aim to do so with empathy. I do not believe in "not my problem".
Lead with curiosity
Curiosity starts with refusing easy assumptions. I seek to understand customers, coworkers, problems, and people before deciding what is true. That means asking deeper questions, getting closer to others' perspectives, and not mistaking my first interpretation for reality. Instead of declaring that something is impossible, I try to understand the conditions that would make it possible.
Automate the pain
Pain is a signal for leverage. When a process is slow, fragile, repetitive, or difficult, I want to understand it deeply enough to make the next version easier. I look for step-change improvements that compound over time. To avoid the trap of over-optimising, I first ask whether the pain is real enough to justify changing the system.
Go the distance
Small improvements compound. I push slightly beyond what feels natural, one step after the other. Progress does not always require a dramatic leap. Repeated often enough, tiny stretches become meaningful advantages. I believe in holding a long-term point of view, while adapting to short-term obstacles.
Set the menu
Customers provide direction, not specification. Great work requires understanding customers deeply enough to ask the question behind the question and solve the problem behind the problem. Then I can shape the solution around what creates the most value, not what was explicitly requested. My goal is to strengthen the core product for each customer, not contort it around any single one.
Live to work
I have come to accept that I cannot separate my work from my life, so I choose work worth living for. My work needs to be deep enough to deserve my energy and healthy enough to sustain it. I need work where intensity turns into impact, with problems worth obsessing over. I play to win, and that includes living well enough to do my best work.