Working from Europe for a Japanese startup
Zac Davison is living in Berlin but works for the Japanese startup MeetsMore, as tech lead of their Foundation team. He explains what the team does, and how he enables them to be more productive.
Zac was on a sabbatical, taking a break after five years working as a software engineer at a medical technology startup, when his friend Eugene got wind of it, and suggested he come work with him at MeetsMore, a Japan-based local services marketplace. Even though Zac was residing in Berlin, and had no interest in relocating to Japan, Eugene insisted he could work completely remotely, so he interviewed with them.
Going into the interview with a skeptical mindset, Zac came away impressed. He said, “They seemed really nice. It was the kind of company I was looking for: a product company who own their own business and made their own decisions. Also I liked the size, between a hundred and two hundred people. Small enough to where you can have impact, but big enough whereby you’re not in chaotic startup territory.”
I liked the size, between a hundred and two hundred people. Small enough to where you can have impact, but big enough whereby you’re not in chaotic startup territory.
Zac signed a contract with MeetsMore, and a year later he is the tech lead of their Foundation team, where their goal is “to make things suck less for developers”. They do this by improving the infrastructure that other developers work on, so that their velocity improves.
For example, his team is exploring moving their codebase from a massive monolithic architecture to microservices. As a first step, they’ve identified a candidate for a pilot-project microservice that was well encapsulated from a semantical perspective. This has allowed them to identify potential issues with a migration before committing to do it wholesale. He said, “We’re having a lot of conversations about how we are actually going to interact with the old system? How are we gonna bridge this gap temporarily without creating a ton of crufty boilerplate? We’re discovering the problems as we go.”
The challenges his team decides to tackle is left up to them. But to make sure they’re not getting lost in the weeds and working on something that’s not actually delivering much value, he frequently checks in with other engineers and managers. By explaining what he’s working on, and soliciting them for any higher priority problems to tackle, he can be confident his team is on the right track.
Besides identifying issues through speaking with others, he also seeks them out himself. One technique he’s used to identify particularly buggy areas of the codebase using the code forensics tool set. For instance, each time someone fixed a bug at MeetsMore, they’d put the issue number in the commit message. By looking at the files that were committed to resolve issues, Zac was able to identify those files that were frequently referenced. Then he used emerg to analyze those files, finding that they tended to be large and heavily coupled, making them good targets for refactoring.
While Zac would love to tackle all these challenges himself, he sees his job as Tech Lead as to support his team of engineers. One key thing to doing this is creating rich stories for them to work on. Though this approach takes time for him, he feels it’s worth it. He said, “I think it directly results in better velocity for everyone. As a team lead, that’s my biggest priority. Because I spend a lot more time than my engineers in meetings and reading things, taking that awareness and distilling that into stories allows them to work faster. This creates multiplicative effects, rather than just doing programming work myself.”
If you don’t experience the pain points of your team, it’s very hard for you to actually relate to them and understand what the issues are so you can fix them.
While he sees his role is to make his team more productive, rather than crank out code himself, he still thinks it’s important to sometimes get his hands dirty with coding. He said “I really hate being in a managerial only role because if you don’t experience the pain points of your team, it’s very hard for you to actually relate to them and understand what the issues are so you can fix them.”
Zac gave the example of slow unit tests. If your test suite is incredibly slow, taking an hour to run, you’ll find out about it as a manager. But what if it takes sixty seconds to run ten unit tests? It’ll significantly slow down the feedback loop, but especially if you have more junior engineers on their team, they might accept it as the way things are. But if you yourself are working on the codebase day after day, you’ll notice the poor developer experience this creates, and can allocate resources to fix it.
While Zac was initially worried about time zone differences, it turned out to be a blessing in disguise. Because his morning overlaps with Japan’s business day, that’s when he does any synchronous communication. By his afternoon, everyone in Japan has gone home, and he can focus on deep work, be it drafting stories, coding, or planning.
I know it sounds weird, but if you look at Slack all day, you can forget what the person is like.
One of Zac’s meetings is a weekly one-to-one with each of the engineers on his team. He said, “It’s mostly just to have face time with people because you need to remember that everyone’s human, and actually exists. I know it sounds weird, but if you look at Slack all day, you can forget what the person is like.”
To run the one-on-ones, Zac maintains a shared document with each engineer. When an engineer comes across something that they want to discuss personally with him, for instance about their personal growth, or a complaint about something, they add it to the section for the next meeting. He’ll also populate the document with anything he wants to discuss before-hand. This way, both parties have a clear agenda, and they can go through the points together. The content of the meeting varies depending on the engineer, but Zac makes sure he regularly checks in with everyone about their personal development, health, and wellbeing.
This approach of having a shared document for meetings works great when he’s communicating with non-native English speakers too, as he can write meeting minutes as he speaks, helping the listeners to stay on track. He said, “I interact with a lot of people who are non-native speakers, even outside of work, and I speak quite a few other languages, so I know the feeling of how when someone’s speaking to you, you can be like 80% of the way there, but don’t fully get it. And you don’t really interrupt sometimes because you don’t want to break their train of thought. So if I type, it means that they can read back over and align it with the words that they heard and say okay, I get it now.”
Everyone is easy to deal with, respectful, and attentive. It’s probably the lowest stress place I’ve worked.
Zac recommends other engineers join MeetsMore because of the laid back atmosphere. He said, “Everyone is really nice. I don’t know if this is the norm in Japanese companies, but everyone is easy to deal with, respectful, and attentive. It’s probably the lowest stress place I’ve worked, but maybe that’s because I worked in crazy startups before, and also in an insanely heavily regulated medical company.”
The organization is constantly improving itself too. He said, “There are problems internally in our codebase, but that’s what we’re here for, my team wouldn’t exist if there weren’t any. But people care a lot and they’re willing to learn. For example, people didn’t really have the practice of writing JSDocs, but my team started heavily doing it to lead by example. When other people saw that, they went okay cool, good idea, I’ll do that. The engineering organization is constantly growing and improving.”
He also thinks the company is at a great size. He said, “We’re big enough to be stable, but small enough where you still matter. There’s no hierarchical cruft from a larger organization, and it’s still at that level where everyone can have an impact and everyone’s feedback is often solicited.”