More from TokyoDev
Right now, the General Union is handling cases at Japanese tech companies where well-established workplace practices have come under threat. These include businesses pushing for return-to-office mandates after years of remote work, eliminating flexible scheduling, and cutting bonuses and other forms of compensation. Sometimes these companies are altering work conditions that were never officially documented but had become standard practice. Other times, they’re trying to eliminate benefits explicitly written into contracts or work rules. In both cases, many workers believe they have no choice but to accept these changes. They’re wrong! Japanese labour law protects workers in two significant ways here. First, there’s the principle of established workplace practices (労使慣行, roudou kankou), protected through decades of court precedents, which can give unwritten customs the same legal weight as written rules. Then there’s Article 8 of the Labour Contract Law, which prevents employers from unilaterally changing documented working conditions. But having these legal protections is only half the battle. While the courts have established strong precedents, as an individual, pursuing these rights can be prohibitively difficult. Taking an employer to court is expensive, time-consuming, and potentially career-damaging. This is where collective action through unions becomes essential. Unions provide both the legal expertise and collective leverage needed to uphold these rights. For tech workers in Japan, these issues have never been more relevant. The tech industry’s desperate need for skilled workers, worth nearly 22 trillion yen in domestic investments, could create unprecedented leverage. By understanding their legal rights and organizing collectively, developers can effectively protect and even improve their workplace conditions in this critical moment. How the courts protect you A series of landmark cases in Japan created robust protections for workplace customs, also known as established employment practices. But what qualifies as an established employment practice? Yukiko Sadaoka, a regular collaborator with the General Union, explained how courts determine whether a workplace practice qualifies to be protected. “There are three main factors. One, a habit or fact must have been repeated and continued for a long period of time. Two, neither labour nor management has explicitly denied following the practice. And three, the practice must be supported by a normative awareness on both sides. The employers, especially those who control working conditions, must be aware of the practice.” Case 1: Post-Retirement Employment Practice (RECOGNISED) 東豊観光事件 (Toho Kanko), Osaka District Court 28, June 1990 In this order by the court, the company’s work regulations stated that the forced retirement age (定年, teinen) was 55. In practice, however, the company repeatedly kept employees on after they had reached this age. This custom continued for six years (1984–1990), during which 7 out of 8 employees who reached the age of 55 were retained. When the company terminated the 55 year-old plaintiff, citing the official retirement rule, the plaintiff sued for confirmation of employment status. The court stated that the practice of continued employment after 55 had become an established workplace custom. That custom overrode the written regulations, despite its relatively short period of practice, because it had been consistently applied to almost all employees who had reached the retirement age during that time. Case 2: Extra Pay for Substitute Holidays (DENIED) 商大八戸の里ドライビングスクール事件 (Syodai Yae-no-sato Driving School), Osaka High Court 25 June, 1993, and upheld by Supreme Court 9 March, 1995 Employees claimed entitlement to extra pay when working on a substitute holiday. The company’s policy was that every other Monday was a day off. If that particular Monday fell on a national holiday, Tuesday would become the substitute day off (振替休日, furikae kyuujitsu). The question was whether working on these Tuesday substitute holidays entitled workers to extra holiday pay. Although this practice had existed for 10 years, both the Osaka High Court, and the Supreme Court denied that it was an established workplace practice because the specific situation—working on a Tuesday substitute holiday—had only occurred 8–10 times during that period. This case demonstrates that frequency matters. Even when established over a lengthy period of time, if the actual instances of the practice are rare, it may not be considered established. Case 3: Bonus Amount Practice (PARTIALLY RECOGNISED) 立命館事件 (Ritsumeikan), Kyoto District Court 29 March 2012 (appealed, outcome uncertain) This case involved a bonus dispute. For 14 years, according to labour agreements (労働協約, roudou kyouyaku), the company had paid a bonus of 6.1 months’ salary plus 100,000 yen. However, there was no provision about bonuses in the company work rules (就業規則, shuugyou kisoku). When the employer announced the forthcoming bonus would be only 5.1 months’ salary, employees claimed the higher amount was an established practice. The court made an interesting distinction: It ruled that the specific amount (6.1 months + 100,000 yen) was NOT an established practice because there had been negotiations each year before agreeing on the amount, even though the final amount had always been the same. However, it recognised that “at least 6 months’ salary” had become an established practice, because the employer’s initial offer had never been lower than 6 months throughout the 14-year period. This case demonstrates the nuanced way courts examine whether a practice has created a legitimate expectation that can’t be unilaterally changed. These examples show that determining what constitutes an established workplace practice isn’t a simple matter of time. Courts look at consistency, frequency, specificity, and whether both sides understood the practice to be binding—even if they didn’t write it down. Other cases of interest The courts’ protection of established practices has occasionally been implemented in surprising ways. Take a case from 1968 that went all the way to the Tokyo High Court. The issue? Whether railway workers could continue their long-standing practice of using the company bath at 4 p.m. and clocking out at 4:30. At first glance, it might seem trivial—why fight over a bathing schedule? But the court’s decision was significant: after 13 years of this practice, with management’s knowledge and acceptance, it had become a legally-protected workplace custom that couldn’t be unilaterally changed. In the 1973 Shishido Shokai case (宍戸商会事件), the Tokyo District Court ruled that a company must pay severance to a voluntarily-resigned employee because consistent payment to other departing employees had established a binding workplace custom. The court classified these payments as deferred wages, confirming that consistent practices can create legal rights without written policies. Even when ruling in employers’ favour, courts have reinforced the importance of established practices. The 1982 Daiwa Bank case (大和銀行事件) upheld the bank’s long-standing practice of paying bonuses only to those still employed on payment dates, ruling that workers who left before payment weren’t entitled to bonuses despite working during the calculation period. These court precedents have established principles that apply universally across all industries. Whether a railway worker’s bathing schedule from the 1960s or solidifying employer rights, established employment practices are a real concept that can be parlayed into tech workers’ fight to maintain their working conditions. What does the law say? Article 8 of the Labour Contract Law also protects you against unilateral changes to working conditions. The law states, “A Worker and an Employer may, by agreement, change any working conditions that constitute the contents of a labour contract.” While the law is written in the positive, the inverse is what is important: “a worker and an employer cannot change working conditions without mutual agreement.” So, what constitutes the “contents of a labour contract”? Does this only deal with working conditions that are specifically written into your employment contract? According to General Union Chair Toshiaki Asari, “The idea that long-standing practices can become part of the employment contract and receive legal protection—even if they aren’t explicitly written—is well-established as a legal doctrine. Therefore, long-standing practices should also fall under the protections of Article 8 of the Labour Contract Law, just like written working conditions.” This perspective is supported by a significant 1991 Supreme Court ruling in the Hitachi Musashi Factory case (日立製作所武蔵工場事件). When an employee refused to work overtime during a production issue, claiming the request was unreasonable, the court found that the company’s consistent practice of requiring overtime in specific situations had become an implied term of employment—even without documentation. Because this practice was long-standing and implicitly accepted by employees over time, the court upheld the company’s disciplinary action. Though the ruling was in the employer’s favor, it also established that workplace customs, through consistent application and mutual understanding, can become legally binding components of employment contracts. Does this mean an employer can never change any working condition? The short answer is: they certainly can. This right of the employer to change working conditions is established in both Articles 9 and 10 of the Labour Contract Law. However, Article 9 also sets up a fundamental principle: employers cannot unilaterally change working conditions to workers’ disadvantage by modifying work rules without employee agreement. While Article 10 provides limited exceptions to this principle, it sets strict criteria that employers must meet. Any changes must be: Properly communicated to workers Reasonable given the degree of disadvantage to workers Necessary for the business Appropriate in their revised content Preceded by proper negotiations with unions or worker representatives This framework ensures that while employers can adapt to changing business needs, they cannot do so by simply imposing disadvantageous changes on workers without justification or prior consultation. The reality of defending your rights But what do these legal protections really mean in practice? Terms like disadvantages, reasonable, necessary, and appropriate sound reassuring on paper. Yet their practical meaning becomes far less clear when your employer suddenly demands you return to the office after five years of remote work, or changes how raises are calculated, or alters stock option arrangements. This is where the gap between legal rights and practical enforcement becomes stark. While the law provides a strong framework for protecting workplace practices, enforcing these rights as an individual is another matter entirely. Taking your employer to court is a long, expensive process that could take years to resolve, and that’s not only in the case of established employment practices. Even the seemingly clear prescriptions of the Labour Contract Law can only be enforced through court action. In the meantime, you’re stuck working under the contested conditions, while potentially damaging both your career and wellbeing. And remember, if you want to negotiate with your employer about changes to workplace practices, they have no legal obligation to even meet with you. They can simply ignore your requests or refuse outright. The power of collective action Unlike individual workers, who can be ignored or denied the chance to meet with management, employers cannot legally refuse to negotiate with a labour union. This right to collective bargaining is protected by the Trade Union Law. Even if you’re the only union member in your workplace, the company must negotiate with your union in good faith. The law also protects union members from retaliation or disadvantageous treatment. Unions offer multiple pathways for protecting workers’ rights and established employment practices. One key strategy is establishing prior consultation agreements (事前協議協定, jizen kyougi kyoutei), which require employers to inform and consult with the union before implementing changes to working conditions. By securing a seat at the table early, unions can influence decisions and propose alternatives before changes are implemented, rather than fighting them after the fact. Through collective bargaining, unions can also convert established workplace practices into written agreements, giving them stronger protection than relying on court precedents alone. By codifying these customs in collective agreements, they become immune to unilateral changes by employers. This matters because collective agreements sit at the top of the workplace rules hierarchy, superseding both individual contracts and company work rules—they’re the gold standard in protecting workers’ rights. True, an employer might still break a collective agreement, but unlike individual workers who can only turn to courts or government agencies, unions have multiple ways to respond. They can file complaints with the Labour Commission, as violating a collective agreement constitutes an unfair labour practice under the Trade Union Law. Most importantly, unions retain the right to take direct action through strikes and other collective measures—options simply not available to individual workers. As an individual, though, declaring union membership often shifts the power dynamic. When you’re backed by a union, you’re no longer facing the company alone. Many disputes are resolved at this early stage, as employers recognise that their actions will face greater scrutiny. While some employers might still attempt to violate the law, most understand that directly confronting unions by targeting their members creates more problems than it’s worth. Remember, your right to labour union representation is enshrined both in the Trade Union Law and Article 28 of the Constitution, which states that “The right of workers to organise and to bargain and act collectively is guaranteed.” Unions can also push beyond merely protecting existing rights, into negotiating improvements that particularly matter to tech workers—like expanded remote work options, clearer overtime compensation for project crunch times, training and skill development budgets, improved parental leave policies, and protections against excessive on-call rotations. Unions can also establish guidelines on emerging issues like AI implementation policies and the right to disconnect after working hours. Conclusion For developers, this situation presents a unique opportunity for collective action. Japan’s tech industry, worth nearly 22 trillion yen in domestic IT investments alone, mirrors the automotive industry of mid-20th century America—a wealthy, rapidly growing sector desperately in need of workers at all skill levels. Like the auto plants of Detroit, modern tech companies rely on a diverse workforce ranging from highly-paid specialists to entry-level developers. This combination—a wealthy industry, a significant labour shortage, and the critical role tech workers play in company operations—creates unprecedented leverage for collective action. Just as auto workers used their position to secure better wages and working conditions in the 1950s and 1960s, tech workers today could wield similar influence. The cost of lost productivity in tech companies can run into millions of yen per day, giving organised workers significant bargaining power. Moreover, unlike in traditional manufacturing where production delays might only affect future sales, many tech companies lose revenue immediately when work stops. By maintaining critical systems, supporting client operations, and keeping online services running, tech workers’ daily tasks directly impact their companies’ bottom lines. Even a small group of organised workers can effectively advocate for better conditions. That’s why understanding your legal rights under Japanese labour law is crucial—it provides the foundation for protecting established employment practices and knowing what you can rightfully demand. But knowledge alone isn’t enough. Whether these rights come from written contracts, established customs, or collective agreements, making them real requires more than just knowing they exist: it requires standing together to defend them. Through union membership, you combine legal protection with collective power—that is, you have both the law on your side and an active organisation working to protect your rights, with real mechanisms to enforce them.
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.
Japan already stipulates that employers must offer the option of reduced working hours to employees with children under three. However, the Child Care and Family Care Leave Act was amended in May 2024, with some of the new provisions coming into effect April 1 or October 1, 2025. The updates to the law address: Remote work Flexible start and end times Reduced hours On-site childcare facilities Compensation for lost salary And more Legal changes are one thing, of course, and social changes are another. Though employers are mandated to offer these options, how many employees in Japan actually avail themselves of these benefits? Does doing so create any stigma or resentment? Recent studies reveal an unsurprising gender disparity in accepting a modified work schedule, but generally positive attitudes toward these accommodations overall. The current reduced work options Reduced work schedules for employees with children under three years old are currently regulated by Article 23(1) of the Child Care and Family Care Leave Act. This Article stipulates that employers are required to offer accommodations to employees with children under three years old. Those accommodations must include the opportunity for a reduced work schedule of six hours a day. However, if the company is prepared to provide alternatives, and if the parent would prefer, this benefit can take other forms—for example, working seven hours a day or working fewer days per week. Eligible employees for the reduced work schedule are those who: Have children under three years old Normally work more than six hours a day Are not employed as day laborers Are not on childcare leave during the period to which the reduced work schedule applies Are not one of the following, which are exempted from the labor-management agreement Employees who have been employed by the company for less than one year Employees whose prescribed working days per week are two days or less Although the law requires employers to provide reduced work schedules only while the child is under three years old, some companies allow their employees with older children to work shorter hours as well. According to a 2020 survey by the Ministry of Health, Labor and Welfare, 15.8% of companies permit their employees to use the system until their children enter primary school, while 5.7% allow it until their children turn nine years old or enter third grade. Around 4% offer reduced hours until children graduate from elementary school, and 15.4% of companies give the option even after children have entered middle school. If, considering the nature or conditions of the work, it is difficult to give a reduced work schedule to employees, the law stipulates other measures such as flexible working hours. This law has now been altered, though, to include other accommodations. Updates to The Child Care and Family Care Leave Act Previously, remote work was not an option for employees with young children. Now, from April 1, 2025, employers must make an effort to allow employees with children under the age of three to work remotely if they choose. From October 1, 2025, employers are also obligated to provide two or more of the following measures to employees with children between the ages of three and the time they enter elementary school. An altered start time without changing the daily working hours, either by using a flex time system or by changing both the start and finish time for the workday The option to work remotely without changing daily working hours, which can be used 10 or more days per month Company-sponsored childcare, by providing childcare facilities or other equivalent benefits (e.g., arranging for babysitters and covering the cost) 10 days of leave per year to support employees’ childcare without changing daily working hours A reduced work schedule, which must include the option of 6-hour days How much it’s used in practice Of course, there’s always a gap between what the law specifies, and what actually happens in practice. How many parents typically make use of these legally-mandated accommodations, and for how long? The numbers A survey conducted by the Ministry of Health, Labor and Welfare in 2020 studied uptake of the reduced work schedule among employees with children under three years old. In this category, 40.8% of female permanent employees (正社員, seishain) and 21.6% of women who were not permanent employees answered that they use, or had used, the reduced work schedule. Only 12.3% of male permanent employees said the same. The same survey was conducted in 2022, and researchers found that the gap between female and male employees had actually widened. According to this second survey, 51.2% of female permanent employees and 24.3% of female non-permanent employees had reduced their hours, compared to only 7.6% of male permanent employees. Not only were fewer male employees using reduced work programs, but 41.2% of them said they did not intend to make use of them. By contrast, a mere 15.6% of female permanent employees answered they didn’t wish to claim the benefit. Of those employees who prefer the shorter schedule, how long do they typically use the benefit? The following charts, using data from the 2022 survey, show at what point those employees stop reducing their hours and return to a full-time schedule. Female permanent employees Female non-permanent employees Male permanent employees Male non-permanent employees Until youngest child turns 1 13.7% 17.9% 50.0% 25.9% Until youngest child turns 2 11.5% 7.9% 14.5% 29.6% Until youngest child turns 3 23.0% 16.3% 10.5% 11.1% Until youngest child enters primary school 18.9% 10.5% 6.6% 11.1% Sometime after the youngest child enters primary school 22.8% 16.9% 6.5% 11.1% Not sure 10% 30.5% 11.8% 11.1% From the companies’ perspectives, according to a survey conducted by the Cabinet Office in 2023, 65.9% of employers answered that their reduced work schedule system is fully used by their employees. What’s the public perception? Some fear that the number of people using the reduced work program—and, especially, the number of women—has created an impression of unfairness for those employees who work full-time. This is a natural concern, but statistics paint a different picture. In a survey of 300 people conducted in 2024, 49% actually expressed a favorable opinion of people who work shorter hours. Also, 38% had “no opinion” toward colleagues with reduced work schedules, indicating that 87% total don’t negatively view those parents who work shorter hours. While attitudes may vary from company to company, the public overall doesn’t seem to attach any stigma to parents who reduce their work schedules. Is this “the Mommy Track”? Others are concerned that working shorter hours will detour their career path. According to this report by the Ministry of Health, Labour and Welfare, 47.6% of male permanent employees indicated that, as the result of working fewer hours, they had been changed to a position with less responsibility. The same thing happened to 65.6% of male non-permanent employees, and 22.7% of female permanent employees. Therefore, it’s possible that using the reduced work schedule can affect one’s immediate chances for advancement. However, while 25% of male permanent employees and 15.5% of female permanent employees said the quality and importance of the work they were assigned had gone down, 21.4% of male and 18.1% of female permanent employees said the quality had gone up. Considering 53.6% of male and 66.4% of female permanent employees said it stayed the same, there seems to be no strong correlation between reducing one’s working hours, and being given less interesting or important tasks. Reduced work means reduced salary These reduced work schedules usually entail dropping below the originally-contracted work hours, which means the employer does not have to pay the employee for the time they did not work. For example, consider a person who normally works 8 hours a day reducing their work time to 6 hours a day (a 25% reduction). If their monthly salary is 300,000 yen, it would also decrease accordingly by 25% to 225,000 yen. Previously, both men and women have avoided reduced work schedules, because they do not want to lose income. As more mothers than fathers choose to work shorter hours, this financial burden tends to fall more heavily on women. To address this issue, childcare short-time employment benefits (育児時短就業給付) will start from April 2025. These benefits cover both male and female employees who work shorter hours to care for a child under two years old, and pay a stipend equivalent to 10% of their adjusted monthly salary during the reduced work schedule. Returning to the previous example, this stipend would grant 10% of the reduced salary, or 22,500 yen per month, bringing the total monthly paycheck to 247,500 yen, or 82.5% of the normal salary. This additional stipend, while helpful, may not be enough to persuade some families to accept shorter hours. The childcare short-time employment benefits are available to employees who meet the following criteria: The person is insured, and is working shorter hours to care for a child under two years old. The person started a reduced work schedule immediately after using the childcare leave covered by childcare leave benefits, or the person has been insured for 12 months in the two years prior to the reduced work schedule. Conclusion Japan’s newly-mandated options for reduced schedules, remote work, financial benefits, and other childcare accommodations could help many families in Japan. However, these programs will only prove beneficial if enough employees take advantage of them. As of now, there’s some concern that parents who accept shorter schedules could look bad or end up damaging their careers in the long run. Statistically speaking, some of the news is good: most people view parents who reduce their hours either positively or neutrally, not negatively. But other surveys indicate that a reduction in work hours often equates to a reduction in responsibility, which could indeed have long-term effects. That’s why it’s important for more parents to use these accommodations freely. Not only will doing so directly benefit the children, but it will also lessen any negative stigma associated with claiming them. This is particularly true for fathers, who can help even the playing field for their female colleagues by using these perks just as much as the mothers in their offices. And since the state is now offering a stipend to help compensate for lost income, there’s less and less reason not to take full advantage of these programs.
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.
More in programming
I like the job title “Design Engineer”. When required to label myself, I feel partial to that term (I should, I’ve written about it enough). Lately I’ve felt like the term is becoming more mainstream which, don’t get me wrong, is a good thing. I appreciate the diversification of job titles, especially ones that look to stand in the middle between two binaries. But — and I admit this is a me issue — once a title starts becoming mainstream, I want to use it less and less. I was never totally sure why I felt this way. Shouldn’t I be happy a title I prefer is gaining acceptance and understanding? Do I just want to rebel against being labeled? Why do I feel this way? These were the thoughts simmering in the back of my head when I came across an interview with the comedian Brian Regan where he talks about his own penchant for not wanting to be easily defined: I’ve tried over the years to write away from how people are starting to define me. As soon as I start feeling like people are saying “this is what you do” then I would be like “Alright, I don't want to be just that. I want to be more interesting. I want to have more perspectives.” [For example] I used to crouch around on stage all the time and people would go “Oh, he’s the guy who crouches around back and forth.” And I’m like, “I’ll show them, I will stand erect! Now what are you going to say?” And then they would go “You’re the guy who always feels stupid.” So I started [doing other things]. He continues, wondering aloud whether this aversion to not being easily defined has actually hurt his career in terms of commercial growth: I never wanted to be something you could easily define. I think, in some ways, that it’s held me back. I have a nice following, but I’m not huge. There are people who are huge, who are great, and deserve to be huge. I’ve never had that and sometimes I wonder, ”Well maybe it’s because I purposely don’t want to be a particular thing you can advertise or push.” That struck a chord with me. It puts into words my current feelings towards the job title “Design Engineer” — or any job title for that matter. Seven or so years ago, I would’ve enthusiastically said, “I’m a Design Engineer!” To which many folks would’ve said, “What’s that?” But today I hesitate. If I say “I’m a Design Engineer” there are less follow up questions. Now-a-days that title elicits less questions and more (presumed) certainty. I think I enjoy a title that elicits a “What’s that?” response, which allows me to explain myself in more than two or three words, without being put in a box. But once a title becomes mainstream, once people begin to assume they know what it means, I don’t like it anymore (speaking for myself, personally). As Brian says, I like to be difficult to define. I want to have more perspectives. I like a title that befuddles, that doesn’t provide a presumed sense of certainty about who I am and what I do. And I get it, that runs counter to the very purpose of a job title which is why I don’t think it’s good for your career to have the attitude I do, lol. I think my own career evolution has gone something like what Brian describes: Them: “Oh you’re a Designer? So you make mock-ups in Photoshop and somebody else implements them.” Me: “I’ll show them, I’ll implement them myself! Now what are you gonna do?” Them: “Oh, so you’re a Design Engineer? You design and build user interfaces on the front-end.” Me: “I’ll show them, I’ll write a Node server and setup a database that powers my designs and interactions on the front-end. Now what are they gonna do?” Them: “Oh, well, we I’m not sure we have a term for that yet, maybe Full-stack Design Engineer?” Me: “Oh yeah? I’ll frame up a user problem, interface with stakeholders, explore the solution space with static designs and prototypes, implement a high-fidelity solution, and then be involved in testing, measuring, and refining said solution. What are you gonna call that?” [As you can see, I have some personal issues I need to work through…] As Brian says, I want to be more interesting. I want to have more perspectives. I want to be something that’s not so easily definable, something you can’t sum up in two or three words. I’ve felt this tension my whole career making stuff for the web. I think it has led me to work on smaller teams where boundaries are much more permeable and crossing them is encouraged rather than discouraged. All that said, I get it. I get why titles are useful in certain contexts (corporate hierarchies, recruiting, etc.) where you’re trying to take something as complicated and nuanced as an individual human beings and reduce them to labels that can be categorized in a database. I find myself avoiding those contexts where so much emphasis is placed in the usefulness of those labels. “I’ve never wanted to be something you could easily define” stands at odds with the corporate attitude of, “Here’s the job req. for the role (i.e. cog) we’re looking for.” Email · Mastodon · Bluesky
We received over 2,200 applications for our just-closed junior programmer opening, and now we're going through all of them by hand and by human. No AI screening here. It's a lot of work, but we have a great team who take the work seriously, so in a few weeks, we'll be able to invite a group of finalists to the next phase. This highlights the folly of thinking that what it'll take to land a job like this is some specific list of criteria, though. Yes, you have to present a baseline of relevant markers to even get into consideration, like a great cover letter that doesn't smell like AI slop, promising projects or work experience or educational background, etc. But to actually get the job, you have to be the best of the ones who've applied! It sounds self-evident, maybe, but I see questions time and again about it, so it must not be. Almost every job opening is grading applicants on the curve of everyone who has applied. And the best candidate of the lot gets the job. You can't quantify what that looks like in advance. I'm excited to see who makes it to the final stage. I already hear early whispers that we got some exceptional applicants in this round. It would be great to help counter the narrative that this industry no longer needs juniors. That's simply retarded. However good AI gets, we're always going to need people who know the ins and outs of what the machine comes up with. Maybe not as many, maybe not in the same roles, but it's truly utopian thinking that mankind won't need people capable of vetting the work done by AI in five minutes.
Recently I got a question on formal methods1: how does it help to mathematically model systems when the system requirements are constantly changing? It doesn't make sense to spend a lot of time proving a design works, and then deliver the product and find out it's not at all what the client needs. As the saying goes, the hard part is "building the right thing", not "building the thing right". One possible response: "why write tests"? You shouldn't write tests, especially lots of unit tests ahead of time, if you might just throw them all away when the requirements change. This is a bad response because we all know the difference between writing tests and formal methods: testing is easy and FM is hard. Testing requires low cost for moderate correctness, FM requires high(ish) cost for high correctness. And when requirements are constantly changing, "high(ish) cost" isn't affordable and "high correctness" isn't worthwhile, because a kinda-okay solution that solves a customer's problem is infinitely better than a solid solution that doesn't. But eventually you get something that solves the problem, and what then? Most of us don't work for Google, we can't axe features and products on a whim. If the client is happy with your solution, you are expected to support it. It should work when your customers run into new edge cases, or migrate all their computers to the next OS version, or expand into a market with shoddy internet. It should work when 10x as many customers are using 10x as many features. It should work when you add new features that come into conflict. And just as importantly, it should never stop solving their problem. Canonical example: your feature involves processing requested tasks synchronously. At scale, this doesn't work, so to improve latency you make it asynchronous. Now it's eventually consistent, but your customers were depending on it being always consistent. Now it no longer does what they need, and has stopped solving their problems. Every successful requirement met spawns a new requirement: "keep this working". That requirement is permanent, or close enough to decide our long-term strategy. It takes active investment to keep a feature behaving the same as the world around it changes. (Is this all a pretentious of way of saying "software maintenance is hard?" Maybe!) Phase changes In physics there's a concept of a phase transition. To raise the temperature of a gram of liquid water by 1° C, you have to add 4.184 joules of energy.2 This continues until you raise it to 100°C, then it stops. After you've added two thousand joules to that gram, it suddenly turns into steam. The energy of the system changes continuously but the form, or phase, changes discretely. Software isn't physics but the idea works as a metaphor. A certain architecture handles a certain level of load, and past that you need a new architecture. Or a bunch of similar features are independently hardcoded until the system becomes too messy to understand, you remodel the internals into something unified and extendable. etc etc etc. It's doesn't have to be totally discrete phase transition, but there's definitely a "before" and "after" in the system form. Phase changes tend to lead to more intricacy/complexity in the system, meaning it's likely that a phase change will introduce new bugs into existing behaviors. Take the synchronous vs asynchronous case. A very simple toy model of synchronous updates would be Set(key, val), which updates data[key] to val.3 A model of asynchronous updates would be AsyncSet(key, val, priority) adds a (key, val, priority, server_time()) tuple to a tasks set, and then another process asynchronously pulls a tuple (ordered by highest priority, then earliest time) and calls Set(key, val). Here are some properties the client may need preserved as a requirement: If AsyncSet(key, val, _, _) is called, then eventually db[key] = val (possibly violated if higher-priority tasks keep coming in) If someone calls AsyncSet(key1, val1, low) and then AsyncSet(key2, val2, low), they should see the first update and then the second (linearizability, possibly violated if the requests go to different servers with different clock times) If someone calls AsyncSet(key, val, _) and immediately reads db[key] they should get val (obviously violated, though the client may accept a slightly weaker property) If the new system doesn't satisfy an existing customer requirement, it's prudent to fix the bug before releasing the new system. The customer doesn't notice or care that your system underwent a phase change. They'll just see that one day your product solves their problems, and the next day it suddenly doesn't. This is one of the most common applications of formal methods. Both of those systems, and every one of those properties, is formally specifiable in a specification language. We can then automatically check that the new system satisfies the existing properties, and from there do things like automatically generate test suites. This does take a lot of work, so if your requirements are constantly changing, FM may not be worth the investment. But eventually requirements stop changing, and then you're stuck with them forever. That's where models shine. As always, I'm using formal methods to mean the subdiscipline of formal specification of designs, leaving out the formal verification of code. Mostly because "formal specification" is really awkward to say. ↩ Also called a "calorie". The US "dietary Calorie" is actually a kilocalorie. ↩ This is all directly translatable to a TLA+ specification, I'm just describing it in English to avoid paying the syntax tax ↩
While Stripe is a widely admired company for things like its creation of the Sorbet typer project, I personally think that Stripe’s most interesting strategy work is also among its most subtle: its willingness to significantly prioritize API stability. This strategy is almost invisible externally. Internally, discussions around it were frequent and detailed, but mostly confined to dedicated API design conversations. API stability isn’t just a technical design quirk, it’s a foundational decision in an API-driven business, and I believe it is one of the unsung heroes of Stripe’s business success. 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. Reading this document To apply this strategy, start at the top with Policy. To understand the thinking behind this strategy, read sections in reverse order, starting with Explore. More detail on this structure in Making a readable Engineering Strategy document. Policy & Operation Our policies for managing API changes are: Design for long API lifetime. APIs are not inherently durable. Instead we have to design thoughtfully to ensure they can support change. When designing a new API, build a test application that doesn’t use this API, then migrate to the new API. Consider how integrations might evolve as applications change. Perform these migrations yourself to understand potential friction with your API. Then think about the future changes that we might want to implement on our end. How would those changes impact the API, and how would they impact the application you’ve developed. At this point, take your API to API Review for initial approval as described below. Following that approval, identify a handful of early adopter companies who can place additional pressure on your API design, and test with them before releasing the final, stable API. All new and modified APIs must be approved by API Review. API changes may not be enabled for customers prior to API Review approval. Change requests should be sent to api-review email group. For examples of prior art, review the api-review archive for prior requests and the feedback they received. All requests must include a written proposal. Most requests will be approved asynchronously by a member of API Review. Complex or controversial proposals will require live discussions to ensure API Review members have sufficient context before making a decision. We never deprecate APIs without an unavoidable requirement to do so. Even if it’s technically expensive to maintain support, we incur that support cost. To be explicit, we define API deprecation as any change that would require customers to modify an existing integration. If such a change were to be approved as an exception to this policy, it must first be approved by the API Review, followed by our CEO. One example where we granted an exception was the deprecation of TLS 1.2 support due to PCI compliance obligations. When significant new functionality is required, we add a new API. For example, we created /v1/subscriptions to support those workflows rather than extending /v1/charges to add subscriptions support. With the benefit of hindsight, a good example of this policy in action was the introduction of the Payment Intents APIs to maintain compliance with Europe’s Strong Customer Authentication requirements. Even in that case the charge API continued to work as it did previously, albeit only for non-European Union payments. We manage this policy’s implied technical debt via an API translation layer. We release changed APIs into versions, tracked in our API version changelog. However, we only maintain one implementation internally, which is the implementation of the latest version of the API. On top of that implementation, a series of version transformations are maintained, which allow us to support prior versions without maintaining them directly. While this approach doesn’t eliminate the overhead of supporting multiple API versions, it significantly reduces complexity by enabling us to maintain just a single, modern implementation internally. All API modifications must also update the version transformation layers to allow the new version to coexist peacefully with prior versions. In the future, SDKs may allow us to soften this policy. While a significant number of our customers have direct integrations with our APIs, that number has dropped significantly over time. Instead, most new integrations are performed via one of our official API SDKs. We believe that in the future, it may be possible for us to make more backwards incompatible changes because we can absorb the complexity of migrations into the SDKs we provide. That is certainly not the case yet today. Diagnosis Our diagnosis of the impact on API changes and deprecation on our business is: If you are a small startup composed of mostly engineers, integrating a new payments API seems easy. However, for a small business without dedicated engineers—or a larger enterprise involving numerous stakeholders—handling external API changes can be particularly challenging. Even if this is only marginally true, we’ve modeled the impact of minimizing API changes on long-term revenue growth, and it has a significant impact, unlocking our ability to benefit from other churn reduction work. While we believe API instability directly creates churn, we also believe that API stability directly retains customers by increasing the migration overhead even if they wanted to change providers. Without an API change forcing them to change their integration, we believe that hypergrowth customers are particularly unlikely to change payments API providers absent a concrete motivation like an API change or a payment plan change. We are aware of relatively few companies that provide long-term API stability in general, and particularly few for complex, dynamic areas like payments APIs. We can’t assume that companies that make API changes are ill-informed. Rather it appears that they experience a meaningful technical debt tradeoff between the API provider and API consumers, and aren’t willing to consistently absorb that technical debt internally. Future compliance or security requirements—along the lines of our upgrade from TLS 1.2 to TLS 1.3 for PCI—may necessitate API changes. There may also be new tradeoffs exposed as we enter new markets with their own compliance regimes. However, we have limited ability to predict these changes at this point.
I've been biking in Brooklyn for a few years now! It's hard for me to believe it, but I'm now one of the people other bicyclists ask questions to now. I decided to make a zine that answers the most common of those questions: Bike Brooklyn! is a zine that touches on everything I wish I knew when I started biking in Brooklyn. A lot of this information can be found in other resources, but I wanted to collect it in one place. I hope to update this zine when we get significantly more safe bike infrastructure in Brooklyn and laws change to make streets safer for bicyclists (and everyone) over time, but it's still important to note that each release will reflect a specific snapshot in time of bicycling in Brooklyn. All text and illustrations in the zine are my own. Thank you to Matt Denys, Geoffrey Thomas, Alex Morano, Saskia Haegens, Vishnu Reddy, Ben Turndorf, Thomas Nayem-Huzij, and Ryan Christman for suggestions for content and help with proofreading. This zine is licensed under the Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International License, so you can copy and distribute this zine for noncommercial purposes in unadapted form as long as you give credit to me. Check out the Bike Brooklyn! zine on the web or download pdfs to read digitally or print here!