Tasks done wrong

The long way is the wrong way

Jon's manager was frustrated with Jon, a member of a small agile software team within a startup. Jon never quite delivered the task at hand. He programmed solutions that were far more sophisticated than required leading to wasted work when requirements inevitably changed. Jon himself would then express frustration when much of his work wasn't used. Other times, Jon spent long days programming solutions from scratch when free open-source packages existed that could have been customized within a few hours. Sometimes he would finish work but fail to communicate completion to the appropriate team members who were waiting for the work, leading to long, unnecessary delays in feature deployment.

Jon's manager had tried writing out more detailed work plans and also pair-programming with Jon to make sure his work is on-track. With a lot of hand-holding, Jon was able to execute the work. However, Jon's manager was not happy with this and did not have the time to continue this level of hand holding.

The communication gap

The manager needed to communicate to Jon that his work involved not just programming solutions, but solving problems and completing tasks efficiently within the context of a fast-changing agile startup environment. This included evaluating the best approach to solving a problem, not just going with a brute-force approach, programming more bite-sized solutions, and communicating with team members.

Solution

We coached the Jon's manager to have the conversation:

I'd like to discuss what it means to complete a piece of work. I've noticed there were times that you programmed things from scratch when it would have been quicker and more suitable to customize off-the-shelf solutions. I've also noticed that often you will program more than is asked for in the ticket specification. Finally it is equally part of the job to ensure the right people are aware that a task has been completed. For a given piece of programming each of the following steps are equally important:

-Spending time evaluating the most efficient approach to the problem, including a thorough survey of off-the-shelf solutions that might be customized instead of building solutions from scratch.
-Being accurate about delivering exactly what is specified as needed and not more. A lot of thought went into defining each deliverable unit of work in our sprint planning. There is a lot of uncertainty regarding whether more complex features might be needed and also what forms they might need to take. So a key part of the work is not getting ahead of ourselves by over-engineering complex solutions.
-It is essential to communicate work completion to those who are waiting for it. It is just as much part of your work to complete the communication around the work as it is to produce the work itself.

Outcome

After this conversation, Jon explained that he really disliked using existing off the shelf solutions and was much more satisfied building code functionality from scratch and owning a single thread of work. However, he was able to understand the importance of communicating work completion and staying within the defined specifications. Eventually Jon left for a larger company where he could work in a more well-defined, specialized role where he could focus on a more specific set of skills and have greater ownership over a single thread of work. This was a good lesson for both Jon and his manager on the nature of the work of a programmer in this agile startup environment.

Take-Home lessons

Be ready to provide a detailed description of the steps involved in completing a task. Also include a checklist of questions to watch out for (e.g., in this situation, such a question would be, "Am I working on anything outside what has been specified?"). Be prepared to revisit and add granularity to these tasks over time. This will allow future feedback to be straight-forward. While for many employees some of these steps will be implicit or intuitive, inevitably managers will encounter employees for which these steps need to be enumerated more specifically.

^*Due to the sensitive nature of our case studies, names and details have been changed to be anonymous.