Episode 29 | Building an Engineering Team in Japan with Kohsuke Kawaguchi

Kohsuke: Part of the joy of engineering management, or probably just any other enterprise that to try, to try some- somethings that you feel uncomfortable with and get a new experience, lessons, learning, from that. I hope everybody finds some of that wherever they work. And then kinda bring back their collective experience so that we can kinda push, collectively push the envelope in every direction possible.

Narrator: Welcome to developing leadership, the podcast for engineering leaders where Eiso Kant and Jason Warner share the lessons on the ins and outs of managing software teams today we're joined by Kohsuke Kawaguchi, the creator of Jenkins and founder of Launchable, the intelligence platform layer helping teams ship high quality software faster. Kohsuke shared his lessons on building two very different engineering organizations from the ground up, and pulled back the curtain on building tech companies in Japan, fighting uniformity, written cultures and economic viability.

As always, this episode comes with accompanying show notes, with a deep dive into the main topics, mental models and key moments from the episode. Find them at developingleadership.co and linked in the episode description. 

Eiso: Hi, everyone. We're back again with another episode of developing leadership. We have a very special guest with us today, which is Kohsuke Kawaguchi, who is the creator of Jenkins but now also since last couple of years, the founder of his second startup Launchable. Kohsuke, I'm really excited to have you with us. We had a really nice conversation before the podcast. I'd love for you to share with our listeners, a little bit about your background and how got to become an engineering leader.

Kohsuke: Yeah. I grew up in Tokyo. And then when I think I was maybe 20 something, I got this unexpected invitation from Sun Microsystems to come over to the, Bay Area and to work for them. Ever since then, I kinda, was in the US. And then some random turn of events took me to work on the software that you mentioned, Jenkins. And after, the idea of the startup around it, and now this is my my second startup, Launchable. I've been doing it for, I think, a few, close to two years now. 

Eiso: Fantastic. And throughout this journey of yours, I know that you built two very different engineering organizations. The one that you built at CloudBees and the one that you're building now. What are some of the- the main lessons that you learned when you got a second go around at building from scratch?

Kohsuke: The first one was really ... Because the project, opensource project existed first. I was hiring people from there. And back then, I didn't realize, but it create this sudden self selected kinda people, very uniform in certain way, very diverse in another way geographic locations. But because I didn't knew any better, I thought, okay, this engineering team is like this, right? And then the second time around I didn't have opensource project to pull people from. Early on, I tried to hire people the usual way, through my ... Actually, I didn't wanna hire from my network, because that means pulling people away from CloudBees because I wanted it to succeed. 

 So, I tried to hire the easier way, like recruiters in the Bay Area, et cetera. And I just couldn't find any people, any good people at a reasonable price. It, 'cause now we're talking past a year, so I mean.

 And that's when I thought, "okay, actually, I need a pool of people who the rest of the tech community is not tapping into, because it's invisible to them." Because I have a, strong affinity and relationship, and that's the engineering team over in Japan. I talked to my co-founder and said, " look, we've been spending, half a year, six figure, not turning great candidates and closing pool halfing us let me build the engineering team over there, I know the people." that kind of turned into, partly my passion project, turned into what I think are the really, sensible decisions that I wanna encourage other people. That's why I wanted to, talk to you.

Eiso: Yeah. That's super interesting. Currently, the entire engineering team is based out of Japan?

Kohsuke: Yeah. I have one guy who's actually originally from Japan, living here.

 He's ex-Googler. And then so he acts as, together with me, a bridge, 'cause all the rest of the corporate functions isn't here. Like most notably the sales and product management. But then, entire engineering team is over there. In fact, they're- they're pretty much all in Tokyo, where everything, every action is. And then we use those key connections, like a guy over here to bridge those gaps.

Eiso: To me it's fascinating, you- you, do you end up finding yourself at two different cultures within the company?

Kohsuke: Yeah, the thing I- I think I'm probably used to this idea of different cultures within the company. The, famously the sales and the engineering have the entire different culture, right? Sales kick off, and they get together in Las Vegas, they can sing and dance and let's hope that everybody comes back home all and then engineering, right? "Okay, what's the cheapest way to have these meetups, 'cause we need to save company money." I think there's already different cultures. I just added in this new endeavor. I just added a different dimension. 

Except, I did notice after building a team over there, that, this particular team that I built there feels very different from the engineering team that I built at CloudBees or the one in the Jenkins project. And I probably shouldn't over generalize every Japanese engineer is like this or that. But but I'd like to think it's so- some that is, tied to what I think of the typical culture norm.

Yeah, so in that sense it's unique. And in some sense, I think, those, seeing those differences and understanding other people, it's kinda the key joy in working in your team, right? I really appreciate that angle, that I'm experiencing right now.

Jason: I'm curious, how often do you get over to Japan, then? Or someone else on the team, maybe product managers get over to Japan? How do you- how do you make this work? And obviously, Eiso and I have done this ourselves in various different constructs, GitHub was distributed and remote, Heroku was distributed and remote, and then Canonical was very distributed and remote.

 And I lived in Australia when I was doing it. But it required a lot of travel. And I'm curious how you manage that.

Kohsuke: At CloudBees, we are used to, periodically getting together. For all sorts of reasons, like building the actual human relationship, keeping so many things, et cetera, et cetera. But as we were planning this first get together of the company, this was actually we built engineering team, but, COVID happened, and then all the trouble disappeared. For the entire two years, we were not meeting in person at all.

That was not something I planned, but, like everybody else, we can kinda survived. and then finally, we had everybody came together, I think th- this May. So that was obviously a very happy moment for everybody-

Jason: What's your perception of productivity during the COVID times versus the non-COVID times, when you could get together physically?

Kohsuke: I think, we- we probably did need to lean more on the written down, cataract of things. Basically writing that, okay, this is how we work. Like, more explicitly written down, than my previous company at the similar stage.

 That Was helpful. We also created more, so like a forced social opportunity. We have this thing called Rocket View Day, like every once a month we do some crazy stuff. Those things did help. And I think relying on those was helpful. But productivity, I ... oh, it's ... I'm still talking about just one team. I'm not, I wasn't too worried about it. It wasn't yeah, I wasn't too worried . About that. If anything, I felt comfortable with the quality of the people who I was able to hire. 

Jason: Yeah. Obviously it's in the zeitgeist now as conversation, where people talk about hybrid, remote or in person and- and all those sorts of things, and I think all of us have various different views on that. And I- I'm curious 'cause you- you've been running it bec- but, I largely kinda fall down on the side of the fence where hybrid and remote is something that is incredibly advantageous for people to use, but don't expect it to work exactly like you would if you were running a team that was in-office. And that's where major failings tend to happen, is people think Well I do this in the office, therefore it doesn't scale and doesn't work with remote. It's well, no, it's different. It's opposite. you know You gotta do X, Y, Z more, as opposed to A, B, C.

I think when people are in, running engineering teams too, it's easier to do this remote, because engineers tend to like being- you know, either a more quiet time and all that and they prefer written communications as opposed to many meetings or water cooler and all that sorta stuff. 

Kohsuke: I mean, if anything, come to think of it, I have never managed a local team. Probably, I- I'm sure if somebody is more used to that mode of operations, this, doing things remote will feel foreign and then that's because of, that- that alone is maybe enough of a reason to differentiate them. 

At some there's a, which is where I was before, there's a different line of exper- they d- they did have an office and large concentrations of people. One in the West Coast and the other in the East Coast. Then there are, like, you know, sprinkle of people remote.

And that did, created a challenge for this, sprinkles. That was something I was, sometimes con- intentionally trying to avoid ...

Jason: That model right there is actually the one I think is the least successful for the remote people. And the people who can manage that in the remote context are usually the super seniors. The people who are well embedded inside the company or just very senior themselves. 

But, I've seen people try to do that with an office in San Francisco and an office in North Carolina, and then randomly hire an intern in Austin. I'm like, "now, of course, that person is going to have a really hard time being successful. They don't even know how to work, they don't even know themselves yet, let alone, working remote in a company they don't understand."

Kohsuke: Yeah. In some sense, I think these general la- layer of the company's probably not something most engineering leaders can control, you kinda gotta play the hands you're dealt with.

 Yeah.

 But I'm saying like, if you are in this remote side of the company or if you're building some, engineering work from scratch, I feel like the world has moved a little bit more in that favor, in part because of the pandemic, but also because, other services like, global what is a professional employment organization, like people who make the payroll easier or stuff like that.

 Yeah.

 Yeah, I feel like the, that- that progress in that area probably, three decades that I've been in the space.

Eiso: Kohsuke, you mentioned something about three or four minutes ago about the fact that you started seeing differences in the organization you've now built, engineering org entirely in Japan, first the one that you previously built, which was global and remote, could you double click a bit on that and- and dive into some of the differences that you- you spotted?

Kohsuke: At- at companies where I built this initial side of people from a talent in the opensource project, and maybe it's because also because how the Jenkins project is structured, where basically everybody get their own sandbox called plugin and they get to basically dictate their own space. That could be almost socially encouraged isolation or responsibility, and people have added in their own space to minimize the collaboration if anything. That might feel counterproductive with actually work globally if you did everything around that notion.

The people they are, like, really strong individually capable they can, that can move therefore forward, but they are also sometimes less cognizant of the team dynamics behaviors for catching like what- what bone needs to be picked up in the context of the team. 

And this team in Tokyo almost feels like a polar opposite. Everybody comes in they're all, have prior work experience, coming pre-wired that sort of eyeballs not just looking at their own individual work, but what needs to be done in the team.

And I was really astonished that, "oh, okay this, there are these other kinds of engineers that exist" and they, without me saying anything, they organize like a monthly retrospect and figure out, like, how to make the team stronger. And one guy points out the challenge that other guy is having. Yeah, that- that never happened at Cloudbees, so I was really just awestruck. Those are the kinda key difference, I think.

Eiso: Do you think, without of course overgeneralizing, but do you think there is a- a cultural component here? Japan is known for its team harmony and-

 Yeah.

 ... Do you think there's something that- that is here that falls within that?

Kohsuke: Yeah, that, I- I wonder about that. I'm assuming that's part of it. I think that another part of it is maybe because the, unlike in the US where there's lots of population centers, so there is some level of distribution that's going on, in Tokyo in Japan everything basically is in Tokyo. Everybody in the tech community basically lives in a, like a, a 50 miles radius.

Perhaps that created some, like a closer tie within the group. Or maybe because a larger part of the soft- the tech ecosystem is actually system integration and vendor building the systems. They are the high- ... The, a lot of attention, they are wanting to, forming a team with short notice from a pool of people delivering a project for the client, working is now next part that is a business owner, therefore, that's not a standard mode of operation here, right? We are building, we are, most of us are working this, like ISVs and building the finer products.

Maybe that- that focus on created, and maybe that created a lot of attention around teams working together and making the effort visible, that- that sort of things.

Jason: We'll slip around a little bit and say you can go back and do CloudBees again you've learned a lot of stuff, you've- you've built a team over, it's your second company, so obviously you've learned a bunch of stuff, but you've built a team in Japan and maybe you've changed your mind on a couple of different things. Are there anything that you would wanna go do different when you're redoing CloudBees? Or maybe generalize it out and say, preconceived notions that you had before that you would want to, correct this time around.

Kohsuke: Yeah I think the one thing that I became more aware is, there's always some uniformity, or like a lack of diversity in some aspects. And almost by definition, when you're lacking it, you can't see that it exists. Like you cannot see the light and instead, you tend to be happy with that Anglo-diversity that you already have. So, in the case of like a CloudBees, like, I was very happy that I'm attracting people from around the world, and they do bring different experience and the- the mode of work in general. The way they carry themselves, and loved it. but in- in retrospect, like, all of them are pretty much all of them in the beginning are male and like I mentioned . They are more geared toward the their hard- hard coding skills, software engineering skills, and less about the team, team soft skills. And then when we interview people based on the people you already have, and when they are the one that's deciding who come in scene and who is not, they tend to self select themselves.

It became difficult, it kinda self created this organization or these people where different kind of people would be, would have a harder time thriving. That's something, I think, I'd probably do differently if that makes sense, I don't know.

Jason: Yeah, it does. And it, what that generalizes out to too, is that there's, have to be intentional, I think, in a lot of cases. Because what you said is also true, which is I see this a lot in the States, and in particular which is people say, hey, they they want diversity, and what they mean by that is, gender or demographic diversity, but the point being that you have one version of one, the you were more intentional about another, you had to be intentional about this. 

It's the flip side of that too is, you could literally have a 50/50, woman to man ratio inside your office, but it could all be within a two block radius of each other.

 Well, that's, you're happy on one dimension, but you're failing on another, you gotta be intentional about those as well.

Kohsuke: Exactly, yeah. That's exactly. I felt, okay engineering in Japan for most people is probably entirely new territory, maybe outside of the Ruby inventor. You probably don't know anybody. There is a, a diversity access that you could exploit.

Eiso: And- and for you right now you said there's- there's very few Silicon Valley based companies, this entire team, from startup is in Japan. What are some of the advantages that it's given you and what are some of the parts that you say, okay, that builds us some struggles? Or I expect expect issues to come up over time.

Kohsuke: Yeah. From business perspective, I think it's finally the, the value per cost, right, the people there. Because it- it's like a blue ocean no recruiting for almost no recruiting for, from the US tech companies are done over there. You have a lot of people, like a talent that are available cheap. And it helps that the yen is getting cheaper. And two, because everybody there is very well connected. When you hire, when you start hiring a few people, the words of mouth, I wanna bring other gre- great people, and I always felt that the, initially you're building anything is, that's always surefire way of getting high quality people. They're also very eager to learn, I think, there are lots of ... 

I think I see this in San Francisco and New York almost every day, some meetup is happening. People are curious about what's going on elsewhere. They have a, they could just walk down a block to attend these things and get to know other friends. They- they, they- they participate in these extra work activities at the at the level that I, I didn't have, I didn't see in the US. Those are I think all good things that's going for them. But a key challenge obviously is, I think, is the timezone and language. Especially, at CloudBees our first remote hire was in Europe. I think it's probably true in many, m- most of the US companies you start here and then you grow over to Europe, and that cover a sudden timezone band, and that makes it painful to add Asia, right?

And language wise, the Japanese is quite far away from the, from English. That creates a challenge on its own. Fluency there is definitely worse than, compared to, let's say, East European countries, where, people there speak fluent English at the native speaking level. I can't say the same thing. The way I bridge those two things is you kinda relying on writing culture. I mentioned already about, maybe like a little bit from a process heavy like identifying like this is how we work more explicitly. Here's how you're gonna write the engineering document, here's how you plan this monthly-

and so long as people know how to do work and how other people behave, it makes it easier. And then that's not just about the Japanese team. I think it's true with any engineering team, but-

Jason: Interestingly, that's very similar to how opensource tends to work too.

 Which is, opensource, because people have been geographically dispersed throughout the world timezones have been a challenge, but too languages, like fluency has always been a challenge, and so a lotta opensource relies on, as you've, we all know here, 'cause we all have various degrees of opensource experience, English is the primary language for heavy written docs, and yeah some teams, some opensource teams might actually get together individually once in a while, but for the most part, they try to do everything out and written in the open. and I think again th- those are lessons that we could all learn, 'cause our building our organizations that grow over time. you know, how opensource has already done this for 25 years or so.

Kohsuke: And another thing, this working mode and speaking of opensource that is great that is happening is part time resource, right? Somebody not working for full time. Maybe they have a easier time if more things are written and the more clear expectations on how they should behave. That's something, I think, about. If you could tap part-time resources then maybe it'll make it easier to access the other kind of talents. 

Eiso: You mentioned the language barrier. do you think that, because there is a language barrier, it has remained like a blue ocean? Because, like you said, you mentioned Eastern Europe, which is, most European tech companies and a lot of American tech companies will have talent remote these days, and Eastern European companies, without almost any barrier because English is- is commonly spoken. 

Kohsuke: Yeah and then, that- that's also why this is a important passion project for me, that, used to be that country was a at one point, I it wasn't crazy idea to perceive that they might become like a, know, like the most dominant nation in terms of GDP. I remember the book called Japan as number one, that was, what, 40 years ago? Now it's nothing like that, right? It's the company, and countries, still I think maybe forcing the GDP scale. But it's slowly declining. And then people there, I feel like, the, as a country, for, to be viable, they need to develop a stronger tie to the rest of the world, is how I feel.

 I do feel some, like roots over there, so I wanted to do what I can help and, to me, that's building like- like a more bridge between two sides of the ocean. And I do, like- removing any obstacle is this I think is also economically viable endeavor. But if it's just a social philanthropy, then I can't do it, right? But if this is a economically viable thing then- then that's a different story. I'm trying to pitch it like that. 

But, you're right. I think that what comes the key obstacle there is language, there's no doubt about it. And I- I don't see how to change that. I do see more and more companies over there switching to English as a internal language of the company. There is more interest among people across the board to learn English and get better at it. And they see especially the engineers see more job opportunities overseas. I feel like it's a, it's a challenge but it's moving in a better direction.

Eiso: Has the engineering Jason and I often talk about the trends that we see in engineering either, on- on tooling, popularity of programming languages leadership practices, Agile Dev, all of the ones that we've seen. I know if we, for instance, I have a bit of experience, with China. and that some of those things have gone in different directions because it- it's a country that has its own language ecosystem.

 Since Japan is- is so oriented on its own language, do you see any things that differ in terms of either how engineering works are run or tooling or anything that is has gone its own way because it's- it's built up its own bubble within its own language? 

Kohsuke: Yeah, I do feel like there's some different idiosyncrasies in the tech stack, especially in established business, tech business over there, perhaps like more use of Ruby, understandably, but even here, I think, the, if you go to the federal space, you see a lot of Java projects and older system integrated [inaudible 00:26:31] more proven stacks that's a dedicated builder, th- that's different from what the Silicon Valley startups tend to do. Definitely that exists. Which for me was less of a problem because, I, before I built the team, I was the only one who was writing the code.

So they could kinda take it and adapt it. I wonder if you're trying to, if you're trying to build one more team establish the product or, and- and you're trying to hire people who come in day one and productive is the stack. Actually, I- I'm curious, does it always work in the ... come to think of it, even at CloudBees, you don't always ... it's kinda difficult to people ... How much value do people place on engineers with prior experience in the tech stack you're currently using?

Jason:  I can speak to that a little bit, because I think that I think tech stack matters when you have less of an track record. Track record starts to matter more when you can point to it and you can say "Here's how I would do that in this tech stack," or whatever. And then, also, there's a difference between front end engineers or application engineers versus infrastructure engineers, which tend to be more adaptable on new technologies and, whatever it is. 

That said, it's still a burden, to bring somebody in who doesn't have the tech stack experience. And I can speak to this locally, I live in Victoria, British Columbia in Canada. And it's the capital of the providence, a province of British Columbia but the biggest employer, here from a tech perspective, is the local government, which uses decades old Java technology. 

When people say, "Hey, we wanna get into burgeoning startup scene here in Victoria," and we say, "We have all these programmers," I- I'm quick to correct them. I say, "No, we don't." We have legacy systems integrators who are employed by the federal government. We don't have, a large pool of developers who are, can be in a startup at the moment.

They might be able to be in a startup a year from now if we employ them in a startup and we get them speed on, the Pythons, the Rubies, the Nodes, the Elixirs, the Rusts, the whatevers of the world, but using Java XML, J2EE, blah, blah, blahs and all that sort of stuff, they're- they're not ready for a startup right now. 

So I think that there's- there's always a gap. There's always a gap if someone's, working for a federal government or something, some entity that looks tat way from a legacy perspective and trying to jump over to a stack that looks like this.

 And it's easier to jump if the more senior someone is but still has a very agile mind and they could work on backend systems. But it's- it's a struggle.

Kohsuke: The similar kinda difference that I realize is if they're used to work for a packaged software company there shipping is a rare event and like a big event- that creates a different kinda mindset and culture from service company. And those things are they do fundamentally affect the design choices you make, so.

Jason:  It's funny you mention that because it's not directly, it's like, it's not Java that would lead you to believe that, but Java's ecosystem tends to be more packaged, even these days still, it's like- "Hey, we're gonna release that in three months, and we're gonna release the war in upgraded the systems and blah, blah, blah," and you're like, "no, we don't work that way anymore. We release 200 times a day," and you know, this is the, Jenkins and stuff like that, a lot of people just don't think that way still. Again, this goes to my point about mindset. You know, and people have a different type of mindset, they can adapt and they can jump over, but if they don't, they're gonna be stuck in their legacy worlds. 

Eiso: Kohsuke, one of the things that I'm still trying to wrap my head around, and staying curious about is, you're building an early stage startup. One of the main things that you wanna do is have your early engineering team as product minded and as customer oriented as possible.

 But, from what I know about your customer base, and kind of language and geography, it's entirely different from a Japanese speaking, Japanese oriented engineering team. How are you bridging that gap and how are you getting the things back to the engineers, to have them in that mindset? Or do you not at all? Or I'm just curious to Yeah. Hear how you tackle that challenge.

Kohsuke: Right. I think the two ... Interestingly, even at CloudBees, the engineers weren't they didn't, or maybe the particular team that I had, they don't seem to be interested in they're actually talking to customers, I felt like, maybe it's because we're building the developer product, I think perhaps there's more assumption, which is incorrect, but more assumption that, hey, that having the target user of what I'm building I'm gonna build what I need. But so maybe there are a little bit of that.

Anyhow, in this run the- the two things I, like I intentionally co- that- that really helped, one is the leadership trying to communicate the sales and product landscape more for the engineers. We- we become like the broadcasting channel. And that, works well with the written c- together with the written culture. And two, we started recording these customer calls and sales calls. And then there's a software that- that could basically transcribe them, you can use the keyword search, the- the PM can use a keyword search to kinda zero in on the product conversations that prospects are having, that's relevant to what they're working on.

And I find that's very useful for engineering. Some of the tech improvements have happened over a decade is really helping. And if anything, this team is far more eager to know how their stuff is getting used. Maybe going back to that more cognizant of what's happening elsewhere.

Eiso: I- know you're- you're very passionate about Japan and- and wanting to develop Japan, as- a- as a tech scene. Is it possible for a foreigner, a non-Japanese speaker to go to Japan and build a tech company? Or to build an engineering team in Japan? Is it something that's feasible today? Or is it something right now only accessible to people who have the ability to speak Japanese and maybe are- are from there, have a- a deep understanding of the culture and language?

Kohsuke: I- I think it's definitely possible. it's probably harder for somebody else with no ties to do it than, let's say, I was able to. this was in- in some sense, it's a little bit of, a dealing, like a, play with the hands that you're dealt with for me. What is my heritage? Maybe that was the ... but I do think it's, I do think it's, it's possible. And- and because this is my passion, I'm happy to help, I was looking to my fellow CEO and he- he had one of his engineer wanted to kinda move to Japan, because I guess he was fascinated with the culture and yeah, so that led to a conversation like that, and, If a few more people built more bridges and, we- we talk about this more, like- like, we are doing right now, then it gets even more easier. I'm looking for opportunity to help anyway I can, really. 

Jason: One of the things you said earlier that I definitely agree with, by the way, is, whenever you have a passion project or, s- something more socially minded, philanthropically minded, and I'm- I'm putting this in that same bucket, you wanna help Japan, you wanna think about this as a longterm mission of yours. The best way to get that done is to sell success.

 And to have success in the thing that you're doing. And I think that's something that's lost on people, as they say, "Hey, I wanna get this done, I'm gonna use my company to get it done," but really, the best way to do that is to have that company be massively successful.

 And then there's a whole economic flywheel, but there's also- even more importantly, it stops the questions. Which is, if it could be done, it would've been done, and you've gotta answer that question.

 A good example of this I think is- is, in Canada, people talk about Canada can't be a high tech, country. And then Shopify happened. And people no, don't lo- no longer talk about that as Canada can't be a high tech company, they talk about specific cities can't be high tech cities anymore. 

And it's- it's the natural evolution of that. But it was so critically important for Canada that Shopify be successful, somebody be successful. I wish you luck in this because I think it's important, but I also want listeners to this, to not be lost. You can't push your social thing forward, it has to bec- it has to come be a success. That's how you're going to be able to do that.

Kohsuke: Yeah. Yeah, and- and- to that, and that's what I mean by economic viability. You know, just because something is a good idea, you can't do it. It has to be actually a positive movement in a business. yeah. in some sense I recognize that the onus is on me- but I so far was able to justify it . And actually, on that point, there's another company who I modeled this after, it is called Treasure Data. And they, I think- they were acquired by, on, couple of years ago, I think more than a billion dollars. Their entire team is, building engineering team is- is in Japan. I- I should probably get them to talk more about how they do things. that's probably your next engineering leader you should talk to. 

Eiso: We can help you, right? there's engineering leaders listening to this right now or watching it on YouTube. And, or maybe founding engineering leaders, and they might be passionate about either moving to Japan or building something in Japan. Where do they start? Besides writing you. 

Jason: Yeah, besides your careers page.

Kohsuke: Yes, so- so, please do- do write to me. Happy to help. And I- I'm- I- I'm thinking about it I wanted to create some place for that. I need to talk more about these things and then collect the- the resources. And ideally that could build a community of people who are trying this. Could be as simple as a- a mailing list or some- some discussion forum like that. Yeah, I ... Hoping to get that going at some point, but not yet.

Eiso: And when someone sends you that email, and says, "Hey, I'm looking to build an engineering team in Japan, I'm a startup founder I've no idea where to start," what's the first thing that you would write them back?

Kohsuke: I think I'm gonna forward this a PDF that the Japanese, Tokyo's government build about, saw this program. And where we- we make an intro ... I'd probably get on the phone and tell- tell them my story. 

 And yeah, kinda go from there. You need somebody, you need to be able to find some guys that, who are resonate with your company's mission. Or become, basically become the forefront of engineers. They are finding some influence or, but they are too that you could have interviewees and so it's things like that, I think, it's helpful. 

Eiso: Since you're one of the very few people who has this as their passion, and- and yeah, now we expect you to build a $10 billion company to put Japan even more on the map for- for us engineering orgs. I- I do really appreciate you talking with us about it, because it's ... to many of us it's a black box, and you opened it up a little bit today, and showed that it's possible. And one of the things that I loved that you shared is that, you- you found a team there that has this incredible team collaboration oriented mindset and- and that's helping you guys, as- as an early stage company. Is there anything else that you'd like to leave our- our listeners as- as parting words as they think about this topic?

Kohsuke: I think there's, part of the joy of engineering management or probably just any o- any other enterprise to try some- some things that you feel uncomfortable with and get new experience lessons learning from that. And to me one of that is this. But I hope everybody finds some of that in wherever they work, and then kinda bring back their collective experience so that we can kinda push, collectively push the envelope in every direction possible. Yeah, that- that'd be my call to action for everyone, push the envelope.

Eiso: I appreciate that. Thank you so much, Kohsuke. It's been a pleasure to have you on today, and yeah, we really look forward to seeing how the journey continues. There's a- a heavy burden on you now to put Japan on the map.

Kohsuke: Thank you.