SAPessi

Another post about my experiences with startups.

The one important thing I have ascertained about programmers during my career is that good ones are hard to find. Furthermore skillful developers tend to be ego-maniacs (I am no exception). The people generally portrayed in films as shy “nerds” are really expansive, loud and boastful persons. After all why shouldn’t they be; a startup’s most important assets are its people, and developers are a vital part of the organism. On the other hand it is also true that everybody is important but nobody is necessary.

In all the startups I’ve worked for, particular emphasis was put in the recruitment process, especially whilst hiring members of the initial core team. Which doesn’t mean only finding smart competent people, but also making sure that they’ll fit in with the rest of the team. Therefore it is very important to have every member of the initial team meet the candidate and make sure that they will be comfortable working with them; even people from different departments, marketing directors should meet programmers before an offer is made.

The other thing you have to make absolutely sure of is whether your newly-hired programmer can accept the technical leader’s style. The manager/CTO (call it whatever you want) has to be flexible, but at the end of the day he/she is still running the show and you can’t really afford to have a small team destabilized, especially when the disturbance undermines the leader’s authority.

I have had to interact with quite a few managers, each one with a different approach to the development process. The two most common and distinguishable modus operandi are certainly the autarchic and the unconstrationist (new word I just came up with).
The autarchic wants to be in full control every step of the way and put a two cents in every decision. The “libertine”, on the other hand, will take care of the big picture and leave the individual programmers to make decisions regarding the piece of functionality they have been assigned.

Neither attitude is wrong. However, I generally adhere to the more liberal approach, hence the title of the post. Being in charge of something every step of the way certainly helps prevent bugs from being introduced, if not because of a CTO’s superior experience because two brains are generally better than one. Anyhow if you try to be involved at every level of the development, from the requirements gathering and analysis to the practical development you’ll quickly end up being overwhelmed with work and with a crew perhaps not prepared to scale and be in charge of new hires themselves.

Contrarily leaving developers some independence in their restricted realm helps boost you team’s morale and prepares a normal programmers to be in change of somebody in the future as the company grows. Admittedly this approach will leave the whole system more exposed to potential bugs, introduced either for a technical mistake or lack of wide-angle-view-to-future-developments of the programmer in charge. The second drawback of this method is that you’ll most likely end up with a code library written with very different styles, hence harder to maintain and get used to for new people. Be that as it may, I still stick with “Celebrate Diversity”.
There’s always going to be a better tool or programming style than the one used when developing something. However, asking a proud programmer to change his code and do whatever you asked for exactly your way is worse than a punch in the guts.

As I said before neither approach is wrong and it’s purely a personal decision of the person in charge. It is a very difficult balance to strike. Ego-feeding is good, keeps the spirits up and developers are more likely to work harder and better. Unfortunately, programmers are human and as you leave somebody in charge of a single piece of functionality there might be nobody to find that stupid bug which could have been caught in a second by an additional brain.