The art of balanced teams

With a no star team you get micromanagement hell, the one star in a team will become a nanny with a bell, but make an all star team and the project will look like an Escher dream.

In a respectable michelin starred Japanese restaurant serving sushi you need about eight years before you are allowed to cook the egg sushi. During this time you’ll find yourself cleaning tools, washing plates, cutting and chopping and so on. Very boring, but when you start you have the energy and the passion of the young so you attend these little chores with your eyes on the big shots who lay out the fish, rice and seaweed.

In a development team you could make the mistake to believe that if everyone is an ace you’d get an awesome product in half the planned time. But its really not the case and i think this way of thinking might be the main plague in failed young businesses or in the “special projects” of large enterprises, you know those “anti disrupt” projects.

If you believe that having a person you pay top salary slice PSD files is OK because he or she is a “front end developer” you are wrong.

Because of this I make the case for a diverse team of varying skill levels. Just as a sushi chef needs its apprentices to blame every day, and the Jedi master had his back covered by some young Padawan, so do your senior or expert team members need the help of the young starter developers. You need your interns for their energy, just as much as they need you for some insight. You should love back your juniors for their efforts, just as much as they love you for giving them a chance. Why? Because otherwise your “aces” will be plagued by boredom.

If you consider that a senior developer, with 10 years of hands on experience, paid at market level, should spend eight hours a day putting data into Smarty templates you are wrong.

Now some people hide behind the truth and tell you that talented and nice folk do everything it takes to ship and they don’t complain. And it is true, but for heaven’s sake, discern a bit here: there is a ginormous difference between bootstrapping an idea, a hackathon or simply diving in to solve some urgent issues — and churning daily at endless cascades of small tasks that all look like sample chapters from “Web Development for Dummies, the 1999 edition”.

The plague of boredom leaves hard to conceal scars on your product.

Sometimes is utterly impossible architectures (since there is nothing else interesting i’ll architect the hell out of this form validation class), other times is simply plain mistakes because of self assured code churning (oh, yes, security trough obscurity is a great idea).

Currently simply browsing around job boards shows the need for juniors is close to non existent. Yet from Bill to Zuck every big shot invites people to learn coding. How are they, all these people learning to code, gonna become anything more than more weight on the industry’s median salary, if nobody teaches them anything? The published stats of the age of Stack Overflow contributors stats clearly show the value experience brings, and it also shows the huge energy discrepancy between young developers and their older brethren. Nevertheless internships are far more present than entry level positions probably because internships are not paid. And then the interns should become at least mid level on their own?

If you consider that you don’t have the time to train people: you are wrong again. You do not train anyone really, what are they dogs? People learn and your only objective is to get eager or fast learners, or, ideally, both. It doesn’t change a lot if you have the young, rushed startup or the monolithic enterprise vibe, having juniors and mid levelers will definitely bring in, well, kind of like the spring: energy and “an unquenchable thirst” for the future.