Postcards From My Life

Lint I find in my mind's belly-button.
  • EPK
  • Consulting
  • Resume
  • Nerd Herding
  • Talks
  • CWJ 09

Posts Tagged ‘developers’

Respect Redux

Thursday, September 10th, 2009

Dear Reader,

Thanks to my friend Alison for pointing out this article,The unspoken truth about managing geeks. This is a must read for everyone who manages IT professionals. From Manager, to Director, to the VP and C-Level, if you have IT professionals below you on your company’s org chart you owe it to yourself and your developers to read this article.

Respect

One of the first points the author makes is that developers want respect.

for IT groups respect is the currency of the realm.

This is one of my favorite quotes in the article because it is so true. It’s also true that many in management don’t understand this and that’s sad. I wrote about respect back in 2006 in the blog post “It’s all about respect” and the fact that management can’t seem to understand this fact led me to write “Leadership in Software Development“, which encourages developers to step up into management so that the next generation of developers can have managers that understand this.

Jeff Ello, the author of “The unspoken truth about managing geeks” touches on several points that strike so close to home that I wonder if he’s not been watching the same things I have lately.

Just because you don’t like what is being said, doesn’t mean the other person is whining

Other than respect, I think the next most important take away from this article is made on the second page in the section about “victim mentality”.

IT pros are sensitive to logic — that’s what you pay them for. When things don’t add up, they are prone to express their opinions on the matter, and the level of response will be proportional to the absurdity of the event.

I’ve personally seen several scenarios play out recently that can be directly attributed to this behavior. In all cases, the “management” attributed disagreement from a developer as whining and ego when in fact things were going on that were not logical and therefore someone said something. What was said, was said in a “manner of fact” way and taken wrong because the person it was said to failed to realize the point of view of the speaker. (I’m being vague here on purpose)

I love Jeff’s call to action to help resolve some of the communication issues:

“Periodically, bring a few key IT brains to the boardroom to observe the problems of the organization at large, even about things outside of the IT world, if only to make use of their exquisitely refined BS detectors.”

To paraphrase, when your developers are complaining, don’t call them whiners or write it off to ego, look past the surface complaint and find out what the problem is. Chances are, there’s a real problem there and managers ignore it at their own risk. This is closely related to one of the points I bring out in “Open Teams“, transparency. Talking to your developers, listening to them and sharing both the good news and bad news will let you tap the brain trust you have built in your IT department to solve the problems that are facing your company.

I’m encouraged that others are saying these things now but still a bit depressed because even though others are saying these things, the people that need to read them, aren’t.

Until next time,
I <3 |<
=C=

Tags: developers, Management, open teams, respect, transparancy
Posted in Management | 1 Comment »

 

A Challenge to IT Companies

Monday, August 24th, 2009

Dear Reader,
[Note: This blog post should in no way reflect poorly on my current employer. I love my job and am not talking about any one company in particular but about IT companies in general.]

The Problem

Something has been bugging me for a while now. I’ve been a member of more IT companies than I care to remember. Outside of cube farms, one thing seems to remain constant throughout, a contract that was written in the 1800s. Most (not all) of the employment contracts I have been handed to sign have contained a clause that states something to the effect:

While you are working for us, if you invent something we like, we can claim ownership of it.

(more…)

Tags: developers, Entrepreneurship, Management
Posted in Management | 14 Comments »

 

Remote Developers

Wednesday, July 29th, 2009

Dear Reader,

This conversation takes place via email at least once a week for me

Headhunter: “I am looking for the best PHP programmer available. Do you know anyone?”
Me: “Yes, I know someone right now who is looking around and is awesome; however, they are not looking to relocate. Are you willing to consider a remote worker?”
Headhunter: “no.”
Me: “Sorry, your loss.”

(more…)

Tags: developers, Management, recruiting, telecommuting
Posted in Management | 18 Comments »

 

Leadership In Software Development

Sunday, January 25th, 2009

Dear Reader,

[Editor's Note: This is an editorial that was originally published on Freshmeat back in 2000. As I'm cleaning up my content, it stuck me that I had never published this here.]

Me to the everybody: “Hi, my name is Cal… and I’m… I’m a manager.”
Everybody: Hi, Cal!

I am a developer who made the conscious decision to move into management. My training, my experience, and my love has always been developing software. I’ve worked under sales managers, business managers, and (shudder) a CTO who believed that all the good software had already been written so we didn’t need to write anything; we could just buy everything we needed. I made the leap into management for one reason: I had a manager who “got it” and showed me by example that developers can make great bosses for other developers. (Thanks, Paul M.!)

During my career as a developer, I learned many different things but the one thing that has stuck with me is this axiom:

“If you have never been a software developer, you have no business managing software developers.”

There, I’ve done it again. At least one third of you are now mad at me. But regardless of your feelings towards me, I stand by my statement because, time and again, whether through personal experience of 24 years or war stories from others, it has survived.

Before you fire up mutt and flame me, let me be quick to point out that I do not believe that this maxim is universally applicable to all situations or walks of life. I am not belittling any person or occupation, but I believe that, in most cases, we as humans, co-workers, and professional colleagues have enough shared experience to be able to relate to each other. I do not believe that this maxim applies to the sexes or to races. However, there are a few areas where it does apply, and the one I know most about is software development. Here are three different thoughts on why I believe this is true, what I believe has caused the current crisis, and what I think we can do about it:

The Balancing Act — Why we are here.

There are very few professions that combine the creativity involved in good software development and the rigorous deadlines, often imposed from the outside. Hurry up and create! The ideas have to keep flowing, they have to be scheduled, and they have to be completed on time. If you have to go figure something out, go. But make sure you are back after lunch and make sure your schedule doesn’t slip. Developers, especially now as we work in Web years, are under increasing pressure to “Get it out the door fast!”.

The rigorous detail work of quality software development, however, has not changed. It still takes time to develop quality software. (You can have it good, fast, or cheap; please pick two.) To those on the outside, it may sometimes seem that what we do is easy. (Heck, we may feel that what we do is easy!) The ease with which developers manipulate the tools of the trade is often misconstrued as ease with which the task can be completed. Only a developer understands the countless hours it takes to master new tools, new languages, and new concepts. In this age of rapid development, new concepts come at us like a fire hose of knowledge. We are supposed to know how to soak it all up and be able to use it in our next project. This is almost a bearable burden if management understands what we are faced with. The problem is that, having never been there, most managers cannot empathize. (And most don’t even bother to sympathize.)

The Boss From Beyond — What has caused the current crisis.

It’s generally accepted folklore in the IT community that managers are managers because they can’t do anything else. What has led us to this state, a climate in which developers don’t respect their managers and managers try to manage a software development team like an accounting department? Volumes have been written on when and why people are promoted into positions they are not qualified to hold. I won’t rehash that here. I have a different take on it.

The question we ask should not be “Why don’t managers understand software development?”; the question should be “Why don’t those of us who do understand the process step up to management?” The obvious answer is that there are very few developers who want to be managers.

In the past, developers would have to turn away from promotions to management (and sometimes raises) so they could remain in development. These days, they find other companies to work for that will pay them more and allow them to continue to develop (but that’s a story for another day). The problem exacerbates itself. The more developers steer clear of management positions, the unhappier software development teams will be with the candidates that become their managers.

We, the IT community, have the bosses we have because we refuse to step up to the plate and take the job. I am not advocating that all developers climb the management ladder; far from it. In most cases, a developer pressed into service as a manager will do no better a job than an accountant forced to code. But until the development community learns to train its own management structure, we are doomed to be managed by PHBs.

Managing In Chaos — What can we do about it?

So now we are all on the same Merry-Go-Round from hell. What can we do to get off? At least part of the answer is obvious. We, as a community, have to train our own managers. For me as a manager, that means that as I interview candidates for development positions, I have to keep my eyes open for potential managers. I have to make sure that I mentor as I was mentored. I have to realize that if I don’t train new development managers, I’m as big a part of the problem as non-development managers.

For me as a developer, and all other developers reading this, we have to make sure that we educate our managers.

We have to teach them concepts like:

  • Deadlines cannot be set from the outside without input from the development team they are being imposed on.
  • Sometimes, it just doesn’t come to you and you can’t force it.
  • You can’t run most modern IDEs on crap hardware!

I’ve found that, in many cases, they can learn. They want to learn. They are PHBs because they’ve never been taught not to be. There are some that won’t learn or, worse yet, think you have a lot to learn about business. If you are under one of these and you work in America, change jobs! Life’s too short and the job market is too tight to deal with goobers like that.
Closing

To fix the present situation, we, as developers, have to make one of two choices. We can take a stand at our present jobs and educate upper management so that we don’t work for PHBs, or we can find other jobs. But make no mistake about it; it is ultimately up to us to fix the problem.

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

Tags: Cal Evans, developers, developing software, Management, phb
Posted in Management, Programming | 5 Comments »

 

PHP Bloggers! Help Me Out…Make a Few Bucks!

Monday, January 14th, 2008

Dear Reader,

Most of you that I know personally, I contacted back in September about a new project of mine, securePHPhosting.com. Now, I’m putting out the call to all my friends, virtual or other wise, asking for your help.

securePHPhosting Elevator Pitch
My goal with securePHPhosting is to build a shared hosting environment as safe and reliable as possible. We go to great lengths to make sure that it’s always up to date and monitored on a 24×7 basis. I’ve been managing shared hosting since 1998 and know quite a bit about it. securePHPhosting is just for PHP developers and it’s run by a PHP developer. Most importantly though, I personally offer all clients money back guarantee if your not happy. Additionally, if our service goes down, we start refunding money.

Here’s how you can help me and possibly yourself.
securePHPhosting has an affiliate program. No, you don’t have to host with me to participate. If you want to, hey, I’d love to talk to you about your hosting needs; but this is about us helping each other, not just me asking for your business. Since I’m really only targeting PHP developers with this service, I’m only looking for affiliates that are PHP developers and have blogs.

If you sign up for the securePHPhosting.com affiliate program, I will pay you 100% of the first month’s hosting fee for each and every client that comes in through your blog. It’s really easy, you sign up, you put the graphic on your blog, you get paid if people sign up. I’ll be honest with you when I say that this isn’t gonna make you a ton of money. securePHPhosting.com is a premium web host and as such our prices are higher than your normal web hosts. I do not apologize for this as a lot of time and effort goes into the upkeep of our servers. However, since this is targeted at the audience you are already bringing in on your blog, the chances of you getting a payout are good.

So the upside is I could be paying you $25 or $50 for you sending me a customer, the downside…well, there really isn’t one. It will cost you about 10 minutes to fill out the form and place the graphic.

There’s my pitch, if you know me and I’ve not pissed you off (lately) think about it. Nothing would make me happier than to share the wealth with all my PHP friends.

To sign up for securePHPhosting’s affiliate program, click here.

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

Tags: affiliate program, developers, PHP, securephphosting, web hosting
Posted in Blogging, Entrepreneurship, PHP, Programming | 3 Comments »

 

Nerd Herding

Tuesday, December 25th, 2007

By Cal Evans

(Editor’s Note: This is an older article. I wrote this around 1999 but most of it still applies today.)

Managing software developers requires a different mindset than managing other types of employees. By its very nature, software development is a cross between the rigorous detail of engineering and the craftsman pursuits like fine carpentry. Because Nerds have to be equally at home in both halves of the brain, they are different and must be treated so.

I’m going to let you in on 5 secrets that I’ve learned over the years for managing Nerds. They are not hard and fast rules that you should follow rigorously. They are suggestions, options that you can use or modify to your current needs. What they all have in common is that they have all worked for me when building and managing Nerd herds.

1) Recruit only the best Nerds

A herd full of excellent Nerds will rise to the level of the best. A herd of mediocre Nerds will sink to the level of the lowest. Nerds need quality peer-to-peer interaction to thrive. When looking for new Nerds, involve your entire herd. From your most senior on down, make sure that everyone has a voice in who joins the herd. Here’s how I did it with one herd:

Resume Rush: Put the word out on the street that you have a position open and resume will start flooding in. Be open and honest about the position, the working conditions and the current herd personality. You want quality matches, not quantity. Also, open relations with one or two of the better recruiting agencies in town. I usually looked for the ones that pre-screened their applicants with some types of skills test. This gave me confidence in them and, as a rule, I received better quality candidates from them than I did from agencies that just scoured monster.com for resume.

During this phase of our hiring process we averaged 10-12 resume for each pre-screen interviewee. This put a real strain on my relationships with recruiting agencies. The upside was that the agencies who were looking for a quick placement, quickly dropped out of the process leaving only those interested in a long-term relationship.

Pre-Screen: Sometimes over the phone, sometimes over lunch (especially if there was a recruiting agency involved), I would meet with each potential candidate. I wasn’t looking at skills at this point, I wanted to get to know the candidate. Does he have the personality that would mesh with the rest of the herd? Can she communicate ideas clearly and concisely? Can she talk fluently about the technologies we are deploying? Most candidates made it through my initial pre-screen. It was just my one and only shot at filtering out candidates by myself that I didn’t think fit the mold. From this point on, I was just another vote. From here on out it was a herd effort.

The Interview from Hell: One of my team members came to me one day and thanked me for hiring her early on in the herd building process. She said she was sure that she wouldn’t have survived the current interview process! The main interview was with the entire herd. It was as ‘no-holds-barred’ as Nerds get. We had some pretty heavy hitting senior Nerds on our herd so if you put something on your resume, you had better know it. There was only one rule (aside from the 100 HR rules for interviewing); no trick questions. As the herd grew in size, my active role in the interview diminished. I spent more time watching how the candidate handled the pressure of the interview and trying to get a feel for the candidate’s personality and how it fit in the herd. Assessing these points was my assignment while the rest of the herd picked them apart technically. It was very important to me that the candidate’s personality was a good fit. In any herd and especially those assigned to high visibility or high pressure projects, the members must be comfortable with each other, must be able to learn to trust each other and yes, must like each other. Personality was 50% of the grade of any interview.

The De-Briefing: Once the interview was over, usually within 30-40 minutes, we would all get back together to discuss what we saw. Instead of going around the room in clockwise fashion (way to regimented), I tried to get the most junior members to speak first. This helped avoid the ‘me-too’ syndrome from the juniors and forced them to think through their opinions.

The most important aspect of the entire interview process was that everyone in the herd got a veto. If anybody gave a thumbs down, the candidate was no longer viable. Yes, this meant that sometimes we passed on a talented candidate. It pained me to let this happen, but to override the process and take the candidate anyhow would have damaged my credibility and who said I was a god at hiring anyhow? If someone saw something I didn’t, they deserved to be taken seriously. The damage I would have done to herd morale by overriding the process would outweigh any benefit that the new herd member would have brought. Trust me, once your herd understands you are serious about this rule, they will think long and hared about any decision to veto. I never had a situation where a single person vetoed a candidate. The outcome of this process was two tight-knit Nerd herds. They worked well together, they played together, they understood each other and they respected each other. Of course they fought with each other, called each other names, played jokes on each other too. It was grand!

2) Invest in your Nerds

Teach them, train them, make sure that everybody is learning, constantly. A Nerd who hasn’t learned anything new in 6 months is a paperweight. It can be as expensive as sending people to a conference or as simple as investingin CBTs. It’s not always the amount of the investment that counts. Quality is important but the very effort of investing shows that you care about them and their future. I’ve always made it a policy to try and make sure that each developer gets to at least one conference a year. More senior developers got to pick the ones they felt were good for them; junior developers consulted with a senior or myself to help find conferences that would benefit them and the company.

Another good way to invest in your Nerds is by buying them books. Nerds love books. If your Nerds don’t have a library yet, start one today! Ask each of them to pick out a book. Have them find it at amazon.com and send you the URL. Add all of them to your shopping cart and order. Make them accessible to everyone who wants to use them, not stuck on a shelf in your office. Encourage your Nerds to continually suggest new books for the library; when they do, order them. Books tend to be $40-$70 each. One new book a week won’t kill your budget, it will, however, show to your herd that you are committed to them.

Along the lines of investing, but in a non-monetary way, try and find interesting projects for your Nerds. Salary is not always the most important thing to a Nerd. Many are motivated by interesting projects. (high “Ohh-Ahh Factor”) Not all projects are going to be fun, but make sure that at least some of them are. Don’t be afraid to let someone run with an idea of theirs. Two to four weeks of R&D, even if it ends up at a dead-end, will pay high dividends in moral.

Finally, invest in a good working environment. Make sure that developers have “walls, ceilings, floors and doors”. The open pit working environment is as much of a hazard to developers as an asbestos lined room. Nerds need to be able to close the door, crank their tunes and zone in on the project for hours at a time. Anything that distracts them from doing this (people walking around asking questions, phones ringing, other developers tastes in music) will hurt your projects.

3) Teach your Nerds

Nerds love to learn. Luckily, the best teaching resource available for Nerds is other Nerds. Try holding ‘brown-bag lunch’ days. Bring everybody and their lunches into the conference room. Let your DBA go over 3 important points of proper database construction, or let your Chief Architect show the proper way to code a business object. There are probably 10 classes that, if you thought about it, you could line up with in-house talent. The more you ‘cross-functional mentor’ the better the different areas of your herd will understand each other. The point is not to train ‘backups’ for key personnel; you will, but that’s not the point; the point is to foster understanding across disciplines.

Also falling under this heading, whenever you hire a new Senior Nerd, make sure that he or she fully understands that part of their job is to mentor the more junior Nerds. Make sure they understand that it will be part of their performance/salary review. A Senior Nerd is not just someone who can sling code fast. A Senior has to be someone that the Juniors can look up to. Someone they can respect and learn from. Someone they are not afraid to approach and ask a question of. They are your greatest teaching tool. if they don’t understand that, they’ve got no business on your herd. I have found that a good mentoring program is actually a perk when hiring. Many senior Nerds enjoy passing down what they have learned to junior Nerds. Juniors, especially those who love being a Nerd, are always looking for ways to learn new tricks of the trade. I’ve actually had people take pay-cuts to join a herd, just for the opportunity to learn. Call it ‘growing your own’ or ‘giving back to the community’ but it’s hard to see a down side to training someone who has a love for development into a top-notch developer.

4) Listen to your Nerds

Staff meetings with everyone are critical. Everyone must be a party to the thought process. Make sure that all Nerds are encouraged to speak-up in staff meetings and voice their opinions. If your boss insists on attending Nerd meetings, make him promise to keep his mouth shut. If she breaks the promise, reach over and slap him. (metaphorically, of-course) Remember, he’s farther divorced from the development process than you are. Like training any other pet, it usually only takes once or twice. I’m the first to admit that I’m a Nerd Herder, I only pretend to be a Nerd anymore. I help set directions, select technologies and try to make life easier for the Nerds. If you’ve got more than 2 Nerds in your herd, chances are good that they know things that you don’t. So let them speak, who said you were the walking embodiment of human knowledge? Ok, so what, you’ve been programming for 15 years..big deal! Still hoping the C64 will come back into fashion so you can dust off your skills and code again? If you are a nerd herder then you can’t possibly spend as much time programming as your Nerds. Deal with it! When a decision has to be made, talk to the people who are actually doing the work. Don’t dismiss them out of hand because “…I want it this way…” Bad mojo, I know first hand from having committed this sin. Even your junior Nerds probably know something you don’t. (If not, go back and re-read secret 1, you missed something.) Let them speak.

When it comes down to it, it’s your butt on the line. You are the one responsible for the actions of the herd. So don’t trust your butt to the thinking of a single person, even yourself. Get as many people as you can thinking about decisions. Not so you can blame them if it fails…you can’t. But because, this way, you’ll be much less likely to need to blame anyone.

5) Feed your Nerds/Play with your Nerds

This one sounds silly, but it’s not. Nerds love food, especially free, food but Nerds are by and large anti-social animals outside of their own circles. If your herd is small, it’s probably very introverted, with your Nerds taking mainly to each other. If it’s large, chances are good that there are cliques within your herd. it’s very important for your Nerds to socialize with each other and with the rest of the company. Lunch is a great time to do this.

Make sure you work into your budget enough to feed everyone at least once a month. Take a Friday afternoon each month and bring in pizza or sandwich-meat trays. Make a rule that everyone must eat in the common area. No one (including the boss) can go back to their office and eat. It’s a time to socialize. Make sure you invite another department to join you. start with your in-house clients (if any) but try and make sure that you have one of these monthly parties with every department in the company.

At one company I worked, the herd was moved into an old warehouse. The company was planning restorations on it and it would eventually become the headquarters for the entire company. But since we ran out of room in our other building earlier than expected, they moved us over before the preparations had begun. it was a rough time for the herd, the working environment was dirty and very (very) open. We didn’t even have the luxury of cubes, just lots of open warehouse space.

The operations team was also moved over at the same time. One day the chief of operations, who was facing the same moral problems, approached me about getting both teams together for lunch that Friday. That was the beginning of what became known, company wide, as “Free Lunch Friday”. It usually cost us $150-$175 a week to feed everybody including whomever could sneak away from the other building, about a mile away. Eventually it expanded into lunch and an hour of “Team Fortress Classic” and was generally the highlight of the week. Hey, you get into a virtual arena with 8-15 other people whom you’ve been ordering around all week and see how peaceful it is. Everybody, sometimes even my own teammates, had a score to settle with the boss! It was great fun.

It was more than just a gimmick to lift spirits, it became a part of the culture of the herd. (Wait until you hand someone a particularly hard task on a tight deadline and they say “…yea, well, I’ll get even with you Friday!”) The herd grew together and also grew out. Those people in operations who were not out in the field would join in on our weekly frag-fest. We even had a V.P. ask for a license so she could join in. (I’m not sure if she ever did, but the rumors that she might were enough to spark excitement)

In that particular situation, even though the working conditions were bad, the deadlines were ridiculous and other departments did not understand the realities of good software development, we were able to build a fun-loving herd who overcame these obstacles and actually got software out the door. It’s a lot easier to ask someone to meet a ridiculous deadline or change a feature after the feature-freeze in an environment when you’ve shown that you respect them and are concerned about their happiness.

Please, PLEASE PPLLEEAASSEE don’t just go to your Nerds and say “…go play games for an hour.” If you do, you’ve missed the point entirely. the point is not to allow your Nerds to play, it’s to play with them. You have to be an active participant. it’s ok to pick something that you enjoy as well as them but the important thing is that you participate. If there’s a new movie coming out round everybody up and take them to it!. Pack up the house and go catch a matinee. Buy everybody pop-corn and a Coke and enjoy the company. The moral you are purchasing by doing things with your Nerds is worth way more than the ticket price. Also, resist the urge to combine an idea like Free Lunch Friday and Brown Bag Cross-Training lunches. Keep them separate if you do both. Free Lunch Friday is about getting away from the work while still at work. It’s about building a herd, not about feeding people.

Word of warning on TFC type encounters: From day one, when we started the TFC games, we stated up front, the server would go on-line at 12:30 sharp and go off-line at 1:30 sharp. It was not brought up any other time during the week. Set the expectations early and follow through. The one thing I had to keep in mind was I was burning close to $1,000 an hour in personnel time. We enjoyed the games, but when they were over, they were over. We did post the game stats on our herds portion of the corporate website every Friday after the game however and that kept the conversations going for another couple of days.

One last note on food, have you got a soft-drink machine for your Nerds? You do? What are you, nuts? Get rid of it now! Buy a refrigerator, put the drinks in there. Make sure you know which drinks each of your Nerds like. (Keep a cheat sheet in your wallet if you have to) Now, make sure that the fridge never runs dry. Make it your personal mission to keep it stocked. If you run low, don’t dispatch a grunt to buy more (and for goodness sake, don’t ever give them petty cash!) Go yourself, let them see you sweat as you lug cartons of drinks in from the car. Now, let them partake freely. Ok, I’ve gone a little over the top but you get the idea. Make sure that soft-drinks are a perk, not a fund-raiser.

Closing:

A good Nerd Herder wears many hats. You must at once function as a mentor, a guide, a chief architect and a poop-shield for your herd. (The last one being one of the hardest) It is your job to make sure that the day-to-day idiocy of upper management not interfere with your herd’s productivity. Do not take this responsibility lightly. You can’t shield them from everything that upper management does, but you can fend off the big pieces. It’s a thankless job. If you are good at it, your herd never knows how much you are shielding them. It’s an important part of your job, none the less and the payoff is productivity. The less that your herd has to worry about management’s infatuation with the latest vendor or technology, the more they can concentrate on actually getting their job done.

Tags: article, Cal Evans, developers, hiring, nerd herding
Posted in Programming | Comments Off

 

Two Rules for Hiring/Retaining Developers

Tuesday, November 13th, 2007

Dear Reader,

Most of you know, but some of you may not know, that one of the consulting services I provide is helping people identify and hire quality PHP programmers. I’ve been hiring developers for a long time now and inevitably, someone will ask me in a conversation, “How can I find good programmers?” Since I assume they know that I charge people to do this, I always refrain from the obvious answer, hire me.

However, after having a variation of this conversation for the then thousandth time recently, I decided to lay my cards out on the table and tell everybody the secret. Feel free to use this without hiring me but remember that if you get stuck, I’m here for you.

Looking back over the 200+ developers I’ve hired in my career as a manager, I can honestly say that hiring and retaining good developers can be boiled down to two rules. Everything else that goes into the process is just details. (And I do want to apologize to my friend Leslie who is in HR. I do not mean to minimize your job by saying you are a detail!) :)

Developer Hiring Rule: Only hire developers you trust.

I’ve laid out elsewhere my process for hiring developers, those are the details. The decision though as to who gets hired and who doesn’t comes down to a matter of trust. To put it a little more bluntly, trust your gut/instinct. As with any hiring manager, I’ve made bad decisions, in all but one case that I can think of though, bad decisions were made because I did not trust my instinct on a person.

This is an especially important rule for small businesses. You may only hire one or two IT people for your entire company. Make sure you really feel that the person is a good fit, both skill wise and personality wise.

Developer Retention Rule: Trust your developers.

If you followed the advice of rule #1 then this one should come easily. I’m not advocating handing a new hire the keys to the company but your developers, more than anyone outside of your management team, will know the inner workings of your company. If you are not a software company then your IT staff will have access to a number of important facts not known to others in the company. If you followed Rule #1 then you’ve got people you trust…now trust them to do their job.

If you are a software development company this is especially important. As a matter of fact, if your company makes any part of it’s revenue stream from software development or from providing services built by developers, and you personally do not write code, you company’s fate is in somebody else’s hands. You want to make sure that you followed Rule #1 and hire people you feel you can trust and that you then follow Rule #2 and trust them to do their job.

What to do when either rule fails you.

Actually, the better question is what can you do when you failed to follow one of the rules. One of the greatest bosses I ever had gave me some sagely advice. “A sharp knife cuts clean.” If you’ve got a developer on staff that you cannot trust, get rid of them and do it quickly and unambiguously. (local labor laws not withstanding)

The #1 task is to get rid of the developer before they become a problem. The second task though is to let the rest of the team know exactly what went down, why the developer is not there and reassure them that their jobs are not in jeopardy. It always astounds me when people suddenly disappear form a corporate org chart without explanation. Does upper management (C-Level usually) think that nobody will notice? Do they think not saying anything is actually better for morale than being open and honest with their employees? remember, you’ve hired people you can trust…trust them to be smart enough to be able to handle the information.

So there you have it. If you don’t want to hire me to help you build your PHP development team, those are the two rules I use to hire and retain good developers.

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

Tags: advice, Consulting, developers, hiring, nerd herding, PHP
Posted in Management | 5 Comments »

 
  • Team Based PHP Training

  • Sponsors and Ads

  • Conferences I’m Attending

  • About Me

    cal_evansThis is my blog. Sometimes it's my deep thoughts, sometimes it's a journal of things I've learned. Every now and then it's my box of shattered dreams. Most of the time though, it's just the place I like to write. Sit with me as I show you some postcards from my life. While you are here, do me a favor and leave a comment.

    If you are looking for my contact information, bio, picture, ASL, check out my EPK.

    My name is Cal Evans and this is my blog.



    Follow me on FriendFeed!

    View Cal Evans's profile on LinkedIn

  • My First Book

  • Support PHPWomen


    US Shop | European Shop

  • What I'm Doing...

    • @emmaemail I am somewhere between the Entrepreneur and The Copywriter. in reply to emmaemail 1 hr ago
    • @foxydot Good News: It will be recorded. Bad News: Two Week delay on release. :S Keep an eye on our podcast feed. in reply to foxydot 1 hr ago
    • LinkedIn suggests that I know John Wall of MoC podcast. Gees I WISH I was cool enough to know him. 1 hr ago
    • More updates...

  • Tags

    API article Cal Evans codeworks conference contest cw09 developers devzone elizabeth naramore Exim flex fun IBuildings iPod jobs Kathy Evans linkedin Management Marketing microsoft MySQL Nashville phar photography PHP phparchitect php developers podcampnashville podcast podcasting poem Programming Quickies respect Silly-Con Valley sixty second tech software development terry chay twitter upgrade video wordpress zend zend framework

  • RSS PHP Podcasts

    • webcast: Introduction to Doctrine 2
    • 8 Reasons Every PHP Developer Should Love JavaScript
    • oddWeek Episode #4
    • Creating Custom Zend_Form Decorators
    • Habits of Highly Scalable Web Applications
    • PHPSPCast #6 – Ao vivo da Campus Party (Q&A)
    • php|architect Podcast: oddWeek #002
    • php|architect podcast: oddWeek #003
    • Podcast #2010-02: Stalker Edition
    • php|architect Podcast: oddWeek #001

  • XBox Gamer Card

  • Me

    • Best web design company
    • Cal Evans Dot Com
    • Cyrano’s Apprentice
    • Evans Internet Construction Company
    • My Life as a Child
    • PHP Podcasts
    • Sixty Second Tech

  • RSS My Blog at php|arch

    • An error has occurred; the feed is probably down. Try again later.

  • Flickr Recent Photos

    Blue Parabola Southern Office-Rear Annex is closed for snowSnow Heart@dzuelke getting ready to give his talk@fabpot talking about Dependancy Injection@derickr giving the opening keynotePeople meeting other peoplePHP Benelux Goody Bag ContentsCheck InDSCN2280The main room

  • Categories

    • Apache
    • BlogBling
    • Blogging
    • codeworks
    • Entertainment
    • Entrepreneurship
    • Flex
    • Humor
    • JavaScript
    • Long Form
    • Management
    • Marketing
    • Me
    • PHP
    • podcasting
    • Programming
    • SQL
    • Technology
    • Web 2.0
    • wordpress
    • WordPress Plugins
    • writing
    • zend framework

  • Meta

    • Log in
    • Entries RSS
    • Comments RSS
    • WordPress.org


Postcards From My Life is proudly powered by WordPress
Entries (RSS) and Comments (RSS).