More from TokyoDev
Over my career, I’ve spent at least one thousand working hours on supporting local developer communities. My current business, TokyoDev, has spent over 8 million Japanese yen (about 53,000 USD) on community sponsorships. What have I received in return? That depends on your viewpoint. From a cold-hearted capitalist perspective, that time and money I invested hasn’t produced enough direct returns to justify the expense. Personally, I don’t see it as wasted—all of it has had a positive impact on society. What’s more, the three businesses I founded have owed much of their success to my community involvement. Those companies are: Mobalean, a technical consultancy that helped companies like PayPal, Match.com, and Estee Lauder build web apps for Japanese feature phones Doorkeeper, an event registration platform that hosted thousands of events per month TokyoDev, a job board that helps international software engineers get jobs in Japan If I hadn’t volunteered for and donated to various developer communities, two out of those three businesses would never have been founded at all, and TokyoDev certainly wouldn’t be the success story it is today. So, despite these “unequal” returns, one of the best strategies for my startups has been to get involved with communities whenever possible. I’ll go over some of the different ways communities have helped grow my businesses, and give specific examples of wins we’ve experienced over the years. Growing through existing communities There are two kinds of communities that can help you grow your startup: preexisting communities independent of your business, and communities you build around the business itself. My companies got their start due to my involvement in existing communities, and I think that is the easier place to begin. Already-established communities not only come with their own networks, but are usually easy to join and happy to receive support. Volunteering This was the origin of Doorkeeper. An industry event, Mobile Monday Tokyo, was registering hundreds of people for their events. Checking those people in at the door was always time-consuming, particularly as some names were in English and others in Japanese, giving no good way to sort the list. Seeing this, my cofounders and I proposed building some software to send out QR code tickets. Back in 2008, that was still a relatively novel idea. Mobile Monday was happy for us to do it, so we quickly built a one-off solution for them. We went further than that though—we also personally manned the doors for their events. I remember the first event where we checked in people using the new QR code tickets. It was quite rewarding to be able to tell the participants, “I built this.” That sense of satisfaction wasn’t the only immediate payoff—because we got involved in the event, it also served as marketing for Mobalean, our technical consultancy. We made connections with people in the industry, and when they had projects related to mobile web development, they started coming to us. Later, after we’d solved all of Mobile Monday’s event registration and ticketing needs, we thought other organizations might benefit from our work. We spent months rebuilding the tool to support multiple communities and launched it as Doorkeeper. Initially, though, it struggled to get users. Meanwhile, we continued to volunteer with other communities we were interested in, such as Startup Weekend Japan and RubyKaigi, Japan’s (and possibly the world’s) largest Ruby conference. We didn’t directly ask those communities to use our software, but after we got involved with them, they decided of their own accord to start using Doorkeeper. Because these events made quite an impact on the tech community in Japan, they helped us grow immensely, leading Doorkeeper to become the most popular platform for developer events in Japan. This wasn’t some sort of coldly-calculated strategy. I don’t think it would have worked if it had been. Sure, we knew that if we were running an event platform, it was a good idea to be involved with events, both to make connections and to personally experience our target audience’s problems. But our main motivation was just to help causes we believed in. I think our sincerity helped motivate the organizers to take a chance on a product that was still rather rough around the edges. Business-wise, Doorkeeper was never a runaway success. We struggled for years to monetize it. The turning point was when we announced we’d go from being a freemium service to an exclusively paid one. A lot of organizers stopped using us, but enough continued that I could finally pay myself a decent salary from the product’s revenue alone. What’s more, there was almost no backlash against the move. I think this was because we’d been socially connected to the organizers for the entire history of the company, and they could see that we were being genuine when we said there was no other way forward. I’ve since sold Doorkeeper, but the lessons I learned still stick with me. Speaking at community events Over the years, I’ve delivered numerous presentations on software development and entrepreneurship at different community events. At least for someone like myself, who doesn’t regularly give talks, preparing for them can be quite time-consuming. While I do believe it has helped keep my businesses in the minds of my target audience, I can’t think of a single example where giving a presentation led directly to a new lead. The closest we came to that was after speaking at a Ruby event about a library for handling subscriptions with PayPal. As part of the talk, we mentioned a new side project we were working on, a web app to make Japanese invoices. One of the attendees, a prominent member of the Japanese Ruby community, tweeted about the new service, effectively launching it. That initial buzz and the SEO-friendly domain name (the Japanese word for invoice), helped us become one of the top search results. The project didn’t end up going anywhere as a business, though, and we sold it around a year later. Starting your own independent community In 2010, I created Tokyo Rubyist Meetup, Japan’s first English-language community for Ruby developers. The goal of the group was to bring together the Japanese and international Ruby communities, and I believe we’ve succeeded. I think my efforts in organizing that community may have been why RubyKaigi chose to adopt Doorkeeper for their event registration. It also helped me connect with some of Mobalean’s best consulting clients. Finally—and most importantly—it indirectly led to developing TokyoDev as a business. The CTO of a local startup said something like, “Paul, I’ve been having trouble hiring developers. I know you’re well-connected with the community. Could I pay you to help hire some?” That CTO, along with others in similar situations, became the first clients for TokyoDev’s job board. Sponsoring existing organizations The methods I’ve talked about so far involve a lot of time but no cost. Sponsoring existing organizations is the opposite: all it requires is money. The cost involved depends on the scale of the sponsorship, and the perceived value of the community. When I saw in TokyoDev’s own data that women software engineers were being compensated worse than men, I wanted to do something about it. The simplest solution I came up with was sponsoring local communities that empower women in technology. I sought out some local organizations and offered to sponsor them, including a few that had never had sponsors before. Since then, TokyoDev has also sponsored local tech conferences, including RubyKaigi. These sponsorships have ranged from 100,000 yen (about 665 USD) on the low end to 1.5 million yen (about 10,000 USD) on the high end. In total, TokyoDev has spent over 8 million yen (about 53,000 USD) on sponsorships. Some of the big-ticket sponsorships have come with booths at conferences, which do provide new opportunities, but also additional costs—staffing the booths, airfare, hotels, etc. The more expensive conference sponsorships have directly resulted in several new clients for the job board, but not yet in any additional revenue (because we take a success-based approach, and those clients haven’t made any hires through us yet). I think for sponsorships to be really cost-effective, the target audience of the community must match your startup perfectly. Part of our challenge has been that many of these communities are primarily composed of Japanese software engineers, who aren’t the main users of TokyoDev. Still, while these sponsorships haven’t been a cost-effective way of improving our bottom line, they have helped communities and gotten the word out, as well as offering some other knock-on benefits. One specific example is from 2024, when we gave away one of our sponsor tickets to a job-hunting developer, and they found a position through a connection they made at the conference. Another example is “in-house.” One of our contractors introduced her daughter to a community we’ve sponsored, which helps young women get into software development. This inspired her daughter to become interested in programming and eventually to enroll in the program—something nobody in her family had anticipated! Growing your own communities While TokyoDev got its start thanks to local, preexisting organizations, we’ve also worked hard to create our own TokyoDev community, both online and off. Running an online community One of the first articles I wrote for TokyoDev was in response to a reader’s question about how I got my job as a developer in Japan. Over the years, I continued to receive emails asking for personalized advice. While I was happy to respond to people individually, it felt like that knowledge could also be of use to other people, so I started a forum using Discourse. Over the years I’d get questions on there, and occasionally someone else might chime in with their experience, but it was mostly just me responding to queries, and so wasn’t anything I’d call a “community.” Along the way, one of our contractors pointed out that it would be nice to create a space where we could casually talk to our users. After he brought it up several times, I made a Discord community. This quickly took off, and currently sits at about 7,000 members. Growing such a community hasn’t been without its challenges. The primary difficulty is moderation—no matter how we handle it, some users feel alienated. Have too soft a hand? The loudest voices win, driving away other valuable contributors. Reprimand or ban people? You make enemies out of what were once fans. I can’t say I’ve always done everything right here, but one thing I did do right was bring on a moderator who cares about the community. Besides having someone to bounce ideas around with, it also helps to have an additional person enforcing the rules. We have seen several benefits from our online community. At least one client made a hire through us that I can directly attribute to our Discord. That said, it’s the indirect benefits that have proven most valuable. For instance, our Discord helped us identify common challenges that developers face when relocating to Japan, making it a good source of topics for articles. We’ve also been able to ask members with unique experiences to write articles for the site, and their posts have been some of the most popular, such as one on Japan’s digital nomad visa. Organizing offline events As our Discord community grew, members started asking us to host offline meetups. We held our first one with a dozen or so people at a space we rented out ourselves, and provided soft drinks. This cost us about 30,000 yen (200 USD). The meetup was a success and we continued to host. Eventually, one of our members offered to hold the meetups at their company. This change allowed us to grow the meetups further, and we started regularly maxing out their capacity with 40 or so attendees. It also meant we only needed to pay for the soft drinks, bringing our cost down to 5,000 yen (33 USD). Not only was that quite cost-effective, but the company hosting the event eventually became a client of ours. We also started using our offline meetings to bring our clients together with the larger developer community, by holding collaborative events where the client gives presentations that are technically interesting to our audience. We’re careful to make sure these aren’t direct recruiting events, as I think that would drive away the very people our clients are looking to hire. By indirectly highlighting why it is interesting to work with them, however, our clients have been able to find more prospects. Initially, we catered these events with pizza and soft drinks, which cost around 30,000 yen (200 USD) for a 40 person event. Since we haven’t been charging clients for organizing these talks, we began asking them to provide food and drinks instead. As a result, these events have been win-win for everyone involved. Our clients get better branding amongst the developer community. Our community members enjoy interesting content and new connections. We establish stronger relationships with everyone involved. In addition to this offline community for software engineers, we’ve also started to build another offline community for the internal recruiters using TokyoDev. We began by hosting small dinners with internal recruiters from three or four different clients. This gave them the opportunity to share about the challenges they faced hiring international engineers. Hosting such a dinner cost us about 30,000 yen (200 USD), and led one company that was on the fence to start using TokyoDev. The dinners have proven to be a big success, and recruiters tell us they want to attend more, but there’s only so much time we can spend on them. To augment these networking meals, we’ve also started holding seminars on the topic of hiring engineers, so we can bring together a larger number of our clients at once. These don’t have quite the impact as the small dinners, but they are more scalable. Conclusion Communities have been key to all of my businesses. If my focus had been solely on maximizing revenues, I think the time and money I’ve spent on community involvement could have been better used elsewhere. But the nice thing about being an entrepreneur is that you get to choose your own metrics for success. And unlike with other business strategies, I can always feel good about what we accomplish. Even if an activity doesn’t create value for me personally, it does for someone else, so my efforts are never wasted. If you’re an entrepreneur looking to combine business and the common good, I recommend finding ways to build your company through the community as well. Whether it’s by spending your own time volunteering, contributing part of your business’s revenues to causes you care about, or building up a community around your brand, all these avenues can help both your enterprise and the public at large.
Since November 2023, I’ve been living in Karuizawa, a small resort town that’s 70 minutes away from Tokyo by Shinkansen. The elevation is approximately 1000 meters above sea level, making the summers relatively mild. Unlike other colder places in Japan, it doesn’t get much snow, and has the same sunny winters I came to love in Tokyo. With COVID and the remote work boom, it’s also become popular among professionals such as myself who want to live somewhere with an abundance of nature, but who still need to commute into Tokyo on a semi-regular basis. While I have a home office, I sometimes like to work outside. So I thought I’d share my impressions of the coworking spaces in town that I’ve personally visited, and a few other places where you can get some work done when you’re in town. Sawamura Roastery 11am on a Friday morning and there was only one other customer. Sawamura Roastery is technically a cafe, but it’s my personal favourite coworking space. It has free wifi, outlets, and comfortable chairs. While their coffees are on the expensive side, at about 750 yen for a cafe latte, they are also some of Karuizawa’s best. It’s empty enough on weekday mornings that I feel fine about staying there for hours, making it a deal compared to official drop-in coworking spaces. Another bonus is that it opens early: 7 a.m. (or 8 a.m. during the winter months). This allows me to start working right after I drop off my kids at daycare, rather than having 20 odd minutes to kill before heading to the other places that open at 9 a.m. If you’re having an online meeting, you can make use of the outdoor seating. It’s perfect when the weather is nice, but they also have heating for when it isn’t. The downsides are that their playlist is rather short, so I’m constantly hearing the same songs, and their roasting machine sometimes gets quite noisy. Gokalab Gokalab is my favourite dedicated coworking space in Karuizawa. Technically it is in Miyota, the next town over, which is sometimes called “Nishikaruizawa”. But it’s the only coworking space in the area I’ve been to that feels like it has a real community. When you want to work here, you have three options: buy a drink (600 yen for a cafe au lait—no cafe lattes, unfortunately, but if you prefer black coffee they have a good selection) and work out of the cafe area on the first floor; pay their daily drop-in fee of 1,000 yen; or become a “researcher” (研究員, kenkyuin) for 3,000 yen per month and enjoy unlimited usage. Now you may be thinking that the last option is a steal. That’s because it is. However, to become a researcher you need to go through a workshop that involves making something out of LEGO, and submit an essay about why you want to use the space. The thinking behind this is that they want to support people who actually share their vision, and aren’t just after a cheap space to work or study. Kind of zany, but that sort of out-of-the-box thinking is exactly what I want in a coworking space. When I first moved to Karuizawa, my youngest child couldn’t get into the local daycare. However, we found out that in Miyota, Suginoko Kindergarten had part-time spots available for two year olds. My wife and I ended up taking turns driving my kid there, and then spending the morning working out of Gokalab. Since my youngest is now in a local daycare, I haven’t made it out to Gokalab much. It’s just a bit too far for me (about a 15-minute drive from my house, while other options on this list are at most a 15-minute bicycle ride). But if I was living closer, I’d be a regular there. 232 Coworking Space & Hotel Noon on a Monday morning at 232 Coworking Space. If you’re looking for a coworking space near Karuizawa station, 232 Coworking Space & Hotel is the best option I’ve come across. The “hotel” part of the name made me think they were focused on “workcations,” but the space seems like it caters to locals as well. The space offers free coffee via an automatic espresso machine, along with other drinks, and a decent number of desks. When I used it on a Monday morning in the off-season, it was moderately occupied at perhaps a quarter capacity. Everyone spoke in whispers, so it felt a bit like a library. There were two booths for calls, but unfortunately they were both occupied when I wanted to have mine, so I had to sit in the hall instead. If the weather was a bit warmer I would have taken it outside, as there was some nice covered seating available. The decor was nice, though the chairs weren’t that comfortable. After a couple of hours I was getting sore. It was also too dimly lit for me, without much natural light. The price for drop-ins is reasonable, starting at 1,500 yen for four hours. They also have monthly plans starting from 10,000 yen for five days per month. WhatI found missing was a feeling of community. I didn’t see any small talk between the people working there, though I was only there for a couple hours, and maybe this occurs at other times. Their webpage also mentioned that they host events, but apparently they don’t have any upcoming ones planned and haven’t had any in a while. Shozo Coffee Karuizawa The latte is just okay here, but the atmosphere is nice. Shozo Coffee Karuizawa is a cafe on the first floor of the bookstore in Karuizawa Commongrounds. The second floor has a dedicated coworking space, but for me personally, the cafe is a better deal. Their cafe latte is mid-tier and 700 yen. In the afternoons I’ll go for their chai to avoid over-caffeination. They offer free wifi and have signs posted asking you not to hold online meetings, implicitly making it clear that otherwise they don’t mind you working there. Location-wise, this place is very convenient for me, but it suffers from a fatal flaw that prevents me from working there for an extended amount of time: the tables are way too low for me to type comfortably. I’m tall though (190 cm), so they aren’t designed with me in mind. Sheridan Coffee and a popover \- my entrance fee to this “coworking space”. Sheridan is a western breakfast and brunch restaurant. They aren’t that busy on weekdays and have free wifi, plus the owner was happy to let me work there. The coffee comes in a pot with enough for at least one refill. There’s also some covered outdoor seating. I used this spot to get some work done when my child was sick and being looked after at the wonderful Hochi Lodge (ほっちのロージ). It’s a clinic and sick childcare facility that does its best to not let on that it’s a medical facility. The doctors and nurses don’t wear uniforms, and appointments there feel more like you’re visiting someone’s home. Sheridan is within walking distance of it. Natural Cafeina An excellent cappuccino but only an okay place to work. If you’d like to get a bit of work done over an excellent cappuccino, Natural Cafeina is a good option. This cafe feels a bit cramped, and as there isn’t much seating, I wouldn’t want to use it for an extended period of time. Also, the music was also a bit loud. But they do have free wifi, and when I visited, there were a couple of other customers besides myself working there. Nakakaruizawa Library The Nakakaruizawa Library is a beautiful space with plenty of desks facing the windows and free wifi. Anyone can use it for free, making it the most economical coworking space in town. I’ve tried working out of it, but found that, for me personally, it wasn’t conducive to work. It is still a library, and there’s something about the vibes that just doesn’t inspire me. Karuizawa Commongrounds Bookstore Coworking Space The renowned bookstore Tsutaya operates Karuizawa Books in the Karuizawa Commongrounds development. The second floor has a coworking space that features the “cheap chic” look common among hip coworking spaces. Unfinished plywood is everywhere, as are books. I’d never actually worked at this space until writing this article. The price is just too high for me to justify it, as it starts at 1,100 yen for a mere hour, to a max of 4,000 yen per day. At 22,000 yen per month, it’s a more reasonable price for someone using it as an office full time. But I already have a home office and just want somewhere I can drop in at occasionally. There are a couple options, seating-wise. Most of the seats are in booths, which I found rather dark but with comfortable chairs. Then there’s a row of stools next to the window, which offer a good view, but are too uncomfortable for me. Depending on your height, the bar there may work as a standing desk. Lastly, there are two coveted seats with office chairs by a window, but they were both occupied when I visited. The emphasis here seems to be on individual deep work, and though there were a number of other people working, I’d have felt uncomfortable striking up a conversation with one of them. That’s enough to make me give it a pass. Coworking Space Ikoi Villa Coworking Space Ikoi Villa is located in Naka-Karuizawa, relatively close to my home. I’ve only used it once though. It’s part of a hotel, and they converted the lobby to a coworking space by putting a bunch of desks and chairs in it. If all you need is wifi and space to work, it gets the job done. But it’s a shame they didn’t invest a bit more in making it feel like a nice place to work. I went during the summer on one of the hottest days. My house only had one AC unit and couldn’t keep up, so I was hoping to find somewhere cooler to work. But they just had the windows open with some fans going, which left me disappointed. This was ostensibly the peak season for Karuizawa, but only a couple of others were working there that day. Maybe the regulars knew it’d be too hot, but it felt kind of lonely for a coworking space. The drop-in fee starts at 1,000 yen for four hours. It comes with free drinks from a machine: green tea, coffee, and water, if I recall correctly. Karuizawa Prince The Workation Core Do you like corporate vibes? Then this is the place for you. Karuizawa Prince The Workation Core is a coworking space located in my least favourite part of the town—the outlet mall. The throngs of shoppers and rampant commercialism are in stark contrast to the serenity found farther away from the station. This is another coworking space I visited expressly for this article. The fee is 660 yen per 30 minutes, to a maximum of 6,336 yen per day. Even now, just reading that maximum, my heart skipped a beat. This is certainly the most expensive coworking space I’ve ever worked from—I better get this article done fast. The facilities include a large open space with reasonably comfortable seating. There are a number of booths with monitors. As they are 23.8 inch monitors with 1,920 x 1,080 resolution, they’re a step down from the resolution of modern laptops, and so not of much use. Though there was room for 40 plus people, I was the only person working . Granted this was on a Sunday morning, so not when most people would typically attend. I don’t think I’ll be back here again. The price and sterile corporate vibe just aren’t for me. If you’re staying at The Prince Hotel, I think you get a discount. In that case, maybe it’s worth it, but otherwise I think there are better options. Sawamura Bakery & Restaurant Kyukaruizawa Sawamura Bakery & Restaurant is across the street from the Roastery. It offers slightly cheaper prices, with about 100 yen off the cafe latte, though the quality is worse, as is the vibe of the place as a whole. They do have a bigger selection of baked goods, though. As a cafe for doing some work, there’s nothing wrong with it per se. The upstairs cafe area has ample seating outside of peak hours. But I just don’t have a good reason to work here over the Roastery. The Pie Hole Los Angles Karuizawa The best (and only) pecan pie that I’ve had in Japan. The name of this place is a mouthful. Technically, it shouldn’t be on this list because I’ve never worked out of it. But they have wonderful pie, free wifi, and not many customers, so I could see working here. The chairs are a bit uncomfortable though, so I wouldn’t want to stop by for more than an hour or two. While this place had been on my radar for a while, I’d avoided it because there’s no good bicycle parking nearby—-or so I thought. I just found that the relatively close Church Street shopping street has a bit of bicycle parking off to the side. If you come to Karuizawa… When I was living in Tokyo, there were just too many opportunities to meet people, and so I found myself having to frequently turn down offers to go out for coffee. Since moving here, I’ve made some local connections, but the pace has been a lot slower. If you’re ever passing through Karuizawa, do get in touch, and I’d be happy to meet up for a cafe latte and possibly some pie.
It’s a fact that Japan needs more international developers. That doesn’t mean integrating those developers into Japanese companies, as well as Japanese society, is a simple process. But what are the most common challenges encountered by these companies with multinational teams? To find out, TokyoDev interviewed a number of Japanese companies with international employees. In addition to discussing the benefits of hiring overseas, we also wanted to learn more about what challenges they had faced, and how they had overcome them. The companies interviewed included: Autify, which provides an AI-based software test automation platform Beatrust, which has created a search platform that automatically structures profile information Cybozu, Japan’s leading groupware provider DeepX, which automates heavy equipment machinery Givery, which scouts, hires, and trains world-class engineers Shippio, which digitalizes international trading and is Japan’s first digital forwarding company Yaraku, which offers web-based translation management According to those companies, the issues they experienced fell into two categories: addressing the language barrier, and helping new hires come to Japan. The language barrier Language issues are by far the most universal problem faced by Japanese companies with multinational teams. As a result, all of the companies we spoke to have evolved their own unique solutions. AI translation To help improve English-Japanese communication, Yaraku has turned to AI and its own translation tool, YarakuZen. With these they’ve reduced comprehension issues down to verbal communication alone. Since their engineering teams primarily communicate via text anyway, this has solved the majority of their language barrier issue, and engineers feel that they can now work smoothly together. Calling on bilinguals While DeepX employs engineers from over 20 countries, English is the common language between them. Documentation is written in English, and even Japanese departments still write minutes in English so colleagues can check them later. Likewise, explanations of company-wide meetings are delivered in both Japanese and English. Still, a communication gap exists. To overcome it, DeepX assigns Japanese project managers who can also speak English well. English skills weren’t previously a requirement, but once English became the official language of the engineering team, bilingualism was an essential part of the role. These project managers are responsible for taking requests from clients and communicating them accurately to the English-only engineers. In addition, DeepX is producing more bilingual employees by offering online training in both Japanese and English. The online lessons have proven particularly popular with international employees who have just arrived in Japan. Beatrust has pursued a similar policy of encouraging employees to learn and speak both languages. Dr. Andreas Dippon, the Vice President of Engineering at Beatrust, feels that bilingual colleagues are absolutely necessary to business. I think the biggest mistake you can make is just hiring foreigners who speak only English and assuming all the communication inside engineering is just English and that’s fine. You need to understand that business communication with [those] engineers will be immensely difficult . . . You need some almost bilingual people in between the business side and the engineering side to make it work. Similar to DeepX, Beatrust offers its employees a stipend for language learning. “So nowadays, it’s almost like 80 percent of both sides can speak English and Japanese to some extent, and then there are like two or three people on each side who cannot speak the other language,” Dippon said. “So we have like two or three engineers who cannot speak Japanese at all, and we have two or three business members who cannot speak English at all.” But in the engineering team itself “is 100 percent English. And the business team is almost 100 percent Japanese.” “ Of course the leaders try to bridge the gap,” Dippon explained. “So I’m now joining the business meetings that are in Japanese and trying to follow up on that and then share the information with the engineering team, and [it’s] also the same for the business lead, who is joining some engineering meetings and trying to update the business team on what’s happening inside engineering.” “Mixed language” Shippio, on the other hand, encountered negative results when they leaned too hard on their bilingual employees. Initially they asked bilinguals to provide simultaneous interpretation at meetings, but quickly decided that the burden on them was too great and not sustainable in the long term. Instead, Shippio has adopted a policy of “mixed language,” or combining Japanese and English together. The goal of mixed language is simple: to “understand each other.” Many employees who speak one language also know a bit of the other, and Shippio has found that by fostering a culture of flexible communication, employees can overcome the language barrier themselves. For example, a Japanese engineer might forget an English word, in which case he’ll do his best to explain the meaning in Japanese. If the international engineer can understand a bit of Japanese, he’ll be able to figure out what his coworker intended to say, at which point they will switch back to English. This method, while idiosyncratic to every conversation, strikes a balance between the stress of speaking another language and consideration for the other person. The most important thing, according to Shippio, is that the message is conveyed in any language. Meeting more often Another method these companies use is creating structured meeting schedules designed to improve cross-team communication. Givery teams hold what they call “win sessions” and “sync-up meetings” once or twice a month, to ensure thorough information-sharing within and between departments. These two types of meetings have different goals: A “win session” reviews business or project successes, with the aim of analyzing and then repeating that success in future. A “sync-up meeting” helps teams coordinate project deadlines. They report on their progress, discuss any obstacles that have arisen, and plan future tasks. In these meetings employees often speak Japanese, but the meetings are translated into English, and sometimes supplemented with additional English messages and explanations. By building these sort of regular, focused meetings into the company’s schedule, Givery aims to overcome language difficulties with extra personal contact. Beatrust takes a similarly structured, if somewhat more casual, approach. They tend to schedule most meetings on Friday, when engineers are likely to come to the office. However, in addition to the regular meetings, they also hold the “no meeting hour” for everyone, including the business team. “One of the reasons is to just let people talk to each other,” Dippon explained. “Let the engineers talk to business people and to each other.” This kind of interaction, we don’t really care if it’s personal stuff or work stuff that they talk about. Just to be there, talking to each other, and getting this feeling of a team [is what’s important]. . . . This is hugely beneficial, I think. Building Bonds Beatrust also believes in building team relationships through regular off-site events. “Last time we went to Takaosan, the mountain area,” said Dippon. “It was nice, we did udon-making. . . . This was kind of a workshop for QRs, and this was really fun, because even the Japanese people had never done it before by themselves. So it was a really great experience. After we did that, we had a half-day workshop about team culture, company culture, our next goals, and so on.” Dippon in particular appreciates any chance to learn more about his fellow employees. Like, ‘Why did you leave your country? Why did you come to Japan? What are the problems in your country? What’s good in your country?’ You hear a lot of very different stories. DeepX also hopes to deepen the bonds between employees with different cultures and backgrounds via family parties, barbecues, and other fun, relaxing events. This policy intensified after the COVID-19 pandemic, during which Japan’s borders were closed and international engineers weren’t able to immigrate. When the borders opened and those engineers finally did arrive, DeepX organized in-house get-togethers every two weeks, to fortify the newcomers’ relationships with other members of the company. Sponsoring visas Not every company that hires international developers actually brings them to Japan—-quite a few prefer to hire foreign employees who are already in-country. However, for those willing to sponsor new work visas, there is universal consensus on how best to do it: hire a professional. Cybozu has gone to the extent of bringing those professionals in-house. The first international member they hired was an engineer living in the United States. Though he wanted to work in Japan, at that time they didn’t have any experience in acquiring a work visa or relocating an employee, so they asked him to work for their US subsidiary instead. But as they continued hiring internationally, Cybozu realized that quite a few engineers were interested in physically relocating to Japan. To facilitate this, the company set up a new support system for their multinational team, for the purpose of providing their employees with work visas. Other companies prefer to outsource the visa process. DeepX, for example, has hired a certified administrative scrivener corporation to handle visa applications on behalf of the company. Autify also goes to a “dedicated, specialized” lawyer for immigration procedures. Thomas Santonja, VP of Engineering at Autify, feels that sponsoring visas is a necessary cost of business and that the advantages far outweigh the price. We used to have fully remote, long-term employees outside of Japan, but we stopped after we noticed that there is a lot of value in being able to meet in person and join in increased collaboration, especially with Japanese-speaking employees that are less inclined to make an effort when they don’t know the people individually. “It’s kind of become a requirement, in the last two years,” he concluded, “to at least be capable of being physically here.” However, Autify does prevent unnecessary expenses by having a new employee work remotely from their home country for a one month trial period before starting the visa process in earnest. So far, the only serious issues they encountered were with an employee based in Egypt; the visa process became so complicated, Autify eventually had to give up. But Autify also employs engineers from France, the Philippines, and Canada, among other countries, and has successfully brought their workers over many times. Helping employees adjust Sponsoring a visa is only the beginning of bringing an employee to Japan. The next step is providing special support for international employees, although this can look quite different from company to company. DeepX points out that just working at a new company is difficult enough; also beginning a new life in a new country, particularly when one doesn’t speak the language, can be incredibly challenging. That’s why DeepX not only covers the cost of international flights, but also implemented other support systems for new arrivals. To help them get started in Japan, DeepX provides a hired car to transport them from the airport, and a furnished monthly apartment for one month. Then they offer four days of special paid leave to complete necessary procedures: opening a bank account, signing a mobile phone contract, finding housing, etc. The company also introduces real estate companies that specialize in helping foreigners find housing, since that can sometimes be a difficult process on its own. Dippon at Beatrust believes that international employees need ongoing support, not just at the point of entry, and that it’s best to have at least one person in-house who is prepared to assist them. I think that one trap many companies run into is that they know all about Japanese laws and taxes and so on, and everybody grew up with that, so they are all familiar. But suddenly you have foreigners who have basically no idea about the systems, and they need a lot of support, because it can be quite different. Santonja at Autify, by contrast, has had a different experience helping employees get settled. “I am extremely tempted to say that I don’t have any challenges. I would be extremely hard pressed to tell you anything that could be remotely considered difficult or, you know, require some organization or even extra work or thinking.” Most people we hire look for us, right? So they are looking for an opportunity to move to Japan and be supported with a visa, which is again a very rare occurrence. They tend to be extremely motivated to live and make it work here. So I don’t think that integration in Japan is such a challenge. Conclusion To companies unfamiliar with the process, the barriers to hiring internationally may seem high. However, there are typically only two major challenges when integrating developers from other countries. The first, language issues, has a variety of solutions ranging from the technical to the cultural. The second, attaining the correct work visa, is best handled by trained professionals, whether in-house or through contractors. Neither of these difficulties is insurmountable, particularly with expert assistance. In addition, Givery in particular has stressed that it’s not necessary to figure out all the details in advance of hiring: in fact, it can benefit a company to introduce international workers early on, before its own internal policies are overly fixed. This information should also benefit international developers hoping to work in Japan. Since this article reflects the top concerns of Japanese companies, developers can work to proactively relieve those worries. Learning even basic Japanese helps reduce the language barrier, while becoming preemptively familiar with Japanese society reassures employers that you’re capable of taking care of yourself here. If you’d like to learn more about the benefits these companies enjoy from hiring international developers, see part one of this article series here. Want to find a job in Japan? Check out the TokyoDev job board. If you want to know more about multinational teams, moving to Japan, or Japanese work life in general, see our extensive library of articles. If you’d like to continue the conversation, please join the TokyoDev Discord.
TokyoDev has already reported that Japan really needs international developers. But the more Japanese companies we’ve interviewed, the more we’ve realized that a talent shortage is not the only reason for Japanese companies to hire from overseas. There are a host of other advantages to recruiting internationally, and a growing number of managers are beginning to recognize the benefits. To gain more perspective on how multinational teams enhance their Japanese companies, we conducted interviews with the following businesses: Autify, which provides an AI-based software test automation platform Beatrust, which provides solutions to help companies maximize their human capital Cybozu, Japan’s leading groupware provider DeepX, which automates heavy equipment machinery Givery, which scouts, hires, and trains world-class engineers KOMOJU by Degica, a payment processor MODE, which pioneers innovative solutions to connect the digital and physical worlds Yaraku, which offers web-based translation management Below we’ve compiled the top reasons they gave for hiring international developers, and the specific ways in which those developers have improved their businesses. These range from the obvious—a greater talent pool to draw from—to surprising and even counterintuitive upsides, such as improved domestic recruiting and sheer enjoyment. The global talent pool Because Japan is suffering a developer shortage, and particularly lacks specialized and senior engineers, Japanese companies are expanding their recruiting efforts worldwide to find the staff and skill sets they need. That was DeepX’s initial motive for hiring international engineers: they needed employees with advanced technical skills. At first, when the company was founded in 2016, DeepX only intended to hire Japanese engineers. However, robotics is a fairly rare specialty in Japan, and those engineers who have studied it were reluctant to work at a newly-formed startup. Consequently, in 2018, DeepX hired their first international engineer; now they employ engineers from 20 different countries. Givery ran into the same issue. Though founded in 2009, the company spent five years trying to find enough staff to develop its B2C programming learning service, but struggled to attract talent because the company wasn’t yet well-known in Japan. In 2014 they received an application from a recruitment service, for an international front-end engineer who didn’t speak much Japanese. Since management was already discussing how best to globalize, they decided to seize this opportunity, despite the fact that many managers did not speak English. Seven years later, half of Givery’s development team of 120 are non-Japanese and hail from 20 different countries. The immediate benefits of widening the applicant pool speak for themselves. However Makoto Mizukami, head of Customer Engineering at KOMOJU by Degica, thinks recruiting internationally isn’t just a solution for today: it’s future-proofing. Because Japan is facing a declining and aging population, Mizukami believes that companies will face increased long-term risks if they insist on only hiring Japanese employees. In order for companies to survive, they must expand the range of people they employ. According to Mizukami, this applies to more than international engineers: companies must create an environment that can accept a highly diverse range of workers, including immigrants, women, people with disabilities, and the elderly. As will be seen later in this article, hiring international workers often has the side effect of creating a more favorable work environment for all. Recruiting at home But hiring international workers has a surprising secondary benefit: it improves domestic recruitment as well. KOMOJU found this out firsthand when they hired Shogo Ito as Staff SRE, since his primary motivation for joining KOMOJU was to improve his English. In Ito’s previous job, while he’d had the opportunity to collaborate with overseas teams, he hadn’t felt immersed in an English environment. But since at KOMOJU English is the primary form of communication, Ito felt confident he’d have a chance there to improve his skills. Givery has also benefited from this trend. It was their initial struggle to find engineers locally that led them to recruit internationally. As their multinational development team grew, though, they discovered that their diversity attracted more Japanese talent as well. As a result, Givery is one of the few tech companies in Japan to meet its recruitment goals on a regular basis. International knowledge Companies that hire internationally usually discover that their new employees bring more to the table than expected. It’s not just a question of tech skills—they carry with them fresh information that broadens companies’ knowledge bases overall. In the case of Beatrust, information from international employees contributes directly to their product. “We have a talent collaboration platform,” explained Dr. Andreas Dippon, the Vice President of Engineering at Beatrust. “The focus is [helping] employees better work with each other. Currently we’re focused on selling this product to big clients in Japan, which all already have some diversification. “Of course in Japan it’s mainly Japanese people, but you also have international engineers joining the big companies as well. So how can we support them collaborating in their company where there’s a language barrier, where there are cultural differences?” Having engineers of different backgrounds, especially with our product, helps us better understand how users think. KOMOJU also credits their global team with improving their product. As every country has unique payment methods and financial rules, the “insider knowledge” of employees from that country has proven invaluable. KOMOJU specifically cited China, which uses a number of payment methods such as Alipay and WeChat Pay that are unfamiliar in Japan; according to them, Chinese employees have been extremely helpful in explaining those systems to the rest of the team. Mizukami gave another example of international knowledge proving helpful. A user who had a free Chinese email address was flagged by the fraud detection system. At that time, Mizukami said, a Chinese engineer told them that “People who use this address cannot be trusted, so it’s okay to ignore it.” With that engineer’s assistance, the team was able to respond to the situation appropriately. Other tech companies we spoke to cited the benefits of international knowledge more generally, but Cybozu in particular knows the value of global perspectives. An earlier attempt to take their product, Cybozu Office, to the US via a subsidiary failed—in part, executives decided, due to differences in business customs between the US and Japan. That was why, in 2022, Cybozu approached international expansion differently. This time they created the New Business Division, an English-first multinational development team specifically designed to help Cybozu adapt existing products to the global market. In addition, the team has been tasked with building new products from the ground up, with an international audience in mind. Staying abreast of new tech Another plus to hiring international engineers, and particularly those who speak English, is earlier access to new tools and technology. Ito at KOMOJU pointed out that information on new services and tools is usually spread through English online media, and that most Japanese engineers don’t keep up with English articles on the subject. This means that, until someone writes an “I tried it” style post in Japanese, information on the latest developments isn’t readily available to Japanese developers. Having international engineers on the team, who are accustomed to scanning the English-language web for new tools and methods, accelerates the process. In addition, since KOMOJU’s official company language is English, there’s no concern about finding software with a Japanese UI, which greatly expands their options. Ito explained that KOMOJU uses services that are not very familiar in Japan, such as JumpCloud, Tenable, Vanta, and Honeybadger. Takuma Tatsumi, a recruiter for Yaraku, confirmed that the latest technology is overwhelmingly in English, leading to asymmetry of information. Even at previous companies, Japanese CTOs would ask the international engineers, “What are the current technology trends?” But since Yaraku has hired a number of international members, they’re now able to keep up with the latest development trends and incorporate new technology when it is, in fact, new. Changes in work environment Most Japanese companies with multinational teams end up making substantial culture changes to accommodate international employees. This could be considered a downside; instead, those we spoke to agree that the evolution of their company’s work environment was one of the top benefits of international recruitment. “The advantage I can see is with a mix of mindsets and [thoughts on the] future of work from so many different places,” said Thomas Santonja, VP of Engineering at Autify. I found a lot of very, very rich discussions about what to do, what not to do, and why, and a lot of debate, which is at least in my experience rarer in a pure Japanese environment. “Canadian and American staff are the ones that are the most vocal about why and how to do stuff, and [they] try to engage to get other people’s opinions,” he added. “That actually created a culture which is not necessarily super common. . . . I believe injecting a North American mindset in the mix is very valuable for a Japanese company, from my side of the fence.” Scott Tullis, head of Global Recruiting at MODE, also endorsed a mix of non-Japanese and Japanese work styles. “We’re a unique hybrid,” he said. Thanks to our Bay Area origins, we have the Silicon Valley tech startup culture in terms of entrepreneurship and innovation, and we also incorporate some of the great aspects of Japanese work culture around teamwork and collaboration. “We’re fortunate to not have any of the more notorious elements of Silicon Valley startup culture here,” he added. “The term ‘bro culture’ comes to mind and is well known in the Bay Area, which we thankfully do not have at MODE. Rather, we foster a more collaborative, thoughtful, and humble culture where people are truly trusted.” While the Japanese side of the company has inspired an atmosphere of humility and cooperation, the American side has contributed a fully remote work policy which, as Tullis pointed out, “is a relatively newer concept in Japan.” “We have offices in San Mateo and Tokyo, as it’s still important to have face-to-face interactions to collaborate effectively and continuously build our culture,” he said. “At the same time, the option to work remotely makes our work environment very flexible, which is beneficial for many team members, especially working parents. Our team comes from a diverse range of backgrounds, so this flexibility is key to better meeting the needs of each individual.” When it comes to work policy, Dippon at Beatrust has leaned on his European background. “ So I come from Germany, with German work culture,” he said, “which is like, we take care to take holidays and take time off and don’t do immense overwork and so on. So I try to bring that culture into my team, which is often difficult, because especially [people from] Japan, China, Taiwan, and so on—they used to work lots of overtime all the time.” So when I told them, ‘Please take the day off,’ and they said, ‘Okay, I’ll take the day off, but I can work in the morning and evening,’ I told them, ‘No, take the day off, don’t come in.’ They were confused at first, but over time I think they adapted to some extent, and now they really enjoy it, and when they come back they come back fully-refreshed and eager. That being said, Dippon takes great care not to impose his own European work paradigms too much. In fact, he finds the cultural differences amongst his team members both fascinating and useful. “Every day is very interesting,” he said. “You learn a lot about their countries, about their work style, and you can benefit from their experience in their work style as well.” Like Santonja, Dippon has noted how international hires lead to a more open style of communication. “The culture benefit is huge . . . when you can foster open communication in your engineering team, which we have achieved now. . . . So everybody can clearly state their opinion and not hold back,” Dippon said. “Which is very different from Japanese culture, from what I’ve heard,” Dippon added. “Even the Japanese people we have, they like that, so they can clearly say their opinion without having to fear any rejection.” All three of the executives quoted above are, notably, international hires themselves. But many Japanese managers also cite the benefits of adapting their company’s work environment. In fact, Tatsumi of Yaraku compared the company’s international members to the introduction of Western culture into Japan at the end of the Edo period, which led to profound cultural changes. Makiko Nakayama, Yaraku’s Human Resources manager, agreed with this. Foreign members are very frank about the issues they face, which is why we’ve created an environment that’s easy for them to work in. Those changes include a new approach to employee communication and collaboration. When work output is low or the team runs into difficulties, rather than immediately thinking, “Maybe someone is slacking off,” Yaraku employees tend to ask, “Why is it like this?” and “How can we improve it?” They said that the chance to actively communicate and think of ways to improve together creates a cooperative corporate culture, which has become one of the biggest attractions of working at Yaraku. International hires also led to new policies around paid leave. As Nakayama explained, employees from overseas told HR, “It takes four days to go home and back, so even if I use my paid leave, I really don’t have much time to rest.” As a result, Yaraku now allows employees to work remotely overseas for 30 days a year. Likewise, DeepX reported that its foreign engineers enjoy their new holiday substitute leave system. This system allows engineers to take a lump sum of vacation any time they like, by treating normal Japanese holidays as working days, and granting the same number of paid holidays. In this way, engineers can take longer vacations when returning to their home countries. But according to Satomi Makino, the system isn’t just used by international hires—many Japanese engineers are happy to take advantage of it as well. I feel DeepX is a comfortable working environment that incorporates the good points of overseas companies. In our interview with Givery, they offered some specific recommendations to other Japanese companies looking to build multinational teams. They suggested starting hiring early in the formation of the company, before internal policies had been well-established. Their newly-hired international employees, Givery’s management found, had different needs and expectations from their Japanese workers. For example, international engineers made requests like, “Can I go to the gym for two hours during lunch?” or “I want to go back to my home country in December. Can I take a month off?” Because Givery didn’t have too many procedures in place, it was able to consider suggestions like these and implement more flexible, globalized workplace practices. If Givery had waited to build its multinational development team until its policies were more firmly established, it may have struggled more to adapt to the needs of its international employees. It’s fun It may seem like an odd consideration, but multiple interviewees cited an interesting reason for hiring international employees—it’s fun! Yaraku’s engineering team was born out of CEO Suguru Sakanishi’s question to himself: What would happen if I created a global engineering team in my own company? Before founding Yaraku, Sakanishi had previously been to the US and worked in an international environment. This experience made him realize how fun it is to work with people from various backgrounds, and inspired him to hire people from abroad. KOMOJU shared a story about a newly-hired Indonesian member’s introduction to Japan. In Indonesia he had a 10 megabit Internet line for 6,000 yen a month; then he learned that in Japan, he could get a 10 gigabit line for the same price. The new hire was so surprised he exclaimed, ‘What’s going on?!’ The whole team enjoyed hearing that and sharing in his excitement. Members at KOMOJU believe that seeing and appreciating cultural differences, especially through casual conversations like this, is one of the unique attractions of multinational teams. Dippon, at Beatrust, describes this kind of cultural sharing as “one of the biggest pluses for me.” It’s so interesting, sitting together after work and talking about, ‘Oh, what’s going on in your country?’ . . . You get this kind of information in the news and so on, but you almost never hear from a person from that country. Conclusion For developers interested in working at Japanese companies, these interviews should offer insight into why Japanese managers are also interested in hiring them. Most businesses like these are looking for candidates who can bring more to the table than their work skills alone. They’re searching for applicants who can contribute the international knowledge and English proficiency that their teams need to level up. These companies also don’t necessarily expect candidates to conform to Japanese business norms. In fact, employees who forthrightly (but politely) explain their needs and expectations can benefit all the workers at the company, not just those from overseas. That being said, developers should be prepared to meet these companies halfway, mostly by being genuinely interested in Japan. It isn’t just a question of being willing to adapt to a new country: these managers appreciate the fun and interest of employing someone from another culture, so they’re keen to share their own as well. As Yaraku put it, they place importance on whether or not the candidate is specifically interested in this country, because that’s one of the greatest values that Yaraku can offer: “enjoying Japan.” To learn more about how you can work in (and enjoy) Japan, check out our job board or extensive library of articles. To continue the conversation, join the TokyoDev Discord.
More in programming
I took an amazing trip to SE Asia last month, including Angkor Wat. I had a hard time finding good reading or other resources to learn from before I went, in part because Amazon is awash in AI garbage. Here’s some books and podcasts I found useful about the Khmer empire in general and Angkor in particular: Ancient Angkor by Michael Freeman and Claude Jacques. The closest thing to a coffee-table book to preview what you will see. The practical information is outdated but the pictures and descriptions are good. Empire Podcast #185: The God Kings of Angkor Wat by William Dalrymple and Anita Anand. An entertaining and fully detailed account of the Khmer empire. It’s basically an excerpt from Dalrymple’s new book The Golden Road: How Ancient India Transformed the World. Fall of Civilizations Podcast #5: The Khmer Empire by Paul Cooper. Another history, not quite as magically well told as Dalrymple but full of good information. Angkor and the Khmer Civilization by Michael D. Coe. A highly recommended history of the Khmer region. Honestly I found this very dry and too detailed, but I did learn from it. Lonely Planet Pocket Guide: Siem Reap & the Temples of Angkor. We didn’t use this much but it seemed like a useful practical guide. OTOH it dates to 2018 so things have changed. My other advice for visiting Siem Reap and Angkor is: go. It is amazing. Plan for at least two full days of touristing there. Hire a private guide and driver if you can, it is absolutely worth it. (Email me for a recommendation.)
Often you’ll see a disorganized collection of ideas labeled as a “strategy.” Even when they’re dense with ideas, these can be hard to parse, and are a major reason why most engineers will claim their company doesn’t have a clear strategy even though my experience is that all companies follow some strategy, even if it’s undocumented. This chapter lays out a repeatable, structured approach to drafting strategy. It introduces each step of that approach, which are then detailed further in their respective chapters. Here we’ll cover: How these five steps fit together to facilitate creating strategy, especially by preventing practicioners from skipping steps that feel awkward or challenging. Step 1: Exploring the wider industry’s ideas and practices around the strategy you’re working on. Exploration is understanding what recent research might change your approach, and how the state of art has changed since you last tackled a similar problem. Step 2: Diagnosing the details of your problem. It’s hard to slow down to understand your problem clearly before attempting to solve it, but it’s even more difficult to solve anything well without a clear diagnosis. Step 3: Refinement is taking a raw, unproven set of ideas and testing them against reality. Three techniques are introduced to support this validation process: strategy testing, systems modeling, and Wardley mapping. Step 4: Policy makes the tradeoffs and decisions to solve your diagnosis. These can range from specifying how software is architected, to how pull requests are reviewed, to how headcount is allocated within an organization. Step 5: Operations are the concrete mechanisms that translate policy into an active force within your organization. These can be nudges that remind you about code changes without associated tests, or weekly meetings where you study progress on a migration. Whether these steps are sacred or are open to adaptation and experimentation, including when you personally should persevere in attempting steps that don’t feel effective. From this chapter’s launching point, you’ll have the high-level summaries of each step in strategy creation, and can decide where you want to read further. This is an exploratory, draft chapter for a book on engineering strategy that I’m brainstorming in #eng-strategy-book. As such, some of the links go to other draft chapters, both published drafts and very early, unpublished drafts. How the steps become strategy Creating effective strategy is not rote incantation of a formula. You can’t merely follow these steps to guarantee that you’ll create a great strategy. However, I’ve found over and over is that strategies fail more due to avoidable errors than from fundamentally unsound thinking. Busy people skip steps. Especially steps they dislike or have failed at before. These steps are the scaffolding to avoid those errors. By practicing routinely, you’ll build powerful habits and intuition around which approach is most appropriate for the current strategy you’re working on. They also help turn strategy into a community practice that you, your colleagues, and the wider engineering ecosystem can participate in together. Each step is an input that flows into the next step. Your exploration is the foundation of a solid diagnosis. Your diagnosis helps you search the infinite space of policy for what you need now. Operational mechanisms help you turn policy into an active force supporting your strategy rather than an abstract treatise. If you’re skeptical of the steps, you should certainly maintain your skepticism, but do give them a few tries before discarding them entirely. You may also appreciate the discussion in the chapter on bridging between theory and practice when doing strategy. Explore Exploration is the deliberate practice of searching through a strategy’s problem and solution spaces before allowing yourself to commit to a given approach. It’s understanding how other companies and teams have approached similar questions, and whether their approaches might also work well for you. It’s also learning why what brought you so much success at your former employer isn’t necessarily the best solution for your current organization. The Uber service migration strategy used exploration to understand the service ecosystem by reading industry literature: As a starting point, we find it valuable to read Large-scale cluster management at Google with Borg which informed some elements of the approach to Kubernetes, and Mesos: A Platform for Fine-Grained Resource Sharing in the Data Center which describes the Mesos/Aurora approach. It also used a Wardley map to explore the cloud compute ecosystem. For more detail, read the Exploration chapter. Diagnose Diagnosis is your attempt to correctly recognize the context that the strategy needs to solve before deciding on the policies to address that context. Starting from your exploration’s learnings, and your understanding of your current circumstances, building a diagnosis forces you to delay thinking about solutions until you fully understand your problem’s nuances. A diagnosis can be largely data driven, such as the navigating a Private Equity ownership transition strategy: Our Engineering headcount costs have grown by 15% YoY this year, and 18% YoY the prior year. Headcount grew 7% and 9% respectively, with the difference between headcount and headcount costs explained by salary band adjustments (4%), a focus on hiring senior roles (3%), and increased hiring in higher cost geographic regions (1%). It can also be less data driven, instead aiming to summarize a problem, such as the Index acquisition strategy’s summary of the known and unknown elements of the technical integration prior to the acquisition closing: We will need to rapidly integrate the acquired startup to meet this timeline. We only know a small number of details about what this will entail. We do know that point-of-sale devices directly operate on payment details (e.g. the point-of-sale device knows the credit card details of the card it reads). Our compliance obligations restrict such activity to our “tokenization environment”, a highly secured and isolated environment with direct access to payment details. This environment converts payment details into a unique token that other environments can utilize to operate against payment details without the compliance overhead of having direct access to the underlying payment details. The approach, and challenges, of developing a diagnosis are detailed in the Diagnosis chapter. Refine (Test, Map & Model) Strategy refinement is a toolkit of methods to identify which parts of your diagnosis are most important, and verify that your approach to solving the diagnosis actually works. This chapter delves into the details of using three methods in particular: strategy testing, systems modeling, and Wardley mapping. An example of a systems modeling diagram. These techniques are also demonstrated in the strategy case studies, such as the Wardley map of the LLM ecosystem, or the systems model of backfilling roles without downleveling them. For more detail, read the Refinement chapter. Why isn’t refinement earlier (or later)? A frequent point of disagreement is that refinement should occur before the diagnosis. Another is that mapping and modeling are two distinct steps, and mapping should occur before diagnosis, and modeling should occur after policy. A third is that refinement ought to be the final step of strategy, turning the steps into a looping cycle. These are all reasonable observations, so let me unpack my rationale for this structure. By far the biggest risk for most strategies is not that you model too early or map too late, but instead that you simply skip both steps entirely. My foremost concern is minimizing the required investment into mapping and modeling such that more folks do these steps at all. Refining after exploring and diagnosing allows you to concentrate your efforts on a smaller number of load-bearing areas. That said, it’s common to refine many places in your strategy creation. You’re just as likely to have three small refinement steps as one bigger one. Policy Policy is interpreting your diagnosis into a concrete plan. This plan also needs to work, which requires careful study of what’s worked within your company, and what new ideas you’ve discovered while exploring the current problem. Policies can range from providing directional guidance, such as the user data controls strategy’s guidance: Good security discussions don’t frame decisions as a compromise between security and usability. We will pursue multi-dimensional tradeoffs to simultaneously improve security and efficiency. Whenever we frame a discussion on trading off between security and utility, it’s a sign that we are having the wrong discussion, and that we should rethink our approach. We will prioritize mechanisms that can both automatically authorize and automatically document the rationale for accesses to customer data. The most obvious example of this is automatically granting access to a customer support agent for users who have an open support ticket assigned to that agent. (And removing that access when that ticket is reassigned or resolved.) To committing not to make a decision until later, as practiced in the Index acquisition strategy: Defer making a decision regarding the introduction of Java to a later date: the introduction of Java is incompatible with our existing engineering strategy, but at this point we’ve also been unable to align stakeholders on how to address this decision. Further, we see attempting to address this issue as a distraction from our timely goal of launching a joint product within six months. We will take up this discussion after launching the initial release. This chapter further goes into evaluating policies, overcoming ambiguous circumstances that make it difficult to decide on an approach, and developing novel policies. For full detail, read the Policy chapter. Operations Even the best policies have to be interpreted. There will be new circumstances their authors never imagined, and the policies may be in effect long after their authors have left the organization. Operational mechanisms are the concrete implementation of your policy. The simplest mechanisms are an explicit escalation path, as shown in Calm’s product engineering strategy: Exceptions are granted by the CTO, and must be in writing. The above policies are deliberately restrictive. Sometimes they may be wrong, and we will make exceptions to them. However, each exception should be deliberate and grounded in concrete problems we are aligned both on solving and how we solve them. If we all scatter towards our preferred solution, then we’ll create negative leverage for Calm rather than serving as the engine that advances our product. From that starting point, the mechanisms can get far more complex. This chapter works through evaluating mechanisms, composing an operational plan, and the most common sorts of operational mechanisms that I’ve seen across strategies. For more detail, read the Operations chapter. Is the structure sacrosanct? When someone’s struggling to write a strategy document, one of the first tools someone will often recommend is a strategy template. Templates are great: they reduce the ambiguity of an already broad project into something more tractable. If you’re wondering if you should use a template to craft strategy: sure, go ahead! However, I find that well-meaning, thoughtful templates often turn into lumbering, callous documents that serve no one well. The secret to good templates is that someone has to own it, and that person has to care about the template writer first and foremost, rather than the various constituencies that want to insert requirements into the strategy creation process. The security, compliance and cost of your plans matter a lot, but many organizations start to layer in more and more requirements into these sorts of documents until the idea of writing them becomes prohibitively painful. The best advice I can give someone attempting to write strategy, is that you should discard every element of strategy that gets in your way as long as you can explain what that element was intended to accomplish. For example, if you’re drafting a strategy and you don’t find any operational mechanisms that fit. That’s fine, discard that section. Ultimately, the structure is not sacrosanct, it’s the thinking behind the sections that really matter. This topic is explored in more detail in the chapter on Making engineering strategies more readable. Summary Now, you know the foundational steps to conducting strategy. From here, you can dive into the details with the strategy case studies like How should you adopt LLMs? or you can maintain a high altitude starting with how exploration creates the foundation for an effective strategy. Whichever you start with, I encourage yout o eventually work through both to get the full perspective.
Adam Silver has an article titled “Do you trust design advice from ChatGPT?” wherein he prompted the LLM: How do you add hint text to radio buttons? It gave various suggestions, each of which Adam breaks down. Here’s an an example response from ChatGPT: If you want the hint to appear when the user hovers on the radio button, use a tooltip for a cleaner design Adam’s response: ‘If you want’ Design is not about what you want. It’s about what users need. ‘use a tooltip’ If a hint is useful, why hide it behind a difficult-to-use and inaccessible interaction? ‘for a cleaner design’ Design is about clarity, not cleanliness. Adam’s point-by-point breakdowns are excellent. The entire article is a great example of how plausible-sounding ideas can quickly fall apart under scrutiny from an expert who reframes the issue. It’s funny how prevalent this feels in our age of fast-paced information overload. You read an argument and it seems rational — that is, if you don’t think about it too long, which who has the time? But an expert with deep experience can quickly refute these mediocre rationales and offer a more informed perspective that leaves you wondering how you ever nodded along to the original argument in the first place. Humorously, it reminds me of the culture of conspiracy theories where the burden of proof is on you to disprove the bare assertions being made (a time-consuming job). Hence the value of experience (and what’s experience but an investment of time?) to pierce through these kinds of middle-of-the-road rationales. Experience helps clarify and articulate what lesser experience cannot see, let alone articulate. That all leads me back to Adam: ChatGPT pulls unreliable, uninformed and untrustworthy design advice from the internet and delivers it with confidence. I mean you can certainly listen to its advice. But I think it’s better to develop the instinct to ask the right questions and be able to recognise bad advice when you see it. There’s no shortcut to gaining experience. You can’t consume enough content to get it. You have to do. Email · Mastodon · Bluesky
Logic for Programmers v0.8 now out! The new release has minor changes: new formatting for notes and a better introduction to predicates. I would have rolled it all into v0.9 next month but I like the monthly cadence. Get it here! Betteridge's Law of Software Engineering Specialness In There is No Automatic Reset in Engineering, Tim Ottinger asks: Do the other people have to live with January 2013 for the rest of their lives? Or is it only engineering that has to deal with every dirty hack since the beginning of the organization? Betteridge's Law of Headlines says that if a journalism headline ends with a question mark, the answer is probably "no". I propose a similar law relating to software engineering specialness:1 If someone asks if some aspect of software development is truly unique to just software development, the answer is probably "no". Take the idea that "in software, hacks are forever." My favorite example of this comes from a different profession. The Dewey Decimal System hierarchically categorizes books by discipline. For example, Covered Bridges of Pennsylvania has Dewey number 624.37. 6-- is the technology discipline, 62- is engineering, 624 is civil engineering, and 624.3 is "special types of bridges". I have no idea what the last 0.07 means, but you get the picture. Now if you look at the 6-- "technology" breakdown, you'll see that there's no "software" subdiscipline. This is because when Dewey preallocated the whole technology block in 1876. New topics were instead to be added to the 00- "general-knowledge" catch-all. Eventually 005 was assigned to "software development", meaning The C Programming Language lives at 005.133. Incidentally, another late addition to the general knowledge block is 001.9: "controversial knowledge". And that's why my hometown library shelved the C++ books right next to The Mothman Prophecies. How's that for technical debt? If anything, fixing hacks in software is significantly easier than in other fields. This came up when I was interviewing classic engineers. Kludges happened all the time, but "refactoring" them out is expensive. Need to house a machine that's just two inches taller than the room? Guess what, you're cutting a hole in the ceiling. (Even if we restrict the question to other departments in a software company, we can find kludges that are horrible to undo. I once worked for a company which landed an early contract by adding a bespoke support agreement for that one customer. That plagued them for years afterward.) That's not to say that there aren't things that are different about software vs other fields!2 But I think that most of the time, when we say "software development is the only profession that deals with XYZ", it's only because we're ignorant of how those other professions work. Short newsletter because I'm way behind on writing my April Cools. If you're interested in April Cools, you should try it out! I make it way harder on myself than it actually needs to be— everybody else who participates finds it pretty chill. Ottinger caveats it with "engineering, software or otherwise", so I think he knows that other branches of engineering, at least, have kludges. ↩ The "software is different" idea that I'm most sympathetic to is that in software, the tools we use and the products we create are made from the same material. That's unusual at least in classic engineering. Then again, plenty of machinists have made their own lathes and mills! ↩
We're spending just shy of $1.5 million/year on AWS S3 at the moment to host files for Basecamp, HEY, and everything else. The only way we were able to get the pricing that low was by signing a four-year contract. That contract expires this summer, June 30, so that's our departure date for the final leg of our cloud exit. We've already racked the replacement from Pure Storage in our two primary data centers. A combined 18 petabytes, securely replicated a thousand miles apart. It's a gorgeous rack full of blazing-fast NVMe storage modules. Each card in the chassis capable of storing 150TB now. Pure Storage comes with an S3-compatible API, so no need for CEPH, Minio, or any of the other object storage software solutions you might need, if you were trying to do this exercise on commodity hardware. This makes it pretty easy from the app side to do the swap. But there's still work to do. We have to transfer almost six petabytes out of S3. In an earlier age, that egress alone would have cost hundreds of thousands of dollars in fees alone. But now AWS offers a free 60-day egress window for anyone who wants to leave, so that drops the cost to $0. Nice! It takes a while to transfer that much data, though. Even on the fat 40-Gbit pipe we have set aside for the purpose, it'll probably take at least three weeks, once you factor in overhead and some babysitting of the process. That's when it's good to remind ourselves why June 30th matters. And the reminder math pens out in nice, round numbers for easy recollection: If we don't get this done in time, we'll be paying a cool five thousand dollars a day to continue to use S3 (if all the files are still there). Yikes! That's $35,000/week! That's $150,000/month! Pretty serious money for a company of our size. But so are the savings. Over five years, it'll now be almost five million! Maybe even more, depending on the growth in files we need to store for customers. About $1.5 million for the Pure Storage hardware, and a bit less than a million over five years for warranty and support. But those big numbers always seem a bit abstract to me. The idea of paying $5,000/day, if we miss our departure date, is awfully concrete in comparison.