Skip to content

Attracting Talent

Dear Reader,
(UPDATE: I podcasted this blog at DevZone)
Yesterday on FaceBook, someone asked this question.

What does it take to get a talented person to join a startup.

Here was my response to them, expanded a bit since I’ve got more room here.

I don’t pretend to speak for all professions here, just developers. Accountants, sales people and phone sanitizers will all have different reasons for joining a startup. However for developers, the answer is not difficult; to attract the best talent you have to pay attention to a few details.

1: Respect them and their opinions.
If a developer thinks that you think you have it all figured out then he/she won’t be very happy. Most developers thrive on technical challenges. They need to know that you need them to solve your technical challenges. They also need to know that you will listen to them when they do solve it. If you’ve got it all figured out then you don’t need a developer, you need a coder, someone who will come in and write the code you spec.

2: The tools to do the job.
A lot of people will tell you that developers need toys. I think this is myth. Developers don’t need cute cube toys. They don’t mind them but it’s not a job requirement. Developers do need the proper tools for the job. There are a lot of places you can cut corners when starting a company, hardware for your developers should not be one of those places. Developers will push a computer harder than anyone else in your company, period. So give them the tools they need to do the job.

A red flag to any developer you interview is seeing the CEO walking around with a fully loaded MacBook Pro while other developers are working with last years Dell “Specials”. I’ve seen it happen before. Great hardware should not be a badge of honor, the higher up in the company you go, the better the computer you get.

To developers, hardware is the tool they use to get the job done. So give them the right tools, let them do the job. If you don’t know what the right tools are, ask them. most developers are happy to tell you what they will need to get the job done. it

Oh and never trust a developer that, when presented the opportunity in an interview to ask questions, does NOT ask what kind of hardware they will be working on.

3: Freedom to create
Most developers are more artist than engineer. They like to create elegant solutions. If they see that you are not open to innovative solutions then they will most likely not be interested in the job. This does not mean you need to just throw a developer a problem and assume they can solve it. Developers need a structure to work within. Make sure that all potential developers you interview know that you have a process in place for development and innovation. Let them know that you are not just going to throw the problem at them and expect them to immediately understand all the issues surrounding it.

4: Freedom to work where they please.
If you want to find the best talent, you have to look outside of your geographical region, no matter what region you are in. When you do find the right person, let them stay where they are. Chances are good that they live where they do because they like it. Why force an upheaval on them when it’s not necessary. Technology now affords managers all the tools necessary to manage remote workers. I’ve said it before and I’ll say it again, any manager who feels that they have to have everyone in the same room to manage them, is a poor manager.

This segues nicely into the “cube farm” argument. I’ve had many managers explain to me why it’s best if we shovel developers into a cube farm because the close interaction makes for better collaboration. To this I always give a resounding “bunk!” Cube farms are a detriment to good software development. Collaboration between your developers is important. These days however, most of that can be accomplished with the right software tools. Developers need a door they can close. An office, where where he or she can escape the steady drumbeat of corporate life is one of the greatest gifts you can give a developer. Working remotely, from home, the locally owned, non-chain coffee shop, or even in the park on a nice day, are usually much cheaper solutions than office space.

That’s my list of details you have to pay attention to if oyu want to attract the best developers. The thing that this list doesn’t cover, but is an important off-shoot of this conversation is that top talent likes top teams. To build a great team you have to be willing to follow the old adage “Hire Slow, Fire Fast”. If you do finally find a developer that meets you criteria and you feel can fit in with your company, hire them and welcome them to your team.

This doesn’t, however, end the process. It should be obvious to you very soon whether you have made the right choice or not. While respecting local labor laws, don’t hesitate to admit you’ve made a hiring decision mistake and let a developer go.

Until next time,
(l)(k)(bunny)
=C=

It’s all about respect

Dear Reader,

Ok, it’s been a while since I wrote last and I apologize for my continued absence. Thanks to several friends, some of whom, I’ve known only a month or so, unemployment has been more like a series of short freelance gigs. Guys, I’m truly appreciative.

However, that’s not the subject of tonight’s post. Tonight I want to give props to all my Code Monkey friends out there. Homies, you know who you are.

This was posted on /. yesterday and while it’s one of the greatest songs since ELO broke up, it also made me think. (BTW, none of this should reflect on my current employers. But it could apply to some of my recent employers, you know who you are)

You have to listen to the words of Code Monkey several times before you get the full gist of it. Those of you who are coders have to get past the obvious truths in the first verse and work your way into the song to get the full benefit. (If you don’t understand the first verse then you won’t understand this post because it’s you I’m talking about.)

This song made me remember a truth I had learned a while back and just filed away. (All you Johnny Phoenix fans…raise your toasted Barbie dolls in the air and scream A TRUTH!) There’s an entire group of people out there that make their living off of the work of others. Most of us call them managers, some of us call the PHB’s. (Pointy Headed Bosses, I had to explain it once when I used it in another article, so I’m explaining it here now for you.) Occasionally, we call them worse. Whatever the moniker we place upon them there is one undeniable truth about all middle management, they occupy that position because they can’t or won’t produce. Managers, I don’t care what you say in you defense, I’ve been in both seats. Management rarely produces anything, they manage the production of others.

Here’s a secret that a lot of managers ignore. Most developers are perfectly capable of managing their own production. Heck, I’ve built teams that are perfectly capable of divvying up the management responsibilities amongst themselves and working without a manager. On the other hand, a surprising large number of software development managers cannot code. I had this argument once with the COO of a company I worked for. He proudly proclaimed that “the Sales and the Development departments were the 2 most important departments in the company”. I stared at him blankly. Then I said

“I can pull any one of my developers in here, give them a client list and they can do sales. How many of your salesmen can code?”

(yes, it was a career limiting move, I wasn’t as smart as Code Monkey)

In a software development company, the development department is not one of the most important departments, it is the most important department. It’s not terribly difficult to build a great software development team. Good talented people are out there. The trick is to find them, hire then, then treat them like kings. Once they understand that you respect them and their talents, they will respect you. (Hint: Immediately fire anyone who demands to be treated like a king. Those people will kill a team faster than anything upper management can do.)

So if you are a manager and you’ve made it this far, do me a favor. Go into work tomorrow and personally thank each developer for showing up, as they show up. (Get there before them!) Then, at the end of the day, thank them again when they leave tomorrow night at a reasonable hour. (Yes, that means you are there when they leave!) Let each of them know that you know that they have a choice. They can choose not to work for you. Everybody has a choice. Thank them for choosing to come in; and do it every day. Let them know you respect them, because that’s important to Code Monkeys.

I’ll leave you with this…that again, I’m ashamed to say, I ripped off of /.

“Putt’s Law: Technology is dominated by two types of people: Those who understand what they do not manage. Those who manage what they do not understand.”

Putt was a Code Monkey.

Until next time,
(l)(k)(bunny)
=C=

Of Deadlines and Due Dates

[Author’s Note:I originally published sometime in 2000. I wrote 3 articles that year on managing development teams. I’m going back and revisiting them because we are moving into another upswing in the technology sector. I see some of the same behaviors saw in the “Bubble”. The rush to be first, “Ship Happens” mentality, etc. (I even had one colleague who was very proud of the the fact that his company shipped crap but then fixed it. That mentality is so wrong that it requires a blog of it’s own.) Anyhow, I felt it was time to bring this one out of retirement to remind managers and developers alike that no salary buys more than your limited attention span. But to have a life, sometimes you have to take a stand.]

I love deadlines, especially the whooshing sound they make as they go by.
   — Douglas Adams

Do not commit to a deadline you did not help set.

The Marketing department (the butt of most Nerd jokes) loves to set aggressive deadlines.

“Over commit” goes their battle cry, “and over deliver!”

The problem is that it’s usually not their butts behind the keyboard at 2 AM trying to “over deliver” on their “over commitment”. Don’t let this get started in your shop. Fight it with every fiber in your body. Barricade yourself in the data center behind your O’Reilly books and refuse to come out until you have a voice in the process! Well, ok, maybe you don’t have to go that far. But you might want to count your “Animal” books, just in case it becomes necessary.

You can be firm but polite when you tell your boss “I don’t think that date is attainable.” Most of the bosses I’ve had in my career want realistic goals. Don’t set goals that are so conservative that it appears that you are padding the date for “slack time”. On the other hand, don’t be so liberal with your sanity that you set a due date that is all but impossible for even all of Microsoft’s Minions to hit. (Not that Microsoft is a gold standard for shipping products on time. It’s just that with as many developers as they have they should be able to hit any deadline.) Bosses are as motivated as you are to set goals that can be hit. They get bonuses too, you know.

In the current software development environment, with everyone trying to outrun the competition, software developers are under constant pressure to get it done faster, Faster, FASTER! Quality takes time, always will. Pick your deadlines carefully and stand by them. If your boss insists that the date be moved (usually up), make sure you have a paper trail explaining that you and your team respect her decision and will strive to hit the new dates but that you do not believe that they are attainable. Then do your best to hit the date!

WARNING: Marketing people work in marketing because they are good at influencing people to do things. Regardless of the hype they are peddling, stick to your guns. If you know your dates are solid (not padded) and attainable, stick to them. No matter how many times you are told to “Find A Way” or “Get It Done”, you are the one who will be held responsible for the date. Pick it and stick with it.

Do your homework!

Never commit to a date until the requirement phase of the project is complete. If your boss asks you to commit to a deadline based on a 1-2 page/paragraph description of the project, don’t do it. This is like taking a team of General Motors automotive engineers, putting them in a large warehouse, and saying “Build me a airplane.” What you get might resemble a plane — heck, it might even have working engines — but chances are slim that it will ever leave the ground, and even slimmer that it will return safely. (No offense to any GM engineers that read this and no fair if GM has an Aeronautics division!)

You have to understand the problem before you can tell how long it’s going to take. You can not fully understand the problem until you have spent the time to design the requirements. No matter what methodology you use to gather the requirements, you have to walk and talk through the entire problem before you can know how long it will take.

It’s the team, stupid!

Unless you manage and code (something I’ve never been able to master), you are not going to be directly influencing whether you hit the deadline or not; your team will. Have a team meeting to go over the requirements and let everybody voice his opinions. They have to think it’s an attainable deadline or you have zero chance of hitting it. It’s vital that everybody on the team feel that her voice is heard and his input considered before the deadline is set.

Once everybody has been heard (as the manager, you shouldn’t do much talking in this meeting), all of you should pull out your calendars, Palm Pilots, or stone tablets and agree on the date and the major milestones. Print a time line as soon as you can and paste it all over your offices. Make sure that everybody knows and remembers what is due when.

It’s you, stupid!

I always tell my teams that if we succeed, we succeed as a team; if we fail, it’s my butt! If you hit the deadline, no matter how many times you tell everyone it was a team effort, your manager is going to see that you hit the deadline. (Do make it a point to share the glory, though.)

More importantly, this holds true if you fail to hit your deadline. You are the manager; if the team fails, regardless of the reason, it is your responsibility. Step up and take your licks. Do not be falsely humble; a good boss can smell manure. Be genuine and sincere. In most circumstances, your boss will respect the fact that you have taken ownership of the missed deadline and will be more concerned about how you can prevent this from happening again than in punitive punishments. If you are lucky enough to work at a company (like ones I have worked for) that considers failure to be a learning process, make sure you identify the problem and work to correct it. However, failure the second time, for the same reasons, is not a lesson; it’s a red flag.

Deadlines ARE important! (just not THAT important)

I do not mean to minimize the importance of deadlines, road maps and milestones. They are critical for all but the most trivial software development projects. However, they are not, nor will they ever be, more important than the lives/sanity/health/well-being of your developers. Setting impossible or even improbable deadlines for software development means that you have chosen to let your developers “eat and sleep” the project. Don’t get me wrong, for the right project, if you have chosen your team wisely, they will commit and go. But it will take it’s toll. What good is hitting a deadline if you lose a good developer in the process. And unless everyone on your team has stock (not options, STOCK) in the company, what is their longterm payout? Why is it important to them? As we move back into a cycle of “War for Talent” good developers are going to be hard to find and keep. Keeping your development cycle in check will help keep your developers on staff.

End Game.

Every time I write, I hope that my experience is helpful to someone else. But remember: this is what worked for me; it may not work exactly the same for you. Use the ideas, but make them your own. And when you improve on them, share them with me and others.