Management Team. The main idea is to get your developers (QAs, etc) do their job how they think is right (because they have more knowledge in it) and not micro manage them.
Idea sounds reasonable, but I have some doubts in situations when people don't have good interperson skills.
Let's see an example with Pet and Jack. They are both senior developers in a team that develops a new version of super product X. They have a product manager who made awesome functional spec and now they are discussing an implementation. Pet thinks that implementing with B-trees will be better, when Jack really likes Red-Black trees. Now, they have a pretty straightforward way to figure out who is right - kick the code in and compare which solution is better for the particular situation. Easy, right?
Wait... what if you need now to choose if you want use library A or library B? And you can't easily anticipate future problems (ops, library A had an issue on HP-UX when you have MySQL demon running), neither you can implement fast enough both solutions and test which one is better.
Even worth, if library A actually a full blown framework for solving problems, and you just need to customize it, and library B is a set of functions which you can use, but you need to develop a wrapper around it to make it work. I mean, when you can't get an abstraction level between your code and a library to decide later which one you wanna use.
Pet and Jack will be arguing wich library is better to use, and because Jack doesn't actually like to speak much (yep, he is better expressing himself in code), he decides to give up and agree with Pet to use library A.
Now, you see +Joel Spolsky has a Team Lead on the chart, which presumably should solve arguments like this. He is taking responsibility for making large design decisions, selecting tools and setting up conventions for his team. For this, Team Lead should have an experience with a lot of things and be very good in judging what will be better for a team and further development
Returning to our example, Pet got promoted to Team Lead, because the guy who was Team Lead before was caught sleeping with CEOs secretary and got kicked off. Pet was chosen because he has better "people" skills and is very knowledgable about product team developing. O yeah, and he is pretty good in beer-pong (Jack didn't go to that party, so we don't know if he is better then Pet).
Pet got a request to implement new feature for next version and sat down with Jack to design. Of cause Jack has some ideas about better design - but he already argued once with Pet and got kicked. Plus, Pet now his boss. So he listens to Pet's ideas, which are mostly good and even if there are some not-so-good design decisions - he will just agree.
So in result, we see that people skills actually worth not just promotion, but who's ideas will be implemented.
No comments:
Post a Comment