Following an unusual career path: from dev to CEO

Full transcript

Neal: Hello. Welcome to the Thoughtworks Technology Podcast. I am one of your regular hosts, Neal Ford, and I'm joined today by another of our regular hosts, Prem.

Prem: Hi, Neal and Guo. I've been a long-term ThoughtWorker as well, being a developer. Now, these days, I lead our Western Canada markets. I play the role of tech director.

Neal: Today, we're joined by a special guest. We occasionally do a series of a podcast that we call Thoughtworker Journey Podcast where we take a Thoughtworker who has been on an interesting career trajectory before, and especially during Thoughtworks. Today, we have-- we always say this but we keep upping the ante. Today, we have perhaps, one of the most interesting career tales from Thoughtworks, which is Guo Xiao, who is currently the CEO of Thoughtworks, but started here as a developer. Welcome.

Xiao: Thank you, Neal. Thank you, Prem. It's a pleasure. It's a privilege to be on the Technology Podcast. [chuckles] I haven't been, I think, on any technology podcast for a while. Thank you for having me here.

Neal: We happen to know that you are deep down, a serious technologist, and one of the very few, I think CEOs who started life as a developer. If you could-- We have a lot of new people at Thoughtworks who probably don't know how you got to where you are now. If you could give us a brief overview of your tenure at Thoughtworks, how you came to be here and what you've done since you joined.

Xiao: Sure. Happy to do that. I still think I'm a developer today. It's just that I don't have anything in production anymore, or Thoughworks don't allow me to do that anymore. I joined a long time ago. It was 1999. I just graduated from school. I was attending a job fair, a campus job fair at Northwestern University. Believe it or not, I was walking around. There were long lines. I remember Microsoft, IBM, some of the other big names at the time, at the event. I was a-- I'm still an introvert, so I don't really like big crowds. I went to the end of the line. There's a booth with no people in front of it. It's called Thoughtworks. [chuckles] That's how I stumbled upon the company.

I do remember clearly, there was a couple, very much of a geek-looking people at the booth. I asked them, "So, what do you do?" I tried to start a conversation. Then one guy said, "We solve very complex technical problems." I was intrigued because I was always and I'm still a problem solver. I like solving hard problems, complex problems. I went through the process. It was very short at the time, by the way. It was just less than a day. [chuckles] I did the logic test. I solved the code problem, went through a couple of interviews and got an offer, and then joined the company. That's how I started my career at Thoughtworks, my first job, and then my only job so far.

Neal: [laughs] That's also amazing that it's been your only job. How long were you a developer before you moved into non-developer roles?

Xiao: Not too long. I think I was probably seven, eight years doing coding work, hardcore coding work, then after that, I remember I was going to help to set up the China office at the time, and went there. Started doing a lot of non-technical work, whether it's getting files filed with the local authority or talking to customers, or looking after the front door, from a security perspective. I did a lot. [laughs] That's how my career started to deviate from technology.

Neal: Of course, now, you are currently the CEO.

Xiao: Believe it or not, it's a long journey but it's also an amazing journey. I'm still very happy, the fact that-- I remember the first interview I had, after such a long time, we're still solving very complex technical problems. I do enjoy working with people who enjoy doing that. It's a privilege to be around, then actually supporting the company in a different way than I did before.

Neal: 1999, give us an idea about how big Thoughtworks was back in 1999 when you joined.

Xiao: It was pretty small. I think it was mainly the Chicago office. Most people were in Chicago. We had about 100 people, perhaps a little less. That's when I joined. I think we had two major projects at the time.

Neal: [chuckles]

Xiao: Just two.

Neal: Now, was that before we had adopted agile practices or about the time that we had started doing agile? A lot of people don't realize this. We started out really as a company that specialized in leasing systems and leasing software. That was some of the early stuff was leasing stuff, right?

Xiao: That was. Then that was also-- my first project was a leasing project as well. About the time we started agile, there was no agile at the time, 1999. It was only extreme programming, I think Scrum, DSDM, and a few other methodologies. It was definitely an interesting time when I joined that the project, actually, I started with, was the one that we decided to use extreme programming. It was a leasing application but building Java. It was a rewrite of info lease in Java. When I joined the project, it was already 12 months along the way, and lots of documentations, no working software, then six months left to deliver. That sound familiar?

Neal: [laughs]

Xiao: What happened, we had some really good people on the project. If you remember, Pramod was on it, David Rice, Paul Julius, Matt Femel. Obviously know what's happening in the industry, especially around extreme programming. They recommended that we should forget about the project management process we've done, we've used it before. Now, we're desperate. Let's just try extreme programming, because there's a guarantee that I can deliver some software at the end of the process. That's how I think we did it, honestly, out of desperation, than anything else.

Neal: [laughs]

Xiao: If we don't deliver that project, it was 670 seven people project at the time, half of the tower's business will be screwed. We had no choice. I think that's when we got Martin Fowler and Ward Cunningham to join the project as a consultant. That's before Martin joined Thoughtworks. He was a consultant to that particular specific project, to teach us how to do TDD, pair programming, refactoring, [chuckles] continuous integration. The most important thing, he turned it into development, so we can write software instead of documentations.

Neal: 1999 is two years before the Agile Manifesto was created. That really is the very early days when it was still in its infancy. You mentioned briefly there, that means that-- I don't know how many people still realize the significance of the Ward number, but you've actually paired programmed with Ward Cunningham, right? That used to be a big badge of honor in the agile world, that you've actually paired with the Ward. Your Ward number is one. [chuckles]

Xiao: I did. My Ward number is still one. It was a fascinating experience, I have to say. I was, I guess, two years out of school at the time, very junior, and Ward joined. He just had this very unassuming personality. He clearly knows a lot about coding, but he would not just dictate the pace of the pair-- we actually did pair, the programming process, or even try to come up with a solution. Every time we have a big problem, especially the one that I remember clearly, his starting point is always, let's try some test. I remember this problem we were trying to solve at the time was to roll back state. It's a swing-based reach-client. It's J2EE. Then we had a lot of operations being done on the reach-client.

Then at a certain point, the customer wants to undo something. We have to store the state of the objects in memory so we can roll it back or in the database, if we can store it there. I was trying to come up with all the clever schemes on how to save the projects, save the objects, the states into some memory. We all just said, let's write a test. We started a simple test. Then he asked, "What's the simplest thing you can think of to just make the test pass?" I thought about it, it was J2EE. We could just serialize the session beings, which we did, and that was a solution. [laughs] Nothing fancy. It was so simple. Fascinating experience working with Ward.

Prem: Did the project deliver after six months? You said you had been 12 months in and you had six months to go. What happened in the end?

Xiao: It did. Believe it or not. We did one-month iterations. At the time, we were far from being able to do two weeks or even one-week iterations. We did a one-month iteration. Then Simon, believe it or not, he claimed to be the first ever iteration manager of the whole industry. I remember we have 60 people sitting in the room doing iteration planning meeting to kick it off. We did six of them, then we delivered software at the end. Well, it's basic but it worked, then we then continued to work on top of that.

Neal: I don't think people can really picture how it's like doing continuous integration without continuous integration servers, because those hadn't been invented yet. [laughs]

Guo: Since you mentioned that, that's actually where the tool itself, CruiseControl, was inspired, through the experience we had on this project. Obviously, Martin and others recommended us to do a bit compile every once a while of everything, and then run the test, to make sure they all work, everything checking the same source code, so we had to come up with a script. I think it was end at the time, the end script to run it. Maybe even before that, I can't remember. We called it Jinx, [chuckles] it's the name of the script. You can imagine, every two hours or so, it was Matt Famel job.

He would just walk around. We were all on the same floor, walk around the office and say, "We're going to jinx it. We're going to jinx it. Everyone, stop checking code. We're going to jinx it," [chuckles] because you have to stop checking code, then be able to do the compile. I think that's how the script's getting more and more complicated. Okay, we can automate that, then we can just get a version, even someone checking code, we don't have to really check on now, we can use a timestamp. Before we know it, that script blew into something that became a predecessor of CruiseControl. I think Paul Julius did something similar on the other project and it ended up building this tool called CruiseControl. That's how it was born.

Prem: What were you doing for your testing? I don't know if J-unit was born at that time.

Xiao: I honestly can't remember, but there was a tool we used. There was a tool we used to to run-- I think it was J-unit, but I can't remember, or maybe something else, but we did a lot of testing, for sure.

Neal: Yes, I think J-unit is pretty old. It could very well be J-unit because it seems like it's been around for a long-- I can't remember anything before J-unit. [laughs] I'm struggling to remember anything before it as well, so I guess [crosstalk]

Xiao: Yes, it's been too long, but I'm sure Google knows.

Neal: Yes, I'm sure. [laughs]

Prem: What was your-- I guess this project was successful and now, you've also probably established yourself as one of those people who was part of this successful project, so tell us more about your journey from there. How does one go from being a developer on a team to six, seven years later, taking on a completely different road?

Xiao: I wish I had stayed on the technology journey [chuckles] and then not taking on other roles, but I remember, yes, I was having fun. I was doing a lot of work on J2EE, then .NET came out around the same time. I think because of our reputation, Martin's reputation and our experience with large scale J2EE project, we actually were asked to go to Redmond and join a Microsoft team to help to come up with enterprise application patterns for .NET platform using similar concepts like OR mapping, other things, for example. There was no Hibernate yet. I moved on to the .NET platform, then later, did a lot of browser based programming as well. I was really having fun, having a good time being a developer.

I think it was more or less the responsibility gene that pushed me to do other things. Like I said earlier, I went to China to help to start our office, and there was no one. I think it was Penny and myself, just two people going around, trying to do everything, hire people, sell projects. We were not doing global delivery at the time. We were actually just doing project for local customers; HR, Finance. You can imagine all the things that need to be done. I just ended up picking up a lot of stuff in my spare time, or sometimes, when I'm not on projects. Slowly but steadily, we got to the point that we have much bigger scale, we need people doing that full time. Then Syd was leaving as well.

That's after two years in China, he went back to the US. I remember clearly, looking for other candidates who can be a general manager for the office. Then I spent six months interviewing people, then just couldn't find anyone that we were happy with. I think it was Roy at the time, looked at me and said, "Xiao, stop trying, just be the general manager yourself." [laughs] That's how I took on the role. Yes, it was more of a responsibility than out of anything else. I didn't want to do it in the first place.

Neal: In your technology role, what was the-- I usually ask people who have had a long career in technology, the peer question, what was your proudest moment from an implementation standpoint, and what was your biggest dumpster fire from a project standpoint?

Xiao: Well, I wish I had more examples I can show off, but it was not long enough. I can only probably remember a couple things along that line. One I'm probably more proud of is the OR mapping tool we built for J2EE. That was before Hibernate. We had a unit of work architecture that captured the OR mapping mechanism. Then it was me and another person who were working on that specific component at the time. I was just right out of school. Didn't have a lot of experience and I was working on something pretty critical and new for a large scale project at the time, so I was definitely having a good time. I don't think I would get a similar opportunity elsewhere, but I think the industry was just brand new at the time.

Then Towers took a lot of risk, asked me to do things like that. I think we did it very well. Later, once we moved to .NET, I was trying to port that code to a .NET platform, but didn't get too far until I realized Erik Dörnenburg was doing something similar. We merged the code, then he outsourced it, called NEO, N-E-O. That was the early day OR mapping tool for .NET. I was pretty proud of that, happy with that.

Prem: Yes, actually, now that you remind me, I joined Thoughtworks in 2002. I remember using that OR mapping tool, but not just on one project, on two projects. When I started at Thoughtworks, I had never done Java programming before, so I remember being completely blown away that somebody could actually write that kind of software as part of a project that they did, so it was really a big aha moment for me when I joined Thoughtworks.

Xiao: Well, that's great. You should thank Erik Dörnenburg. He did most of the work. We definitely discussed, then tried to merge the ideas together. It's very similar architecture. Then speaking of .NET, that's probably where Neal, to your question, where I struggled most with in my career being a developer. It was also early days when .NET just came out. I remember literally getting on a plane to London to join project, a .NET project, to be the tech lead and was thrown a book, "Read this," [laughs] on the plane. No one knows how to do that, so I definitely don't think it's a lack of training. It's just it was brand new.

I was intrigued by this .NET remoting concept. I thought that's interesting. It was new. It doesn't, I think, use the standard web-based, browser based protocol. It was another reach-client project, so I used .NET remoting on the project. It turned out, it didn't scale very well. It's the first version, so understandably, there's some limitations to it. I remember having to do a lot of scaffolding around it, trying to cache, trying to download, do asynchronies download, trying to do all things to improve the performance. I think we barely squeezed it through the performance matrix to get it live, but I always feel bad that it's not something that's going to scale in the long run.

Maybe it's different now, but I was feeling bad that I should have-- maybe not. Maybe it is just the price you'd pay when you try out new things and then perhaps, someone would have to re-architecture that, take away the communication component and replace it with something else.

Neal: Yes, building the first one of anything is always interesting. In fact, you may have been around for PicoContainer, which Paul Hammett created, which was the precursor to Spring, which was also an early Thoughtworks project.

Xiao: That's right. I remember it, because I was at UK at the time. I actually remember seeing Paul talking about PicoContainer all the time in our sessions, then the after work conversations.

Neal: One of the questions I also ask people who have had a career that has dealt with technology, but also the non-technology side of software projects, which you've also had your role in, what is your biggest or most recent epiphany about software development, or maybe agile software development in particular, since that's mostly what we do here at Thoughtworks.

Xiao: That's a tough question because I haven't been really technical for a long time. Although, I do a lot of bits and pieces of programming in my spare time. I play with Arduino boards, and then doing some programming, just as a hobby. I haven't done anything, heavy lifting, myself. I think for me, especially in the last, I would say, seven to eight years being the CEO of Thoughtworks, having more of a holistic view of the entire organization, I thought a lot more about the organizational design of Thoughtworks, why it is what it is, why we have a geography-based organization.

Then through having this conversation with Rebecca and others, just ask why do you think we did it this way? I should learn something new. I think there was a hunch since the early days of Thoughtworks. That is, we didn't like how things were done in the industry at the time. That's how we used extreme programming, and then we open-source tools, we did a lot of things that's different to the time. One of the things we didn't like was this verticalization of developers. It's not just an organization, a lot of organizations put their people into vertical structures.

You work on insurance industry, or you're working on retail or financial services, what tends to happen is that people just got used to with a few tech stack, with a few packages, then they specialize in it, then they get very good at it. There's a lot of the reason why people do that. There's a lot of efficiency gain. You can do the same thing 25 times, and you got really fast, really efficient at doing that. I think that where the industry was heading at a time, but we, I think, believed otherwise.

We think that technologists should move from tech stack to tech stack, from vertical to vertical, solve different problems, bring your experience to a different domain, then should continue to learn and become better at solving general problems as opposed to be specific problems. I think I did that myself. I think a lot of Thoughtworkers did that. That's why we organize itself as geography. In the geography, you can work on all kinds of technical problems, or different domains, as opposed to get locked into a certain area. I think recently, I started to realize more and more that the theory behind it is that generalists are generally better at solving problems or being innovative than specialist.

I think it's best captured by this metaphor Kent Beck used a little while back called paint drip people. His main thesis is that the way you develop skillsets should be like a forming paint drip, where you draw a brush across top of the canvas. Then sometimes, when you do it enough, some paint accumulates and a drip starts to roll down. Instead of painting along the drip, you keep painting at the very top until more and more drip start to form, then that's how your specialty gets formed by being a generalist. You can still be a specialist with enough drip forms, but you should keep trying to do different things as opposed to focus too much on a narrow area.

I found that fascinating, and of course, that was probably my biggest aha moment. Aha, that's what we have been doing at Thoughtworks, is training generalists. Then my most recent example of that was the Zhamak Dehghani's data mesh. It's just happened that pre-COVID, my last technical conference was a GOTO conference in Copenhagen. Then Zhamak was there too, I attended her session. She was talking about microservices. It was new at the time, and she was doing a lot of work around it and talking about the architecture, the philosophy behind it. I clearly remember that Zhamak is a microservices architecture specialist.

Then a few years later, she ended up working on a lot of data projects, then ended up applying a similar philosophy to data architecture and come up with this concept called data mesh, which is catching everyone's attention like wildfire at this moment, and her book I believe, is coming out soon. Then when I read the data mesh, I realized, "Oh, it's actually so similar to some of the principles behind microservices." That's when I realized, aha, why Zhamak invented this idea, but not some data specialist, because she was more of a generalist than a specialist and he applied her experience from different domains to solve a problem in a new domain.

That's just another good example to reinforce my belief that generalists are more innovative than specialists. Now, come back to Thoughtworks, obviously, as CEO, at least, I have to articulate why we're doing things a certain way and why it makes sense. I think it does make sense in the long run. We invest more in building people's skills across a wider spectrum of technology, then over time, they actually get more efficient, not at doing the same thing, but at solving new problems. That's how we've become a premium service provider. I think that's why Thoughtworkers have written so many books and open-source software becomes so innovative.

Neal: Yes, I think that's a great example of-- The common advice that you get if you're a primarily a Java developer, then you spend some time in the .NET world, you pick up things from the .NET world that you bring back to Java and you become a more rounded developer because you've seen more EDMs, you've seen more colloquialisms in other languages and you can apply that. I think you're exactly right. That's more broadly applicable across your entire technology portfolio if you're paying attention to how things fit together, which Zhamak is very good at paying attention to how things fit together. She's well suited for that. [chuckles]

One of the interesting things that I've noticed, and you've been around with Thoughtworks and been involved in the business for a long time, that consulting companies tend to move through inflection points around size and geography. I was in a small consulting company and you reach a certain point where your support staff is just enough, but really stretched, and then you hit this point where you add more support staff and you can add more-- For us, it was around 20 people. I've heard around 100 people is one of those, and we've just recently crossed this inflection point of 10,000 people.

Have you noticed a bunch of inflection points like that and are you anticipating the next big inflection point in Thoughtworks' career trajectory?

Xiao: Yes, it's a good question. It's also a difficult question to answer clearly. Like you said, we have found that the most effective community is less than 150 people. There's a term for it. I forgot. What's that?

Neal: Meaningful contacts.

Xiao: That's right. We're 150, 120, we have always built offices at that size. Then when it grows beyond that, then we build a new office in a different city. We have been expanding our footprint in that pattern, in that matter for a while. Prem would remember this clearly. At some point, Bangalore just got a lot bigger; 200 people, 300 people, 400 people, 500 people. What do we do? I think we actually split the office to two. I think the West Bangalore or East Bangalore office.

Then I don't know the details, but somehow, it didn't work out that well, we ended up merging them together, but still, I think in the process, we have always been trying to figure out, how do you build community that people can feel they're part of as a human being. That means that maybe there's all phases of the natural community you can build around when it gets too big. Maybe it's big programs of work, maybe it's practice technology. Maybe it's other different ways of organizing. I think we're being learning how to do that over time. I think our first inflection point is offices like Bangalore, Chennai got a lot bigger, and how do we then continue to organize ourselves to form this sense of a community?

I think the best way we certainly have learned previously, is to rotate people. You don't lock him into a community forever. In fact, even at a country level, we have-- I think-- It's not a policy, but we have always had more than 10% of our people work in different countries, other than the country they started at. Rotating people, moving them around can both create the community and then connect the communities. I think we're at a different stage right now, I do think now is a very interesting time. Not because of size. 10,000 people? We can get to 50,000 people and still build a lot of communities around the world and scale that way. I think the most interesting happening industry at this moment is remote working.

We now have almost every country start to hire people remotely. Then they don't even come to the office to get set up, get started. They can start remotely, then join in projects remotely. How do we then build this community? The sense of community when people are not in person with each other? I think we historically relied a lot on ceremonies, stand up meetings, away days, kickoff, showcase, lunch sessions, to build that sense of a community. When you're not co-located anymore, I do worry that this is going to deteriorate and who knows what's the impact?

I also don't think that we can just dial back the clock. The genie is out of the box. I think people want to work remotely and we're going to be a hybrid world from now on. I think that's going to be an interesting challenge for us to deal with.

Prem: Wonderful. As someone who started as a hardcore programmer, do you have times when you miss that and have you thought of going back to do some programming?

Xiao: I have. I definitely miss the time of solving complex technical problems. I know a lot of my job is solving complex problems, but there's no-- Yes, there is, but I shouldn't say there's no. There's this sense of satisfaction, that comes from solving technical problems, that's different. I think the one I miss most is the instant feedback. You do something, you run a test, it works or not. You get a green bar and then you get a red bar, you know exactly why and how to do it. Management is a lot more messier. You do a lot of things. You don't know which one is working, which one is not working.

You almost just have to face, "Okay, this is the right thing to do, right way to do things, and then focus on principle philosophy," but technical problem's different. I really enjoy solving difficult technical problems and being introvert. That also is just my sweet spot. I can sit in front of a computer for hours thinking through a problem, trying to play with it, rather than talking to people all the time. Can I go back? I think I missed the boat a little bit. Then Neal, you asked earlier, how long was my career as a developer. I do think that seven to eight years was a little too short. I got enough. I scratched a lot of surfaces, but haven't really got enough depth built in my experience.

If I had stayed 12 years or above, I think I can still return because I have enough of a pattern recognition to recognize how big complicated project gets structured and what do you have to worry about. Performance, security, all that, but I haven't really got a lot of depths in that. If I go back right now, I can be a solid developer, but I don't think I'm at a point I can just smoothly move back and forth yet. Yes, I need to write more code [chuckles] if I want to go back.

Neal: It reminds me of a cartoon that's making the rounds in social media right now, of someone saying that if their family has a hard time understanding him, because it's the developer saying, "Yes, I got a different error message. Success." [laughs] It's the instant feedback in programming. It's either right or it's wrong and there's a reason. That's why it's a big green bar or a big red bar, not just success or failure [chuckels] that's that instant feedback [crosstalk]

Xiao: That's right. It's fascinating, teaching my son to do some Python programming. He's trying to guess the right answer, trying to get the results. Then sometimes, you make a couple of 10s, there's different error messages, and he never pays attention to the error messages. Every time he changes, I have to force him to look at the error messages. "It's different. That's great."

Neal: [chuckles]

Xiao: Then he was frustrated, "It's still not working. Why are you so happy?"

Neal: Progress is measured in many different ways, [laughs] how developers measure progress. Any last words of advice for a technologist in Thoughtworks who may one day aspire to be CEO or move into a different role within Thoughtworks, or move to a different country? I've noticed that one of the obvious paths to working in upper management at Thoughtworks is having worked in many different countries and many different circumstances. Any good advice you can give to people?

Xiao: Yes, I actually do. I think my path was an accidental path because I just decided that, "Oh, I want to help with this. I want to help with that." I said it was driven by responsibility, but a lot of that was also just driven by curiosity. I was interested. "If I do something different, what would that experience be?" My favorite quote, actually, that's what I want to leave with, if I can, is from Aaron Swartz, our favorite hero technologist. He said at one point that his recommendation from a career perspective to all technologists is pretty simple, is, "Be curious, read widely, and try new things." I think if anyone wants to do something different, just follow that principle, there's going to be a lot of opportunities out there.

Neal: Fantastic advice and that's a great place to wrap things up. Thank you so much. It's always a great pleasure chatting with you. If you ever want to appear on some architecture sometime and work on that side of your technology, I'd be more than happy to do that. Thanks again for joining us Guo Xiao. Thanks Prem. We will see you next time.

Guo: Yes, I'll be delighted. Thank you. Thank you, Prem. Thank you, Neal.

Prem: Thank you.

Neal: Thanks everyone. We will see you next time.