The best leaders are not always the ones with the best answers, but they are usually the ones with the best questions.
Power Questions by Andrew Sobel and Jerold Panas has a great summary of the of mindset of a good questioner…
Are you a software craftsman? Do you value growing your skills as you simultaneously learn from and teach the other members of your team? Want to help us build the world’s best cross-platform mobile solutions for field service workers?
The folks that fix your A/C when it’s 100 degrees and keep your toilet from backing up into your living room deserve the best software technology can provide, and we need your help. We are looking for a key addition to our Agile/Scrum/XP team that is building a highly scalable, event-driven, mobile-enabled platform. This person will be test-driven and team-focused. He or she will be a mentor to team members new to TDD and some of the other XP practices.
Must haves:
Highly valued:
Voted as one of the Top 30 Places to Work in NJ, Marathon develops supports and sells SaaS software and marketing solutions to the SMBs in pest control, landscaping, HVAC and other service verticals. Comprehensive benefits package including vacation, insurance, and company sponsored profit sharing plan. Contact me at efarr@marathondata.com or @efarr.
There is no more leveraged activity in building an effective software team than recruiting. The hours or days spent choosing people to add to the team will have a disproportionally large impact on your team’s effectiveness.
If you haven’t already read Joel Spolsky on hiring, you must. Now. The two big ideas I learned from Joel are still the most important ideas in all of my recruiting success…
If you cannot answer the “Should we hire this candidate?” question with an enthusiastic “yes,” then it’s a no-hire. There are no “maybes.” The reasoning is simple—a mistaken hire is much more costly than a mistaken no-hire.
I find this principle easy to agree with but difficult to follow. Great developer are always hard to find. The pressure “be reasonable” and hire a maybe candidate has caused me ignore this principle. I’ve regretted it every time.
There is a simple rule of thumb to hiring any developer on any team. You are looking for two things: the candidate…
Look at the following grid.
You would never intentionally hire Useless, but lets look at two easy hiring mistakes.
Tinkerer: Someone who is smart, but doesn’t get stuff done. This mistake is easy to make because he gives good answers to typical interview questions. However, once you hire him (or her) you find that nothing actually ships. Our industry is full of smart people who are content to learn and write code, but don’t want to commit to finishing something. They never have to deal with customers or operations or any of those messy details because they are always almost done.
Mess Maker: Someone who is not smart, but gets stuff done. This mistake is easy to make because he can tell you all about the projects he has completed. However, once you hire him, you will find that he leaves a trail of messy, fragile code behind him. You will spend more time trying to fix the messes than you gained by having him create them.
The effective developer is the one who is smart enough to appreciate the competing factors and trade-offs that come into play when creating software and is driven to see his solutions solving problems for actual users.
Identifying the smart developers who get things done is no easy task. I’ll have more to say about that in future posts.