They Should Jump Out Of Bed Every Morning!
How to win friends and make software developers happy! Sounds simple, however, as most of you will know, managing software developers is tricky business. Making them happy day to day is even harder. I would strongly advise that anyone managing software developers should be a developer first. It is true that just because you are a great software developer doesn’t mean you should be promoted to a manager. However, I strongly feel that if you have not been in the trenches, on death march projects, or simply do not understand the developer’s mentality inside out, you will be at a loss when trying to figure out this “special” bunch of people.
I’ll try and take this from where my other post, The One Minute Software Development Manager left off because I had a lot more to say, and didn’t want to lose anyone in my boorishness.
I will try and touch on just a few areas you should always think about when you work with developers on a day to day basis. The goal? Make them jump out of bed, excited to get to work to solve problems!
Your Attitude
Managers that want to be mangers to boss people around, give orders, or think that if you make them a manager, they will suddenly be looked up to by people in the organization and team, are probably the worst managers you could ever have! This is the wrong attitude! You should never, never, never promote someone to a manager that craves the title, or the responsibility. Just look at what happens in the history books to people that craved power, and were given power.
The Right Attitude
So what is the right attitude to have? Managers should be facilitators of the development process. If you hire a new manager, make sure they absolutely love software development, and understand software developers. If you are promoting people from within, my preferred method, take software developers that are natural leaders, that have the team already looking up to them. Take developers that have been doing development for years, and want to get more done by leading a team, and growing that team to succeed!
So, make sure you have the right attitude, be a 360 degree leader, and everyone will want to follow you. People should want to be on your team because you are an awesome leader, motivator, and coordinator, not because you are a manager.
Challenging Problems
Software Developers want to work on challenging problems. They love solving things! They love puzzles, riddles, quizzes, new approaches to solutions. If you make the mistake of assigning your developers non challenging problems, or worse, no problems to solve at all, you will see some extremely unhappy developers. Getting developers to write documents, answer help desk calls, and create project timeliness is a crime punishable by death of your team.
At this point you’re thinking, well, I need status reports, and I need someone to answer the phones. Again the finesse factor comes into play. Let’s try some examples shall we:
Scenario A:
“Hi Sean, I need you to answer some help desk calls for the week, we are totally swamped.”
Scenario B:
“Hi Sean, I have noticed an increase in help desk call volumes, and the help desk does not seem to be finding any patterns or rhyme or reason as to why. I’d love it if you could take help desk calls next week, to help me find patterns and ultimately come up with a solution to why the spike in volumes!”
Which scenario is the right one? B of course! And you will probably get your software developer to solve some serious problems that sometimes get lost in the QA process through miscommunication from the help desk.
Micro Management
This is the deadly sin if you are trying to manage software developers. If you start to use this tactic at any point, watch out, you will lose developers like the plague has infested you team. The second you fall into this trap you are instantly questioning their ability, and their skills. You have just managed to demotivate your team in the worst way you possibly could.
Project Delayed?
If a project is delayed, or a system is not functioning to spec, you can count on your software development team to be more freaked out about it, than you are probably. The absolute best thing you can do is show them you are confident in their ability, and let them solve the problem. At the same time you obviously need to stay on top of the situation, and ensure that they are on the right path to solving the problem. This is where prior programming experience is vital if you are going to be a great software development manager.
You Must Have Software Experience
An experienced software developer will have that “blink” instinct to know if his team is on the right path, or the wrong one. He will be in sync with his team when problems arise, knowing quickly if they are approaching the problem correctly, and will have it resolved shortly. An experienced manager, with no software development experience, will be freaking out at the first sign of a problem with an application, because they simply do not know what is truly going on, and feel helpless as a team of developers is trying to solve a problem. They will cause havoc, stressing out the developers, and ultimately causing them to make silly mistakes.
Trust Your Team
Showing your team you are confident in them, while at the same time staying on top of the situation and making sure that Titanic is not going to hit an iceberg requires some serious finesse, and software development experience.
Think about this for a second. When you hire a software developer, or even a graphics designer, or a video producer, why do you hire them? You hire them so you can have someone that is highly skilled (hopefully if you have done your job) focus on an area and exceed your expectations for the job! Does it really make any sense for you to tell them what to do at a micro management level? If you answer yes, it does make sense, then you have hired the wrong person.
Meetings
I hate to break this to you, but software developers view meetings as a complete waste of time. Software developers are much more real time when it comes to things, and if you are sticking with Agile, you shouldn’t really have your developers in a whole lot of meetings. Developers live by e-mail. They can easily review their emails, make sure things are complete, and move on. Should an email come in that is far too complex to figure out without asking more questions, they will then go and ask the sender for more direction (at least if they are awesome developers).
Conduct Short Meetings
Stick to keeping your meetings as short as possible, and if at all possible, just have SCRUM meetings at the end of the day and that’s it. Any time you have a few developers in a room to meet on something is seriously unhappy time for a developer. The reason being they instantly start calculating things like: How many lines of code could I have written already, How many people are in this meeting that are not needed, How many man hours are we loosing per week in meetings.
Run Efficient Meetings, Don’t Waist Their Time
I am by no means saying meetings are useless, but make sure they are action oriented, to the point, and do not involve a lot of people. For example if you have 15 people in a meeting, and you only need 1 person at a time for 5 minutes at a time, do everyone a favor and just go to that person, then the next, and so forth.
At the end of the day, your team leaders can withstand more meetings than the software developers because they are trying to work on their management skills and executive skills, but your software developers want to program and solve problems! Let them.
Teach Them New Things… Feed Their Brains
You don’t necessarily have to be the one teaching, but it would help if they had a mentor to look up to and learn new skills from. If there is nobody in your organization setup as a mentor, create them, or feed their brains other ways! Let them buy any book they want, take classes they want, and take any certification exams they want. Let your developers work on the latest platforms and give them the latest tools to learn their trade better! The more you have your developers learning, the happier you will make them! Let’s try another scenario:
Scenario A:
You have the best working conditions, nice office, great compensation package, free lunches and dinners. Breakfast is waiting for your developers every morning. However, they are all working on Visual Studio 6.0, with no add-ins, and developing on Windows 98 computers.
Scenario B:
You have your developers working in a basement, no windows, terrible compensation package, no free food at all, and no health benefits whatsoever. However you give them Dual Core machines with 4GB of Ram, triple 22Inch LCD Panels, and have them developing AJAX applications, creating Web Services, learning ASP.net 3.0, PHP, Java, Web 2.0, XML.
Which one of these scenarios do you think a software developer would rather work in? B of course! Now sure I painted an extreme picture to make a point, but it’s true, and constantly forgotten!
Build Software That Matters
Something Steve Jobs has always done phenomenally well, is created a cause, and a purpose in his software development teams, and the companies he has managed. People want to change the world; people want to do things that matter! Being significant is a human need that we all need to fulfil!
Create A Cause
If you create a cause in your team to want to be bigger than themselves, you will not only have amazing software, and probably do things that no other team can do, you will also have some of the happiest, motivated developers around working on your team!
Don’t expect to keep a developer around if all you have him doing is crystal reports, adding in new functions into programs that are 5 years old, and updating ancient stored procedures.
Highly Used Software
Get them to write software that will increase sales of the entire organization, and help the company grow and donate even more money to a local charity. Get them creating new software interfaces that will make using your software easier, faster, and more efficient, helping the order entry team go home earlier on the weekends! Get them to build software that will get used by thousands of people, not by five users!
Help Them Find Their Passion
At the end of the day, when the dust settles, developers are on a journey to find themselves, to find out what they like doing best, and excelling at it. Will they be a Software Architect, a Lead Developer, an Executive Vice-President, or a Business Analyst? Will they choose Windows, database, or web programming?
If you can help your software developers find their passion, what they are truly made to do, you will be rewarded by having some of the happiest developers around. You will also make friends with some of the c00l3st people you will ever meet!
The Conclusion? It’s a Two Way Street!
I love working with software developers! I give them as much respect, advice, leadership, responsibility, and personal time I can possibly give them. They in turn, love working on our team and love getting up every morning. Together we achieve some pretty awesome stuff!
Going through both sides in the last 12 years, from help desk to pay for school, software developer, consultant, software development manager, to Vice President of Technology, I have definitely see both sides! I’ve had to do my fair share of firing and dealing with lazy programmers that think they are the second coming. I just plain don’t accept that on my team, and honestly, neither do the other team members. Nearly every member on my team scores extremely high in my 15 point, How to Rate a Software Developer, but is at the same time humble, compassionate, and caring.
If I had a flat tire, ran out of gas, or any other emergency, they would come help a the drop of a hat, and they would treat each other the same way. When review time comes, they know how their reviews will go before we even do them. In a competitive market, assuming you have the best developers, and assuming they treat you fabulously and with respect, you need to follow these rules, period. The days of Laissez Faire leadership and Transactional leadership are over. You need to be Transformational.
If you liked this article, please share it on DZone, del.icio.us, StumbleUpon or Digg. I’d appreciate it.
Its so obvious, but I think you hit upon the most important point. Developers want good equipment to work on and new technologies to work with. I’d definitely pick Option B.
A big mistake (from developer’s perspective) for any manager is keeping a legacy system around and making people update it. Its usually a cash sink anyways. Upgrade to the new technologies and your developers will feel vastly more satisfied at their job.
For me, I really cant stress this enough. Every job I’ve left has been because I was forced to work on older technologies (ASP3, .NET 1.1, PHP) than what I was hired to for (ASP.NET, Ruby on Rails). Manager are reluctant to pay upgrade costs, but the end up paying more in turnover rate as their devs move on to newer, more exciting technologies.