Confidential, not anonymous. Performance, not pay rise

Confidential, not anonymous. Performance, not pay rise

(First posted on Medium)

Peer performance reviews are broken, but if you must have them, read on.

Traditionally, peer reviews are anonymous. Reviewers are asked a bunch of questions and possibly asked to give a grading of a peer or colleague. I’ve never seen this work particularly well anywhere I’ve worked and there arecountless articles decrying their use. There are two fundamental reasons, I believe, that cause them to suck.

  • The purpose is unclear: why am I reviewing this person? How do I know my comments will be taken seriously and in the context I wrote them in?
  • Mistrust: how do I know the process is fair? Are my reviewers spending as much time as me? Do they know me enough to give a balanced review? Will this mean I get less of a pay rise? Is it worth my time?

These lead to two secondary problems:

  • Procrastination: everyone leaves doing their reviews until the last minute, this means they’re rushed, low quality and bland.
  • Closure: what happens to my comments? How do I know they made a difference? I am apathetic about this.

I dislike the anonymity of these kind of reviews chiefly because they do their part in fostering a culture that doesn’t value transparency, they make secrecy seem like it’s a behaviour that’s sanctioned by the company — secrecy shouldn’t be sanctioned — we demand openness, transparency and honesty — anonymity inhibits these behaviours during one of your most crucial activities.

What can we do about it?

Performance, not pay rise

This one is easy(ish).

Dan Pink talks about the three things people need for high performance are autonomy, mastery and purpose. Of the three, purpose is what is important in this context. Give your reviewers a reason to complete a review. The reasons, of course, are up to you — but what is key is that, to get the most of them, they should be unhitched from pay reviews. Peer and performance reviews are about helping the person being reviewed to improve in some way — either professionally (usually this is the case) or personally. Linking them to some kind of increase (or, decrease) in remuneration will kill the value of these reviews faster than video killed the radio star.

Do your peer/performance review cycle at a different cadence to pay reviews
It’s easiest to do them all at once, I know, but staggering them (even by a couple of weeks) will be useful in this context. In Work Rules! by Laszlo Bock, he states the Google have their pay review sessions a month after their performance reviews. This is enough time to decouple them in the minds of Google employees. He says that it reinforces the idea that they are separate to have the activities as separate in everyone’s calendar.

Make it obvious what they are for
When you send out whatever missive you choose to kick off a review cycle, make its purpose absolutely explicit and keep repeating this. In The Advantage by Patrick Lencioni, he says that, to get the message of what is important across to an entire company effectively, you need to repeat it and repeat it until and don’t stop, even if you think everyone gets it.

Follow up and close the feedback loop
This one is important and almost universally missed out.

As a conscientious reviewer, you spent time and effort on writing a good, balanced review of your peers, giving examples of behaviour and congratulations on a job well done. You hit the “send” button with a sense of a job well done and then … nothing.

What we’re missing is feedback for the reviewer. The whole process is (rightly) geared around the person being reviewed — we look to change behaviour through decent feedback to the person being reviewed and give them concrete reasons to improve, or continue down a certain path. There’s really no good reason why we can’t follow the same logic for the person doing the reviewing. Otherwise, they will only ever feel like their feedback is dropped into a black hole.

For example, let’s say that Bob was being reviewed, and he was informed that, while his work on the Acme project was excellent, his timekeeping could be improved so as not to keep his colleagues waiting around at the start of meetings. Bob discusses this with his manager and agrees that he’ll make sure he ends meetings five minutes early to be on time to the next one.

After the review process with his manager, Bob will pen a short email that is sent to his reviewers:

Dear Colleagues,

Many thanks for taking the time to give such honest and balanced feedback, I’m glad that my work on the Acme project was appreciated, I worked hard to make it a success.

I’m sorry that my poor-timekeeping is causing a problem for some of you, I wasn’t aware it was having such an impact — I’m in too many meetings! I’ve committed to leaving meetings five minutes earlier to make sure I’m on time — please bear with me while I do some rescheduling, as it may take a week or two to get into the new routine.



Without much more effort, Bob has closed the loop, for both himself as a means to thank his reviewers and apologise (if necessary) and also for his reviewers, they can see their feedback was taken seriously and acted upon.

Next time they’re asked to complete a review for someone, they’ll remember the feedback loop was closed and will try to provide good, constructive feedback that can be acted upon.

Confidential, not anonymous

Making reviews and reviewers public leaves many people quaking in their boots. Complete transparency is not for the faint of heart (but, it’s somewhere you should aspire to) and consequently, not something I would encourage jumping straight into for anyone with an already established process. What I would encourage though, is moving from anonymous to confidential.

The difference is important on many levels. But what does it mean?

Anonymous means that nobody knows the identity of the reviewer, neither the manager or the reviewer. Confidential, on the other hand requires that the reviewer’s name is known, but only to the manager of the person being reviewed. The benefits of a confidential review system outweigh any potential risk that may come with one.

For the reviewer
Removing the comforting blanket of anonymity means that anything written down, must now be carefully considered. If I know that the manager of the person I am reviewing will know what I’ve written, I can’t provide useless waffle, bland platitudes, backbiting or simple bullshit. The fact that my feedback can be sense-checked means my feedback will be more considered and, hopefully, of a higher quality, which will improve the process end-to-end. I also understand that, should my feedback require clarification, I’ll be asked, directly, to provide it. So, I feel some measure of shared responsibility for resolving any issues that I bring it.

For the manager
In the past, I’ve seen feedback that is useless. Sometimes it’s personal feedback (one employee has a personal problem with another), other times, it may not have an example accompanying it, on rare occasions, the feedback may border on gross misconduct, or a sensitive problem that cannot be dealt with in a normal peer performance review process. When the feedback is anonymous, it stops there. There’s not much I can do about it and adding it to the performance review brings little value.

If, as a manager, I were to know the author of the feedback for one of my employees, I could do something about it. I can understand both sides of the issue and, when it’s not anonymous, I can take remedial action that may otherwise be impossible. For example, a personal problem could be fixed by encouraging the parties to discuss it — “Pete is frequently short with me in our Thursday afternoon meetings and it bothers me, have I done something to upset him?” — Pete has a call scheduled with the unreliable service vendor before the Thursday meeting and he is often arguing with them on the phone (and only I know this). I can encourage Pete to reschedule his meeting and then spend some time with the feedback author to explain the situation and ensure them they’ve done nothing to upset them. Of course, I would know both sides and can discuss this potential outcome with the author of the feedback and see if they’re happy to sit with Pete to discuss it — this would expedite the resolution to closure much quicker than me saying “Pete, you’re grumpy in the Thursday meeting and someone thinks you’re upset with them”.

I can find clarity on any feedback that I don’t understand (“Sarah didn’t do a great job on that work for Bobs Books INC” — “What do you mean Sarah? What was the problem?”).

Finally, I can deal with much deeper problems sooner that I could with anonymous feedback. When feedback is anonymous, the remedial action is broad, when it is confidential and I can seek clarity from the author and the remedial action can be precise.

Obviously, any outcome to a more serious problem would be discussed with the author beforehand, to ensure they are comfortable with the process and that confidentiality remains.

For the person being reviewed
If I know that my reviewers are not hiding behind a shroud of anonymity, I know that any feedback will be considered and of a higher quality. I also know that because my manager knows who the feedback is from, I can assume it will be fair and balance and that my manager will do what is required to make it fair and balanced if it isn’t. In short, with it being confidential and not anonymous, I know it will be fair and I know it will be meaningful for me in helping to improve myself.


Most of us don’t have the luxury of running HR or People Ops for the companies we work for and, for the most part, or demands for a better system of performance reviews (or NO performance reviews) will fall on hard-of-hearing ears. However, small changes like these I propose will move us closer to a better, fairer way of reviewing our staff and actually make sure it is a meaningful process that provides value for everyone involved.

Sorry, It’s Company Policy.

Possibly the most frustrating, emotionally bankrupt and redundant four words you’ll ever hear in the workplace.

I recently had the displeasure of hearing these words. Not, thankfully, said to me however. What made the whole situation worse was the person who uttered this charming sentence had allowed the policy to be bent only the day before.

“Policy” as described by the OED is:

a course or principle of action adopted or proposed by an organization or individual

“Policy” as described by most companies is:

a rule which we can use to bash you over the head in order that you do our bidding.

Policies are usually created as a sledge-hammer answer to a walnut sized problem. In the past, someone (or many someones) have done something which was bad for the company (or, another company) and this has resulted in their being a policy.

As a general rule, humans work for, or with you. As we all know, each human is a unique a beautiful snow flake. Trying to apply a “policy” to govern the actions of behaviours of your workforce as a whole is pointless and demeaning. Take the time to understand the people who work with you instead of putting your fingers in your ears and going “lalalalcompanypolicylalala”.

The only policy you should have is one of common sense and decency. Treat your staff like the people that they are, not the resources that Taylorism would have them be.


(Also, beginning the statement with “sorry” is also disingenuous – if you really were sorry, you wouldn’t have to say it in the first place…)

Does It Need to Be Said? Don’t Lie.

I recently watched Liz Keoghs “Let’s be honest…” YouTube that she did at the goto; conference. It was a fun and engaging talk, but I was frustrated and, frankly, surprised that there are companies or individuals that need to be told don’t lie. She used examples from previous positions to illustrate her many points, but there were two that stuck out for me (well, most of the points were salient, but these were the two that had the most impact on me).

The first was her statement that we’re no longer finding better ways to build software, we already know how to build software, we’re finding better ways to discover. Liz had the sentence from the agile manifesto on screen when she said this. Now, while I’m still not entirely convinced that a nearly 12 year old document is as valid now as it was when it was written, I believe that, if any of it is true, then that be is – we’re still finding ways to build better software. The constant evolution of our industry is testament to that. Don’t get me wrong, we’re much better at it now than we’ve ever been, but it would be arrogant to announce that we’ve reached the pinnacle of software development. Even if you’re a super-duper, high perfoming, cross-functional team, if you stop trying to improve, you’ll rot from the inside out.

This doesn’t mean that the rest of Liz’s statement is wrong, we’re also finding better ways to discover what our software should do, the fact that BDD is now more popular than ever means we’re trying harder to find out more about our products, not just how we build them.

The other thing Liz said in her talk was about user stories and how, we’re lying if they’re not actual stories for the user. Gojko said the same thing in his angry Monday blog post and it got me to thinking. Gojkos was a better example in that “As a user, I want to register, so I can use the site.” is probably a lie – no user ever wants to registers, it’s a necessary evil we perpetrate over and over again in order to provide some persistence for the users’ experience – however, we have the story because we think we should. It might be better phrased as “As marketing, I want the user to register, so I can send them email” or similar (Gokjo has other examples).

But, for me this misses the point. The stories are a catalyst for conversation, what they actually say should really be irrelevant. They could say “Login” and just a a placeholder. This will force the people involved to talk about what that means and how they should build it. It’s this conversation that needs the to be focussed and honest, not the story card. It also needs people to think differently about how they go about the discovery process and this, for me at least, is key to what both Liz and Gojko are saying.

I believe that, for the most part, we lie without knowing we’re lying (is that even lying?). We make verbal assertions about thing X to move us passed that to get to thing Y. The danger then, is that you don’t revisit thing X to work out whether or not your assumption was correct. Do the quickest, most expeditious thing to move you from nothing to something in order to find out if you were right, if you spend too long worrying about whether your story card says the right thing you’re going to miss out. After all, it’s all about the users, get it in front of them and let them tell if you’re lying.

Finally, I believe in starting from a position of trust, this means that I cannot entertain the idea that people are lying until it’s proven they are. The people around me (and, hopefully, you) don’t lie. They’re professionals and adults and shouldn’t lie. If we ever find ourselves in a position where we have to point this fact out at a conference, we’ve got much bigger, darker problems than what we write on story cards.

Is Legacy Code Actually Technical Debt?

Technical debt can come in many forms, but is your legacy codebase really technical debt? If you make decisions based on the knowledge you have at the time, can the problems these decisions cause later (either weeks, months or years later) be called technical debt? I don’t believe so. If we’re going to use the analogy of taking on a financial burden, then you wouldn’t be able to take on a financial debt without knowing about it and, if you somehow did manage to do that – would you even be responsible for the debt (if we think about how those who took on a credit card with PPI are now claiming all that money back)?

There is plenty of discussion about what technical debt it on the internet. For example,Wikipedia sez:

Technical debt (also known as design debt or code debt) is a neologistic metaphor referring to the eventual consequences of poor or evolving software architecture and software development within a codebase. The debt can be thought of as work that needs to be done before a particular job can be considered complete. As a change is started on a codebase, there is often the need to make other coordinated changes at the same time in other parts of the codebase or documentation. The other required, but uncompleted changes, are considered debt that must be paid at some point in the future.

Martin Fowler describes it as:

 In this metaphor, doing things the quick and dirty way sets us up with a technical debt, which is similar to a financial debt. Like a financial debt, the technical debt incurs interest payments, which come in the form of the extra effort that we have to do in future development because of the quick and dirty design choice.

My question is then, if you write code, or architect an app to the best of your ability, with the best code you can – no cutting corners, or missing tests – is it technical debt when you come back to the code months (or years) later, and it requires huge refactoring because it’s out of date?

I would suggest that no, it isn’t.

If it’s part of your system that hasn’t required work since you wrote it, then it’s simply legacy code. Technical debt is smelly code that you create deliberately. That is, you need to cut corners, or hack stuff, to get your code out of the door quickly. If you know you’re not writing the best code or architecting your application correctly, but you do it anyway, that is technical debt.

Accruing Interest

The thing about technical debt, like real debt, is that over time, intrest accrues. Let’s say that on day one, you deliberately create some smelly code in order to get something deployed quickly. You decide to fix it the following week. A week later, it takes you two days to write the code correctly.

Let’s say, however, that you couldn’t fix it a week later – something more important came up – instead, you could only fix it a month later. Now, because the codebase has moved on – other devs have committed code, you’ve committed code etc etc – what would have taken you two days to fix a week after you wrote it, might now take you five days to fix (assuming that for every week, the code gets complex enough to add another day to fix it). This means, your interest on this technical debt is roughly one day a week. So, if you leave technical debt for months, it’ll take much, much longer to fix and, depending on your position, every new dev you add to your team will compound that interest, until it spirals out of control and you end up declaring bankruptcy and re-writing the codebase from scratch.

Sound familiar? Might as well do it properly the first time round…

The Foundations of a High Performing Software Development Team

Get Busy by Dusk Photography
Ants are high performing. Yes they are. Can you lift 100 times your own body weight? No. Get Busy by Dusk Photography

(Article first published as The Foundations of a High Performing Software Development Team on Technorati.)

Building high-performing teams requires a foundation of core values in order to channel the traits and skills needed to be successful. Sounds like marketing blurb right?

Let’s break it down into manageable chunks.

What is a high performing team? The answer, I suspect, will differ depending on who you ask, but when asked of a team of software engineers or developers, they’ll tell you it’s a team that can do anything, do it quickly and do it right, while maintaining rhythm and a steady growth of both the team and it’s individuals. The question is, how do you build this team? Firstly, you need the right people. Hand-pick your teams, or don’t – it’s up to you. Great success can be head with constructing teams of star players as well as having teams of volunteers. After that, it’s about coaching the team to performance and that needs to start with core values.

These values should contain the following at least; respect, trust, openness, focus and commitment. If you get your team to help craft these values, they may come up with a few more. Make sure the team understands, or comes to an agreement on what each of these mean (focus is a good one, what does that mean? Can you have focus if you’re having fun?).

With the foundation in place, the skills and traits build on top of that. Depending on your team these will differ also, but some traits will always be there; the team will be able to self-organize, they’ll be totally committed, an unshakable belief in themselves and what they can do, they’ll be responsible and own their own problems, they’ll be motivated and engaged.

With the foundations in place and the traits emerging, a high performing team will emerge, they’ll get stuff done, the right stuff and they’ll do it with pride, skill and a devotion to quality.

‘Get Busy’ Photo by dusk-photography

The 8.9 earthquake in Japan sucks

My thoughts are with the people of Japan who, right now, are under an onslaught of enormous proportions from mother nature. First an earthquake to fuck shit up, then, if that’s not enough, a tsunami to mop up anyone lucky enough to have survived the initial catastrophe.

Nice one mother nature, sometimes you can be a bitch.

I saw a tweet today that said:

Hellicopter flying over me on Ocean Blvd urging people to move away from the water but herds of people still coming hoping to see a #tsunami
11/03/2011 16:52

And it reminded me of the sci-fi book, The Moon is a Harsh Mistress. Where a penal colony on the moon starts a revolution and demands independence from earth. The only weapon they have is a giant catapult used for firing barges of grain at the earth. They repurpose it to throw rocks. These impacts are worked out by a computer, so they know where they’re going to hit. They inform the people of earth when and where these rocks will hit (mostly government buildings and military installations) instead of people moving AWAY from the impact zones, they move toward them instead, to get a better view of the show … and end up dead.

Don’t be stupid people, stay away from the danger.

Goodbye Servelocity…

I used to have an account with Servelocity. They were fairly cheap, but their implementation of Plesk was shockingly buggy and their customer service was non-existent, even if you used the premium support line. I did kind of feel sorry for the staff working there as they even seemed to give up using the forum after a while as they would just get trolled.

Today, I received this email and it’s testament to everything that is wrong with a webhost that has this on their support page: As the majority of our customer base are highly technically able and in order to provide the most competitive product possible our private servers do not come with support as standard.

Dear Subscriber,

We advise that Servelocity Ltd.  will not be able to offer services to you after the end of March 2011.

We thank you for your support in the past.

Yours Faithfully,
Servelocity Ltd.

So long Servelocity.

Give Thimbl the Open Web award!


Why Thimbl should win the Transmediale/Mozilla Foundation Open Web Award

Thimble by zimpenfish @ flickr

The Telekommunisten Collective thinks that people should finger each other as often as possible. Maybe even several times a day, hell, why not once an hour? As often as you like!

People thrive on interaction with other people. Mutual stimulation is a deeply felt human need, a key characteristic of what makes us human. Imagine that instead of reading your status updates on Twitter or Facebook, your friends would just finger you instead.

The Finger protocol was originally developed in the 1970s as a way to publish user and status information, such as who you are, what you’re working on, and what you’re doing now. This is how the relatively few folks with access to networks posted pithy personal bios. From when colourful polyester pants were still groovy until the 90s people used to Finger each other all the time! Finger evolved into a completely decentralized system, where any user could finger any other user as long as they were both on the Internet. There were no big companies in the middle to control these users, or monitor them, or try to turn their personal data into money. Fingering was a personal matter between users, direct and unmediated, and nobody really knew exactly who was fingering who. Promiscuous, right?

Sadly, these heady days of open relationships slowly came to an end. Finger software was developed before the Internet had many users, and before development was driven by commercial interests. The idea was bold, but the software was primitive. Capitalists and their desire for profit have no interest in such freedom and promiscuity and chose to instead fund centrally controlled systems, in which they are intermediaries. Investors wanted control, so that they can commodify and monetize these relationships. Instead of users fingering each other with reckless abandon, people are now stuck with centralized, privately owned services like Facebook; chaperoning their relationships, imposing user policies on them, and monitoring and monetizing their conversation.

Back in June 2010, Telekommunisten had had enough! “People must be freed from these puritanical, controlling, consumerist, profit-seeking cults”, they thought. If witchcraft, wet shaving, rocker hair and skinny jeans could make comebacks, why not Finger? The Thimbl project was born, and immediately started working on giving the project an online identity and releasing tools to create a microblogging platform built on Finger, that groovy 70s protocol.

In October, Telekommunisten received the news that Thimbl was one of three projects nominated for Transmediale/Mozilla Foundation Open Web Award and almost immediately, Thimbl broke on Hacker News and the project started to attract significant interest. Thimbl started popping up all over the place: P2Pfoundation, ecopolis, alt1040, O’Reilly Radar, OneThingWell, Ecrans,… Evan Prodromou from competing service even took a playful swipe at us!

Finger was becoming cool again. The masses were longing to finger each other!

In a few short months, without much in the way of a marketing strategy and with a budget that could be stored in a matchbox, Thimbl has managed to gather over 250 followers on Twitter – the very service it someday hopes to compete with – and has been the subject of hundreds and hundreds of tweets. Thimbl even has a small following on, which is closer to the heart of Thimbl than the service with birds and whales. The website has over 300 ‘Likes’ with its Facebook button and the Telekommunisten Facebook fan page is abuzz with talk of Thimbl. The project has even gathered over 100 votes on the Drumbeat platform. Not bad for a project that was completely unknown to all but a handful of people when the award nominations where announced!

Still, the problem remains: Capital will not fund free platforms like Thimbl. Even with the buzz Thimbl has, building a community big enough to actually create a viable platform without financing is a major challenge.

Wouldn’t it be great if Thimbl could actually win the Open Web award? The endorsement of Transmediale and the Mozilla Foundation would be a tremendous boost for the project, perhaps enough to give the community the needed escape velocity to break free from centralized social media like Twitter and Facebook and make Finger the once and future king of personal status updates! Transmediale and The Mozilla Foundation had a great idea: instead of having a jury decide the winner of the award, present three projects to a community engaged with the open web and its technical, political and artistic dimensions. Mozilla had recently launched the Drumbeat project, just for this purpose, as a hub for projects that embrace the open web to get support and find contributors. So it made perfect sense for Drumbeat to host the voting for the award.

Drumbeat is a fantastic initiative from Mozilla and has a really promising future. However, Drumbeat is a relatively new platform. As a result none of the projects received much attention from existing Drumbeat users or from the Transmediale community jumping on to Drumbeat to participate. The idea that an impartial community would consider the three projects and select a winner didn’t quite work out. Instead, it has become a competition to rally the existing supporters of the three projects to sign up to Drumbeat and vote for them specifically, without genuinely considering voting for the others. This means that, honestly, the vote count is about as impartially meaningful as a Florida election run by Diebold.

Thimbl is up against two cool projects as candidates for the Open Web Award; Booki, the book publishing platform behind FLOSSManuals and many great book writing sprints, and Graffiti Markup Language, a project to enable analysis and archiving of graffiti writing which has the support of many awesome, large and active communities like F.A.T. Lab and eyebeam. If the open web award is really meant to give well-earned support to existing, successful projects like Booki and GML, then we will celebrate their success with them at the award ceremony in a few days. We readily concede that Thimbl has not yet achieved anywhere near what these projects have and that our community is much, much smaller and far less known.

Unless we succeed in our desperate bid to convince Lady Gaga to dump Polaroid and instead dedicate her star power to the cause of ushering in a new golden age of rampant fingering, we are very unlikely to win based on Drumbeat vote count. But if Open Web Award aspires to “clearly demonstrate the unbound potential of the open web in ways that can spark new thinking and practices,” as stated, then, damn it, Thimbl is the most about the open web!

We live and breathe the open web, directly addressing the technical and social issues facing the open web in every aspect of the project, in the code, and in our manifestos. We talk to anyone who will listen about how the open web is not just critical to the future of the Internet, but to society itself. And people are beginning to take notice.

Selecting Thimbl for the Open Web Award at Transmediale would be one heck of a powerful spark. Igniting the new thinking and practice that led to the idea of Thimbl with a clear and bold statement of support for an open web that is truly open! The multitudes are trapped and frustrated, clinging to their social interactions within sterile, commercial platforms, longing for wanton, unbridled realms of contact.

Join us in inscribing upon on our banners the revolutionary slogan, “Don’t be a Twit, it feels good to be fingered!”

Give Thimbl the Open Web Award!

With Kind Regards, Your Telekommunisten. /////////////////////////////////////////////////////////////////

(psst… pass it on)

No holiday allowance, company credit card AND I’m the boss?


37signals, their staff and, specifically, Jason Fried and David Heinemeir Hansson are a constant source of inspiration to me. I devoured their book ‘REWORK‘ in one sitting and always enjoy the freedom their staff have to post on the company blog. Today, I found this article on called Un-Manage Your Employees and, frankly, it’s both awesome and a bit crazy.

In summary, they have a different member of staff manage the teams every week. They become the go-to guy, the decision maker, work out an agenda and write the company update. It’s an interesting approach and one which, I’m sure, keeps everyone in the company engaged. I imaging no one says ‘I can’t do it, management won’t let me!’ … especially when they ARE the management.

The other interesting things from the post (and stuff I knew already) is that, every member of staff gets a company credit card, they simply email receipts to a group inbox for auditing purposes, there’s no signoff and no one is required to get permission to buy stuff. Also, they don’t track holidays or sickdays. In fact, David Hansson suggests that they have to REMIND people to go on holiday. No one abuses either of these perks. 37signals staff are passionate and dedicated to their work, partly because of the ethos of the company I guess.

Working for 37signals must be very cool, but I imagine it would take you a while to get used to it. ‘What? I have no holiday allowance? I can take holiday when I like AND I get a credit card?’. New starters must be constantly looking over their shoulders, especially if they’ve come from a more traditional, corporate background!

I hope 37signals continue in the same vein. They make some good products and stand as an example of how great company can be to work for.