You Be the Manager: A Case Study of Unmotivated Developers

An SbR reader contacted me looking for guidance on how to work with a group of un-motivated developers; his email is below (posted with permission).

I will post my reply next Monday, after giving you a chance to weigh in on the situation.

Q: “In the course of providing Change Management consulting services to an owner operated company, I got involved in trying to find out what was happening in their IT department (4 Software Engineers). They are all on salary with full benefits.

The IT Departments absolute priority is to insure the company’s current software and network system is operational. In general the current company system only requires minimal daily maintenance with periodic planned upgrades. Accordingly the Software Developers are able to focus the majority of their time on development of a new ERP software system.

They have been at the project for approximately 5 years. Design is complete and development is underway. After much discussion and prodding I managed to get them to produce a timeline to deployment versus completion. Deployment defined as being able to switch from using the current system to the new system with a minimum of equal functionality to the current system. The timeline is to a specific date versus effort in months. They arrived at the deployment via sophisticated process versus an educated guess so I believe it is realistic.

In my view stakeholders must have a deployment date and developers need a realistic deadline. We have our deployment date (set by the developers, not stakeholders) but I suspect they are not committed to it. They start at 8:00 am on the dot and are out the door at 5:00 pm. Lunch and coffee breaks are never missed. My concern is that they have been spoiled by not previously having a definitive deployment date so it is expected to balk at accountability.

My instinct is to shut the project down but I also do not like to give up.

[I’m looking for] direction on how to motivate this group to want to take ownership and to rise to the challenge of meeting the deployment date.”

If you were in his shoes, how would you handle this situation?

Start Small, Get Big
Growth Secrets for Self-Funded Startups. It'll Change Your Life.
What you get for signing up:
  • A 170-page ebook collecting my best startup articles from the past 5 years
  • Previously unpublished startup-related screencasts
  • Exclusive revenue-growing techniques I don't publish on this blog
"The ideas and information Rob provides should be required reading for anyone that wants to create a successful business on the web." ~ Jeff Lewis
Startups for the Rest of Us...
If you're trying to grow your startup you've come to the right place. I'm a serial web entrepreneur here to share what I've learned in my 11 years as a self-funded startup founder. Luckily several thousand people have decided to stick around and join the conversation.

For more on why you should read this blog, go here.


#1 Chris Mullins on 03.27.07 at 11:51 pm

Any project that 20 man-years in (5 years * 4 people), and is only now getting a schedule has been very badly mismanaged. Almost by definition, developers working on a mismanaged product are unhappy. The product manager should forced to go to PMI Boot Camp. The Devs aren’t to blame here, it’s a business failure, not a development failure.

#2 Frank J Kelly on 03.28.07 at 12:25 am

I’d approach it a little more softly 1) Ask the developers how much functionality they think is complete? 90%, 50%, 10%? Have them give you reasons why they say so. If the number is anything less than 75% then you need to talk to management about cancelling the project (25%+ means at least 18 more months of the same). Management may not sign off but at least you know what you’re in for (18+ months of more mess). Be careful though because if the developers find out you canned their project they are not exactly going to love you. 2) If it’s more than 75% have the Developers tell you what functionality they can demo to users and by what date – set demo milestones that are 2-3 months apart. Basically move it to more of an iterative user-accountable approach. Another issue is after 5 years how much of the requirements has changed? -F

#3 http:// on 03.28.07 at 12:48 am

Oh wow!!! Make them schedule a demo as soon as possible for whomever is paying the bills. Either there will be pride or embarrassment at this prospect. Lord, if I am ever on a five year long project – find me a new profession!!!

#4 http:// on 03.28.07 at 1:36 am

I think a mental shakeup might be needed. Some quick ideas: 1) Have a session devising a results only based remuneration system with the developers. (If you were to dump your nice secure income stream how would it work…) 2) Get the developers to suggest which parts of their work is world shattering and toss around ideas about cashing in on that!! 3) There’s no mention of a manager in here, whoever it is should be in on this stuff. 4) A developer to create a rapid (2 week or less) comparison of the business when the design was created and now. Jointly work out what that means. 5) Maybe even get the developers to call in ERP vendors and grill them about their products. Produce a comparison report that might be published. 6) If you had to start deployment in 2 months what would you be able to do, mind you it must be solid else… 7) Off site session maybe 3 days to a week, some plan to keep operations running… From that you can get a feel of what is really going on, and more important what might be possible.

#5 http:// on 03.28.07 at 2:29 am

I would ask these questions first: How do the managers know they are not committed? Why is 8AM to 5PM not good enough? What do the managers mean they are spoiled? What is the velocity the managers expect? How do the managers know their exepectation is correct? How is the quality of the deliverables? How do the manager get the answer to the above question? How do the developers feel about their velocity? What do all project team members including statkholders want from this project?

#6 Michael C. Neel on 03.28.07 at 2:40 am

Sun Tzu said if the troops aren’t following orders, then the general is not clear. If the general makes himself clear, then the officers were not clear. Replace the officers. Sun Tzu never blamed the troops for the mistakes of the Army. This problem here is a clear management problem, and most likely rooted in a management that doesn’t understand process, or setting clear, well defined goals then committing to them. 5 years sounds like focus has shifted and there is no one in place to tell the stakeholders to make a decision, or else there will be no system. Waterfall or Agile – 5 years is more than enough time for either method. The worst thing you can do is blame the developers, even if you feel they share in it. They have already been managed into not caring, and you have to show them there is a real change in management to bring them back. I have never met a developer who started out not caring. I have met several who have been trained not to care. Last, the hour thing (8-5); if you think developers should be working overtime hours *normally* it’s not a hard guess why developers don’t care.

#7 Martijn on 03.28.07 at 8:07 am

The devs not being committed because they only put in the required hours is, of course, bollocks in the sense that; If the work can’t be done in the default set of office hours, then the project has not been “set up to succeed” (nudge rob) Saying “rise to the challenge of meeting the deployment date” means that you don’t trust your devs to do the right thing, or get the work done on time. And I bet they feel the same about you. The use of the word “spoiled” kind of shows how you think of your developers. I suspect that after 5 years, they’re just tired and cynical. After having done 5 years of work without any well defined milestones or deadlines makes a person go numb. I bet they just don’t give a shit anymore. They just do their daily grind thing. And that is _always_ a indication of bad management. I bet the devs havent been challenged enough to keep them motivated. It seems to me that there is no personal bond with your developers. Your email doesn’t say how the devs feel about the project. Just your perspective. This can mean two things. Either you know and didn’t include it, or that you have no intrest in how the devs feel. Maybe you should ask them what they would like to do, instead of making the descisions yourself. If you want accountablility, you should let them make the call.

#8 Dominic Delmolino on 03.28.07 at 12:54 pm

Bake in some more deadlines and intermediate dates — call them “stretch” goals. SET THEM YOURSELF — don’t ask for them — you set the dates. Reward them if they make the stretch dates. Stuff like, “Module X must be completed by the end of next week”. If they get it done by YOUR date, give them a Friday off — or a round of free Starbucks — or a set of Amazon gift certificates. Anything to get them jazzed. Start motivating them to achieve progress. If it doesn’t work for the “whole” team, then give them individual goals. Publicly reward and praise the individuals who make those goals. They need to be challenged to achieve…

#9 http:// on 03.28.07 at 2:08 pm

Both Michael C. Neel and Martijn have made all of the points that I would have made. The only thing they didn’t out right state was that they had been in that situation before. I currently am. Having come off of a nearly 4 year stint with the same miserable client, I feel exactly like the developers you write about. I also have been one of the most highly motivated developers in years past. Without a doubt, the last client ruined my motivation. The pride in me really wants to regain that motivation, but on my own schedule and not by some monkey-boy manager’s BS “motivational tactics”, Those same tactics will accomplish nothing short of further de-motivating me. Remember, those same tactics were a large part of what got me into the situation that I’m currently in. The little bit of “active pride” left in me can’t possibly leave this post simply as a rant. So if it was my call as to what to do… First off, if you really care, on a personal level, about your team of developers and/or you are treating this as a business decision and they have the skills and knowledge to get the job done, then sit down first as a team (very important to avoid rumors), and then individually with them to find out exactly what is going on in their heads. Second, once you have confirmed that they actually do care and you definitely want to keep them around, work with them to create an incentive plan to help get them back in the groove. This is all above and beyond their current salary and benefits. They already get those and short of losing their job, which typically isn’t that big of an incentive to stay when the employer doesn’t really care, they have received those for the past 5 years doing exactly as they have been doing. The justification for the incentive plan is all about performing a cost/benefit analysis of replacing them (with unknown talent – i.e., equal, lesser or greater, costing who knows what) versus keeping them (motivated or unmotivated). If it only cost you $10-20K/developer ($40-80K total) to get them back motivated again (and yes, it very well might take that much, as $1000-$5000 wouldn’t do much of anything for me personally), it’s probably worth going down that road. Anyway, step one is actually caring, step two is not making the same mistakes your predecessor did, and step three is learning to not treat white-collar workers like blue-collar labor, because if you do, blue-collar labor is all you’ll get out of them (meaning employees that simply punch the clock).

#10 Neil Mix on 03.28.07 at 8:19 pm

How can a project languish for 5 years without having a negative impact on the company? Perhaps the reason the team is unmotivated is because they are acting without purpose. If the current system requires little maintenance, and the goal of the new system is only to meet the requirements of the existing system, what motivation is there to get the new system done? Launching a new system inevitably entails lots of work fixing unexpected problems. Doing so without a major improvement over the existing system equates to more work for the developers for no tangible reason. Find the reason for the project’s existence, and you’ll find your developers’ motivation.

#11 http:// on 03.29.07 at 12:07 am

This sounds like a hypothetical question. In an age of extreme programming, who would plan a development project with 4 developers for 5 years? And who is writing a custom ERP system these days? The consultant says he ‘suspects they are not committed based on observed hours’, and states the ‘majority’ of their time is spent on the new system. Is the project plan off track? The consultant should be analyzing the status of the project based on data not coffee breaks. Decisions should not be made on ‘instinct’ alone, but on data which has been analyzed resulting in meaningful information. If the current plan is not acceptable to Senior Management, then corrective action is needed, and the plan should be revised. The behavior of the developers might change along with a revised plan.

#12 http:// on 03.29.07 at 10:56 am

(A few quick points before spewing my ten minute advice: Good developers are problem solvers and capable of more than just writing computer programs—leverage this. A developer’s worth, productivity and motivation are poorly measured by the hours they keep—abandon that metric.) It sounds to me that the development team and its management (the senior developer?) are overly removed from the business objectives, budgeting, concerns, etc. My suggestion would be to first, similar to what others have written, find out what they individually think about the project. If they are pessimistic, then that is a really bad sign. Consider plan B. If they are optimistic, then pull them closer into the fold. Expose them to the decision making process, include them in it, show them where they contribute to big picture and where they are failing. The reality of the situation (as opposed to unqualified threats) should be motivating for the team. If they understand that, beyond their jobs, the success of the project is at stake then you can get more out of them…to include higher productivity, suggestions, comprimises, etc. After all that, if they shrug their shoulders and say “that is not my problem” or “that is not my job” when confronted with reality, the project is in deep trouble…and it is time to explore plan B. Good luck and let us know how things work out!

#13 http:// on 03.30.07 at 11:57 pm

Cancel the project, it is a drain on the company’s resources. If the “stakeholders” are not engaged then they do not care. If they do not really care they will not make the behaviorial changes that any corporate software requires. I guarantee this software will never be used or if it is, the ROI will be negative.