Tag Archives: leadership

To hire an expert developer or not to hire it… that is the question

HamletI guess that’s an easy question, right?

It’s fairly easy to know if a developer is an expert in some technical field, programming language or framework. Just read his or her resume and search if the tech is in her assets, check if there is any real working experience with the particular tech and for how long. That would give you a pretty good idea (in theory) of what this “expert” knows. Finally you’ll have the option to test her the first days doing real work and that’s were you can realize if your assumptions where good or not about her expertise. Pretty easy.

So I imagine that your answer will be to try to hire the expert. And you are right, I always try to do that also.

Of course we all want to hire the expert, but a good leader has to see beyond the surface of the evident. Should this question be the main purpose of your search? Should this be the most important factor in determining who will be your next team member?

During these past months I had the chance of meeting a lot of people from the IT area, programmers, startup guys, company owners, CEOs, CTOs, you name it. In some point of the conversation with them we usually started talking about forming teams, how to do it, and how to search for new members for that teams. And almost always people say the same thing: “I want experts in such and such tech”. “I’m tired of people saying they are experts when they are not!”. “If you don’t have an expert in tech X your project’s most likely is going to fail”, “I always search for experts in Z framework, it’s not negotiable!” And a lot more things that what really show is that they are only focused in searching the best expert they can find for a particular technology and nothing more.

This situation keep amazing me all the time I think about it. First of all because, although they have only this objective, most of them fail to detect if the person is really an expert at all; and they realize the lack of expertise well after the hiring process, when the projects have already begun. That doesn’t talk to well of the recruiter abilities! And second, but more important, is that these people are not taking into account a critical factor in their recruiting efforts: technology and software development are always changing and evolving.

Technology and software development change and evolve constantly. Today you are an expert in a language and framework, but tomorrow a new library is published… and what are you now? A “vanishing expert”, so you’re not so cocky now, eh? And if you want to keep your cocky attitude, you should learn the new features. This happens almost daily and with every tech you can imagine. New framework versions, new programming languages releases, problems encountered during development that are only solved using a library that nobody knows, testing libraries and frameworks, version control tools, continuous deployment tools and servers, internal scripts… the list could continue almost indefinitely. So every “expert” in a particular technology, actually is a vanishing expert, her days are counted. So that’s want you’ll get at best when focusing your recruiting efforts in tech experts alone.

After all this, I guess that you are starting to see where I’m going.

When you recruit your next team member, your main focus has to be finding the expert, but not in a particular technology, but instead in learning new technologies. You should search for the guy that enjoys learning new things and evolving, that can become proficient in a small amount of time with the new techs needed, that is not afraid of testing new things, that has the confidence of finding a solution to a problem she has never seen before, that has the capability of investigating new things and learning them. A developer that could meet these requirements, will become automatically a proficient developer with any tech that you put in front of her. And that’s exactly want you should search first!

How to detect these things is the topic of another post. But for now just remember this guy, and ask the Sword of Omens, to give you Sight Beyond Sight, in every recruiting effort:

Sight Beyond Sight“Sword of Omens, give me Sight Beyond Sight!”

And just to make the fans cry:

ThunderCats by ThunderCats on Grooveshark

We don’t need another hero!

Hero developers. That breed of super heroes that solve every damn coding problem that arises in our software projects. They are fast, and usually they complement it with lateral thinking, boosting their quickness with solutions that seems taken out of a magic hat. And it seems they are always there when we need them. They have a great commitment to the project, they love to save the day, even on weekends! They seem to have an affinity with programming languages, they even understand the ones they have never seen before… and quickly.

New requirements enter the show with no adjustment in schedule? – No problem, we have Superjavaman with us!

Bugs, bugs and more bugs!!! What are you doing people? PHPman, here… take the key of the office. Stay this weekend, please. We need to be ready to deploy on Monday! Refactor anything you want, I don’t care, but make it work! Oh… yes, and turn off the lights when you finish. Thanks!

Client: “What? I didn’t mean only A and B… What I meant was that we need the app to do A, B, C, D, E, and all the remaining letters of the alphabet!” – Team Leader: Uuuups… better start lightning the C#Signal, we are gonna need Supersharpy right now!

This guys are really great. It’s always nice to have one of them in the team.

But guess what?… If you need heros more than once in a while… you suck as project leader!

Yes, and I’m sorry to tell you this, but it’s true. Don’t take it personally. I have fall into the hero trap myself more than once, so I’m also talking about my own problems here. When a software project has problems, they are usually caused by a bad leadership, and not because of bad developers.

Of course, this is not the way that project leaders want to put it.

“Hey, project leaders don’t code, so why are they responsible of bugs?.”

“Project leaders are not the client, they are not to blame for those unintelligible requirements. The client is!”

“Wait a minute… as a project leader I usually double check all time estimates with a developer, so I’m not the one to blame about bad schedules.”

Really? Is that easy? Are developers so awfully bad coders that they introduce bugs in every code they touch? And if it’s so… you didn’t notice until well advanced in the project schedule?

Aren’t project leaders the responsible of the project, including understanding what the client wants? And if this is not clear enough, don’t they have the responsibility of at least communicate this to the client and try to solve the issue?

Do project leaders come from a parallel universe where time works different than here? Why they can’t understand that time estimates are only that… estimates, not promises? It seems to me that not matter if the project leader was a developer just until yesterday… today is project leader, and now he forgot that a good time estimate requires time. You need to know exactly what you have to do in order to tell accurately how much time is going to take. More time, better estimates; less time, worse estimates.

And all this gets worse at corporate levels. Usually at big companies every one functions in Pontius Pilatus mode, trying to avoid responsibility of any decision. They only lack the water bowl… but if they could have one, the picture would be complete! (I guess that I’m going to code a mobile app of a water bowl, so every time this guys have to take a decision, they can tap the bowl and a voice in latin says something like “The decision is yours… not mine….”).

So please… we really don’t need another hero. We need common, normal, ordinary developers who work good enough to get the job done. But what we really need is good project leaders. The ones that know that software development is a team effort, and know how to facilitate the workflow between team members. The ones that helps them solve problems, and that take the rocks out of the road, not the other way around!

Is your responsibility as project leader to make your team fit together, and to help them not to loose focus in unimportant tasks. Bugs are your responsibility… just ask developers why they have them, and if there is something you can do to help. Requirements are your responsibility… so be sure that everyone understands exactly what has to be done. Schedule is your responsibility… so take the action needed to make the client understand what an estimate means, and don’t fall into the “Holy Bible Syndrome”. And last but not least… please, hear what developers warn you about, they usually make their warnings when there is enough time to do something. If they talk… listen.

So here ends the software development catharsis… After all this, I’m just hoping that I have some readers old enough to remember this:

We Don't Need Another Hero (Thunderdome) by Tina Turner – www.musicasparabaixar.org on Grooveshark

Mad Max: Beyond Thunderdome

Mad Max: Beyond Thunderdome