*This article is translated from a Japanese one written in June 2020.
These years have been very challenging for startups to adapt because of the pandemic.
Especially for Ubie, with the business domain in healthcare, it was a particularly turbulent few months, with an emergency launch of a service for consumers that had been in development before the company was founded and had a ¥2 billion fundraising in order to prevent the collapse of healthcare. As a company, we have achieved to enter the next phase of our growth, with more than 50 full-time employees.
All though we have only been on a short journey, I thought of taking this opportunity to look back on the process of development in the organization and write about the insights we have gained over the past three years.
About Ubie’s engineering team
I would like to start off by quickly introducing Ubie’s business and the engineering team. Our mission is “To develop a healthcare guide for everyone” and we provide value to medical institutions and consumers. As the word “technology” is in the mission, we believe that we are both a medical and tech company, which is the key feature of our organization. As a software engineer myself, I have been focused on technology since the company’s founding. Our development organizational structure consists of several scrum teams, including LeSS. The following is our development team structure.
Number of engineers, as of May 2020
・Software Engineer (Web App): 9
・Software Engineer (SRE): 2
・QA Engineer: 1
・Data Engineer: 2
・Machine Learning Engineer : 3
It is said that hiring engineers are very difficult, especially for early-stage startups. Without exception, Ubie had and having difficulty in hiring engineers since day one. In the first year or so after the company had started, when the biggest priority was to Product-Market Fit (PMF) service, there were days when we only had 2 or 3 engineers, including myself. We were developing the product with a small number of engineers, and at the same time, we were conducting many interviews, and sending a bunch of messages through Wantedly, Twitter, and other media, even on weekends. But we were not able to hire anyone.
However, we had always kept going and continued to implement various measures and actions from time to time, such as creating a system for referrals and optimizing the hiring flow, using a PDCA approach. As a result, we expanded to our current number of 19 (including new coming employees). I could guess many startups are facing similar problems too.
Number of engineers since the establishment
The role of a developer in Startup
The value of startups lies in the ability to disrupt existing industries and take risks to create innovative business models that have never been seen before. For large companies, this is very difficult, because of the need for business probability to implement new business models. In other words, for a startup, verification that has yet to be demonstrated is an essential process for business activities, and the difference between success and failure will depend on the sense and speed of measures taken.
In this context, the value of an engineer is to demonstrate the probability of the product/business through repeated verifications at high speed. Also, they must make the product actually usable by customers and users, and reflect the learnings in the product. The reason why many books and methods on product development methodology suggest that product development should be completed in-house, rather than outsourcing, is because the team can reflect on what they learn inside the company for further improvement. Creating backlog items and visiting medical facilities are always encouraged in Ubie.
Hiring engineers in a startup
I heard a phrase some time ago, “A-class talents will invite A-class talents, but B talents invite C-class talents.” Especially, the more talented engineers are, they are more inclined to work with the best. Of course, there might be a purely intellectual curiosity as a single engineer, but there is more to it than that. Engineers are more influenced by the architecture and technology stack of the current system when compared to the business side. Even if a newly joined member has a lot of discretion, it is difficult to completely change the underlying data structure and system architecture if the business is already somewhat advanced. Startups will need to focus on business growth and cannot afford that cost.
Never compromise on hiring initial members
For the above reasons, we recommend startups never compromise on hiring initial members, especially engineers. If you make a compromise, the core team will not scale, and by the time you start thinking that engineering is important for business growth, you will have a huge liability in your business. In that situation, probably the best engineers won’t want to come, and you may end up with an accumulation of debt, not only in your systems but in your organization as well.
Engineers who fit in startups
With these backgrounds in mind, the following three factors are important in determining what kind of engineer is best suited for a startup.
- Skilled at verification and able to make disposable applications to test
Pivoting is the norm in startups, and many things are not a given. Among them, applications are very changeable and fluid. Contrary to what I mentioned about clean design, it is important for members to be able to discard the application if needed. Of course, no one wants to create something that will be thrown away. However, for startups and agile development organizations, the value of learning from validation is sometimes greater than the product itself, and being accustomed to throwing things away is very important to accelerate the speed of business growth. Also, even if you have an idea but you do not verify and don’t have the output by the end of the day, it will be difficult to keep up with the speed of the startups.
2. Commit to the growth of the product, not the process of making the product
Good engineers and designers tend to be so absorbed and focused on making that they forget about the product’s growth. However, it is extremely important to be an engineer who can think whether what you are trying to create will truly solve users’ problems and even decide to not develop it from the result of verification. A product that no one will use, is a waste of a very important resource in the development team.
3. Be able to design a system that does not create data debt
Ubie is doing the data-driven business to predict the potential disease. Even if the application can be discarded and replaced, the data entered by users in the past cannot be discarded. For a company like Ubie, which provides AI products, the data itself is the core of the product. If the data scheme is designed in the wrong way, it won’t contribute to business growth even if the data is accumulated.
Challenges Ubie faces in the 1→100 phase
As you have read so far, I’ve written about what kind of engineers fits and plays an active role in the 0 to 1 phase and in the pursuit of PMF. For Ubie, we must further scale up for business growth while maintaining the value of the disease prediction engine as a core value.
Building a network effect
Until now, Ubie has grown based on its core competence of accuracy in disease prediction. However, from now on, the major challenge is to build and structure an external network. The model is to further increase the number of medical institution users through a newly released service for consumers (general patients). And “AI Symptom Checker Ubie” will provide direct access to medical interviews to medical institutions, enabling doctors to accurately understand patients’ past illnesses and symptoms. Further on, we hope to create a better medical experience for patients.
Appropriately split the domain for organizational growth
In the current phase of the user base beginning to expand, services are required to have the domains to be appropriately divided and designed to provide user value at high speed, contributing to business growth, while at the same time obtaining data in a reusable form. And as the number of services and types of value offered increases, it is important to note that the number of communication paths will increase and the speed of communication could slow down. Of course, there is no single solution for the architecture of the system, and it will be influenced by the organization, team structure, and technology stack at the time. Even in Ubie, engineers are engaged in heated, controversial discussions with each other on a daily basis to make the best decisions. These cross-team discussions about the organizational and team structure are what I believe one of the appealing aspects of working at Ubie.
Conclusion
Thank you for taking the time to read this long article, and as I mentioned above, Ubie is rapidly expanding the business and organization. When I was writing this article, I had some flashbacks to the past memories, including some difficult ones. Even so, my startup life has been so intense that I feel the years I spent were much shorter. From now, we will be working with the consumers and challenging many projects in the future. If anyone is interested in Ubie’s business or development, please feel free to message me on Twitter!
Technology is the key to the future of medicine. We need your help to create the future of medical care.
