And so begins the second half of the post. If you want to go back to read the prior half, please see Hiring and Keeping Good Engineers (part 1)
I recently read a post by John Hunter entitled, “Finding, and Keeping, Good IT People,” and couldn’t help but think it merited some additional thoughts on the subject. He makes a few main points in his post, namely: look at the hiring process, reduce your requirement count, treat existing staff well, and a good programmer is a good programmer. I’m going to expand on all of them here.
Look at the hiring process
Your hiring process is intended to filter out the large number of applicants into a small pool worthy of interview. How this process is implemented can turn good engineers off from of a job simply because it is not robust enough to handle the applicants that apply. Continue reading “Hiring and Keeping Good Engineers (part 1)”
So now to the final discussion in my series. About Great engineers! I have been pondering this one, because, for some reason it’s the hardest to provide valuable information about. Great engineers/employees in general are hard-working, deadline-meeting, project-churning machines that bring value to your organization consistently with a smile on their faces. What could be wrong with that?! I’ll guess that nothing is wrong with that, though there is the matter of keeping them as great engineers. Lack of motivation, disinterest in doing the same ol’ thing, frustration with other engineers, and many more daily occurrences can push their productivity down. So for a manager, your job is to ensure that they are happy and able to do their duty!
Without further ado:
Assholes assholes everywhere…. ok, not really. I spoke about engineers who behave with utter disregard for anything or anyone but themselves in this post, and now the time has come to elaborate on how a leader can manager these types of individuals. These can be very easy to deal with (for the idle asshole), or incredibly difficult (with the conniving ones), but regardless of how asshole-like they are, here are some tips to deal with them when they are under your employ.
What can be worse for a manager than to have someone come into their office trying to weasel out a favor? Ok, I’m sure that any type of disciplinary action is worse, and even layoffs, but the idea of someone going out of their way to try and push an agenda of theirs onto you is definitely up in that top pet peeve list. I have seen managers go from both extremes of pushing an employee out of their office when they realized what they were trying to do, to falling into it hook, line, and sinker, and then many somewhere in between.
One of the biggest complaints I hear from fellow engineers is that of feature creep. For those of you who don’t know, feature creep is the process where others in your project team, or management, get a great idea that they think would be good in your project. They then proceed to tell the engineer that this feature is critical and needs to be implemented in the system, and then, “how long will it take?”
This post is not devoted to feature creep though. Its focusing around deceitful and underhanded behavior in trying to coax something out of another person. It is also about a coworker of mine who came into my office and began to explain how a desired feature was requested by one of the team. He informed them that he couldn’t do it in the time he had already allotted, so if she wanted the feature put in, she needed to move the deadline back by a few days to accommodate the development time. To her, that was not a satisfactory answer, and so she spoke to another in the design team… who then went back to the engineer and asked for the same thing. Yes, he got the same answer.
Hopefully, you have already read A Manager’s Focus and An Engineer’s Focus. If not, I encourage you to do so, because the purpose of this post is to discuss why it is that engineers and managers tend to have difficulty communicating. In fact, many times, while watching communication happening during meetings, it is fascinating to realize that both are talking, thinking their point is getting across but in reality they are talking to the equivalent of a brick wall!
In the world of business, you can look at required tasks several different ways. At the largest scale, you can look at how a company’s stock price fluctuates with organizational decisions, ROI, Resource management and supplier/customer relations. Each area you turn to, there are many different components which aggregate into the whole. You can keep going further down until you finally hit those workers who are doing the seemingly menial tasks that must be accomplished in order to get the answers you (the manager) need to have in order to perform your job satisfactorily.