Wil was looking for a developer job in Japan and came across Givery. It seemed to be a great match for him. Not quite an early stage startup, but with eighty employees, it wasn’t too big either. The people seemed quite sociable, and frequently held get-togethers, allowing him to immerse himself in Japanese culture. At the same time, enough people spoke English that he didn’t need to rely solely on his conversational Japanese abilities.
But what sealed the deal was the product itself. He said, “We help companies hire engineers based on their skills with our product, track. I come from a not so traditional engineering background, so having the ability to make an impact on the industry here, changing it to be not so much about your background, but about your skills instead, really resonated with me.”
Wil had applied to join Givery as an engineer, wanting to immerse himself in code. But in an interview with one of the executives, the discussion took a turn away from technical things. He said, “We talked a lot about business, how to set goals for the company, how to set KPIs, and things like that. The company was still pretty immature in terms of processes of how to manage teams. Like the development team had a lot of different tasks given to them, but they didn’t know what the priorities were. So even though the product was doing well, it was clear that they needed some help organizing, to make sure everyone was facing in the same direction.”
Everyone I spoke to was so kind and empathetic that I felt that even though I had other offers from other companies that were all hands on coding, I felt like Givery was something I wanted to dedicate many years of my life to.
Through their conversation, the executive became convinced Wil could be the one to help them improve things. Wil said, “They convinced me to take the management job. And I guess I convinced myself too, because the company’s mission really resonated with me. Everyone I spoke to was so kind and empathetic that I felt that even though I had other offers from other companies that were all hands on coding, I felt like Givery was something I wanted to dedicate many years of my life to.”
One of the first things Wil did was introduce agile development best practices including sprint retrospectives, where his team could talk about what went well and what didn’t. In the first couple of retrospectives, the engineers consistently raised the same problem: they were constantly being interrupted by stakeholders whenever an issue came up.
Wil’s solution was to implement a new QA process to minimize bugs and also create a dedicated space for the Customer Support (CS) team to report issues and contact him when they encountered an issue, rather than directly messaging an engineer, as that would allow him to triage the issue to ensure the team wasn’t being interrupted mid sprint. It wasn’t hard to get the CS team to agree to this. He said, “It was just a matter of explaining to them why we needed to prioritize things. Like if we do it this way, then the engineers can focus on what they’re working on, and that’ll create more impact to the customer than if they’re just getting bombarded with investigation requests for not so serious issues.”
If the only time the development team is talking to the CS team is when the customer has an issue, it creates a kind of sad dynamic.
This approach did create a new challenge though, as with Wil in the middle, the CS and engineering teams began to feel siloed, as they now had less direct communication. To increase cohesion between the teams, they introduced biweekly sessions where engineers and CS alike can share wins. He said, “If the only time the development team is talking to the CS team is when the customer has an issue, it creates a kind of sad dynamic. So in order to fix this, we implemented a biweekly half hour ‘win session’ where we just celebrate some of the wins. The CS team will share with the development team things like compliments we’re getting from the customers. The development team will share how the CS team’s feedback has helped their progress. It creates a dynamic of not just ‘oh, there’s something wrong’, but we can appreciate each other’s role in catching and reporting stuff.”
When Wil joined, the majority of the engineering team was Japanese, but as it’s grown from nine to twenty-four engineers, it has also become incredibly international, with members from more than ten countries. He said, “We ended up hiring a lot of people who could only speak English recently, but it’s not a product of me going out to look for it. It’s just a side effect of the market. In my opinion, we have a pretty high bar when it comes to technical skill. It’s still a small team. We’ve had more luck finding really solid people when we expand the search. Japan is one country, and there’s a lot of amazing engineers here, but if you expand it to the entire world, the level just goes higher and higher because you have more people to pick from.”
I don’t think it’s a good idea to build a team where everyone is like a hive mind that thinks the same way.
Having a diverse team, with members from around the world, has brought other benefits. Wil said, “I don’t think it’s a good idea to build a team where everyone is like a hive mind that thinks the same way. There are benefits to that and maybe it’s easier to get everyone to agree on everything, but that doesn’t mean you’ll build a better product for your customers. In my opinion, it’s better when people add to your culture rather than fit into the culture. So you bring people from different parts of the world with different types of experiences in life. They’re not, they might not fit into your culture, but they bring in new ideas. And that’s what I’m looking for.”
While growing the development team has been one aspect of Wil’s role, he’s also been focused on retaining the existing engineers. This has been synergetic, as having a happy team helps to sell potential candidates on the company. He said, “I just have the team members speak with the applicants. When the applicants talk with them, they’re like I know the manager would say all these nice things, but talking to these people, they’re actually true.”
We also have quarterly evaluations, so that if you’re doing a good job, your salary can continue to go up very steadily.
Wil identified compensation as one key aspect of talent retention. He said, “When I first joined, Givery wasn’t super competitive on the salary front. Since then, we’ve done a lot of studies of the market to make sure that we are around the top in Tokyo. We also have quarterly evaluations, so that if you’re doing a good job, your salary can continue to go up very steadily.”
Another aspect to retention is providing a flexible working environment. This can be things like giving employees the choice of working fully remotely, granting sick leave, and also being accommodating to the employee’s individual circumstances. He said, “For example, the sister of one of our engineers was graduating, and she’s in Palo Alto in the US. So he went there and worked remotely for the last three weeks. Having the ability to attend an important family event is huge.”
The final facet of retention is granting developers autonomy. He said, “Just trust them to do what they do. Don’t hover over them. Give them a goal and let them get the job done. When people believe in the product, they’ll want to make it better.”
All this work to improve the environment for engineers has paid off. He said, “It’ll soon be three years since I joined Givery. We only lost one engineer that whole time, and it was for some personal reasons. No one’s left the team because they had issues with our work environment or anything like that. I’m really proud of that.”