Planning, execution, and control are essential to a successful team’s DNA. In Part 1 of this series, I expanded on planning. In this essay, I dig into execution.


Execution is where the real tangible work happens. It consumes most of the working hours for individual contributors. This is by far the most challenging part to get right. Why? Planning and Control are top-down. There are good examples of how to get them right. Execution, on the other hand, has many variables. The larger the team (or the company), the more complex things get. 


Execution depends heavily on line managers and individual contributors. They are a crucial part of making a plan work. Similar to the previous part of this series, I will share some tips on executing better and avoiding common pitfalls.

Execution Tips

Following are some tips to improve execution within a team, regardless of its charter:

  • Define explicit roles and responsibilities (R&R). R&R should be clear in each project: who owns which part of the execution? Different companies have different ways to address this. Smaller companies, such as early-stage start-ups, don’t have the luxury of having dedicated people for other project parts. So, it is expected from someone such as an individual contributor to wear multiple hats. Clear R&R sets the right expectation for the team responsible for which part and avoids confusion during execution.
  • Tech debts will slow execution down over time. Tech debts occur over time. It may start with adding a simple if statement for a VIP customer to grant them some functionality to get more revenue. Years later, the code will look like spaghetti. No one understands how it works, and people are afraid to touch it. A simple change may take weeks because of the complexity and testing. This is just an example. Of course, there are many other types of tech debts. But, they share a similar characteristic: they slow down the execution. Intelligent leaders can identify which debts are causing bottlenecks for the team and put conscious effort into paying them off. 
  • Organizational debts and unnecessary red tape can lead to friction and slow execution. Unlike tech debts, organizational debts are hard to observe. In early-stage startups, there are policies (implicit or explicit) to speed up deliveries. As the company matures, these policies need to be updated to ensure the success of the company. Here is an example. A startup with 15 engineers has one QA for manual testing for weekly releases. This QA should sign off on the release candidate before the release. This works fine until the engineering size grows and features become more complex. The naive solution is to add more people to the QA team to help scale. This works until the QA can’t keep up with the workload. Engineering teams still need explicit sign-off before releasing, so they have to fight over QA resources. It results in more QA work, friction for the engineering team, a longer feedback loop, and potentially more mistakes. One way to address it is to loosen up the “explicit sign-off” policy and invest in more automation. 
  • Non-planned work disrupts the execution flow. Incidents and bugs are examples of non-planned work that sneak into a team’s workload. Incidents require attendance, investigation, writing postmortems, and addressing short-term mitigation. Bugs require back and forth with customer support or the business partner to resolve. All suck the time from the team’s execution focus on important projects. Good leaders allocate time in advance for non-planned work based on historical data. If non-planned work becomes too disruptive, it can be due to other organizational problems.
  • Use the right people for the job. People have different traits even when they share the same organizational title. Take engineers, for example. One can be good with quality and the other one with speed. One can investigate things in detail, while the other can manage multiple high-level items without deep knowledge. Choose the right trait for a specific project.
  • Too many or too few processes can slow down the execution. Processes intend to make execution better. A good process can be repeated between projects of the same type. Too many processes can slow the execution and bog down the project with unnecessary bureaucracy. On the other hand, too few processes can lead to misalignment and possible work churns. 
  • Perfect is the enemy of good. Perfectionism can cause delay and consume the project resources on non-important stuff. There is always a good enough state that cost/benefit is optimum. It is important to point out must-haves and nice-to-haves. I covered this in my Good Enough essay.
  • For individual contributors and line managers, the focus is essential. Individual contributors and line managers spend most of their time in execution. They need enough focus time to execute properly. Constant context switching and fragmented schedule can lead to slower execution. I wrote about Time Management in one of my essays.
  • Escalation is necessary to unblock progress. Escalation is a last resort tool. However, escalation at the right time can save time and reduce friction. It is important to know when and to who one should escalate. Who is usually a person in an authority position who can call the shots and make quick decisions. When is a bit tricky. It shouldn’t be too soon or too late.
  • Too many dependencies can cause frequent pauses during execution. Dependency can be on another service, department, or individual. For example, a team wants to prototype a feature requiring a new API to be added to an upstream service owned by a different team. While the implementation seems straightforward, creating alignment between two teams takes way longer. Code review can become a bottleneck since two teams don’t understand each other viewpoint. Another example can be a new feature which requires integration with a 3rd party tool. Reviews from the security and legal team can take much of the execution time. This happens while the engineering team is going back and forth with them on the non-implementation part of the project. These dependencies will eventually be there as a company grows. The best way to deal with them is to avoid them as much as possible. For example, if an existing tool can do the job you want, it is better to use that instead of buying a new one, even if the new one is better in some ways. 
  • Frequent requirement changes create busy work. When requirement constantly changes, there will be churn in work. People seem busy, but there is no real value delivery. Projects can span years without any real value. Looking closer, you can find people working hard, but they also churn their work. It usually happens when there is a disconnect between the implementation team and the actual consumer. It is helpful for the implementation team to be involved in all phases of development, including requirement gathering. 
  • Proper prioritization maximizes value delivery. Prioritization is a gray area between planning and execution. In planning, prioritization is essential to ensure enough resources are allocated to the right project to maximize value. However, in execution, we must prioritize one project over another due to time or resource constraints. Which task to prioritize now becomes important. In one of my previous posts, I expanded on this topic: Project Properties: Effort, Cost, Value.
  • Don’t underestimate employee engagement in execution quality and speed. Engaged employee utilizes their time more efficiently. They pay attention to details and do their best to implement with best practices in mind, catching edge cases and writing proper documentation. Back to one of the previous points on using the right people for the job, some people are more engaged in a specific type of project. For example, one can be excited about shipping a highly visible revenue-generating feature, while another is more engaged in a refactoring project. 
  • Burnout is a silent productivity killer. Employees who suffer from burnout have reduced productivity. It is hard to notice burnout since it is a mental state. Good leaders notice employees’ productivity changes and take action early on. I explained more about Burnout in another article.
  • Too many and too few people actively involved in a project will cause execution problems. Both extremes are equally bad in projects. Too many people create unnecessary friction. Too few people, on the other hand, leads to overworking and delay in deliverables. Adding people to a project doesn’t necessarily increase the execution speed. 
  • Micromanagers and disengaged managers both cause execution pain. Micromanagers cause mental pressure on employees by constantly looking over their shoulders. They kill innovation by telling them how to do their work. Conversely, disengaged managers won’t help when the team needs them. The team has to find their way out, which is not the most efficient way.
  • Lean towards experimentation and incremental value delivery. In an ideal world, we know for sure what a customer wants. We go to the drawing board, design a system, implement, and roll it out. However, in real life, it is more complicated. We don’t know what customers want (even when they say they want it). Investing a long time to develop a new product or a feature without knowing its impact will waste resources. It is more of a bet. The culture of experimentation and incremental value delivery over time can help the team to have a shorter feedback cycle with more data to influence their decision. 
  • Migrations without a proper strategy can cause execution pain. Sooner or later, a company may migrate to a new programming language, framework, or tool. They have a good intent in heart: slowing down execution for a short time to make things faster in the future. Depending on how a company approaches migration, it can be a breeze or a pain. A good migration strategy has a technical, process, and people part. The technical part ensures a smooth migration and that users get the best experience (even if it is degraded). The process part is on how to prioritize and reduce unnecessary red tape. The people part is about change management and making sure people are on board with the upcoming changes. This topic requires its own article. Fortunately, Gergely Orosz has written a good one in his blog: Migration Done Well.  
  • Reorgs slow down execution on all affected teams in the short term. A reorg intends to focus the new teams on what is more valuable for the company- a new product line, for example. In theory, people move from one team to another, work on new stuff, and hopefully be productive from day 1. In reality, when a reorg happens, some projects are already in flight. Depending on new priorities, a team should take ownership of those projects. This team may be a different team that started the projects. The new people have limited knowledge about the projects but must finish them. Another problem is the ownership split. Services will get tossed to another team. The service moves with its bugs and feature requests. It takes teams a while until they get comfortable with their new ownership. During this period, it shouldn’t be surprising that productivity decreases. 
  • Ineffective tooling and lack of automation create chronic frustration. There are manual things we do every day, from deploying a service to production to running an experiment and seeing the results. Depending on the level of automation, people may find these day-to-day tasks easy or frustratingly dull. Imagine a system that automatically runs checks on pull requests when they are merged to the main branch and then automatically pushes them to production. Compare this to a multi-page instruction on manually pushing new changes to production. The former, the engineer, can focus on something else and trusts the system. While the latter, they have to spend a lot of time in a boring, stressful, and error-prone activity. 
  • Too many owners and no owners are equally bad for execution. The ownership gap creeps up over time. In the case of no owner, it can be due to a tool or service made by a team or an individual. Either the team got disbanded, or the individual left the company. That tool or service doesn’t have any owner as a result. On the other extreme, there can be cases that multiple teams own a tool or service due to various reasons such as reorg. This is equally bad compared to no ownership. Why? Other teams now have to contact multiple teams to get alignment. There is no clear cut between ownership components. There are gray areas that touch multiple teams’ operations, and neither may take ownership of making changes. Ideally, there should be one and only one owner for each component.
  • The high bus factor is insurance for support continuity in the future. When there is more than one person knowledgeable about a system, we create a safety net if one of the owners decides to take a long time off or leave the company. In hot components, having more than one SME can help distribute the load of support. 
  • Tactical and strategic teams have different execution muscles. Tactical teams, which most product engineering teams fall into, are good at executing fast. They have a higher tolerance for tech debts and bugs. They may churn work often due to experimentation and requirement changes. On the other hand, strategic teams, which platform and infrastructure teams fall into, execute slowly and have a lower tolerance of debts and bugs due to the critical things they own. Choose the right team for the job.
  • Incorrect incentives for teams and individuals result in busy work. These incentives can be for personal gain or due to an unfit policy. An example of personal gain is promotion. Individuals or managers may take on work to create a case for promotion. This is okay when the outcome creates more value for the company. However, in some cases, this may lead to unnecessary complexity. An example of an unfit policy is to demand high availability (e.g. >99.99%) for a service that is not revenue-generating or tied to critical user flow. The owning team may spend quarters increasing the resilience of this service. However, there is no real business value connected to it. 
  • Make sure the budget is there before executing long migration projects. Long projects are the ones that span years. Long migrations are examples of these types of projects. Some examples are: migrating from a local data center to the cloud, migrating to a new programming language, or migrating from an in-house tool to a 3rd party tool. The problem with these kinds of projects is that the real value usually comes after quarters of fundamental work. Executives must sponsor these migrations to ensure they have enough budget (people and money) to finish.
  • Ineffective communication between team members or cross-team collaboration results in misalignment and potential work churn. During execution, communication between stakeholders is essential. Design reviews, code reviews, feature roll-out, bug reporting, and support are examples of when communication is happening. Proper communication is necessary for each step to ensure stakeholders are aligned, and the team is working towards the right objective.
  • Project management is an underrated skill in driving a project. In early-stage startups, hiring a dedicated project manager is a luxury. Depending on the project scope, product managers, engineering managers, or individual contributors take on project management. It is important to know the basics. In larger organizations, a dedicated project or program manager is necessary to make sure smooth execution, especially when a project impacts many teams.
  • Good conflicts result in better outcomes, while bad ones cause unproductive friction. Technical conflicts are generally good conflicts. Different people or teams come together to find a better path for a problem. On the other hand, personal conflicts can lead to frustration. It is crucial to have an ultimate decider for a project. They can call the shot and move on if conflicts get to a non-productive level. Frameworks such as RAPID are helpful in these situations. 
  • Lack of proper documentation can lead to slower productivity and under-utilized systems. When a new system or feature is created, it is meant to be used by some users, internal or external. If there is no good documentation for the next generation of developers or users of the system, the effort of creating that tool goes to waste. It will be harder to extend it or use it later on. 

Execution Deficiency Symptoms

There are symptoms that leaders can watch out for to identify problems in their team’s execution practice:

  • Simple things get longer than expected to execute. Leaders who have spent a long time close to the front line understand how long things should typically take, even if they are not SMEs on a particular subject. This should be a good clue that something is not working right. 
  • Some metrics (e.g. DORA) can show execution problems. Organization-level metrics can be the indicator of an underlying issue. These metrics and other quantitative or qualitative data should be used to point to a specific problem. There is no silver bullet on how to solve the issue. But, measuring and identifying incremental steps to improve them is an excellent place to start.
  • Line managers and individual contributors consistently raise issues like paralyzing tech debts or collaboration problems. Line managers and individual contributors are close to the action. They understand the execution pain the most. Higher-level leaders must listen to their concerns and see if any synergy between different people points to a hot spot. 
  • Signification amount of unplanned work is a sign of an underlying issue. When a good portion of the team’s time is spent on incidents and bug fixes, there will be less for executing other commitments. 
  • Long migrations show a potential execution problem. This is more problematic when a migration requires federated efforts from multiple teams to finish successfully. Many factors prolong the execution, such as competing priorities or technical impediments. Line managers and individual contributors are the best people to share their issues with higher-level leadership. 
  • Frequent churn in work creates an illusion of productivity. In reality, this can be a sign of a problem. The development team is busy writing code and deploying features in this case. Looking closely, you can find a high churn in their work. This is not really obvious from metrics and requires more investigation.


The importance of execution in the planning, execution, and control process cannot be overstated. It is the most challenging part, as it heavily depends on line managers and individual contributors and requires effectively managing many variables, especially in larger teams or companies.

To improve execution, it is crucial to implement strategies such as defining clear roles and responsibilities, addressing tech debts and organizational debts, allocating time for non-planned work, using the right people for the job, finding the right balance in processes, and prioritizing tasks effectively.

Leaders must also be vigilant in identifying symptoms of execution deficiencies. This includes recognizing when simple tasks are taking longer than expected, observing negative trends in performance metrics, listening to concerns raised by line managers and individual contributors, addressing high amounts of unplanned work, managing long migrations, and reducing frequent churn in work.