KOMOJU’s Customer Engineering Team seeks business-minded, flexible devs who can use both Japanese and English
Head of Customer Engineering Makoto Mizukami describes the unconventional candidates his unique team is looking for.
KOMOJU is hiring for its Customer Engineering team, and is on the hunt for candidates with specific skillsets and, perhaps, unconventional backgrounds.
But first, what is Customer Engineering?
“I prefer to call our team kind of ‘experimental,’” said Makoto Mizukami, Head of Customer Engineering. “The Customer Engineering team is very unique. There are only a few companies that have a team like us.”
It’s a common problem that product development teams are quite busy, so that they don’t have sufficient capacity to promptly respond to customers. And I believe the Customer Engineering team or similar team solves that problem properly.
Instead of escalating customer requests to other development teams, the Customer Engineering team creates the solutions themselves. “ I’d say I’m using at least 50 percent of my time for coding,” Makoto told us, “and then using the [remaining] 50 percent for other stuff, mainly for communicating with other teams or customers.”
Makoto gave an example of how that works in practice. “This is something I was working on in July, the third month after I joined Degica. . . . We provide a plugin for users of WooCommerce that will let them integrate their own EC site powered by WooCommerce and KOMOJU. Then there was a bug . . . that blocked certain merchants from integrating their EC website and KOMOJU correctly.”
So if I were an ordinary support engineer, what I would do would be to report that there wasn’t a great customer experience to a real owner. But what I actually did was directly work on the plugin itself and develop a balance fix for that specific issue, and then just ask the code owner to review my pull request and have it merged.
Originally, KOMOJU sought standard technical support engineers to handle these types of issues. But when Makoto joined the company, COO Kazunori Kajihiro decided to set up a new division. Previously, Makoto had worked as a DevOps Customer Engineer for CircleCI. “He might have thought,” Makoto said, “that someone like me with experience in support engineering, but not really an ordinary support engineer, would do something that can differentiate [KOMOJU] from our competitors.”
KOMOJU’s ideal candidates
As of now, the Customer Engineering team has two members, Makoto and Aaron Clark. Makoto’s looking forward to hiring more members, and he has a good sense of what sort of developers can succeed in this role.
He emphasized that customer engineers only spend about half of their time coding, so it’s important to find candidates who can enjoy the other aspects of the job. “ I just want to underline,” he said, “that the [coding time] percentage would be lower than for ordinary development-type roles. Our focus is always on listening to customers and responding to customer needs.”
Makoto went on to suggest that the best applicants may be interested either in consulting, or in one day running companies of their own: “ I say our company would be a good step for them, because that would give them a lot of chances to know more about business.”
Definitely our [team members] will be exposed to customer communication. That will let them have more exposure to customer businesses. And also, some customer inquiries require a very wide range of interdepartmental collaborations, so that will also expose those people to internal business affairs.
Since Makoto is looking for a specific type of developer, he’s quite open to those with nontraditional backgrounds. “There was one candidate . . . who was a kind of business consultant,” Makoto said. “And then, that person did a quick boot camp, and applied to us. That person went to the final stage because we acknowledged that they had a very strong motivation to grow more and test their skills in a real business set-up. We are definitely opening up for such people.”
Of course, coding ability remains important. Team members often have the opportunity to contribute to open source, Makoto told us. In addition, candidates should also be willing—or, ideally, strongly interested in—using a variety of languages.
In the case of the WooCommerce plugin bug, for example, Makoto needed to dive back into PHP. “For me, that was the first time, after ten years, even to touch on anything that has to do with PHP. . . . I definitely needed to take some time to recall [it], but I was able to do that, and I was excited to recall how PHP behaves, how I should write it.”
Language needs
Both Japanese and English are required for the position, but Makoto stressed that willingness to make an effort in those languages matters more than full fluency. Aaron, for example, is not a native Japanese speaker, but handles the majority of customer communications.
“Aaron is very good at Japanese,” Makoto told us. “He’s kind of humble, so he never admits that he’s really good at Japanese. But I judge that he’s very good, so that’s not a problem for us.” However, “if Aaron is really struggling to think about how he should explain things, then I can still help him.” That would hold true for future team members as well.
[If] engineers with English-leaning communication skills want to enhance their Japanese-style communication, then I am really happy to help them.
More problematic, according to Makoto, would be hiring a fluent Japanese speaker who is reluctant to use English. While he and Aaron often speak in Japanese, “I would like my [team members] to communicate more with our engineering teams, where 90 percent of people are mainly using the English language.”
But again, full fluency is less important than the motivation to try. “Even if they would see difficulties in that type of communication,” Makoto said, “then definitely I can help them. As long as such candidates have the motivation to enhance their skills. . . . Even if they just open up about their ideas in Japanese, then I can help translate into English, for example.”
In Makoto’s experience, perfect language skills aren’t necessary to make customers happy: “It’s more important that we explain everything clearly, rather than the language being really [elevated]. Actually, the opposite can happen quite often. If a native Japanese speaker coming from [our] team is failing to explain some technical concepts, then that can make merchants or customers quite upset, because for them, what we said is quite nonsense. But if Aaron is explaining something . . . [the explanation] can be a little bit unnatural, but if it is clear enough and makes sense, then they never get upset.”
The work environment
Despite the pressure of interacting with customers, the work environment Makoto describes is low-pressure and supportive. He’s created a specific protocol for the Customer Engineering team’s interactions with merchants, in order to maintain a good relationship without subjecting the team to undue pressure.
I would say I’ve never been at the front of a stressful situation, and I can explain why. First of all, we keep trying to explain whatever we can in a very honest way. It may be related to Japanese culture, but basically, that honesty is really honored. Therefore, as long as we are honest, merchants are unlikely to get upset.
“The other thing,” Makoto continued, “is if a merchant really gets upset, that [customer] should have an account manager inside [our sales] team. . . . Then what we will do is collaborate with those people so that we can spread that stress across the teams. We can be on the same page, we can be aligned, and then try to convince and try to, let’s say, calm down the merchant in a very cognizant way.
“This is why I say I’ve never been in a very stressful situation as an individual. We are trying to reduce such situations, and also, even in such situations, we have a team to cope with that type of [problem].”
Makoto also sets the tone in his communication with customers. “In order to avoid a gap in expectations, we try to set very low expectations, and then try to [exceed] those expectations.”
We usually try not to have a deadline. We tell [customers] that we’ll do our best, but we can’t guarantee any deadline.
This works in part, Makoto explained, because “in most cases, requirements and constraints given by customers aren’t actually hard. They can be complex. . . . [Then] what we will do, to approach that type of situation, is show our attitude that we really want to solve the problem with them, not by ourselves. Based on my experience, in many cases, customers can understand that. Customers can be very collaborative.”
Makoto gave an example of a complex customer request handled by his team. “ There is a merchant [customer]. . . .I think they will launch their website this week or next week. And they told us and the company that they will contract with us if we can provide a specific feature for PayPay.
“When you use PayPay, you generally just scan the code and then hit the pay button. In the background, actually, there are two processes that can run. One is just to pay. The other is to reserve the funds and then capture the funds once a product is shipped or handed over to the customer. We call it authorization of the payment. Then the question is, how long can we keep the authorization valid?
“Originally, we were allowing those authorizations to be valid only for 30 days. However, that merchant wanted to extend that validity up to around 180 days. So, we received that request. . . . We thought that would be challenging,” Makoto admitted. However, the size of the merchant, and the contract, offered a significant incentive. “I committed to developing that, and they actually gave [the project] to us. This is why the merchant on board is very happy and they are launching the EC site this week or next week with us. That’s one of the stories that I can share.”
This project did require some cross-team collaboration. “For releasing that feature,” Makoto said, “we communicated with other teams, like the sales team, the customer success team, and also the operations team, which configures certain values—just for example, they are in charge of setting the validity expiration date for those authorizations.” But most of the actual coding Makoto handled himself.
[For] 90 percent I did everything. Only [for] 10 percent did I ask other teams that are in charge of payment methods to have a review of my code, so that it wouldn’t have bad side effects.
And yet Makoto also told us, “ I’m a really lazy person. I really hate working overtime. . . . I will try to avoid that.” Usually the only time he works after 6 p.m. is if he’s coding and hasn’t reached a good stopping point. TokyoDev asked Makoto whether, if a future team member wanted to leave at 6 p.m. sharp every day, he would have a problem with that.
“No. No,” Makoto answered at once. “That’s specifically what Aaron is doing. He comes around 9 a.m., and then he just clocks out nine hours after that. . . . If he comes a little bit late, let’s say ten past 9 a.m., then he can clock out at ten past 6 p.m.”
Want to join the team?
Makoto is greatly looking forward to expanding his two-person team. “To be very ambitious, I’d say I want to make this team really big. . . . [Our goal] is to make our team develop products based on customer needs, whereas the product development teams are developing our product based on what we can do and what we should offer.”
We have, right now, fifty people for the product engineering [team]. Thinking about the world we’re moving towards, maybe at some point we can have fifty customer engineers.
To review, KOMOJU is looking for candidates who:
- Speak Japanese and English
- Have great communication skills
- Are as interested in business operations as they are in coding
- May have a nontraditional background
If the world is indeed moving towards more customer engineering teams, why work for KOMOJU’s? As with every other question, Makoto answered honestly. “I will try not to be offensive, but let me be very frank: from my perspective, the payment business in Japan is really ‘not cool.’
“On the other hand, I’d say our company wants to become a technically-leaning company. That is a huge differentiator against other teams. And especially thinking about our competitors, there are only a few who can be like us . . . very fast-paced and always thinking about the cutting edge of business and technology. I’d say that would be the most attractive part of [KOMOJU] as an employee.”