Practical Execution Excellence for Managers and Leaders — Part 1

Being a part of a rapidly growing organization can be a valuable experience for learning to be a strong manager. The typical question that haunts senior management / senior leadership in a rapidly growing organization is like this: “why the heck with more people in our organization it takes us longer and longer to get things done?”. This article will try to explore and discuss one of the possible angles why this problem happened which was caused by lots of people, especially managers, do not understand about execution excellence concepts and do not employ the right execution excellence model according to what the project or task needs. Understanding this framework and concept is very crucial so the right things can be done in the right way in the most effective and efficient way.

This article, although not intended to, would assume a more relevant / closer context for Engineering Lead, Engineering Manager, Product Manager, and Senior Product Manager in a technology startup company. It also aims to assist the transition for people who are previously heavily involved as IC (Individual Contributor) roles, have been performing really well, and then have been promoted into Lead or Manager without much prior experience in managerial work. Typical worry or concern for several people that I knew personally going into that path is that they are having a hard time valuing their contribution as Lead or Manager. Sometimes, they are even confused about what they should do to become a good Lead or Manager. A quick answer, one of your biggest contributions as a Lead or Manager would be in the form of identifying, carrying, and deploying the right execution excellence model to project / task execution at hands.

Due to its importance, this article will aim to explain and outline what is actually execution excellence and how you can practically achieve execution excellence in your day-to-day work. Hopefully the reader of this article can understand more about this critical concept and can help them to become a better, more effective leader / manager.

Let’s start our journey by understanding different execution excellence models through a simple real world example. Let’s assume there is a company called “TBT (The Best Tech)”. TBT is a technology startup company that provides entertainment SaaS service to multiple medium and big enterprises as their clients.

One day, TBT CTO came to one of his team’s Engineering Manager (EM) and said: “Hey, I think we need to develop feature A and B in our platform”. The manager thus asked the CTO, “Why do we need to develop this feature, boss?” The CTO told the EM that this feature is required by our sales team to interact better with our client. It would help them to close more deals and means it would drive the revenue of the organization. Hearing that, the EM thus thought for several moments and said “Okay, I’ll ask the team to develop the feature.” The CTO said, “Okay, then, I’ll wait for the feature to be delivered”.

If you resonate with the story above, it’s actually a typical day-to-day scenario in your life as a middle-manager in a startup company. Only the task might be varied, it may not be about developing features. The tasks may be about rolling out of a certain technology to multiple teams, migrating databases, refactoring stuff, applying system improvement, and so on — etc. Considering multiple real world scenarios, I can say the probability of the outcome could be placed in the following spectrum:

• Not Executed : The tasks are buried due to lots of higher priority tasks filling in the backlogs of the team. The CTO thus asked the EM after a quarter. “Hey man, how’s the feature development progress so far? Is it done yet?” The EM, buried in the busy day-to-day management suddenly realized, “Ugh !” and said to the CTO “Sorry boss, the team is really busy”. The CTO was shocked to hear that, however, he cannot say much. The tasks then never being executed and delayed for quite a long time.
• Problematic Execution : The task is communicated by the EM to the team. The team thus will execute the development for feature A and feature B. It was then put to sprint by the team. The development of the features itself is pretty costly. It took 2 engineers and 2 sprints to finish the development of the feature A and feature B. At the time of the deployment at the end of the sprint, the EM announces it to the company communication channel, 1 hour before the scheduled deployment happens. After the deployment happens, suddenly some part of the system got problems and caused the system to go down. Everyone is confused about what caused the problems. Turns out just before the deployment, another team is changing the API contract used by the feature A & B and causing the way the feature consumes the API becomes obsolete causing critical bugs. The CTO, curious about the root cause of the issue, asked the EM to conduct a Post-Mortem. He later found out that the feature A & B developed by the EM’s team was actually using the wrong API contract and completely different from what he’s imagining or asking for.
• “Okay” Execution : The task is communicated by the EM to the team. The team thus estimates the development effort for feature A and feature B. It was then put to sprint by the team. It took 2 engineers and 2 sprints to finish the development of the feature A and feature B. The development of the features itself goes well. At the time the features were gonna be released to production, the EM informed the CTO that the development of the features were finished and the team was going to release it to production soon. The CTO, knowing some context, suddenly said to the EM: “Hey man, I noticed that the other team is actually trying to change the API, you should check on with them”. The EM, hearing that thus following up the other team EM. It turns out that the other team is trying to change their API and it breaks a previous contract that has been established with the previous API. The EM thus re-coordinate the effort to ensure the development is compatible with the new API. The features were released safely, 1 week after the estimated timeline due to last minute change happening. The EM thus reported to the CTO that all the feature development was already completed.
• “Good” Execution : The task is communicated by the EM to the team. The EM tried to gather feedback and estimation for the execution effort required to complete the development of feature A and the feature B from his team. At the time of the estimation meeting, he noticed that the feature A & feature B is actually using an API from another team. He thus created a 10-minutes kick-off meeting to announce the start of the development of the feature A & B. He explained that the feature development effort will take estimation of 1 sprint. In that meeting he invited the CTO, the other team EM and informed them about the development of the feature A & feature B. The other team EM realized that actually they were gonna change and deprecate the API that is used by the EM’s team. He thus informed the EM at the kick-off meeting. Knowing that information, the EM took note about the API change and they adjusted their development plan to use the new API created by the other team. It took 2 engineers and 2 sprints to finish the development of the feature A and feature B. The development of the features itself goes well. At the time the features were gonna be released to production, the EM informed the CTO that the development of the features were finished and the team was going to release it to production soon. It was on time. The CTO was happy with the execution result and the features were delivered safely and on time.

(Please do note the case above is assuming a reasonably well culture where people generally want to get things done and do not have “harming” intention to sabotage execution)

Up until now, could you spot / abstract away what’s the key difference between the various execution outcomes? Do we have a better execution outcome more than “Good” execution outcome?

Chances are if you can resonate with the example above and be able spot the difference, it means that you have a pretty good understanding about execution excellence. For a final illustration, I would like to present a last point on what I would call an “Excellent” Execution :

• “Excellent” Execution : The task is communicated by the EM to the team. The EM tried to gather feedback and estimation for the execution effort required to complete the development of feature A, and the feature B from his team. The EM prepares a document that quickly summarizes what are the things that need to be changed and affected during the development effort. He noticed that the development efforts needed to be integrated with other team’s services. He contacted the other team’s EM and discussed his potential development effort. The other team’s EM informed the EM that they are gonna deprecate and change the API soon. The EM took that information and altered the document. After finishing up the document he quickly gathered all the respective stakeholders (the CTO, other team’s EM, Principal Engineer & Architect in the team) and presented his execution plan that is laid out in the document. He was trying to get validation on the approach that was used to execute the feature development and make sure they are correct and the right decision was made. The CTO, Principal, Architect gave 1–2 inputs to make things more effective & efficient. They also bring out several things that need to be considered. Turns out there were some processes that needed to be adjusted in other teams after the feature was in effect. The EM thus informed the audience that this development effort will take 2 engineers and 2 sprint, with estimated task breakdown of ~20 tasks. He took the meeting notes and recorded all the points that were made on the discussion. He thus got a sign-off & buy-in from the required authority (in this case the CTO). After that, the EM worked with his Team Lead to breakdown the task required. On the 1st week, the EM informed the CTO that the progress of the execution was on around 40%. The team did well and moved faster than the EM thought. The EM took responsibility for giving frequent progress updates to the CTO through a written report. At the end of 1st sprint, the CTO knew that the team had finished 12 out of 20 tasks. The development of the features goes well. The CTO was happy with the execution result and the features were delivered safely and on time.

Now, do you see the difference between “Good” execution vs “Excellent” execution?

Maybe some of you are wondering what’s the point of laying out the detailed example above. The example above tries to provide some practical guidance and examples to illustrate how various managerial activities might manifest in a certain project / task execution in an organization. It also can help you to illustrate the different spectrum of manager’s capability in carrying project execution. This spectrum of capability is the key answer of the question of “why the heck with more people in our organization it takes us longer and longer to get things done?”. The hypothesis is simple, really. If you have strong management team that can provide execution excellence, chances are you won’t have that question. It’s every executive’s dream to have a team of strong managers. It is also actually one of the critical components of executive’s work, to build up a strong management team that can execute and deliver consistently.

Obviously, a strong management team consists of a couple of strong managers. Strong management team will provide execution excellence to the team / people around them resulting in a far higher organizational productivity. I define Strong Managers as people that understand the Execution Excellence model and can deploy the right Execution Excellence model to the right execution context (mostly about projects, initiatives) so things would happen smoothly without lots of surprises. Strong Managers are the people that can guarantee delivery and outcome of many things.

So, now, let us define Execution Excellence which is the critical requirement of a Strong Managers. To be honest, it’s really hard to define it in simple words or sentences. So, I would like to try a more aspect break-down approach to help you understand the concept. Execution Excellence has the following aspects :

• Problem Understanding : A correct, again I emphasize, correct knowledge, scope, breakdown, and description of what exactly the problems need to be solved, why it needs to be solved, the differences / changes that would take effect before and after the execution, risk factors that might affect the execution outcome, and mitigation plan if any of the risk factors happened. In this point, I would need to emphasize that the context is more about the understanding of a certain already known problem and possible solution to solve it. The understanding aspect here is slightly different with strategic understanding (which I think I would try to discuss in different articles) in which the focus is more about figuring out the right problems to be solved (to make the unknown known). The understanding here covers how to solve the known well enough. Ideally, in this understanding aspect, you would lay down or describe several possible approaches, options, alternatives that may work to solve the problem at hand,
• Alignment in Decision Making : Once an understanding is achieved, then an excellent execution will need to make sure that everyone shares the same understanding. You will need to make sure that the decision for the execution approach, decisions, action items, timeline, and priorities are known to relevant stakeholders. The aspect of alignment is not the same as everyone agrees with the decision, however, nevertheless a decision about the execution approach, action items, timeline, and priorities is made. Sometimes you will need to have the voice of authority to get the decision, sometimes you will need to just push it and execute to get the decision being made. Ideally, in the alignment phase, we should be able to lock in the important priorities & sequences in the execution, the timeline of the execution, the action items of the execution, and the execution approach that we choose.
• Progress Visibility : Once alignment is achieved, then you will actually enter the phase of the execution. The key rule here would be simple : People like to see and know the progress. By people, executives (C-Level) and your boss is included. So, a good execution has enough progress information to relevant stakeholders. Everyone knows what are the things that need to be done (can be in form of checklist / task items), when is the estimated time for all the execution to be completed, and where is the current execution position residing.
• Recall : I consider the aspect of recall as one important part of execution excellence. This aspect would cover some critical questions, one of them such as : at that time why did we make the decision to execute with this approach? What is the context of the project executions? What are all the decisions being made throughout the execution? The unpopular name for Recall would be Documentation. (I choose Recall as an aspect name for its more cool name, really). With documentation, it provides an excellent ability for the people, whether they are involved / not involved, to be able to recall how a certain execution is progressing, why a certain decision is being made, what are the approaches and the result of the execution. To be honest, if we execute excellently, this Recall aspect will automatically be handled as this documentation serves as one of the key tools that is a critical part of execution excellence.

A measure of excellence in execution would be reflected in those 4 aspects. The concept and the breakdown of the aspect itself is pretty simple, even sometimes obvious. However, in reality, lots of people are having a hard time doing it well enough. It’s pretty common to have lots of gaps between understanding the conceptual versus applying the practical (in Bahasa, we called this term “ah teori”).

In Part 2 of this article, I will try to discuss in more details about the practical aspect and how to apply the concept above. We will try to cover the practical tools, processes, and tips and tricks to achieve execution excellence in your day-to-day work. In Part 3, I will try to outline a simple case study so you might get a deeper understanding of how you should link the conceptual with the practical.

P.S: In Indodana — part of Cermati Fintech Group, our leaders do care about the growth of every team member. For example, this article is written with the intention to coach all the managers and leads in our organization so that they can level up their capabilities. As the Indodana organization rapidly grows, understanding the concept of execution excellence is being more and more critical to keep us agile and productive in delivering important things. Even, at the very least, the right execution excellence is required to make a project move.

Personally, if you’re looking for a platform and opportunity where you want to grow your leadership and managerial skills, I deeply believe that Indodana — which are part of Cermati Fintech Group — can give you the challenge that you need to further strengthen your managerial capabilities. We have lots of exciting plans ahead of us and we are always hiring for various roles ! (At this time especially, we are eagerly looking for strong candidates to become Product Manager, and Engineering Talents). If you think that this article resonates with you, and you are eagerly looking for a place where you want to work with people that want to live the same principles laid out in this article, please feel free to contact me via LinkedIn or shoot me your CV via email to antony@indodana.com.

Thank you message: I am deeply thankful for Winson Waisakurnia for proof-reading this article and giving some meaningful feedback and suggestions before this article gets published in the wild.

Lastly, if you have any questions / feedback, feel free to shoot me an email / reach me out via email to antony@indodana.com.

Cermati Fintech Group is the leading startup company in FinTech space focusing in Indonesia market. The product portfolio consist of Cermati.com, Indodana, Cermati Insurance, and Cermati Bank-as-a-Service. Our group vision is to bring more financial inclusivity in Indonesia by empowering players inside the ecosystem.