Image by Kyle Hale
When starting on a new team I often struggle to describe one key aspect of my role - Execution. How do I go about characterizing what execution is? Is execution making other engineers more effective? Does it mean helping speed up feature deliveries? Or is execution just resolving tickets quicker? In my experience, none of these quite cut it in terms of capturing the essence of execution. In reality what I’ve found is that teams that execute well have a very intangible quality that can only be experienced, not measured. This blog series is my best attempt to describe what these factors are and things we could do to foster such an environment for teams to flourish in. My hope is that this series serves as a good resource for senior engineers and engineering managers looking to enable their teams while at the same time helping junior engineers to level up in terms of learning the nuances of execution. For the sake of simplicity I will be making definitive statements based on my experience and opinions, ones that are subject to change as teams and processes evolve.
Through the course of this series you will encounter overlapping themes that seem connected to one another. Do not consider them separate; in the process of practicing one you may well end up using another.
In order to keep the themes organized and manageable I’ve broken down this topic into 3 parts:
Ways of Working
Keeping it simple
As engineers we often find ourselves in situations where the problem in front of us is very daunting and intimidating. These problems seem that way because the questions we ask have convoluted answers. And because the answers aren’t straightforward they lead us to taking actions that are ineffective and not sustainable.
If this is a situation that you encounter often and the answers aren’t helping with the path forward, try reframing the question to find a simpler answer. Let me elaborate using an example. Say an engineer has been working for over a week on a low effort bug. Our first intention may be to ask the question:
Why is it taking so long?
However, the answer to this question will usually be a long winded monologue around the technical nuances of a complex system. Instead, we can reconsider and ask the following questions in its place:
- Did we set the expectation with the engineer that this task was meant to take a day or two?
- Did we give them enough context on the problem before-hand to set them up for success?
- Did we try to work around this by altering the product or design requirements?
- Did we set the expectation to ask for help in such situations?
- Did we decide on a plan of action if it took longer than a day?
- Could daily standups have brought attention to this issue sooner?
- Did we assign someone to follow up with the engineer on their progress?
Asking questions like these help us better understand the underlying issue and unblock ourselves on the way forward. So the next time try asking questions that yield simple answers and take it from there.
What a lot of engineers don’t realize is that high functioning teams have a strong partnership with other disciplines like product, design, research etc. to deliver successful products. Generally, this process begins to break down when engineering is left siloed and isolated. Teams with a disconnected engineering team usually have work handed down to them to execute on. Unfortunately, there are several downsides to working this way; the ones that we see manifest quite frequently are:
- The designs or requirements are not clearly communicated, resulting in the wrong thing being built.
- The designs are simply infeasible given the engineering constraints.
A lot of time and effort is wasted in the ensuing iterative process to get the product built. A simple way to short circuit this entire loop is to push engineering upstream to more exploratory phases of product development. When engineering is an active participant in the process, they help provide stakeholders with valuable context around design or product choices that are technically complex given engineering limitations. They also help sort out timelines and deliverables by estimating the time and effort needed when considering various approaches to getting the product built. Now finally when it is time to execute they end up having all the necessary context without needing someone to bring them up to speed.
If adding engineers to every meeting seems excessive, try getting creative around what participation means. For example, try implementing a sign-off procedure for important stages in the product cycle or have a weekly sync meeting. Whatever the approach, just make sure the engineering team is informed and has a say in significant decisions made by the team.
As engineers are included in the process, they will inevitably start contributing towards product suggestions early on to help and innovate with new ideas. Engineers who are well versed with the nuances and technical capabilities of frameworks know how to leverage them to craft delightful experiences. A few examples of this are gestures that improve the overall usability, faster load times that reduce product friction, and offline modes that create a more responsive UI. When used well, collaboration builds collective ownership around what is finally delivered to users.
Disagree and commit
This is something that is easier said than done. We all have our own views and outlooks that make us uniquely different. We care about our work and how we approach it. Working on something that is contrary to how we think and feel makes us uncomfortable. So when asked to set our thoughts and feelings aside to disagree and commit we find it difficult to practice.
We have all experienced marathon meetings with conflicting viewpoints, heated arguments, and high emotions. Very rarely do these arguments ever lead to amicable outcomes. These meetings are usually followed by long periods of inaction where no decision is made and nothing changes. The goal of disagree and commit is to avoid these periods of inaction by committing to a decision as a team. This allows us to either succeed or fail fast. You do this by prioritizing the team over yourself while using the time as a learning exercise. Whatever the outcome, you will be one step closer to knowing the answer. If deciding on the course of action is tricky, it is preferable to have a person nominated as a “decider” beforehand who can make that call. Once a decision is made we commit to it together as a team to use the opportunity to react fast if things don’t go as planned.
Make a note to account for the cost of execution before considering the approach. For decisions that are fairly large and have significant long-term implications, think about either breaking it down into its smaller constituent parts or getting a signal sooner by reconsidering the approach in favor of a low-effort one.
This concludes the first part, in a sense I’ve covered my biggest themes that have proven useful around ways of working. If this sounds useful then I would recommend checking out the second part that talks about ways of building.
Feel free to get in touch with me via LinkedIn
If you find this kind of work interesting, come join us!