Thoughtworks is acquired by Apax Funds. The current management team will continue to run the company as before.

Twice a year or so, I get together with the Thoughtworks TAB - a selection of senior Technologists from our global organization. One of the main products of our meeting is our Technology Radar. The radar has got a lot of attention and raises some common questions, which this FAQ hopes to answer.

Sales commissions are almost universally used in the software business, as in all business sectors. They are liked because they align incentives between sales staff and the companies that employ them. Nevertheless there are serious problems with the sales commission model, problems that led Thoughtworks to get rid of all sales commissions in 2013.

In an interview with InformIT I give my (rather skewed) view of why I like working at Thoughtworks. We talk about how I got there, why I stay, and what people can do to join and prosper at our interesting company.

Over the last couple of years several of my colleagues have been organizing code jam events where developers get together to write software for charitable causes. A good example is a regular code-jam in New York that works on RapidFTR. Chris George, a ThoughtWorker based in New York, helped organize a one-off event in New York in August 2010. The group didn't get as much done on the day as they had hoped, but in a bar afterwards decided to try to get together more regularly. Since then they've been meeting every week. It's a small group, still mostly ThoughtWorkers and friends, with a core of 3-4 people rising to a dozen when we've had a big project in town.. (Chris is happy to have more people join the group, so if you are interested drop him an email.)

Many people have found these events to an enjoyable way to use our skills for purposes that we find rather more fulfilling than many day jobs, and a way both to learn new skills and learn from a different group of people. So I thought I should share our thoughts on how to set one up.

One of the commonly accepted beliefs in the software world is that talented programmers are more productive. Since we CannotMeasureProductivity this is a belief that cannot be proven, but it seems reasonable. After all just about every human endeavor shows some people better than others, often markedly so. It's also commonly observed by programmers themselves, although it always seems to be remarked on by those who consider themselves to be in the better talented category.

One of the big themes in Thoughtworks is to encourage a diverse range of people in all parts of the company. (In this context we mean diversity in terms of such things as gender, race, sexual orientation, and the like.) We want to be a company where historically disadvantaged groups such as women and non-whites can feel comfortable and get just as many opportunities as the traditional WASPish leaders. Roy, being a notable mongrel, obviously cares about this diversity.

As a company grows, you have to worry more about how it's led and who's responsible for choosing the leaders. Most companies have owners (shareholders) and they ultimately select the executive management. Executives then make most decisions for the company (or at least they like to think they do).

There are many reasons why I'm comfortable about working at Thoughtworks, much of it is because most of the people here share a broad set of principles with me. One that's caused some debate over the years is our attitude to our own intellectual property - in essence we give it away.

One the interesting aspects of the open source world, particularly for us, is how it's proving to be a fascinating research community. Open source projects come in many guises, but a fair number of them are taking an idea and programming around it to see where it goes and whether it has value. That's a notion that sounds strange if you believe that design and programming are separated, but makes a lot of sense if you accept that they are tied together.

There are a few things that I've come to think are fundamental to how I see software development. If I had to pick one as my key to software development it's that the critical element in a software development effort are the people you have doing the work. The productivity of the best developers is far more than the average, much more than the difference in salaries. Therefore the most important part of getting cost effective software development is to hire the best team you can, even if the individual cost of the developers is much higher than the average. A few high ability (and expensive) people will be much more productive than many low ability (cheap) developers. That productivity difference means that a few high ability people will produce software more cheaply even if they cost more on a daily rate.

Imagine a hiring situation. There's two candidates both with a few years of experience. In the blue corner we have someone with good broad design skills in the style of design that you favor (in my case that would be things like DRY, judicious use of patterns, TDD, communicative code etc, but the actual list isn't important - just that it's what you favor). However she knows nothing of the particular platform technology that you're using. In the red corner we have someone who has little knowledge (or interest) in those issues, but knows your platform really well - edge cases in the language, what libraries are available, fingers move naturally over the tools. Assume all else about them is equal (which it never is except for thought experiments like this) and that your team doesn't have any gaping holes that this candidate might fill. Which one would you prefer?

I've spent a lot of time of the last year wandering around Thoughtworks, talking to lots of people on lots of projects. One message that's come home really firmly to me is the value of rotation.

When we talk about Thoughtworks, we mostly talk about us as a software application development company. We also talk a bit about our values and how we are trying to be a different kind of company to most corporations. But all this is dancing around the point - fundamentally Thoughtworks isn't about being a company.

One of the basic tenets of agile development is that requirements changes aren't just expected, they are welcomed. This poses a particular challenge when an external company, like Thoughtworks, is doing work for client. Many clients want a FixedPrice arrangement, which is really fixing scope because they see the FixedScopeMirage. But a fixed scope contract is totally at odds with agile development, so what is a company like us to do?

I've tended to avoid writing about Thoughtworks in my blog. To a large extent this is because I don't like anything that looks like advertising for my employer - the logo on every page is quite enough of that. But more and more my mind gets full of the kinds of things we are doing not just in our delivery work (which is the source for much of the ideas in my writing) but also in the way we structure ourselves. The reason I gave up my successful life as an independent consultant was because I felt Thoughtworks was a special and unusual company. In the last year I've been more and more interested in the social aspects of my employer, and so I've decided to start blogging about some of those.

Thoughtworks has come to China. It's been a long-held ambition for several people to open a China office. Roy has always held it as part of RoysSocialExperiment. In addition Xiao Guo, who's given me so many good experiences and ideas in software development, has long wanted to start Thoughtworks in China.

For the last month or so I've been hanging out in our UK office, catching up with various UK ThoughtWorkers. I was intending to visit some of our client projects, but just catching up with people in and around the office has kept me pretty busy (it's also wiped out any book writing progress, but that can wait till I get back home.)

Thoughtworks is an unusual company, which is why such a corporate-skeptic as myself has hung around for a decade here. An important feature of Thoughtworks is that we take a broader view of our purpose than simply a commercial entity. Over the last couple of years we've been using a three-pillar model to describe the way we like to think of ourselves.