Basics of motivating your engineering staff

You're a manager of a small development team. You begin to pose the question: what do I do with these guys? How do I get things done? They are the experts of their respective domains. Who am I to tell them what to do?

Well, one of your major responsibilities is making things happen, but you can't do it all yourself so motivating others is the key to your success. Your objective is three-fold: keep your people coming back to work, have your people get to work and finish things on their own, improve the quality of the product.

There are hundreds of books on management. The styles vary from the mean boss to parenting examples, but the basics can be boiled down to just a few basic principles. These are so easy to do, that it's almost silly, but it'll make your employees happy and make your life easy. It will also make you very effective. I am going to recommend two first steps and then the day to day steps are below.

Pick a mantra. It must align with management so make sure that you vet this mantra with your clients and boss. It may sound silly and it may sound petty to have a mantra, but it really works. Some ones that tend to work are "Service first" or "Our code is tested". If you must pick more than one of these, never pick more than three. Now you have a means to build an organization. Concentrate on fulfilling this mantra and building up the team toward achieving this goal and all of the subgoals that accompany it.

Software is a service. This is easy to forget as a software developer but as long as you are adding value to a company by doing things that other people can't or don't want to do, you are providing a service. Keep service foremost in your team's mind and discussions.

Now the day to day is a bit different: these are the things that will help you build your team into a super team that will make you and them very happy.

• Set the standard. Show people what good looks like. Present acceptable examples of well-tested code that meets the coding standards and is easy to read and maintain. Once people understand the minimum requirements which you've made clear, it makes their lives easy. This also comes down to defining what a design doc looks like, a systems plan, a deployment plan and so on. Beyond code, this can be extended to behavior: never be petty, always be helpful, think about customer service that you like and mimic that, give your people your attention and so on. If you are a good example, they will admire and respect you. If you are asking for quality work, it’s a given that you also would do the same.
  
• Planning. Involve your team in planning. You have a list of tasks and some of them are critical, but many are not so have your team work with you in deciding the direction of the team. They are professionals and so you should respect their ideas and opinions.
  
• Options. Give them some choices. The choices should be as big as possible, but even small choices make people much happier. You have a list of things that should be done, so while you are doing team planning for the next delivery cycle, ask each of them what they would like to work on and assign tasks appropriately. Invariably, you will have someone who may be a bottleneck, so explain to the others that you will need to better balance the tasks so that they all get done. People do understand. If the list of tasks is fixed, maybe you can allow your employees to pick the order in which things are done. Even this small amount of control gives people a better sense of control over their lives and they are way happier. It also gives them a sense of ownership and thus improves quality.
  
• Listen. Listen to your employees. Think of it this way: you are paying these people good money and why? They are professionals. Treat them like professionals and they will act like it. This is where you build your team into a monster of productivity. It will make a huge difference. This means one-on-one meeting for at least one hour every two weeks. This also means a 1/2 hour meeting at least three times per week with your entire team to talk about whatever engineering thing that you think is important. This meeting is critical: you must have it. It forces the team to communicate and everyone hates it, but is solves far too many problems to be avoided. You can talk about team interaction, coding standards, schedules, company politics, or whatever. Also, allow other people on your team to conduct the meetings to talk about what they they are working on or to ask design decisions. Everyone should actively participate. Hand the markers and whiteboard to others.
  
• Focused work. This is a reminder to keep people on tasks and try to avoid too many distractions. You must be a team player and always strive for the betterment of the team and still balance that with finishing important tasks set out a few weeks prior. Your company will want to pull your people into other teams or keep your people busy with other tasks. Just add the latest requests to your task list and tell other people or teams that you will do it as soon as you can. You have a list of tasks and you should be prioritizing these tasks along with your team members. Everything in the world will seem to be a higher priority than what you are currently working on. Sometimes those things are more important but usually, they are just another task that you can put off for a little while. If you are doing SCRUM, then any new tasks will be started within a few days anyway. Allow your people to interact with other teams because this is a necessary part of work and it makes them feel better connected anyway. You aren't trying to hide your people from the company. But avoid the expansion of scope during a sprint (strongly discourage this), and no new tasks - if it can be avoided at all. While this may seem like too much process to some development managers, this is the bare minimum of process that you should enforce. If there is anywhere you can go wrong as a manager, it is most likely to be here. Some of my best programming experiences have been when a manager allows me to finish something before moving on to the next high-priority task. Definitely pay attention to priorities set by other teams but this is up to you so make your best judgment and be prepared to defend your prioritization. Make sure to have time in the schedule for maintenance.
  
• Scheduling. Once someone has picked a task, let him/her pick the schedule. If it will take too long, then break the task up into subtasks and this may reduce the length. Also, remind everyone that this is engineering and that engineering takes time. It isn't up to you as the manager to define how long something takes because you will miss some details in the scheduling meeting. Also, consider the cost of building a test suite for this new functionality and cost of integrating that new code and test suite. There are lots of hidden costs in any engineering exercise. If your people start to take too long, this is where your expertise comes in and you can do some XP and more hands-on. In fact a feature that is taking too long is a great opportunity to get deep into the code yourself. Enjoy it. One more thing: make sure that any task has short-term deliverables (this is a sprint idea); this guarantees that if something is running behind schedule, you catch it early.
  
• Professionalism. Use the word engineering often. This removes a lot of the emotion from discussions and focuses on the tasks at hand. It also adds a level of professionalism. But you've also got to mean it. If you have any doubts about what engineering is, think process and testing. People can tell you how they feel during a regular meeting or in a group, but if you are conducting regular one-on-ones, then they feel no need or they are likely to only talk about professional stuff in a public forum. When you conduct regular one-on-ones and people feel that you are really listening, professionalism just happens automagically.
  
• Task list. Always have other tasks laying around that people can do. Often, someone will get stuck on a particular problem and be looking for a solution. Tell that person to take a break from it and work on one of these lower-priority tasks for a few days and s/he will feel a lot more refreshed having accomplished something. You will also have banged out another task, and only put a small delay on that other deliverable. If s/he is still stuck... you are the manager, help him/her. XP or working together on it is always a great exercise socially and from an engineering standpoint. This list of tasks can also become your plans for future development so that you never sit idle. Maybe, you can work on these when you have time.
• Early behavior correction. Tell people when they make mistakes: do not wait. If it is a minor mess up, you can tell people in front of the team. If it is a medium or serious mistake, pull him/her aside and tell him/her. If you wait more than 24 hours, you are asking for trouble because people forget what they said or why they said it. Good managers course correct their employees immediately. This helps them, you, and all of the other people with whom they interact. Never, never, never berate an employee in front of others and be extremely careful telling your manager about bad behavior of your engineering staff: it could undermine his/her career and make you look bad too. Only tell your manager when attempts at fixing behavior fail.
  
• Give recognition. Never take credit for work done by others. Always give it to the team and to individuals. Everyone knows that you are facilitating the success so you don't need to take credit for anyone else's success. If you do, you disrespect the employee and you are transparent to your managers who will see you as petty. The occasional reward for excellence helps too: tickets to the game, a trophy, an airsoft gun, or whatever.
  

That's it. If you can do these and stick to it, stay consistent, and be respectful, all of your worries about management will magically disappear (well, almost). Your employees will keep coming back to work because people listen to them, respect them, and they feel more professional at work. The work getting done just happens because they have ownership over their tasks and they respect the work being done. The professionalism aspects improve quality.

Good luck.