If you can’t solve the problem, go for a walk!
When interviewing for the software engineer position at LiLz, Eric asked me the following question:
"With your background and experience, you could be getting a high paying cushy job at one of the tech giants, doing software architecture or some such high level thing. Why join a tiny startup and write low level product code?"
Why indeed.
Almost twenty years ago, I went through the rigors of getting a Bachelor of Mathematics with a Computer Science major at the University of Waterloo, graduating with distinction (though just barely). I spent the first seven years of my career working at a fintech startup in San Francisco (most of it remotely from Japan), part of the fairly impressive team of engineers who previously worked at Amazon, Google, Microsoft, along with some talented fresh grads some of whom would later found successful companies of their own (and failed companies, like your's truly). I worked across the stack, from building high performance services with in-process databases that server stock trading data, to complex portfolio visualizations and management UIs. I always had an interest in and critical eye for usability, so naturally ended up gravitating towards the frontend.
Eventually I left to start my own company, and lead tech and product as CTO, and so have experience with the very raw reality of trying to build something useful and commercially viable from scratch, while at the same time trying to maximize the productive output of a small engineering team, in a sustainable manner that doesn't sacrifice the longterm growth and well-being for short-term bursts of output. In the world where mass market consumer tech was increasingly causing addiction, anxiety, robbing people of their attention span and selling their eyeball-hours to the highest bidder, we wanted to flip the relationship between people and tech back to what we thought was normal: make tech a simple tool for people to improve their daily lives. For our startup specifically we focused on meal planning and chores. We did not reach profitability, but did survive for four years, which in startup land is a decent run.
I then joined another startup to use all my front-end-heavy software development experience to step a level above regular product work, and design and build the holy grail of frontend stacks. Most developers have a wish list for their stack. For frontend stacks, it typically looks like this:
I wish I could use the same language in the frontend and backend (F# in our case)
I wish we could use the same codebase for the web and mobile apps
I wish it was easy to do the right thing (e.g. any button that fires an async action by default comes with a spinner attached) and hard to do the wrong thing (e.g. give user no visual feedback that "something is happening")
I wish I could just simply subscribe on backend data and never have to do another raw API call
I wish I had powerful and expressive DSL for each subdomain of frontend development (styling, component tree structuring, etc)
and so on. We wanted it all, and we had a very ambitious CTO with a healthy disregard for the limitations of reality, and his direction was clear: "We're hiring you to build the holy grail of frontend stacks".
We thought it would take us a year, in reality it took about five, though a good portion of that time was spent building out actual apps that used the progressively improving versions of our holy grail stack. To say that the work was challenging would be quite the understatement. The more requirements you want to satisfy, the more the constraints associated with each requirement come into conflict with each other. Eventually the myriad of constraints is so restrictive that finding solutions becomes an exercise of slowly and persistently rolling a giant boulder up the mountain. But after all the struggles, we succeeded, and though pride isn't something I experience naturally, it's probably reasonable to say that I was proud of how close to the goal we managed to get.
Over the five years of building the holy grail of frontend stacks, two things became apparent to me.
First, spending each and every day on super challenging problems, finding narrow tunnels within the multi-dimensional spiderwebs of constraints, is just not sustainable for me. I find that at least half of the weekly workload needs to be of the "comfortably coding at a healthy pace" to sustain challenging problem solving for the rest of the week. Very-hard-problems-all-of-the-time is suitable for a cushy research job at a university, with little pressure to deliver on tight deadlines, but combined with a startup mentality, this mode of work becomes hugely taxing.
Second, I sorely missed product development. My motivation circuitry has always been based on delivering useful features to human users, usually by iteratively improving a product that I personally care about. And having just finished a marathon of language/framework/stack design and development, I felt like I was long overdue for some good old product building.
Finding the next challenge proved to be difficult. As you may be able to tell from the above, I grew progressively more opinionated about just about every aspect of my work. So any company that I'd join would have to satisfy some very stringent constraints.
A huge part of doing good work is saying "no" to things. I knew what kind of problems and products I didn't want to work on. I knew what technologies I didn't want to touch. I knew what sort of work environments didn't suit me. I didn't want "just a job", I wanted a job where I could feel meaning in what I did, honestly care about the product and the work every day, and be surrounded by people who are both competent workers but also good human beings with lives outside of work. I wanted to be held to a high standard, and be able to do the same to my colleagues. I didn't want bureaucracy. I didn't want overtime for the sake of signaling one's dedication to the company — I have long ago learned that doing great programming work for eight hours per day tires you out so much that any additional hours spent are useless (or your day has a lot of bureaucratic downtime, like meetings, which lets your brain rest).
Talk about a multi-dimensional web of constraints, eh? You can imagine that the number of choices that satisfied a reasonable subset of my constraints was quite limited.
I came across a posting for a software engineer job at LiLz on LinkedIn. In the country where most startups end up in Tokyo, seeing one defiantly headquartered in Okinawa put a huge smile on my face. Gutsy. I like that. They also seemed to take pride in the quality of their work, both the user facing product, and the code that powers it. It's surprising how rarely such a commitment is stated explicitly, even though every company out there has a generic "values" page on their website. There was something genuine about LiLz, and I ended up submitting an application.
After applying I looked into the company in greater detail, reading the website, news articles, the company blog. The more I read the more impressed I felt. A product that users seem to love? Check. A small team that punches far above their weight? Check. Humble, down to earth, doing great work with no glamorous but empty-sounding proclamations about changing the world? Check.
Based on the data I was gathering, the image of Onishi-san, the CEO, was particularly impressive and unexpected. His management style is "supporting my colleagues, empowering them to do their best work". In a world where there's plenty of managers who feel like their job is to boss their underlings around, this was a breath of fresh air. The man's the CEO of the company, yet his photo isn't plastered at the top, but is lost at the end of the second row of LiLz employee introduction slide. He focuses on solving real problems that real people have right now, not entertains some grand theoretical visions. He understands that saying "no, not now" is how you stay focused on the problem at hand and polish your product without spreading the team too thin. Even small, simple things, like his statement that going for a walk is a great way to get unstuck when solving problems, resonated deeply with me. This is the person who sets the company culture? Man, count me in!
The first interview I had was with Kuba, the CTO. Two hours went by quickly, and the discussion was engaging. I got to ask a vast number of questions, from the particulars of the software stack, to the philosophical approach to software development, to questions about the camera hardware, the current roadmap, the company's financial health. He responded to everything straightforwardly, with good humor and complete honesty.
In preparation for subsequent interviews, I read other team members' blog posts about how they joined LiLz. The posts were overflowing with humanity — everybody had their own style, their own background, their own way of telling their story. They talked about the work-life balance that working for LiLz afforded them. I strived for this when trying to build my own company — empowering people to do excellent work during regular business hours, and then go home on time and enjoy their private lives. And now here I was reading about a startup with a small team, having reached product-market fit, accomplishing just that! I felt a little jealous, but more importantly, I really wanted to be part of it!
Interviews rolled on. My friends were joking that by the time I get an offer, I would have met all the employees and all their extended families. But jokes aside, I really appreciated the amount of care they put into selecting candidates to join their team. I've been on the hiring side of the table many times before, and understand that the importance of finding the right people cannot be underestimated.
It's been almost a month since my first day. I'm happy to report that so far I have not discovered any broken promises or red flags. During my onboarding, I've spent a week full of random sporadic tech discussions with Kuba, and was reassured by how he manages to both have strong opinions and a flexibility to discuss and adjust them when necessary. Tech decisions at LiLz are aimed to address fundamental business needs in a healthy, straightforward manner, rather than to stroke one engineer's ego or personal preferences. Communication is clear, careful, and friendly. And for the first time in years, I'm once again doing product work, coding at a healthy pace, discussing how to move the product forward, how to deliver more value, having fun. It's still a little surreal that I somehow found a company that satisfied my copious constraints to this degree, but here I am, hopefully to do great work for years to come!