Working in a dentist office with a mission to simplify fieldwork maintenance
My name is Kuba, and I’m the Chief Technical Officer (CTO) at LiLz. In this article I’ll share a little bit about myself, how did I come to be part of the founding team at LiLz, and how my tasks here fit into the mission of making lives of technicians around the world easier. And why all that technical innovation is happening out of an unwanted dentist office.
So who am I to be claiming I can head technology here anyway?
Fast forward towards end of high school, and my stack of programming books had a lot more depth to it than introductory HTML courses. But when it came to choosing my university major, I decided to study mechanical engineering instead of computer science. At the time I felt that would like to work on robotics in the future, a field that, in my mind, required both disciplines. I reasoned that since I already had some knowledge of computer science but knew nothing about mechanical engineering, l would benefit more from studying the latter at university. Despite this decision, during my time at university, I found myself gravitating more towards software engineering projects. It turned out I had more fun working on code than dealing with tasks like calculating the stress of a cantilever beam.
And as I drew closer to graduation, it was more and more clear to me that I enjoyed the software side more than pure mechanical engineering aspects, and I ultimately decided to pursue a career in software development. At the time I didn’t come across any robotics-related positions that appealed to me, so I started looking for positions related to high performance computing, another area that excited me. As as result, I joined research labs, first at Nanyang Technological University in Singapore, and later at Okinawa Institute of Science and Technology in Japan. While there I was helping researchers in logistics and molecular biology domains to process and analyze experimental data.
At this point, a keen reader might point out that being excited about high performance computing is great, but mechanical engineering degree probably didn’t prepare me for building good solutions for problems in that space - and they would be correct. It was at that time that I decided that to become a professional in the field of software development I need to fill in the gaps my in computer science knowledge, and got serious about studying from relevant textbooks. And I started to keep a log of textbooks I read - you can view it here if interested.
After spending a few years in academia, I felt it was time to transition to the industry. While I learned a lot working on high performance computing software, there were numerous aspects of software development I wouldn’t have a chance to engage with at my research lab. Technologies like databases, web servers, mobile development, and cloud computing rarely came into play when writing data analytics code for a small research team. And I also felt that would like to be involved in developing software that is being used by more than only a few internal users. This desire led me to join Lexues, a software consulting business from Okinawa with ambitions to build its own services. I joined as the first engineer for the newly formed R&D group. My goal at Lexues was to explore new technologies and share my learnings with the business side, with the hope that the learnings will help identify promising business problems that can be solved with new technology more effectively than with existing alternatives, ultimately leading to new services.
During this time, around 2015, I delved deeply into the world of deep learning. I already had a decent amount of experience in computer vision and simpler machine learning algorithms, and deep learning appealed to me a lot because it promised to be the right tool to solve some computer vision tasks I wanted to tackle in the past that previous approaches couldn’t handle reliably. The next two years I spent reading seminal papers and books in the field, building my own deep learning libraries, reproducing state of the art models, and helping others understand the subject.
In summer of 2017, with the blessings of Lexues, which was trying to restructure itself, our R&D group, led by Onishi-san, who was its manager, established a new company - LiLz. The same team, but the goal was slightly different now - instead of exploring new technologies and feeding ideas to business side to decide which ones to act on, we would choose ourselves which problems we believed were worth solving. We didn’t have the problem defined at the onset, but we knew we wanted to build our own products and services. And we knew we had a strong team with a set of skills in Artificial Intelligence and Internet of Things that can solve problems that couldn’t be addressed by older technologies.
So we moved into our first office - a very cheap, but also damp and murky former classroom in a forgotten building of a local university. When we first entered the room, surprised spiders turned around to look at us and asked “You boys lost?”. We respectfully brushed them aside, placed in the room a few simple tables in the room, and set about looking for the right problem to solve! As the most experienced engineer on the team I was named its lead, which is the role I held at Lexues too, and shorty afterwards promoted to CTO position.
It took us better part of a year to find the right solution, and it wasn’t a unanimous decision right away, but eventually we settled on solving the pain of maintenance inspections, and named our budding solution LiLz Gauge. When we made the decision to build LiLz Gauge, gears shifted very quickly for the engineers at LiLz, including yours truly. Almost overnight, we had to move from machine engineer roles to full stack engineers who could not only build AI models but also a web service around them, deploy it, manage it, and make sure its UX is easy and compelling for fieldwork technicians.
So how did I go about suddenly becoming an expert on all that? The magic sauce was:
I didn’t - few aspects, especially frontend technologies, took time to get strong in. The very first version of our UI was about as sexy as Windows 3.11. Shortly after that we had a group of experienced frontend consultants join us, and we learned a lot on the subject working with them
A lot of textbook - on technologies and best practices in all the fields I wasn’t well-versed in yet. I’ll refer you to my list again
Careful design, being methodical and thinking ahead - not just if initial solution solves the problem at hand, but also how it might respond to new requirements over time
I won’t be claiming left and right that every architectural decision we made in the process of building LiLz Gauge played out perfectly in the long run. Stell, since we began tracking these metrics in 2019, we’ve been averaging 2.5 releases per week and annual service uptimes above 99.98% (equivalent to less than two hours of downtime per year), so I believe we got a lot of things right.
Why is LiLz the adventure to have?
Through sheer luck of discovering I like coding so much I decided to do it for a living, and zero conscious career planning on my side, I found myself to be a part of an industry in which human talent sees huge demand. Software engineers can choose from a wide variety of problems they would like to work on, and businesses they would like to work with. With so many adventures available to software engineers out there, why do I believe LiLz is the one to embark on?
The biggest reason is that we genuinely make a measurable difference in the world. Our remote monitoring service has enabled clients to save hundreds of kilometers driven every month. We make it possible for maintenance staff to finally work to a predictable schedule, not worrying about receiving emergency calls or performing inspections in the middle of the night or family events. And we help businesses like energy and health care providers to avoid unplanned downtimes, making sure they can continue to provide essential services that our society relies on.
And while right now we are making fieldwork operations easier across hundreds of facilities in Japan, problems we’re solving exist in economies around the world. We’ve been hard at work getting ready to be able to deliver LiLz Gauge to facilities across the globe, and I'm very excited to see where we will be able to bring positive impact over the next few years.
We have a great team of highly motivated professionals that want to work together to build a service that brings a measurable benefit to the society. And I don’t think we were simply lucky to find the right people. Our CEO deserves the credit for building a company culture that allows people to feel ownership and encourages them to try new ideas, and our core values are defined to help us attract people who aspire to similar ideals as we do.
Even putting aside the grand goals, and zooming in on day to day tasks, working at LiLz is fun. As an engineer, I couldn’t ask for much more - a clear problem to solve, business side that has good understanding of engineering (both our CEO and head of Customer Success have a background in software engineering!), a company culture that treats mistakes as opportunities for learning rather than failures, and software development process that allows fast flow from ideas to delivery.
Our first office was a murky classroom tucked away in a forgotten corner of a local university. That’s where LiLz Gauge was born. Our second quarter is a former dentist office. The entrance looks nondescript at best. The whole building probably saw its best days more than two decades ago. Power sockets spaced out throughout surprising locations, often at eye level, give away that this place wasn’t designed to be an office. But this is where we grew from a minimum viable product with first early client to a business that’s gearing up to enable unconstrained and easy remote monitoring at facilities around the world.
And what am I doing here anyway?
In the early years of LiLz Gauge, I held responsibility for all architectural design, large portions of cloud infrastructure, the deployment process, and numerous implementation aspects.
Now that the development team grew larger, and I’m not the only senior engineer on the team, I can partially step back from LiLz Gauge’s development and focus on the broader IT needs of the company. Within LiLz Gauge I still spend significant amount of time reviewing architecture design and code, helping younger engineers when initial solutions could be improved, and directing tasks that we work on. But I’m less involved in designing architecture myself. Instead I work on IT aspects outside of LiLz Gauge a bit more. Some of areas I am currently involved with are:
Ensuring different departments within the company leverage available software tools to drive efficiency in their operations.
Addressing the necessary security training for our staff and collaborators
Identifying potential improvements in our group's operations
Improvements in our cloud infrastructure automation
Keeping an eye o which emerging technologies we should be investigating
Somewhat aside from my engineering role, I’m also often involved in business conversations with foreign clients and distributors. I find it a lot of fun to be able to participate in this part of our operations, and witness how LiLz Gauge is being used by businesses abroad. Again - bringing LiLz Gauge outside of Japan is an exciting mission I want to be a part of.
And if all of that wasn't keeping me busy enough, business development is already hinting at plans for a new service that would aid in easing fieldwork operations in areas other than gauge inspection. ^^