managementYou have an objective, a budget, and a team. You are a manager and you want the project to be done. You get your team together in a meeting room to discuss the plan. You tell them what needs to be done and ask them how fast they can do it. Then, you do the motivational dance and beg ask them to commit. They nod and go back to their cubicles. Of course, after a few months of “hard work” all the milestones are missed and you get back to the planning meeting. And, yes, you pay their salaries anyway.
This top-down management formula (boss says, everybody nods) was inherited from the times and industries where staff was easily replaceable and vitally dependent on the employer’s will. Call it the time of slavery, if you will. The basic principle was: “If you don’t do what I say, you suffer.”
Those times are over. Well, not everywhere, but in software development—for sure. The suffering part is gone and the formula has evolved to: “If you don’t do what I say, I feel sad.” You simply can’t make them suffer anymore. The only instrument that is left in your hands is guilt. However, it doesn’t work well with professionals. Unfortunately.
And because of that the traditional idea of planning doesn’t work either. No matter how you plan, you can’t get an honest commitment from the team, that’s why your plans will always be wishes instead of plans.
I suggest a better formula: “If you do what I say, you benefit.” Here is how it works: you identify expected deliverables, their quality acceptance criteria, put reward tags on each one (money, points, promotion, free vacation, or maybe cookies), and ask your programmers: “How much do you want to earn?”
They will do their own planning, having in mind their own time resources, putting together all the sophisticated motivational pieces, and then make their decisions: “I’m going to do these 12 tasks and earn $5,000.” Then, using this information you create the plan and calculate the timeline of the project. They tell you what they want to earn and you know what results you will get.
Thus, instead of making plans and making the team deliver according to them, you identify the points of reward and observe the intentions of the team to earn them. Your plan will be the derivative of people’s greed ambition.
Of course, this may be easier said than done: Spoiled and lazy programmers, who are in the overwhelming majority, most likely will refuse to work for awards. My advice is not to convince them too much. Just offer the awards on top of the salary they are getting already. Rewards don’t need to be large. What’s important is the shift in the decision making process. The decision to complete the work has to be made by the programmer, not you. The decision has to be based on their own selfish reasons.
What’s left for you is just to put their decisions into one document and see when the project will be completed and how many bonuses you have to prepare to pay at the end.
