Gears Within Gears
What Made Thoughtworks Work, Part 2: Talent

What Made Thoughtworks Work, Part 2: Talent Unpublished

· 8 min read

In my last post, I made a systems argument that Thoughtworks had an outsize impact on the software industry by way of its focus on process, as a result its particular culture, its way of thinking about software, and the customers that it served. This time I’d like to take a look at what made Thoughtworks tick on a human level: its talent acquisition, cultivation, and retention processes.

The appeal

If the presumption was that they were able to recruit particular talent, we should then start by asking the question: why did people want to work there to begin with? They didn’t have a stellar technical reputation, or the highest total compensation, or even the most interesting work. Yet they nonetheless attracted a number of major industry names, and punched above their weight for influence and access.

The short answer is that they successfully became a destination employer for people who were interested in software process and craft, particularly applied at scale, on problems notable not for their algorithmic complexity but for their domain complexity, and for whom the travel burden was not a dealbreaker (or was even a draw). At a large tech firm you can work at scale on interesting algorithms—Google is justifiably famous these—but they typically don’t claim much innovation in approach. Thoughtworks was able to elevate their talent pool through their focus on improving the fundamental craft of software; more than any other firm, this gave their alumni a certain cachet within the industry in roles involving digital transformation, devops, or platform engineering. This is perhaps their most notable difference from Pivotal Labs, which worked in similar ways but focused more on smaller, more nimble firms.

The second major component is that they successfully navigated a middle path between white-glove consulting firms and traditional worker-for-hire IT shops; they eschewed both the “up-or-out” model of traditional partnerships and the just-barely-a-company feel of more conventional body-shop contractors. They had a distinct culture, perspective and way of working; their rates were fairly high by IT standards1, which meant that your advice was likely to carry some weight; you could work there and receive some reasonable shot at a decent career in software. They would show up, in force, at technology conferences that covered topics they were interested in; they made their presence felt in ways that didn’t involve a lot of traditional marketing by using their human capital well.

They did all that while also offering some of the trappings of a premium consultancy. They had a generous expense policy and gave their employees an extraordinary amount of latitude in its use; they had a global perspective and you could, if you applied for it, work and travel internationally; many US employees became nomads without a permanent base of operations, a promise that I and many others took up time and time again. (Think Up In The Air, only in hoodies.) These kinds of non-monetary perks are difficult to find outside of larger white-glove consulting or legal firms, particularly for junior employees.

The reason it was important that they find a middle ground was because their talent strategy involved attracting nerds. Nerds are (or were) proud but egalitarian; they want to feel rewarded for their knowledge and chops, but status can be as good or better than money. Nerds also love to learn. In the days before programmers swapped hot tips on maximizing their total comp, Thoughtworks got an awfully long way by leading with the appeal of status and high-velocity upskilling.

The unconventional hiring process

Thoughtworks’ hiring process at its inception had a reputation for being rigorous, but it wasn’t rigorous in the way that, say, Google’s was. Thoughtworks screened better than anyone I’ve ever seen for people who (1) got stuff done, (2) collaboratively, (3) without compromising on quality.

Where Google and Facebook screened for algorithmic mastery and academic creds, and Microsoft was famous for its brain teasers, and startups often screen for sheer velocity, Thoughtworks screened for craft: they were less interested in whether you could solve very difficult problems and more interested in whether you could solve problems in a simple, sustainable way.

They also screened for culture fit, and they meant it. More than any other place I’ve worked, you could walk into a Thoughtworks office anywhere in the world and meet people you recognized. The place was permeated by genial collegiality and a sense of shared ethos.

In part, this is because Thoughtworks shrank the talent pool from which they’d hire aggressively. The first question you had to answer if you wanted to work for Thoughtworks, at least in North America and Europe, was: how do you feel about getting on an airplane every week, for years? And oh, by the way, how do you feel about going overseas for six weeks for training? Oh, and you’re aware that we write every line of production code in collaboration with other people, right? If you want a private office, look elsewhere.

If you, like me, were a programmer and a recent CS grad in the mid ‘00s, the answer was: Are you sure you’re hiring the right guy? Don’t programmers sit in cubes or, at best, dark rooms all day? Haven’t you folks read The Joel Test? Seems inefficient. But sure, I need a job, I’ll bite.

This had important knock-on effects for the culture, about which more later.

The second thing that Thoughtworks did is that they screened for practitioners, as opposed to, say, academics or thought leaders. Engineers were required to write code as part of an initial screen—not a universal practice in the industry when I started there, though it’s close to one now—and each submission was graded for cleanliness, structure, and production-readiness. Even Staff Engineers and Architects were proud to be hands-on practitioners; backseat driving was abhorrent as a concept and I recall multiple occasions where we challenged client CTOs to follow suit in their own hiring practices.

They were also not interested in flair or showboating. I’ve subsequently screened hundreds of code submissions at other firms, and this choice is less common in the industry than I’d like.

Part of screening for practitioners meant an interview in which you did the work: for Thoughtworks, this meant pair-programming, live, with your interviewer. This practice has subsequently come in for a great deal of critique for the stress and power imbalance it places on the interviewee, to which I say: it worked. If that wasn’t enough, the interview process also involved a logic test, as well as a series of meetings with various technical and management folks from the operations side, concluding with a leadership 1:1 before an offer was made. Supposedly the process was comparable in difficulty to McKinsey and BCG.

This interview sent an important message to applicants: you will be expected to practice your craft, and you will be expected to do it in the presence and with the consent of others: cowboy coders are not welcome. It also sent the message that even people working in leadership or sales roles had to have chops in order to have credibility in those roles.

The final thing they did, starting from shortly before I joined in 2007 and continuing up until roughly the present day, is that they sent every new college hire, from all over the world, to India for six weeks of training. Training new grads isn’t unusual in corporate America (though it’s particularly notable here since they provided so little of it later in one’s career), but a few things set it apart. First, India is and was not Thoughtworks’ corporate HQ; second, training is usually provided in the geography of origin rather than localized to a particular spot; and third, most training programs, because they’re provided locally, are adapted to one’s local culture.

My training program had grads from India, Thailand, China, South Africa, England, Switzerland, the United States, Canada, Brazil, and Australia. Many of the usual suspects in the industry were represented, to be sure, but it gave the organization a pronounced internationalist bent nevertheless.

I learned three powerful lessons from Thoughtworks’ hiring process. First, that self-selection is enormously important in narrowing the talent pool to something that matches the culture you’re striving to create; “we just hire talent” isn’t enough. Think the (probably apocryphal) Ernest Shackleton recruitment ad, or, a personal favorite, Leslie Knope’s job ad for Club Swanson.

The second lesson I took away is that your hiring process is critical to creating culture. If you screen engineers by asking them to solve algorithms problems, you will end up hiring people who believe that success is defined by them. This is self-reinforcing: people who pass the first screen and succeed will, via selection bias, come to believe that the screen itself was a critical factor in their own success, and that to change or dismantle it is tantamount to lowering the bar on talent.

The third lesson I learned is that hiring for talent is meaningless if you can’t define what you mean by talent. Thoughtworks was an extraordinary place to work, but one of the things that stands out about their talent strategy is that they didn’t draw heavily from graduates of conventionally well-respected computer science programs—your Stanfords, MITs, and so forth—and they did just fine at attracting and retaining extremely capable people, by the standard of people who could successfully move a business forward. Thoughtworks cared about talent, but they knew what they wanted from it.


  1. In 2007, my hourly rate at McKinsey, the first client I was staffed at, was $170/hour (~$260 in 2024), against a starting salary of about $70k/year. ↩︎