Becoming a CTO and building an engineering culture (Japanese)

Biography

After graduating from the University of Tokyo's Graduate School of Information Science and Technology with a Master's degree in 2017, he worked for a major telecommunications company developing numerous systems, including an online store. While studying methodologies such as Scrum and LeanXP and practicing team building and scratch development from scratch, he is also involved in cloud technology selection and agile development promotion and training for internal use.

Links

• amptalk profile on Eight Values

Transcript

Ryohei Watanabe: Hello, welcome to Eight Values, today I will be talking with the CTO of amptalk, his name is Suzuki Keita. Mr. Keita, thank you for coming on。

Keita Suzuki: Thank you for having me.

Ryohei Watanabe: For those who are not familiar with the company amptalk, how would you describe the business and the product you make in 30 seconds?

Keita Suzuki: amptalk offers a SaaS service for transcribing and analyzing business negotiations. We automatically retrieve and transcribe recordings of business negotiations conducted through online meeting tools like Zoom, Google Meet, Teams, and analyze when and what each person spoke. We provide a service that even leaves meeting minutes automatically, aiming to reduce labor hours and strengthen sales organizations.

Ryohei Watanabe: What kind of job did you want to do before amptalk, Keita-san?

Keita Suzuki: I was at a place called SoftBank, and I was mainly in charge of system development for online shopping services.

Ryohei Watanabe: At that time, why did you decide to become a co-founder of amptalk?

Keita Suzuki: As I mentioned earlier, when I wanted to create a product on my own, I met Representative Inose through a friend of a friend of a friend. At first, I didn't really have the intention of starting a company, but as the two of us continued to develop the product for a while, I felt that it matched what I wanted to do, so I've become a collaborator in this form.

Ryohei Watanabe: Initially, there was no expectation or feeling that this would turn into a business. How did it feel back then? What was the environment like when you were developing?

Keita Suzuki: It really felt like we were using our weekends. At the time, there were only two of us, Inose and me, so we were just constantly repeating the process of discussing how to create a prototype of the product, creating it, showing it, and creating it again.

Ryohei Watanabe: Sounds really fun.

Keita Suzuki: It was quite fun.

Ryohei Watanabe: I think there was a phase where you were doing it as a side project. When did you decide to quit SoftBank and commit 100% of your time to this?

Keita Suzuki: It's when we were confident that this product would sell and that it has value for the users.

Ryohei Watanabe: Do you remember? Do you have any experiences or memories? Any episodes where users were happy, or memories from that time?

Keita Suzuki: In that sense, I don't know if it has already been mentioned, but we once pivoted the product, or rather, we changed its direction. Initially, we were creating a product to support sales role-playing, and while we thought it would certainly be effective, for the salespeople who were actually using our service, introducing our service meant increasing costs, or being made to role-play. Things they didn't want to do. Of course, I think it has a certain effect, but for those who actually use it, when the idea of recording and analyzing actual sales talks was born and we started prototyping, we felt that this is something that everyone would be happy to use. We also received such feedback from users, so our impression of our product changed a lot at that point.

Ryohei Watanabe: In the early days, there might have been tough feedback, and I think some customers didn't want to role-play. What motivated you to continue at that time? Initially, customers didn't really want to role-play. Why did you want to continue amptalk even after receiving such feedback?

Keita Suzuki: If I were to talk about myself, rather than wanting to create something specific, I always had a desire to create something that users would be happy with. This is at the heart of my engineering career. I have a desire to create something valuable for users. Therefore, after the pivot, I started to feel that a product that users would be happy with was gradually being created. That was my motivation to continue.

Ryohei Watanabe: From then until now, the team has grown, the product has achieved product-market fit. When you consider your experiences up to now, what do you think are the reasons or causes of your success?

Keita Suzuki: One reason is that we value user feedback and always start testing our assumptions as quickly as possible. We release frequently, gather user feedback, make improvements, and repeat this process in a very rapid cycle. Even when we first started offering the role-play product, we made a product that could simply record and evaluate without even making a login function at first. We let users see it first and only when needed, we added a login function. Instead of creating one large product, we improved the product while repeatedly testing hypotheses, and we were able to incorporate user requests more and more. I think that's a big reason.

Ryohei Watanabe: Now, Hirata-san is the CTO of amptalk and I think he's rapidly expanding the engineering team. What kind of team are you aiming to build? What kind of engineering team do you want to create?

Keita Suzuki: As for me, I am aiming for a team where the engineers have confidence, pride, and responsibility in our product, and can work autonomously.

Ryohei Watanabe: What do amptalk and you, Hirata-san, do to create such a team? What has been the most effective main thing you've done to create this culture and this team?

Keita Suzuki: Well, first of all, in order for them to have confidence and pride in our product, it's easy for management to just tell them to create something. However, if they just create it, it's not interesting as an engineer, and it's hard to feel like they're contributing to the business. I think it's important to have a conversation with the engineers from the stage of deciding on the use of the product. Quite often, engineers will give feedback like, "Isn't it easier to do it this way?" or "Wouldn't it be more user-friendly to do it this way?" In such exchanges, engineers' understanding of the business also comes out. Then, I think it's important to have a real feeling of why the functions they are creating exist and who they are for. That's the value aspect of the business side of the product, and also the technical aspect, such as the quality of our product and the maintainability of development. I think it's necessary to have confidence in these areas. In that regard, I think it was significant that we established a solid automated testing system in the CICD pipeline from the start, and we worked on creating a system where we can confidently improve our product.

Keita Suzuki: Yes, basically, if there are requests from customers or if there are suggestions within the team that we need this function, basically, anyone can throw that into Slack. Myself and the representative mainly consider the business impact of this feature, and decide on the priority. When we decide to implement this feature, we decide on the detailed internal specifications, and if it's simple, we might decide it at the top level, but if we think it would be better to consult with engineers or designers, we open up the discussion to them and decide on the details through discussion. We describe in detail why this feature is needed, who wants it, what the issues are, and why we need this feature to solve them, and then we assign the implementation of one feature to the engineers one by one. That's the flow of our development.

Ryohei Watanabe: So, once an engineer takes charge, what kind of support or management do you, Keita-san, provide?

Keita Suzuki: I try not to manage too much, but for example, if there's a junior level engineer who's not sure what to start with, or if they're stuck, I'll work with them to break down the tasks. First, we need this kind of screen. Then we need to prepare this API. We need to implement this in the backend. We break down the tasks in detail like that. On the other hand, for members who can move autonomously to a certain extent, I let them handle task decomposition by themselves. I do code reviews, but I try not to micromanage too much.

Ryohei Watanabe: What do you look for in a code review, Keita-san?

Keita Suzuki: Indeed, I believe it's crucial for any future development members, or even new people who come in, to clearly understand what a code is intending to do, and what it aims to achieve, just by looking at it. The naming conventions of the code, the way classes are divided, and such areas where the intention is clear just by reading the code, are what I place a lot of importance on.

Ryohei Watanabe: There was talk about scoping within the team, for example, if such a problem seems likely to occur, how do you give feedback? How do you give feedback to the software engineer?

Keita Suzuki: Feedback from each engineer?

Ryohei Watanabe: Yes, I think there are opportunities to give feedback on various things. When you always give feedback, what do you care about? What primarily becomes the reason for giving feedback?

Keita Suzuki: When I give feedback, rather than saying specifically what you should do, I'm mindful to say things like, if you do this, it could cause problems for someone in the future or future issues might arise. What do you think about trying this instead? That's the kind of feedback I aim to give. Is that a good answer?

Ryohei Watanabe: No, it's an extremely kind feedback. If I were software engineer, I'd be happy. It's an opportunity to learn something new and it gives the impression of a consultation. Keita, now I want to talk about your role as a CTO, what responsibilities does a CTO have at Amplitude? What is the role defined as?

Keita Suzuki: Well, I believe the most important role is to serve as a bridge between management and technology. So, when there's a business challenge, I think the most significant role is to indicate the shortest route to solving it with technology.

Ryohei Watanabe: What kind of CTO do you want to become, Keita? What's an ideal CTO in your opinion?

Keita Suzuki: Well, there's no definitive answer. When I think about what an ideal CTO should be, I believe the most important thing is a sense of balance. I think it's crucial to have a balance between business and technology. If we lean too much towards technology, as an engineer myself, I have a strong desire to create clean code. But if we lean too far that way, we might work on things that seemingly don't produce any business value, which we need to avoid. Conversely, if we keep accumulating technical debt, over a long-term span, it would gradually decrease development efficiency, eventually becoming a minus. But from a short-term perspective, refactoring and resolving technical debt doesn't seem to generate immediate value. So it's about making decisions to work on this now because it will affect our future, and having management understand that. I think the CTO should propose and promote this perspective from both the technology and business standpoint.

Ryohei Watanabe: Keita, you've been serving in the role of CTO for about two or three years now, I think. Have your management style and methods of fulfilling the role of CTO changed over these two or three years, from the first year until now?

Keita Suzuki: The work I'm doing has changed significantly. I originally liked the process of how to continuously improve a product while maintaining long-term development speed without accumulating technical debt. I was heavily focused on technology, like the introduction of automated tests, CI/CD without human intervention, and how to run development more efficiently. There's also design talk, like test-driven development, clean architecture, domain-driven design methodology, and more. So, I was heavily focused on how to continue development without reducing product productivity. But recently, I've been focusing more on incorporating user requests without any leaks, sucking them up without missing anything, and deciding whether or not to proceed through a certain decision-making process. I think my role has shifted towards viewing the entire flow, from user feedback to product development, rather than just focusing on technology.

Ryohei Watanabe: I'd like to dig a little deeper into this decision-making and whether or not to proceed process. How do you decide? For example, when you have two features and you're making the decision of whether to proceed or not, what do you consider?

Keita Suzuki: The most important thing is the business impact. I think that's the bottom line.

Ryohei Watanabe: Business impact.

Keita Suzuki: However, for example, there might be a very heavy function with a lot of business value, and another one that isn't as valuable but can be done quickly and therefore has an immediate impact. So, I often consider the current situation and decide which one should be done first. It's not uncommon.

Ryohei Watanabe: I think there are various customers using amptalk's products, do their needs vary from company to company? Not all of them have the same needs, for example, one company wants this feature, another wants that feature. Do you see that kind of diversity in needs?

Keita Suzuki: Of course, yes. There's a lot of diversity.

Ryohei Watanabe: How do you decide on that? Are there cases where you decide to develop this feature, or that this feature seems to be mainly used by this one company?

Keita Suzuki: As a basic principle, we've decided not to provide individualized solutions. Of course, we take requests from each company and incorporate them into our features, but when we do, we always consider how we can generalize or universalize them. For example, a user might tell us they want to do something. In that case, we always keep the perspective of "if we use this feature, we can solve that problem, and we can generalize it like this."

Ryohei Watanabe: Thank you. Now I'd like to talk a little bit about interviews and software engineer candidates. I assume you interview software engineer candidates, what do you look for and how do you evaluate them?

Keita Suzuki: There are various perspectives, but what I try to keep in mind is not so much the skill set that the person has at the time, which is important, but more importantly, their mindset and culture fit. Of course, technology is at the core of the company's value and is important, but I think it's crucial that the person is interested in our product itself, and in solving business challenges. It's not that someone who knows technology is bad, but rather, we prioritize whether the person's ideology matches what we are doing.

Ryohei Watanabe: Do you have any advice for successfully passing the culture fit process at amptalk?

Keita Suzuki: Advice? There's no surefire way to pass, but we do value how much interest one can take in our product. So it's not about pretending to be interested in the product, but rather, really thinking about whether you can take interest in it yourself. If you're going to take an interview, I would like you to think about whether the product and the company's culture match your own.

Ryohei Watanabe: When you talk to software developers, other than salary, what do you emphasize when you talk about the appeal of working at amptalk?

Keita Suzuki: Well, one thing is that we really value how to maintain the quality of the product without compromising development efficiency. This is reflected in various practices, for example, we have made test-driven development a standard in our development process, and we are quite thorough in doing automated tests. When I talk to other startups at the same pace, they are surprised, but now we have thousands of automated tests. But I think that's a great asset for engineers. When you join a new company and add feature development, you're always worried about whether you've broken your own features. When that happens, it's important to be able to detect degradations in the form of automated tests. Of course, testing is for the sake of customers and for explaining the business side, but what's most important is whether development can be done in a state where psychological safety is guaranteed for engineers. Therefore, I think that the developer experience is something we can be proud of compared to other companies.

Ryohei Watanabe: I suppose amptalk doesn't have an on-call system with those tests. Like, if the system breaks in the middle of Monday night, there's no system to contact this person.

Keita Suzuki: Well, not that we don't have one, but... basically, if an alert is triggered or a problem occurs, everything is automated and notifications go to Slack, so whoever notices it will respond. At that time, I will be on standby, but we value the concept of blamelessness. When a problem occurs, it's not the fault of a person, but the system. Conversely, when a problem occurs, instead of reflecting or working hard to improve, we value solving it with a system. So when an alert is triggered, of course, we need to respond immediately, but afterwards, we need to think about what system we need to prevent this alert in the future, or to create a system that can automatically recover. We allocate quite a bit of time to make sure that even alert responses can be automated as much as possible. Thanks to this, we're able to move more towards solving problems with systems rather than relying on human effort.

Ryohei Watanabe: Do you have any advice for someone who has just become a CTO for the first time? From your own experience, what have you learned so far?

Keita Suzuki: Indeed, when you reach this position, there are few people within the company you can consult. However, many CTOs from various companies are struggling with the same issues. Therefore, I think it would be beneficial to participate in communities of CTOs and discuss your concerns. Even if it doesn't lead to a solution, sharing your concerns can be helpful. As you reach this level, there are many things that you can't learn from books, so it would be beneficial to increase your connections with senior CTOs and peers who you can consult. This is based on my own experience.

Ryohei Watanabe: What kind of discussions take place among CTOs?

Keita Suzuki: We often discuss real, on-the-ground issues. For example, we might discuss how we are recruiting, or specific technical challenges we're facing and how to resolve them.

Ryohei Watanabe: Excuse me, can I ask another question? Could you tell me about amptalk's tech stack and why you chose it? Could you explain what tech stack you use when you work with amptalk at software engineer?

Keita Suzuki: In terms of our tech stack, on the front end, we use Nuxt.js and Vue.js for single page application structure. Our backend is running on Node.js, and both are based on TypeScript. As for analysis, because our product also performs topic analysis and such, we use Python running in Docker containers for this part. All our applications run on AWS. In terms of decision-making, although there's a range of opinions, we try to align the skills for the frontend and backend as much as possible. We do this in terms of our size and also when assigning tasks to engineers. We do not assign tasks as frontend or backend tasks, but assign tasks by feature so that users can perform certain actions. We aim to be a feature team, and in doing so, the technology from the frontend to the backend would be handled by the same team, so we decided to align the language as much as possible to allow seamless development.

Ryohei Watanabe: Thank you, Mr. Keita. Thank you for today. This was Keita Suzuki, the CTO of amptalk. Thank you.