3 ms·
> However building teams on in individual hires take too much time and effort, with no knowledge about compatibility or assurance regarding the resulting effici
by d--b 9y ago
> However building teams on in individual hires take too much time and effort, with no knowledge about compatibility or assurance regarding the resulting efficiency of the team
Yes, but the cost of integrating too different cultures is also pretty steep. A group of people will tend to resist change stronger than an individual person. When you hire new people, they tend to bring what they know, arguing with things like "trust me, we used to do it that way in my previous company and it was great", now if the 10 people you hire think the same, you will have some serious cultural problems.
That said, I've seen a team (6 people) hire happen once, and it actually went well. The hired team was composed of super nice guys though and integrated very well with the existing team.
- oDot 9y agoI can't understand why that's a problem. I am a great believer in "strong opinions, weakly held". Now, I do agree that "trust me it's cool" is not a very good explanation, but if a good one is provided, and if it's better than what you currently have, you should listen up and change your ways. Otherwise that new hire will go on HN ranting about you saying "trust me, we're doing it that way for a while and it's great." Do you hire for skill or obedience?
- d--b 9y agoWell, in fact you do need a certain obedience from your new hires. It's a bit optimistic to believe that every choice a team makes is 100% rational. Choice of a certain technology, coding language, coding style, management methodology, all these things are fairly cultural in the sense that people tend to push for things they're more confortable with. My point is that integrating 2 teams of people where each group has a strong culture is a hard thing to do. It's really natural to form camps. For instance, you're the cto of your company, and one of your principle is to limit your dependency on third party components. And you hire a team, where their culture is to build quickly on a lot of 3rd party libraries. Nobody's fundamentally right or wrong, but the new hires will think that "we've joined this super controlling company that ties our hands and we can't do shit". And the cto will think: "crap we've hired this team of cowboys who will add a lot of operational risk to our processes". And in a meeting where you try to explain your principles, it's way harder to impose your culture when you're fighting 10 people than if you fight 1 person.