Engineers, like most people, are notoriously lazy. They tend to scan documentation and emails instead of reading them. They tend to tweak existing code instead of refactoring it. They tend to do just enough to stay out of trouble instead of a thorough job (expediency over quality). Better engineers are more rigorous, but constraints and pressure can make any engineer understandably lazy with some details.
However, there are situations when engineers should be lazy. I’m not talking about lazy work habits; I’m talking about lazy evaluation. In a busy work environment, engineers typically apply eager evaluation; that is, they execute what’s in front of them immediately. But sometimes lazy evaluation is a better strategy; that is, it’s better to delay execution of what’s in front of you until it’s actually needed, allowing time for new data to surface that informs your choices.
When is it better to be lazy? Certainly not when people are waiting on you to deliver priority work or information. However, it’s advantageous to be lazy when dealing with pressing issues that aren’t yours, assigning future work, handling reorgs and other staffing changes, and engaging emerging opportunities. Many people are too eager to deal with these kinds of situations because they could be impactful to their future well-being. However, sometimes being lazy pays off.
Don’t worry, be happy
Most work put in front of you is best handled immediately, particularly if others are depending on your feedback or contribution. Naturally, higher priority work comes first, where priority is a combination of importance and urgency. However, sometimes high priority work isn’t ready for execution due to crucial dependencies or information that’s not yet available to you.
You could rush in early, but being too eager can lead to poor quality, lost productivity, misaligned plans and resources, significant rework, and unnecessary conflict. Take a breath and a step back, understand the situation, and patiently wait for the situation to resolve. Here are a few examples.
There’s a pressing issue that involves you and your team. Time is of the essence, but resolving the issue isn’t really your job. Maybe it’s a question directed to a peer, employee, or partner—not you. Maybe it’s a bug or feature in your area, but the issue is in a component you depend upon that’s owned by a different team. It’s tempting to jump right in and be the hero, but that’s overfunctioning—never do other people’s jobs uninvited.
As I discuss in Never been manager, doing someone else’s job (overfunctioning) enables the persistence of the underlying problem and prevents people from learning and growing. In addition, you don’t have all the information and context that the intended people do. Take a breath, step back, and let the right people do their jobs, whether they report to you or not. Monitor the situation and be ready to step in as needed, but avoid being too eager. If the right people are unable, unavailable, or unwilling to complete the job, you’ll be ready when asked.
No I in team
Your team has a bunch of work in its backlog. Everyone has their favorites areas, technologies, and features, so it’s tempting to assign upcoming work items in advance to their natural owners. However, when an item rises to the top of the backlog, the natural assignment might be to someone who’s unavailable. Unfortunately, once that work is assigned, it’s hard to reassign it—doing so feels like taking work away. Now you’re forced to either delay a top priority item or take an item away from its natural owner. Not great.
Instead, it’s better to defer assignment of work; that is, wait to assign work until it’s necessary (“just in time”). At that point, you can choose the appropriate assignment as a team. Perhaps it’s worth delaying the work item until the person with the most expertise can grab it. Perhaps it’s worth shuffling items between team members, to free up the right person. Perhaps a different team member would like to learn about a new area or act as a backup, and this work item would be a great start. Perhaps any team member could do the work, so it’s best assigned to whoever is available. Regardless of your choice, you have far more information about the right assignment at the time the work is needed than you do far earlier.
For more on managing work efficiently, read Productivity mechanics.
Who are you?
Your team just experienced a staffing change. Maybe you’ve got a new lead. Maybe you’ve got new team members. Maybe it’s a group-wide shuffle, and you need to pick a team. Your leadership might be tempted to assign people to teams immediately to reduce uncertainty and its associated angst. However, not only are they unlikely to make optimal assignments, but they also lose an opportunity to involve and re-recruit the staff.
Instead, it’s better for leadership to hold off making team and area assignments and instead allow team members to make their own choices. Here’s how that works:
- The group manager brings everyone together and describes the available areas and teams (including size) in an unbiased and enthusiastic fashion. Sometimes the leads present each of their areas themselves, but that may bias the results.
- Team members ask questions, which the manager and leads answer.
- Team members then write their top three choices on a sticky note, which they place under their top choice. (This can be done online for remote members.)
- If teams end up unbalanced in size or makeup, managers may move a handful of people to their second choice to achieve sufficient balance. (Only use third choices in a pinch.) If people volunteer to move their stickies, that’s even better.
The result of this exercise is a feeling of empowerment and buy-in from team members that increases retention and morale. I’ve been doing this kind of exercise for 20 years, and I’m always surprised at the choices some team members make—choices I certainly would have missed.
The team assignment exercise I describe works great, but when there’s plenty of other change or stress happening in your group, you may choose to keep team makeup as stable as possible.
You and your team are finishing up a big project and wondering what you’ll be working on next. It’s tempting to pick today’s hot new area and get up to speed. However, being too eager to get started could jeopardize the completion of your current project and may lock you into a plan you’ll later regret.
Instead, it’s better to brainstorm a bunch of different new projects together with your team. Then monitor the announcements and reports of each one as you finish your current project. What’s hot today might be passé or even debunked tomorrow. Besides, new opportunities are always arising, so keeping your options open can lead to a timely, awesome new project later. Often, different project ideas can be combined in innovative ways—design thinking at its best. Sure, it’s unnerving to lack certainty about your next project, but relaxing and focusing on your current project, while staying open to new areas, can put you in the right place at the right time.
For more on seeking new projects, read Opportunity in a gorilla suit.
Grace under pressure
Being eager to jump right into the problem in front of you is often desirable and constructive, but not always. Sometimes it pays to be a little patient when immediate action is unnecessary or possibly detrimental.
Hold off on engaging a problem that really belongs to someone else, until you’re asked to assist—doing so helps solve the underlying problem and helps grow the people involved. Avoid assigning work items until necessary—doing so avoids delays and provides an opportunity for team members to learn new areas and back each other up. After staffing changes, allow team members to choose their own team assignments—doing so creates higher morale, engagement, growth, and retention. Brainstorm new projects and keep an open mind until your current project is complete—doing so gives you the best chance of working on an innovative and impactful area.
Who knew being patient could pay off so well? Relax, but keep your eyes open and mind informed. Fortune favors the prepared.