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)
Treat existing staff well
This is one of those *duh* kind of comments. Most managers understand in their minds that being a good member of the staff merits being treated as such. However, in practice, this tends to change into getting the job done, rather than making sure the employees are happy doing their jobs. I speak to so many people about their job satisfaction and what they’re doing only to hear comments like, “Eh, it’s ok”, “Not quite what I want to do”, “I wish I could be doing something more interesting”, etc.
Sometimes, yes, engineers need to do tasks that aren’t full of glory and happiness, but I would argue that most of the time, the goal should be engagement and excitement in doing their job! After all, who wants to spend the next 25 years of their lives in misery where every time someone asks how they like their job, they reply with “Eh, it’s ok, but it works…”
These days, I hear all too often, “At least I have a job.” I fully understand the economic conditions with employment, but really, for most educated individuals who have a college degree (yes it still helps), the unemployment problem is not as a bad as for those uneducated or mildly-educated ones. If you don’t like your job, it’s up to you to change how you want to work.
If you’re a manager, it’s YOUR job to try and make every one of your employees wake up and be excited to come to work! Perhaps your project vision is too narrow and needs to be expanded. Perhaps, as Dan Pink suggests, it’s time for you to instigate a “Work on what you want” day. Whatever you choose will depend on your own situation and what you can offer to your staff. But regardless of what it is, the goal must be “I love working here!”
A good programmer, is a good programmer
For any programmer/software engineer/coder/code monkey, this is very much a true statement. Programming requires two fundamental skills: logic, and an understanding of syntax, grammar, and vocabulary. In fact, the first follows along the same lines as the Pareto principle. 80% of writing software is knowing the logic behind it. It’s understanding not only how if-then, while, and switch statements work and flow, but also understanding the background behind variables and data structures.
These concepts are almost always separate and apart from the syntax, grammar and vocabulary of different programming languages. A stack in C has the same functionality as a stack in VB and so on. An array is the same in nearly every language. Now there are some lesser utilized languages that have some very interesting properties which I won’t go into here, but the point I’m trying to make is that by virtue of being a programmer, you have your foot 80% in the door.
Even if you don’t know a lick of C#, your understanding of C, or Python, or PHP (all similar languages) gives you an ability to jump that last 20% over time. In fact, rarely are the higher-level concepts even used. Most programming is at a low enough level that one could get up and running to write some simple software in a few days. I learned the basics of C# (which almost writes itself) in about a week to create a prototype testing tool for our quality assurance department.
Managers, if your job requires a language to be written in, don’t hold that as a strict requirement, but a preference for ease of learning. The learning curve on languages is very short and can be done easily.
While much of the job satisfaction that individuals pull from their employer is placed at the employee’s feet, employers and managers need to understand that their actions have a profound impact on how one of those employees perceives their situation. The culture of the organization is a huge facet of that happiness and engagement, and culture can only change slowly and consistently. If your culture is negative, it’s up to you, the managers, to push it towards the opposite. It won’t come quickly, nor easily, but over time, it WILL change if there are enough champions throughout management to make it happen. A change plan, without action, is no better than trash.
Have you had to work to change your culture? What steps did you take? Do you have thoughts about what I’ve said? Please leave them in the comments!