My Thoughtworks journey: Rebecca Parsons

Episode transcript

[Music]

Neal Ford: Welcome everyone 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, Birgitta.

Birgitta Böckeler: Hi, I'm Birgitta Böckeler and I'm recording today from Berlin, Germany.

Neal: We are doing today one of our series of podcasts that we call the “Thoughtworker Journey” podcast. Where we take someone who's been at Thoughtworks for a while, who has been at several interesting roles and we're interested in the career path that they got to or they managed to get to that position which is a clumsy way of saying it's the Thought Worker Journey Podcast. The thought worker that we're discussing the journey with today is another voice that you'll certainly recognize if you are a frequent listener to our podcast. It is our very own CTO and one of the other hosts, Rebecca Parsons. Hello, Rebecca.

Rebecca Parsons: Hello, Neal. Hello, Birgitta. Happy to be here.

Neal: The last one of these Journey podcasts that we did was with Guo Xiao, our CEO. He was interesting because he had no real career before Thoughtworks. He started his first job was Thoughtworks as a developer, and then became, eventually, through many years and many experiences, CEO. Rebecca is perhaps a polar opposite of that [laughs] and has had many interesting twists and turns before she made it to Thoughtworks and then even within Thoughtworks. Let's talk about Rebecca's journey as a technologist and how Dr. Rebecca Parsons ended up as the Chief Technology Officer at Thoughtworks.

Rebecca: The best place to start really is in my freshman algebra class because we had moved from a small town in Wisconsin to Peoria, Illinois, which for me was a big city! [chuckles] The school district in Peoria thought, "She's coming from this small rural school district." I had actually been in a special program, and so in the fifth grade, I took freshman algebra. I show up to a freshman algebra class and it's, "It's clear that she knows all this stuff already."

Birgitta: Can you just explain to me, Rebecca, because I'm from Germany? Freshman, fifth grade, does that mean that it was ahead of where he should be?

Rebecca: Yes. In the US system, you go kindergarten through eighth grade. You start kindergarten around five normally. Then high school is freshman, sophomore junior, senior. I had taken effectively ninth-grade algebra when I was in the fifth grade. My algebra teacher at the time was taking a computer science programming class at the local university, Bradley University. He bought another copy of the textbook, it was PL1 programming, and gave it to me and said, "I'm going to bring you in every once in a while to have you take the tests to see if there is perhaps something that I'm teaching that you weren't taught. Otherwise, go work your way through this. I will run your programs." It was of course done on cards at that point. For whatever reason, we actually had a keypunch machine at my high school. We didn't have any programming or data entry classes, but we did have a keypunch machine. He gave me the key to the keypunch room, and I would type in my programs and he would run them for me. I just fell in love with programming.

When I got to university, I was going to major in computer science and I did that. My computer science program was really more of almost an IT because I had to take two semesters of economics and marketing and business administration. I had a great economics 101 teacher and I just fell in love with economics. I got a double major at Bradley University in economics and in computer science. My first real technology job I had been playing with computers and doing some programming with the CPM operating system and all of that.

My first real job was actually with Caterpillar Tractor Company. That came about ironically because of the dentist that I worked for. One of his patients actually was the overall manager of all Caterpillar's training programs. Their cooperative education — kind of like an intern program — had only ever been mechanical engineers, electrical engineers, people who actually helped Caterpillar Tractor Company design tractors. They thought technology was going to start becoming more and more important. This was actually in the late '70s.

He wanted to bring in computer scientists into the co-op program and asked if I would be interested. Here I am filling out insurance forms at a dentist's office, [chuckles] and talking about a computer science job. That's how I got started at a real job in programming.

Neal: Some further context for those who certainly wouldn't know outside the US, I think Caterpillar's probably the largest employer in Peoria, Illinois. Is it not? It's a massive–

Rebecca: Oh, by far.

Neal: Yes, it is. Peoria is basically a life support system for Caterpillar. [laughs] If you're in Peoria, it's not surprising that you would find a job there at Caterpillar. Which would seem like a weird non-sequitur otherwise if you didn't know that about [chuckles] Peoria, but that certainly explains it.

Rebecca: I started working at Caterpillar and one of my jobs there I was doing warehouse automation. Actually, one of my first tasks was a classic legacy modernization because Caterpillar had the first two automated warehouses that had ever been built on the planet. They ran on an IBM 1800 computer. At that time, there were two remaining functioning IBM 1800, both owned by Caterpillar. IBM basically said, "There is no longer any amount of money you can pay us such that we will continue to support these computers. You have this dropped at a date." Of course, we had to redo the system.

Birgitta: It was kind of like an early adopter's problem. They had adopted this so early that then they also were the first ones who had to do legacy replacement.

Rebecca: Exactly. The system was actually designed by an electrical engineer, but it was a very early instance of basically a data-driven application. We had the essential structure, but you would encode the configuration of the warehouse. This is going to come to a T and it can either turn left or turn right and you turn on this thing to make a turn left and you turn on this thing to make it turn right. The beauty of the system was after we replaced that first warehouse, someone else was replacing the second one. I went to Lafayette, Indiana, which is 198 miles door to door. [laughs] I remember that because I drove it a lot to install a completely modern warehouse.

The hardware was completely different but the structure, that system was just so well designed that we were able to use it to support a really old-fashioned warehouse and the most modern warehouse possible. To tell you how old the other one was, their bin full sensor was the motor overload. You push and push and push and if you can't get the new load in, then oh, bin must be full. [laughs] Now, of course, if you've got toilet paper in the bin and a V16 engine block and you push, it goes off the back and falls to the floor. [laughs] There was just something so fun about working with physical systems. My favorite moment was fixing a problem and watching a V16 engine block move where I wanted it to. It's just like — no report generator, no nice screenshot is ever going to replace that physical thrill of that went where I told it to! [laughs] 

At some point, I wanted to move on. I've always been more of a systems person. I got a job basically as the tech support person for a semiconductor design group. They were designing semiconductors. I was supporting all kinds of computer-aided design systems. We also did a lot of simulations. I got to work with a CDC 205. Then we actually had serial number one of the Convex S1 supercomputer which was a combination parallel and vector.

I got to work with serial number one of something, which was really very exciting.

Neal: Crazy expensive at the time too! About the processing power of an Apple watch now, I'm guessing? [laughs]

Rebecca: Probably.

Neal: It was one of those things. [laughs]

Rebecca: Then I worked briefly for a division of Amdahl in their communication division actually working on intelligent alarm monitorings. If you think about massive networks and switches, one switch goes down and minus one switches say, "Hey, I can't talk to that switch anymore." You don't want to be flooded with those redundant messages. We were trying to find different ways of intelligently filtering alarms so that you could correlate different alarms together and all of that.

Birgitta: Sounds very familiar thinking about microservices architectures. Where people are like, "How do I know which of the services is actually the problem when all of them alert?"

Neal: It's amazing to me how much the same problems keep popping up over and over again because that's exactly what the CORBA smart agent did. When it was looking for brokers, the smart agent would do exactly that broadcast. We keep solving the same problems over and over again, [laughs] generation after generation.

Rebecca: During the time both, that I worked at the semiconductor place and Amdal, I had been going part-time working on my master's in computer science at the University of Texas in Arlington and decided that if I was really going to be serious about getting a PhD, I could not do it part-time. I applied and was accepted at Rice University in Houston, Texas. I quit my job and went to what went to Rice and had a wonderful time there.

I was very fortunate because in about my second month, there was a talk given in the department, and one of the professors, and I was taking a class from him at the time, Matthias Flicen. He asked a question at the end of the talk about did they have this particular structure and formal system to support the work that they were doing? They said, no. I said, "That sounds really interesting to me." Because this representation was important for compilers. By that time I knew enough about programming language semantics and such that I knew I wanted to do something of that. That seemed to fit squarely on that fence between very applied and very theoretical which is something that matters to me.

Basically, I had my PhD adviser and my dissertation topic in my second month as a graduate student which normally doesn't happen, which is also why I got my first paper published much earlier in my career than normal because I started working on this thing. Moving on, I went and did a postdoc at Los Alamos National Laboratory in New Mexico. Because it is one of our department of energy nuclear research groups, I needed a security clearance.

Basically how things worked at that time is the US budget year starts on October 1st, and the FBI would do clearances until it ran out of budget from the DOE, and then it would stop doing clearances until the next October 1st. I started in April and so my clearance didn't come through for a while. I could get in on occasion and work with the people I was supposed to be working with, but my office was actually what they called outside the fence.

I was in, literally, a trailer with some computational and molecular biologists who were working on the human genome project. I got involved with genetic algorithms applied to the Human Genome Project while I was working outside the fence. Then the people I was working with inside the fence, that was more extension of the work I did in my dissertation. Then I took a detour [chuckles] and did the thing that I said I was never going to do. When I went back to graduate school, I said I will never be a tenure track assistant professor, and I will never live in the state of Florida.

I took a tenure track assistant professor position at the University of Central Florida, but I never really thought I was cut out to be an academic. I had taught some classes when I was working at Los Alamos and had people encouraging me to take up teaching. I did and I didn't like it. Then I got a call one day from someone that I had been involved in a computer user society, the Digital Equipment Corporation Users Society, DECUS. I had been involved in their artificial intelligence, special interest group, ultimately becoming chair of that special interest group.

I worked with this guy and he called me up and said, "You have got to come work for this company." It was Thoughtworks. This was in late 1998, early 1999. As I said, I wasn't terribly happy at the university, so I thought, "Might as well give it a try."

Neal: That's about year five of Thoughtworks which started in '93. Is that correct? Yes. That's what I thought.

Rebecca: I went through the interview process, never talked to Roy, who's the founder. I got a call and they made me an offer and I said, "I haven't talked to Roy yet." He said, "We're trying to get Roy to not be involved in all of the interviews." Because at that point even the people who were manning the reception desk, Roy was interviewing. I said, "I've been in this business long enough to know if I'm reporting to anybody, I'm reporting to Roy, and I'm not going to take a job at a place where I can't talk to who I'm going to be reporting to. Thank you very much for your offer, but I decline."

Birgitta: Good for you, Rebecca, good for you. [laughs]

Rebecca: About 20 minutes later, the recruiter called back and said, "Roy would like to talk to you." [laughs] We had the most enlightening conversation. It was just under two hours long and Roy told me everything he thought was wrong with the company. He said, "I don't want you to think I'm stupid. I know these things are wrong. This is what I think is wrong. This is what I'm currently trying to do to fix it. This is why I don't think I've succeeded in fixing it yet." I had asked my friend, Jim, the same question, "Tell me all the bad stuff."

Roy's list was about three times longer. That's how transparent he was about how he viewed the company and such. It's like, "Wow." The other thing that struck me from the interview process that I think is so much a part of Thoughtworks, one of the people who did a technical phone screen with me, and you have to realize that when I joined Thoughtworks, I probably had triple if not four times the number of years experience of anybody else in the company. That wasn't true of some of the project managers and the analysts but in terms of the developers.

I'm doing a technical phone screen, and to this day neither one of us remembers specifically what David said, that I interpreted as he understands my dissertation topic. I launched into this. This is the stuff that I'm working on — then I stopped after about five minutes and I was just so excited about, okay, we're going to have this really in-depth conversation about something I haven't really talked about much lately. He said, "I have absolutely no idea what I said that indicated to you that I would understand anything that you’d just said."

[Laughter]

I thought, "This is somebody who is a senior technologist at this company who is openly saying, "I don't have a clue."' I thought, "If that's the ethos, if that's the culture, I want part of that," because there are so many people in our business who seem incapable of saying the words, "I don't know," or" I don't understand." I got really excited about those two things. I started at Thoughtworks on December 14th, 1999. I wasn't going to start until after the new year, but they said, "No, please." Ironically, my first client with Thoughtworks was Caterpillar.

[Laughter]

Which I just thought was this amazing full circle.

Birgitta: I have to say up until now, it just goes to show again, so many of the turns in your career that you described were serendipity and/or something that you didn't actually actively seek out, but somebody brought it to you. Like the biologist in the trailer with you, the dentist's client, or how you found your dissertation topic, then a friend calls, you go to this company. It just goes to show again that so many things-- it's a bit scary, but it's also a bit almost assuring always for me, when I hear people describe these things, how many things just happen. You just have to have open eyes and just go out and talk to people and try things and all of that.

Rebecca: Yes, and be open to trying things or exploring things that you hadn't thought about doing. I remember I was on a panel when I was still at the university and it was a career panel, so I was the academic, and then they had people in different kinds of jobs in the industry. Somebody said, "Everybody who ends up in academia, they always knew that that's where they were going to be and so, tell me about your path." It's like, "Okay, mine was not a straight line at all. [chuckles] It went like this because I didn't think about the fact that I was ever going to end up at a university."

Neal: Went straight from university to Thoughtworks. Had you ever done any consulting work before? You certainly had technology background, but never done any consulting before Thoughtworks, is that correct?

Rebecca: No consulting. As I was going through the interview process, I realized just how good a fit consulting is for my personality. I consider myself something of a firefighter. I want to go in and look at a new problem, figure it out, okay, done, next. That's what you get to do. Part of how I kept my sanity at the semiconductor company was I was supporting, I think at one point, nine different computer architectures and 11 different versions of operating systems. I got to learn the internals of the CDC operating system, and I got to learn VMs internals, and there was an RSX system there and a couple of different flavors of Unix.

There was a data general, I think, somewhere else and it was just-- I had all of these things and I could move around and I wasn't stuck in a technology stack. That's what a lot of people who are working for a company, you're in one technology stack, you're clearly in one domain and that's just not enough variety for me. [chuckles]

Neal: That definitely is one of the appeal of the consultant is you get to see lots and lots of different things. If you're a natural pattern matcher, you start noticing similarities and things across clients which is where things like books come from which you've co-authored at least a couple of books since you've been at Thoughtworks. I know that because I co-authored one of them with you which is Building Evolutionary Architectures, but you also contributed to Martin Fowler's Domain Specific Languages book, right?

Rebecca: Yes. I wrote mostly the chapters on the moral traditional compiler tools. This is how you use things like lex and yacc and some of those more traditional compiler tools for parsing. A lot of what Martin and I were trying to do with the book was demystify those tools because so many people take compiler theory in their undergraduate computer science course and their parsing languages like C++. They're incredibly complicated compilers. Personally, I love the theory. There's one particular proof in The Dragon books, that was my favorite lecture when I taught the compiler of course at university because I just loved going through that proof.

For many people, the compiler class is that "Oh, I just have to get through it." Many people wouldn't try to do external domain-specific languages because they were afraid, "Oh, that means I have to write a parser. Do I have to use yacc? Oh, no." We wanted to demystify that process so that people could realize that actually for most of the DSLs you build, they're relatively simple languages. You don't have to get into all the messy stuff that you got into in your compiler class. It's actually not that difficult.

Neal: External languages are tough because you have to use not one, but at least two different three-letter mysterious Unix tools to make it work. Lex and yacc. To me, you were talking about seeing the engine block move. To me, the compiler is the clearest manifestation of magic because you take this highly structured prose poem, and then you run it through this thing and it makes things happen. Engine blocks move and so that to me was always the magic. That's the thing I enjoyed most about compiler class.

It seems like you've always leaned heavily into the more abstract difficult parts of computer science. [chuckles] Evolutionary computing and compiler theory, and some of that stuff. Is that just your natural inclination or is that another serendipitous thing that led you into that branch of this field?

Rebecca: I think it's more just natural. I think in models and I think in systems, I do not think in pictures. I do not interpret pictures, please no pictures.

Neal: We famously have one diagram in the Building Evolutionary Architectures book called Rebecca's diagram because it's the one that she created, one and only diagram that she's ever created for publication. [laughs]

Rebecca: Yes. In fact, the closest I ever came to throttling my PhD advisor was when I turned into him my penultimate copy of my dissertation. I went, to see, "What final edits do I have to do in this?" He gave it back to me, and we talked about a couple of things and he said, "There's just not enough pictures." I thought I was going to explode. I said, "Matthias, you know me and pictures. If you want more pictures, fine, sketch it out. I'd be happy to use the tools to create them, but don't ask me to figure out where they might be useful because I actually think I have all the diagrams in there that I need. Thank you very much."

[Laughter]

Neal: Let's talk about some of the kinds of projects you worked on at Thoughtworks because, by the time I got here, you were doing a lot of enterprise architecture consulting, which makes total sense. If you were a dual major in economics, and computer, it couldn't be a more perfectly suited enterprise architecture role. I know you've done a lot of different kinds of-- what are some of the notable projects you've worked on here?

Rebecca: Obviously as I mentioned, the Caterpillar project and that was at the time, the largest J2EE code base. I think at one point we had I think well over 500,000 lines which at that time for Java was huge.

Birgitta: Again, Caterpillar early adopter. Yes?

Rebecca: Yes.

Neal: If I can interject, my first project at Thoughtworks many years later in 2005 was also on Caterpillar. The notable thing about that project was, and I made this statement at one point, every line of Java code that can be written had been written in that project, but the real trick was go to find the person who knew where it lived now. You could go to somebody and say, "Hey, I need some code that translates XML into this other document format." I remember the guy on the project had sit and think for a second, "Okay, go look at this package over in this module, over in this, and we've already--"

Everything that you could have written had been written in that project, and you just need to go find it. It became a librarian exercise rather than a coding exercise. I think that project in some form is still going. [chuckles]

Rebecca: That is my understanding. Then I went over and helped start our UK office working on yet another legacy replacement. This one was for a trading system. Neal has heard me talk about this trading system because I use this as an example of how there is no one perfect architecture for all systems because you say trading system and everybody immediately thinks low latency, high throughput, performance is key. This was a commodities trading platform and they only did maybe a hundred transactions a day.

They didn't care about throughput, they cared about never losing a message. At that point in time, they had three different data centers they had to keep in sync, one in Singapore, one in North America, and one in the UK. We spent a lot of time thinking about how would we manage this communication infrastructure so that we knew where all the messages were, we knew we had the right level of redundancy across the three data centers.

That was just a fascinating project from that perspective. Then I worked on a retailer and that was an interesting combination between a highly distributed architecture and a centralized architecture because what they had had previously was primarily store-based servers. They had approximately low number of thousands stores with a total of I think it was 14,000 tills scattered across maybe 6,000 stores or 4,000 stores or something. They had previously had store-based servers with very light centralized processing.

They wanted to go highly centralized but they'd had a communication failure once in their history where they lost all of their doors in Scotland. Even though they really wanted a centralized architecture, they couldn't bear to have a centralized architecture because what happens if we lose Scotland? Again, it was a very interesting architectural problem of how do we give sufficient power to the tills because they didn't want store servers anymore.

We had PCs for tills. How do we get sufficient store processing capability just in case we lose contact with the mothership but still have a really centralized architecture? There was a lot of thought that went into how do you maintain consistency across the tills, how do you do the synchronization back to the mothership, and all of those kinds of things. A very fascinating architecture. At that point, once that project was finished, that's really when I started getting into more of the enterprise architecture consulting and workshops.

Although I had done a fair amount of that, particularly at the retailer because they were trying to figure out how are we going to make this work in our system, what kind of architectural governance should we be having? Things of that nature. I was involved in those conversations even though the program of work to replace the in-store systems was completely separate from the IT group.

Neal: If I'm not mistaken, you were the only chief technology officer Thoughtworks has ever had. Is that correct?

Rebecca: I'm the only one that ever really had the job. Very early in my time at Thoughtworks, it would've been in the year 2000 just before the bubble burst, Thoughtworks took on some private equity money. When they were going through that process, people in that business expect a business like ours to have a CTO so someone was given the CTO hat. They were still working on projects all the time. Roy was still ultimately making those kinds of strategic decisions for the company. It was a pair of them. Neither one of those people would say they were actually the CTO.

One person did apply to be CTO. He wrote up this three-page memo of how he was going to dictate how everything was done on all of our projects and it's like, that is for Thoughtworks, the absolute wrong way to be a CTO. [chuckles] We hire lots of smart people for a reason. Why don't we listen to them? Why don't we empower them?

Neal: I think that the reflection too of the very early days of Thoughtworks, and you alluded to this, that we didn't have a lot of people in Thoughtworks at that time who had had the experience you'd had on client sites for doing basically CTO and enterprise architecture level work. Your background plus the experience you'd had on clients had made you the most obvious candidate because of real-world experience on the ground of basically doing that kind of work for a while. I think a lot of capabilities within Thoughtworks have grown as needed like that versus imported from the outside world just part of the agile grow-like-a-weed nature of Thoughtworks generally.

Rebecca: I would agree with that assessment.

Birgitta: Then I don't know, why don't you also talk about how you got that actual job of CTO then, not just the hat, but the job and how has it changed over time? I'm sure it has.

Rebecca: At that time and actually since the beginning, I was on basically any overall Thoughtworks leadership or management team. Originally, there was just one Thoughtworks. There was Roy and all the other people and we got to be about 1,000 people. That's where Roy finally broke. It's like, "I cannot have 999 direct reports. We're going to have to do something about this." Over time, the different management structures have morphed but I had always been the technologist sitting on that group.

That was something that was very important to Roy. We consider ourselves tech at core and how can you say you're tech at core if you don't have technologists at all of the decision-making tables? Not just to weigh in on technology things, but to weigh in as a technologist and thinking about the business problem from the perspective of technology. To some extent, I was the logical choice because I'd been on all those groups where all of the other Cs — the CFO and the CEO – had been sitting.

I think part of it too is that breadth of experience not just at Thoughtworks because I've worked for a government research lab, I've worked for a semiconductor company, I've worked for a computer manufacturer. I've worked in the government. I've been in academia. I had a breadth of organizational experience as well that I think played into it. Initially, I was still involved with clients, and then over time, I became more the person that you brought in when you want a C-level. I distinctly remember one meeting where I said at the beginning, "Hello, I'm Rebecca, nice to meet you." At the end, I said, "It was a pleasure to meet you," and nothing else.

My presence in the room got the meeting with the client executive. Fortunately, that only happened once, and fortunately, I was already in the city so I didn't actually have to fly there just to be a token.

Neal: The ceremonial role of CTO. [laughs]

Rebecca: Exactly. What really has changed — initially, I was very Thoughtworks and Thoughtworks’ clients-focused. That started changing in part with a distinct little push from Martin. He was asked to do a keynote for QCon and he said, "I will do it if you allow me to pair with Rebecca." We did a variant of a talk that I had further developed after that which was basically trying to explain how agile and enterprise architecture really can cooperate. That's when I started to have much more of a public presence. Now I speak at several conferences a year and that certainly wasn't true when I first became CTO.

Neal: It is a good outlet for the technical parts that you still really love about technology because you still really do, I know from experience love technology, and technology's really a thing. That gives you an excuse to dabble in technology. Let's talk about one conference in particular which is the Grace Hopper Conference. In fact, back in 2018, you've been involved with Grace Hopper for many years. Back in 2018 you actually received a Technical Leadership Abie Award as part of Grace Hopper. Particularly for people who are not familiar with Grace Hopper, explain what Grace Hopper is and what an awesome event that is.

Rebecca: First, Grace Hopper as a person — Admiral Grace Hopper — was one of the very early programmers, she was involved in the creation of the language COBOL. I actually got to meet her once at that Digital Equipment Computer User Society at their conference. She was a keynote speaker one year. The Anita Borg Institute for Women in Technology began in the 90s, actually, doing what they called the Grace Hopper Celebration of Women in Computing.

It has always been predominantly women. Maybe 2% men attend, maybe 5% men attend but for a woman in technology, it's a completely different experience to walk into a technical conference, hear people talking about quantum computing or distributed systems and you look around and it's, "Oh, there are people who look like me."

Birgitta: It's a total inverse. I was at a conference once, there were 2,500 people and 25 women so it's the exact inverse.

Rebecca: Exactly. The organization is now called AnitaB.org. They are advocates for diversity, equity, and inclusion. They focus on the three aspects being able to attract women either to the field or to an organization, how you retain women either in the field or in the organization. How do you advance women appropriately? Because one of the things that many people don't realize, they want to focus on the girls. We need to get those 12 to 18-year-olds excited about technology which is true, but women leave the field at twice the rate that men do.

It's not because of childcare responsibilities, it's not because of family care responsibility, it's because they don't feel like they're paid properly. They don't feel like they have a chance for advancement. They don't feel like their accomplishments are properly recognized. One of the things AnitaB.org does is work with companies to help them effectively fix their culture and fix the environment so that women and other underrepresented groups they feel welcome. They feel like they can contribute, so you don't have to be absolutely passionate about technology to hang in there.

There are a lot of men for whom technology is just a job. It's a good-paying job but their eyes don't light up when they talk about what they do. The people who Thoughtworks, our eyes light up when we talk tech because we're passionate about it. That's why I'm still in the business because I can't imagine not being in technology. I just can't fathom it. I'll figure out how to put up with all the stuff.

Neal: Figure out how to put up with all these ceremonial CTO roles so that you can get to do the fun CTO parts.

Rebecca: Exactly.

Neal: That's a great place to wrap things up. Thank you Rebecca for this great insight into your career journey. I'm sure many people who have listened to you for a while had no idea of all the various routes you took to get here. Thanks, it's always a pleasure to talk to you and hear about your history.

Rebecca: Thanks, Neal, thanks, Birgitta. Thanks for the wander down memory lane.

Neal: [laughs] It was our pleasure. Thanks a lot and thank you for listening and hope you join us for the next episode of the Thoughtworks Technology Podcast. Join us on the next episode of the Thoughtworks Technology Podcast where me, Neal Ford will be talking to three of the helpers who help put the technology radar together. The current and two former ones will talk a little bit about how the radar is put together and some details about the behind-the-scenes that you may not know. Join us for the next episode of the Thoughtworks Technology Podcast.

[Music]

[END OF AUDIO]