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