In this post I want to talk about a procedure that I have been developed to streamline execution of engineers’ tasks.

Task Execution Procedure

The task execution procedure or work efficiency procedure is intended to bring novice engineers up to speed and encourage experienced ones to be on the same wavelength. Over the past years of working in various leadership roles, I have developed and refined my procedure so that the teams I managed complete the projects assigned to us on time. I believe it is innovative and effective as it has improved the way my colleagues complete their work and we have increased our efficiency as a team.

In my previous roles, I led groups of engineers who were knowledgeable about the topics of interest and enthusiastic about what they had to do, but did not necessarily know how efficiently to execute their tasks. I have to confess that I was hard pressed to develop such a procedure that enabled me to efficiently and effectively take advantage of the resources I was given to solve the problems and deliver products on time. This type of situation, in which a manager has to stretch resources to the fullest, is common in start-ups, mid-sized companies, and even big-companies. This is because managers cannot always hire talents who meet every job requirement.

My procedure consists of three major steps: the writing of a contract, iterations of execution and revision, and a postmortem. In the first step, an engineer spends a week or two thoroughly thinking about how to execute their task. The expected outcome is a document that clearly and succinctly defines the goals of the task, its inputs and outputs, other specifications and schedules for delivering their parts. I usually try to assign an engineer with a task (e.g., developing a SW module) that is matched to their credentials, and/or aligned with their career goals. When a task does not align with their credentials, by writing a contract, the engineer has an opportunity to learn what they are going to do. In a nutshell, this is a planning phase that externalizes the ideas and logics engineers intend to use to meet the project’s requirements. To me, planning always comes before action, my notion of plans/planning is similar to what Josh Kaufman described in his book, “Plans are not useful because they help you predict with better accuracy - they are useful because the act of creating the plan helps you understand requirements, dependencies, and risks more thoroughly than when you started.” To complete this step, understanding what the customers (e.g., for most of the cases, they are engineers from other teams who will be using what we are developing) want is critically important. This should go without saying, but without understanding what the consumers want, an engineer is highly likely to waste their time as well as that of stakeholders. To this end, an engineer needs to meet their customers many times until the contract is completed. During this step, I or a senior engineer who had been through the procedure more than once typically became involved in moderating discussions between the engineer and the customer, and helping the engineer come up with a more realistic plan. Once this step was completed, the contract acted as a playbook that guided us through a designated period of time and led us to spend our time more efficiently by helping the engineers focus on the benefits which the product would bring rather than features that may satisfy the engineer. Additionally, we had a document that forced us to keep our feet on the ground and stick to our plan, and we could always come back to it if something unexpected happened.

The next step is to iterate two sub-steps: execution and revision. In this step, we begin to see the development of the product, observe how the contract is unfolding, and measure the progress of the task. During this phase, it is important that all team members stay on the same wavelength. To this end, I use the idea of the daily scrum in which we stand in a circle and each team member talks about the following three things for five minutes: 1) what is an overall progress thus far, 2) what has to be done today, and 3) what is (are) a blocker (s), if any. This way, all team members see the big picture and can help each other if he knows how to get around blockers. This step sounds like just the execution of the plan, but there is an aspect of revision that offers us a buffer for dealing with unknown unknowns. When we write a contract, we do our best to think thoroughly about the work. As the contract is completely based on teams’ collective knowledge, there is a chance that it may fall short and end up mostly touching upon known unknowns. Therefore, there is always a chance a team will face something unexpected. When this happens, stakeholders get together to analyze what has occurred and revise the plan to modify the means of how to get there while trying not to change the schedule. Unless we have clear justifications for extending deadlines, the deadlines should be respected. We then repeat the task execution and revise it until we deliver what needs to be delivered.

The last part of my procedure is a postmortem. This is another documentation step in which the engineer has to review and write about how they executed the task based on their contract. This gives us an opportunity that helps us analyze the outcomes from the perspective of the task’s specifications and, if necessary, develop some ideas on how to improve the outcomes. In addition, the outcomes of postmortem have been very helpful for newcomers and anyone catching up on a project.

With my task execution procedure, I have often observed that my teams are able to spend their time, much effectively, without distraction and execute tasks more easily without confusion or ambiguity because the procedure offers clarity regarding the tasks we have to execute, expectations we have to meet, and feedback on the results. The procedure has led to success, as we have delivered milestones (e.g., a target tracking module for drones, visual SLAM packages and remote driving package for autonomous mobility). Another result I would like to highlight is that I have seen many new engineers become more efficient in utilizing their time and effective in delivering on their job descriptions.