Eli Weinstock-Herman

"The Engineering Team isn't getting enough done"

February 27, 2022 ▪ management posts ▪ 16 min read

Talk about sending stress levels through the roof.

On a scale of 1-10, "Your team isn't getting enough done" can take it to 15.

🔥🔥🔥 🔥🔥🔥 🔥🔥🔥 🔥🔥🔥 🔥🔥🔥 🔥🔥🔥 🔥🔥🔥 🔥🔥🔥

My heart rate jumps up even imagining someone saying it.

However, this doesn't actually mean your team is executing poorly. There's a lot of nuance and perspective to this judgement. I've turned this opinion around with several teams, which tends to be more about alignment and communications then making the team "work harder".

  • Step 1: Don't let it overwhelm you.
  • Step 2: Dig into the nuance behind that phrase

Hopefully this post will help with the second.

The "Shorter" Version

Hearing that statement the first few times, it felt like the speaker expected me to "make the team work harder". However, every time I've changed an org from "not enough" to "wow, they get so much done", the solution had nothing to do with making people "work harder".


"Your team isn't getting enough done", they said.

Multiple assumptions built into that statement
A lot of assumptions in one statement
We need to unpack that statement:
  1. What do they mean by "getting work done"?
    • Activity: Do they expect to see hands on keyboards 40 hours/week?
    • Output: Do they expect to see new features delivered?
    • Outcome: Do they expect to see an impact on product goals?
    • Outcome: Do they expect to see an impact on business metrics? (revenue, cost, etc)
  2. Were we on the same page on what the team was going to do?
  3. Are we communicating what we have done through enough/best channels?
  4. What if they're wrong? Do they align with the organization's priorities, strategies, or goals?
Goals, Strategies, Principles, and Methods
Are we working towards the same goals and targets?
When we have a different understanding on these, we see less value in each other's work. Maybe we are pulling in different directions, maybe results are just invisible. "Do more" doesn't solve either of those.

We need to make sure we're moving the expected direction, broadcast that work (a lot), and correct any larger organizational alignment problems that led to this situation.

Taking Action

Plan, Do, Study, Act: Identify problems and tactics, try solutions to those, continue to evaluate, iterate. There is no one and done solution to these types of problems.

Through a conversation with this speaker, we ought to be able to find a couple fundamental gaps.

These are highly dependant on the organization, but here's some tactics I've employed:

1. "How we work"

A spectrum from activity to business outcomes
What do people expect to see?
  • Align w/ manager: is the team working at a lower or higher level than your manager expects?
    • To even have this discussion, we have to get on the same page about what it means to do work. Activity, Outputs, and Outcomes.
      • Activity: people are visible in front of keyboards for given hours
      • Activity: number of PRs completed/week
      • Activity: number of tickets closed/week
      • Meta Activity: velocity (velocity isn't activity, it's information about activity against an estimation of actual activity)
      • Output: completed wireframes or design docs
      • Output: number of features or fixes shipped
      • Output: features that should increase in accessible market
      • Outcomes: changes in customer behavior from features shipped
      • Outcomes: validation or invalidation of product hypotheses
      • Output: actual increase in accessible market
      • Outcomes: impact on business goals and metrics
    • We also need to be on the same page on scope of impact and autonomy:
      • Low: Does the team receive orders and execute?
      • High: Receive opportunities and budgets, and identify and deliver solutions?
    • Lower than expected: make a plan for how we'll increase the teams level of operation, if the team is task or activity oriented, what do they need to shift towards larger scopes or even outcomes?
    • Higher than expected: educate your manager (over months), why is it better to have a highly engaged team focused on outcomes instead of focusing on butts in seats? if the team is good at working at a higher level of scope or autonomy, attempting to scale them down will hurt morale, productivity, and retention.
  • Align w/ speaker: educate and socialize: this is how we work right now, this is how we intend to be working in 6 months (if different). Here is what success looks like. Here are a couple awesome Ted talks about this method of working. Here are signs in our competitors job ads that they have shifted to this method. Here are benefits our customers expect from competitors or because of the apps on their iphone.

2. "What we are going to do"

  • Write it down: There is too much ambiguity in what we remembered we understood from what someone thought they were telling us 2 months ago. Write it down, share it back, "Is this what you said". (consider something like design docs? Documentation in an Agile Org)
  • Written Tickets: capture chunks of work or goals in a ticket, make sure it has a description, link to external documents, pictures, or otherwise agreed on context. If there is still disagreement about the scope, expand what you write to a common pattern that specifically captures the scope or acceptance criteria, to the appropriate level for the team (tickets can reflect strategic objectives or tasks, don't let process-of-the-month decide for you)
  • Review work before starting: "This is what we will be doing", I prefer to start at the highest possible summary level at first, then iterate and add more detail until I feel like we're achieving alignment. It's easier to go from summary to just the right detail in meetings than it is to talk through work at an inch-by-inch level and back out to the right level (especially since inch-by-inch detail in advance requires that much more preparation, planning, fragility, etc.)
  • Pre-demoing: using mock-ups or draft documentation, the team can demo how something will work to show and validate their understanding before starting
  • Reiterate Background Capacity: If bugs, support, or other work is handled automatically by the team (versus weekly planning meetings, etc.), make sure this is addressed in reviews, pre-demoing, or announcements: "we will continue to address bugs as....ths week", "we are increasing...", "we are decreasing". This will be ignored after some point, but the first 6 are important to everyone now, and the next 6 are important to the person who joins later.
  • Awareness, in advance: Announce upcoming large work or new themes of work in advance, at least twice
  • Awareness, at the start: At the beginning of projects, sprints, etc. announce the scope or list of work.

3. "What we're doing and getting done"

  • Make work visible: use visual boards to make it visible that activity is occurring
  • Announce: announce the delivery of notable new work - requires a balance, if you want people to be overwhelmed with how much is going on then report every new delivery, if you want them to read some of those announcement than only the most important ones
  • Regular announcements: send a regular summary of completed work, make it useful (links to source information, custom release notes, etc. are good for this), but the focus is to reinforce "here's 16 items going out the door you wouldn't normally see". I've mixed weekly release notes, monthly or quarterly newsletters, and quarterly or annual "review" announcements. Use multiple mediums, for instance a video for the quarterly review with a blog post accompaniment, summarized/announced in email, slack, and the next company all hands.
  • Demo: show people the new outputs that have been produced. This can be live or recorded, and recordings can be embedded in newsletters or other regular announcements
  • Celebrate: not only good for team morale, but also a way to visibly re-communicate work that has been done and that the team or members of the team have been successful and productive.
  • Convince others to celebrate: hearing the message from others can help get through or reinforce the information, convince your manager to communicate wins or share positive feedback in wider group settings

4. Organizational Misalignment

  • Support someone else solving it: if a sales leader hs a different expectation about the product goals, then we can go to the product leader and offer to help fix that problem
  • Support someone owning it: if there isn't someone that owns product strategy, then we have examples of value we could achieve (alignment) and the speaker is potentially on our side in going to convince someone (CEO) that organizational clarity is needed
  • Own it ourselves: and sometimes we may be the best person to take it on, but we should convince our boss of that first
  • Own it silently: the last option, and most thankless, try to fill in the gap on your own: massage the mixed priorities you receive into a common shape, back into an organizational strategy if one isn't defined, translate work the team is doing it to reflect the level people are expecting - this is a survival method, though, if the org hasn't been willing to listen to the prior items, there is a gap (it may be them, it may be you, but it's there).

"Say what you're going to do, do it, say what you did"

The problem with telling people what we're going to do one time is that folks won't hear us, will have a different image in mind, ignore the communication channel we picked, etc.

We not only have to tell them before, during, and after, we also have to do each of these multiple times through multiple channels, like the examples on the previous section.

"We're going to do X, is X what you meant, this is what X will look like, we're going to do X soon, we're starting X, we're doing X, here's a preview of X, we're 1/3 of the way on X, we're 2/3 of the way on X, we finished X, here's a demo of X, the team was awesome this week as they shipped X, we finished a bunch of things including X, here's the quarterly newsletter which includes X"
About the time you feel like you're saying it 2x-3x more often than necessary is when you can be sure everyone is hearing it at least once, and the probably need to hear it at least two or three times, longer if it's a multi-month project.

Educate and Reinforce

Recurring 1-1s with managers and other leaders can be a great platform for educating others and reinforcing announcements for folks that tend to tune out particular channels (some people don't read, some multitask consistently during meetings, etc.). Group meetings are great places to gently reinforce these items: announcements of big successes, summarized stats on shipping, outcomes we'll be testing in a few months through new deliveries, etc.

Quantity can be the signal

Also, sometimes the volume of communications is the signal. People will stop reading or listening to some communications after a while, but still receive a sense of comfort or progress from seeing that communication show up in their inbox/channel right before marking it as read ("I could look at the details if needed, but they have a track record of it all being there and they just keep on shipping, not like they used to...");

Expanding on Causes

For the rest of the post, I'm going to provide deeper examples and questions.

Mismatched Expectations, in more detail

Earlier, in the Unpacking section, I outlined a few of the underlying assumptions that could be present in the speaker's statement.

I think it's easy to overlook just how much nuance is present when we talk about another team's performance, and unpacking it further can help identify these causes from their feedback.

Picture of the landscape, from expectations to work to perception
No one person's expectations and perceptions is correct, the best we can be is aligned

Misaligned Goals

The speaker may expect "work" to be prioritized differently, or to a different definition of:

  • Different business goals: "I know the CEO said our goals are X, but..."
  • Different set of product goals or strategy
  • More or less focus on permanent features vs experiments
  • Different engineering priorities: balance of new product delivery, new product experimentation, delivery + experimentation to maintaining service levels, compliance activity, handling bursts of support, security, and changing technical dependencies
  • A particular communications style of completed work: push vs pull, synchronous vs asynchronous, interactive vs broadcast

Perception of "working"

And by "seeing work", they could mean

  • To see work in progress: "working from home during a pandemic" has been hard on folks who relied on seeing busy people in cubes
  • To see work differently: less talking, more talking, people typing non-stop, more demos, less demos
  • To see work supervised at a more or less granular level
  • Different evidence of results: hours of activity, tickets completed, new features delivered, product or business outcomes

From a Different Background

  • Have unspoken or incorrect expectations based on experience with prior companies
  • Have a different interpretation of goals, strategies, or tactics

And the team may be challenged

Last, it's also possible the team has a different perspective due to internal challenges, like:

  • Missing a capability to be more effective
  • Lacking motivation
  • Lacking availability, with high levels of process overhead, meetings, support and on call time
  • Suffering technical friction, with high levels of technical debt, mismatched architecture, inter-team coordination
  • Suffering from turbulence, too frequent change of priorities, goals, relationships, and processes

Who should own defining this?

When we identify what the speaker expected to see, sometimes we find that they have a different set of goals in mind, goals that we may not be responsible for setting.

For instance, if a Head of Sales is saying they expected more from us, in the context of sellable features, that may actually be a conversation that needs to be had between them and the Head of Product, or the CEO. We can provide some clarity, but the underlying gap may be that the person responsible for the decision hasn't communicated it well enough through the company. We need to connect the speaker to that person.

And what about in small companies, where responsibilities may not be clear?

All roads lead to the CEO (eventually). We can provide our best understanding, but the fact that there is such a diverging opinion underscores why someone (perhaps us, perhaps not) needs to create a clear understanding of the goals and priorities, because otherwise we're pulling in opposing directions and wasting energy.

"Work Harder"

There is a second level of flaws in this statement, that I have difficulty fully unpacking.

Some folks have learned that more hours equals more production.

In some industries this is true. Other times this is a reflection of success bias: "surely those extra 10 hours/week that I wasn't with my family were the reason I was successful."

This post has gone long, but beware that behind a lot of the Activity and Output expectations above is a misunderstanding that more hours of knowledge work equate to more success. The only method I've found to combat this is to continuously, regularly succeed at shipping product and business outcomes. To reinforce over and over that success at outcomes is not a simple hours-in-value-out equation. Until they stop saying, "the team must have put a lot of extra hours in last week".

So the team doesn't need to improve?

I've avoided this topic until the end.

The biggest improvement we can make is to ensure we're pulling in the same direction, but that doesn't mean the team can ignore improvement on how they work.

Entropy is the enemy of every good team, whether it's slowly tearing down the codebase, our understanding of the domain, our coordination, etc. Standing still is falling behind, so once we know what direction we're facing we should be constantly improving.

Additionally, a team that is constantly experimenting and improving is better poised to take advantage of fast changing circumstances in the company and market.

Picture of the landscape, with team questions highlighted
Is the team:
  • Missing a capability to be more effective
  • Lacking motivation
  • Lacking availability, with high levels of process overhead, meetings, support and on call time
  • Suffering technical friction, with high levels of technical debt, mismatched architecture, inter-team coordination
  • Suffering from turbulence, too frequent change of priorities, goals, relationships, and processes

Overtime and "work harder" tends to focus on the appearance of Activity at the cost of Product and Business Outcomes. Continuous improvement exercises ranging from regular retrospectives, Kaizen, external consultants and advisors, and more can help the team become more effective and impactful.


"Your team needs to get more done".

"Work harder!" doesn't solve this. Alignment, communication, and fixing organization gaps do.

Related Posts