Everything, everywhere, all at once
How a narrowed focus can avoid tragedies and improve your team's outcomes and morale.
Hi everyone! Welcome to the August’s issue of The Engineer Manager newsletter. 👋🏻
Lately, I’ve been thinking a lot about a common issue we face in both personal and work life – having a lot of things on the plate. In work environments with agile and lean practices, many of us have probably already heard about "limiting WIP". It's almost a mantra that always pops up when this comes to mind.
That said, this video of
got me thinking that this exercise is actually more nuanced than it seems. That's why I'd like to reflect a bit on how to acknowledge and establish clarity regarding the work in progress, as well as how to make any necessary adjustments. This way, Software Engineering teams can remove everything from their plate that doesn't need immediate attention and avoid turning themselves into sinking ships.
This painting is called Shipwreck off Nantucket (Wreck off Nantucket after a Storm), by William Bradford.
Acknowledgment
Outcomes might be measured by a set of outputs, code being one of them. And code (or removal of it) is a mere output of the software development process. A Software Engineer undoubtedly has various other responsibilities within the Software Development Lifecycle that demand time and cognitive resources. Engaging excessive time and cognitive load inappropriately can result in the creation of subpar or irrelevant code.
That being said, it is important to understand that limiting work in progress (WIP) is not solely about "stop starting and start finishing," but also involves the strategic reallocation of attention and resources. Tasks like plannings, documentation, huddles, and personal agendas can consume a significant portion of the team's time. Recognizing that coding is just one phase in the Software Development Lifecycle (SDLC), and that it has both predecessors and successors, can expand one's perspective. This perspective acknowledges that success often eludes those who attempt to juggle too many tasks simultaneously on a Kanban board.
Speed alone ignores direction. Velocity considers both speed and direction as vector-based components. Given these considerations, how can we enhance velocity within such contexts?
Narrowing down
I like to give my teams full autonomy to collaborate on the what and decide on the how, once the why is thoroughly comprehended, as I’ve explained on the first issue of the newsletter. Nonetheless, I must confess that I have already made a huge mistake: trying to provide autonomy without first providing alignment. In practical terms, this signifies that I anticipated them to arrive at a destination entirely on their own, with a substantial level of detail. However, at times, they found themselves contemplating multiple destinations or were uncertain about what the exact destination should be.
As Engineering Managers, it’s our job to drive consensus between the direct engineering stakeholders and the engineering teams of what is THE thing to be tackled now. And this can be done in two different perspectives, as shared below.
Outside-in
Flexible roadmaps, beautifully explained here by
, are a concept we've been actively experimenting with over the past semester. They have proven to be a significant catalyst in fostering consensus around the critical tasks requiring immediate attention and assessing our capacity to execute them. Not only that, they also provide clarity of the next priorities candidates and make sure that there’s a formal agreement of the job to be done.Inside-out
The internals of dealing with the now are important. Therefore, it is important to ask ourselves as Engineering Managers:
Do the teams understand not only what must be done now, but also why? Sharing both context and vision of the value stream that’s being evolved is crucial for sharpening the focus. After that it is also important to ask your self: are they engaged with it?
Do the team work well in a cross-functional way? Is every role in the team clear to everyone? Is collaboration really a thing?
Do they have the appropriate capacity and means to do it? Did the estimations took into account everything that they should? Does the team has the appropriate tooling? Do they have the autonomy to self managing their time and create blocks of uninterrupted work?
Iterating and communicating
All of the things mentioned are somewhat vague - and that’s intentional. The goal here is not to provide a solution to a nuanced problem, but to provide triggers where an open conversation might start when this problem is faced - both collectively and individually. These prompts are meant to yield process refinements and the introduction of mechanisms that can be tailored to your team's specific context. This, in turn, assists in achieving a more focused, harmonised, and transparent workload, as well as refining internal and external working methodologies.
Revisiting is also part of the process. I link to think that my job as an Engineering Manager is not to always come up with the right process to be followed, but rather to enable the team to find out which process is more suitable for them. At times, this empowerment involves recognising inefficiencies and facilitating the suggestion of necessary adjustments—whether technical or not.
Wrapping-up
Maintaining a high Work In Progress (WIP) within your teams and among individuals will undoubtedly take its toll on them. The hidden costs of excessive context switching and heavy cognitive load have an impact on velocity, as evidence shows - thanks
for referencing it.A strategy that me and my teams have been experimenting is to have a clearly communicated roadmap, both internally and externally. Additionally, we make sure to narrow down our focus to work on only one big thing at time and have well planned capacity and time for BAU: planning, focus, reviews, tech debts and support. These approaches have been implemented with a certain degree of variation across different teams, recognising the necessity for adjustments that align with each team's unique profiles.
This is an intersection of two of the four P’s mentioned by Thiago Ghisi in tech careers: process and people. With that in mind, my recommendation to approach such situations is: focus first on people, understand them and their environment, and adjust the process accordingly, not the way around. From my point of view, this approach is indispensable for ensuring the efficacy of processes.
Thanks for reading and see you in September! 👋🏻