Something I always wish existed was a recruiting platform that hired a team as a whole. Today it's pretty much just a recruiter coming to me, and saying "Hey wanna change the future at xyz?" where the only criteria that I might work is based on my skill set on my resume. Instead i'd rather fill out a survey, and get matched with some people I would probably work really well with. Maybe you hack together for a weekend. Once your team has a set of strengths and weakness, and a price, companies can bid, and the team as a whole judges where to go.
I think how well a team works together is sometimes more important then how much knowledge you may have of some arcane framework.
Just a couple of anecdotes: one thing I've seeing in 2 diff companies now is the new CTO bringing in their posse. It not only didn't work (for the CTO and his gang), it also undermined the rest of the company, who immediately felt "left out".
I've also watched an entire frontend team quit and go work at a different company because, well - they were a pretty well-knit team, but more loyal to each other than to the company...
I think management "teams" are a completely different beast to "regular" teams that are mostly individual contributors. I think it would only really be smart to hire a "regular" team as a unit.
The frontend team case in point didn't actually have any managers. That's complicated because what you're buying there is a group of people with already-set practices and that works well together - if you're not careful, you'll end up with a "silo" that just doesn't communicate with the rest of the company.
That kind of thing happens when a big company acquires a small startup, for instance (and it's the main reason I always see acquisitions/acquihires failing spectacularly) - again, all anedoctal...
My current company consists primarily of people who got the shits with our previous, much larger organisation. The problem is any new hires will be years behind on organisational culture (clients, history, in-jokes, references, shared adversity, etc). Still, 'having a strong team' is one of those good problems to have.
Yes, that sounds like a terrible idea - unless the CTO and his gang were very self-aware and made sure they integrated themselves into the team. Which it sounds like they did not.
1 - A team can succeed in one environment but fail in another.
2 - If the team does fail, you have a lot more rebuilding to do.
3 - Teams that are independent of company can have different loyalties. The principal-agent problem [0] gets a lot worse if an entire team is being held hostage.
4 - Many times you're not building the project team from scratch. You start with people who have succeeded on other projects.
Gabe Newell at Valve believes in this and it worked well when they brought in the team that made Portal.
"RPS: We’re really interested in your view on the independent games scene. I’ve just spoken to the Portal team and discussed Narbacular Drop and the job offer, and their shock and delight at finding themselves in that position…
Gabe: Something that gamers should probably understand is how important it is that game teams stick together. No matter how good a job a team does the first time they make a game they’re going to do a much better job the second or third time. There’s just so much value in a team having shared experiences to draw on, and my reaction looking at these kids was that they had done this fabulous thing. I go to all these trade shows and see all these tedious, derivative, lifeless games, and these kids had done something that was better than 98% of the gameplay I see. The idea that they wouldn’t work together again was a tragedy. They needed an opportunity to work together and ship a full-on game. If they were able to do that exciting a game the first time, then it’s nothing to what they’ll be able to do in the future. It turned out to be a really good idea."
Reminds me of Jim Collins' Good to Great. Step 1 - Get all of the right people on the bus, even before you know where it's going. Steve Jobs would hire the right people even before he knew what to do with them. Netflix hires the best of breed knowing that titles and roles are only as relevent as the task at hand. Being able to rely on people to work together, collaborate well and get the job done with quality is the definition of success.
This happens all the time - they are consulting firms. I have plenty of friends that get hired as teams and go in and do excellent jobs that a single person could not accomplish. The sum is greater than the parts.
I read a study of 'lift outs' - teams poached from one firm to another, to perform similar roles [1]. In investment banking, these liftouts are focused on one or two key analysts who bring juniors with them to the new firm.
Sometimes these worked because the acquiring firm had no expertise in a particular area. The biggest impact moving in teams has is that you are familiar with a lot of the business customs already - you have a support team in place. Your shared network can grow a lot more quickly. However, with a liftout, you have enormous pressure to succeed; there's less 'onboard' time since you should know how to work in your team already.
I think it's way more important. When you're working productively with people you enjoy working with, it's almost hard to imagine feeling bad about your job.
This is one key advantage of startups, actually. Just take your dream team, and co-found a startup with them. Find the business that your particular group can excel at. The more this becomes a viable alternative to just taking a job, the more we'll be optimizing the matching of great teams to big opportunities.
That's a fun way of thinking, but it distorts the reality of a startup. Startups are far more then JUST a team, its a combination of a good idea, and resources. Added to that, the team is probably a much different kind of team then what your average enterprise is probably looking for. Though much of the skillset that makes a great startup team converges with what makes a great say enterprise software team, there's also significant differences. For instance a startup team isn't going anywhere without a member with suburb marketing skills. In an enterprise though the team that markets the software is very likely to be different than those that develop it.
Of course you need a good idea and resources. But success in an enterprise environment also requires more than just the team. It requires developing a clear vision of what you're going to build, participation from marketing and sales teams, and navigating internal politics. Not to mention ongoing commitment of resources. If you think about the mechanics of providing reasonable guarantees of such support to a group that already identifies as a team, you'll find they mostly reduce to either venture investment or consulting service contracts.
It feels like you may, in the longer-term, sacrifice different thinking for productivity. If I worked with the same team for years, unless we were some how really, really pushing ourselves as a group, I think I would miss out on whole worlds of approaches to problems.
Thanks for posting this link, I went looking for it when I saw the parent comment. I think there's obviously a lot of value in this (with some drawbacks as well). It's strange that acquihires are typically the only time it happens.
This is very similar to the way my team of subcontractors works. The only downside is when you are the only member of the team who is not up for a particular job. That can cause some friction.
The business model for app companies and contract software firms comes to mind. The team is really a small business itself and signs contracts with other companies to build things. Is there something different to these that you'd see? Or is it the idea of a team being hired on directly by company after company vs building to a contract?
We already do this @ Gigster. Except you don't get hired to be full time employees. You get "hired" to work on short term projects (that you can accept or deny) which is arguably more fun.
Multiple developers are common on (mobile) apps that require custom backends and larger projects that need to hit a tight timeline. All projects have more than one person on them and typically at least 3 (dev, pm, designer)
The problem with this approach is you would inevitably end up breaking the team as your budget may not fit the team available. This approach also ignores the managers who allowed the team to flourish in the first place. There is something fundamentally wrong with this whole article as it ignores the high hiring bar that Google already has in place which creates a self selection bias.
The problem of hiring individuals to join the firm still exists though. Although I like the approach you propose more than the "dump a bunch of resumes" approach.
I think how well a team works together is sometimes more important then how much knowledge you may have of some arcane framework.