On development teams, balancing priorities while keeping focus is hard. Without an intentional approach you can quickly find your team submerged in a lot of different work, hurting progress on your most important goals.
But the real world is messy. Prioritization is hard. Work comes in many shapes and sizes. Unplanned work pops up at the worst times.
Managers face many difficult questions:
Should you have multiple work streams on your team? If so, how many? How do you balance long and short-term priorities? How should you handle unplanned work? What about on-call? How big should your team be?
This post outlines some approaches I’ve found effective in helping my teams maintain focus and get stuff done, amidst all the chaos and unpredictability of the real-world.
All computer systems have technical risks. It’s impractical to design risk completely out of a system. Since we don’t have unlimited time or resources, it’s important that we be methodical about how we prioritize investments to mitigate that risk.
As engineers we go to great lengths to measure many aspects of our systems; latency, error rates, health checks, and so on; but too often we rely on our intuition to make decisions about risk. Systematically surfacing and understanding your technical risks is absolutely essential to ensuring you prioritize mitigating your highest risks first.
When it comes to professional development, many engineers struggle to put concrete plans into action to achieve their goals. They know what they want; they just can’t get started.
When you think about it, this isn’t surprising. Many professional development goals are intangible. “Improve communication” or “become expert in technology X” have no real endpoint. They represent a continuum of growth and improvement. They are aspirational. They can only be tackled by steady progression.
As goals, they also tend to have lagging indicators. For example, an engineer might only find out their communication has improved or be seen as a subject matter expert in technology X over time through feedback.
One approach I use which has worked well for many engineers is setting execution-based goals.
As engineering managers our time is always in short supply. Most managers I know complain about never having enough time. We are busy people! At some point in your management career you realize you just can’t get more accomplished by working more hours.
When it comes to time management, there is no panacea; but there are small things you can do that when added together, can make a big difference. What follows are some small things that have really helped me reclaim time and attention, increase focus time, and just lower my baseline stress level on a daily basis.
Have you heard of zombie standup? If not, there’s a good chance you’ve been part of one at some point. Zombie standup is just what it sounds like – a lifeless meeting where people go around a room and talk about what they are working on but nothing much useful happens as a result.
When done well, standups are a highly effective tool to keep work progressing in the right direction. In this post, I’ll talk about my experience with a different standup format than the one most commonly used. A format I think does a much better job of accomplishing the intended goal of standups in the first place.
Is your team scared to change their process? Are they endlessly evaluating or arguing over different options and their pros and cons? As an industry, we practice fast experimentation with new products and technologies; frequently releasing, getting feedback, iterating, and learning. So why do we resist doing this with our processes?
Does the above sound familiar? If you have worked in an engineering department for any length of time, you have probably had this experience.
So what is going on here?
The problem is that there is a fundamental disconnect between the two people about what they are actually talking about. The product person thinks the engineer is talking about a calendar time estimate. But the engineer is thinking about an estimate in terms of the effort involved – one that is completely divorced from any specific calendar or scheduling considerations. This is one of the reasons why many projects are late.