4 ms·
Why should you get a say in who works with you? As a team lead I'm trying to find the right balance. If we hire only people the current devs like we endup hav
by wolco 8y ago
Why should you get a say in who works with you? As a team lead I'm trying to find the right balance. If we hire only people the current devs like we endup having too many similiar developers with the same mindset and shortcomings.
Trying to have a more diverse, balanced team means you don't get a say.
- hopler 8y agoWhy do you think your good people don't want to work with people that complement them? Why do you think you are so much better than them at balancing a team? I pity the team that has to work with such an egostistical openly hostile lead, but I imagine it must give you plenty of experience with recruiting and hiring.
- wolco 8y agoYou want someone as equally as good as you who complements your skillset. I want someone different than you who renforces areas where you are weak so the product is stronger overall. Getting along is good overall but being able to debate from different perspectives is important. What you think of the hire shouldn't matter because you are looking to perserve your place on the team and that taints your judgement. You shouldn't hire your own boss for similiar reasons. You should never hire your peer.
- lordnacho 8y ago> Why should you get a say in who works with you? The feeling of autonomy is quite important for a lot of modern knowledge workers. There's more than one lever, but if you force enough of them, it becomes a crap place to work.
- ddingus 8y agoActually, doing that means everyone getting a balanced say. Two way street. If you make it one way, it is all on you, and when that team says that, you get all the credit. Good or bad, and the team knows it. Will definitely throw you under a bus, given cause. If you make it a balanced discussion, everyone taking shared ownership, then it is on everyone. The difference shows up in two places: One, bad call. The team can come together, own it, and letting the bad call go is not so rough. The follow on discussion is rational and productive. The other one is getting that different point of view. Having that discussion sets great expectations. Being challenged, getting better, all that is welcome. A team that does this successfully tends to congeal and do extremely well. Play it how you want to play it, but I definitely prefer to have it all on the table, open, team discussion, frank, high value. Mix in a reluctance to blame and shame, favor choices outcomes and data and you get a team that can weather the good and bad, everyone helping everyone too. The lead is responsible for cultivating that culture, empowering people, resolving conflicts, etc. Also owns team business meetings, data, all that. Just saying.
- wolco 8y agoI've been in both situations and places inbetween. If the team lead owns it they should take the blame and give credit to the team. If the team kind of owns it then everyone is off the hook or on. It also invites the owner/vp to talk directly with the programmers which undermines the lead. No one mentions this but the lead in development is one of the rockier jobs. You rarely have power to hire/fire without a manager, all development problems come your way, credit goes to developers. You have very little power compared to other industries.
- antt 8y agoI would like some evidence that balanced teams are good. Given that in higher dimensional finite spaces all the points are close to the edges of the space you would expect the most unbalanced teams to be the most successful ones because they can explore the parts of the solution space where you have the highest chance of finding a profitable solution. Unix was not build by well rounded people. Xanadu was.
- wolco 8y agoThe Unix team didn't interview each other the Xanadu team probably did. Non-well rounded people would do less well if the decision was up to peers.