Eli Weinstock-Herman

"The Engineering Team isn't getting enough done"

February 27, 2022 ▪ management posts ▪ 18 min read

I've been there...

I've heard (and turned around) this phrase in several organizations.

My goal with this post is to share perspective and tactics I've used to turn this opinion around in multiple organizations.

This draws on experience turning things around as a member of the team, as a newly elevated lead, as a newly hired manager, and as a peer to the manager of the team. It feels like it is common for someone outside the team to have this perspective, even if they're not in the management chain, so I hope this post helps.

Find the real problem

The first few times a leader told me the team wasn't working hard enough, it felt like I was expected to make the team work harder, somehow. As if they were otherwise lazy and just needed to be goaded into putting in real work.

Sometimes that is what they meant, sometimes it wasn't. It's never been the actual solution, though.

Unpacking the statement

"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. Was there a clear understanding both directions on what the team was going to do?
  3. Are we communicating what we have accomplished through enough/best channels?
  4. Is the speaker aligned with the organization's priorities and goals? Is the team?
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.

0. Interview that person

We have unpacked the statement a little above, now we need to talk to the person and see which ones are our gaps.

Be careful here. Don't assume that they are aware of their own deeper motivations or expectations yet. We also don't want the conversation to feel combative.

  1. They have a right to their opinion. It's based on their perspectives and is therefore right for them.
  2. Seek to understand: explore why they have that perspective and opinion so we cna make things better

"Our folks come from different prior companies and leaders with different goals and cultures. I want to make sure we're putting our energy into making things better for this company and not working harder in a lot of different directions. Can I dig in a little on where you see the team failing to deliver so we can make sure we focus on the right spots?"

Once we know where our gaps are, we can start building alignment on how we work (which translates into how people see us work, and whether they see us us being productive).

1. "How we work"

We need to align with leadership above us on expectations, then if the speaker who first told us the team wasn't operating well is not in that chain, we need to align with them.

Get to the same place on what it means to "do work".

A spectrum from activity to business outcomes
How does this organization think of productivity?

Align w/ manager: is the team producing work the way our manager expects?

  • Examples of that spectrum:
    • 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 (generally a measure of completed estimates, not real time)
    • Output: completed wireframes or design docs
    • Output: number of features or fixes shipped
    • Output: shipped features that should drive business metrics
    • Outcomes: changes/impact on customer behavior
    • Outcomes: changes/impact on business metrics
    • Outcomes: validation or invalidation of product hypotheses
    • Outcomes: business and product goals achieved
  • What level of autonomy is expected from the team?
    • Low: The team receives orders or a fine-grained list of tasks and is expected to execute
    • High: The team receives goals and budgets and is expected to identify and deliver solutions

If the team is operating:

  • Too far to the left:
    • Make a plan to elevate the team: how will you take them from the stage they are on now to where they're expected to be? Do you need to test their skills with some trial runs to see what their capabilities are, then plan skill enhancements or progression over time?
    • Communicate the plan: tell the manager that this is the level we thought we were operating at, this is where we now know we need to be, this is our plan to get there, this is how they will know it is or isn't working and how they will see "work getting done" as we progress
  • Too far to the right:
    • This one is tricky
    • Is the manager/organization teachable? If so, you could have the team scale back to more output or activity based measures for a period of time as long as they know there is a plan to move them back up to higher levels of autonomy and impact. That plan will have to include how you will win over the manager and organization and educate them on the greater value that occurs when folks are more aligned with delivering business impact.
    • This assumes your team is capable of operating at that higher level, if they ar enot (but want to be), you may need a plan that simultaneously steps them back to lower output or activity metrics, teaches the organization the value of outcome-based goals, and provides the team training or experience to get better at executing at that level.
  • Align w/ speaker: if the person judging the team isn't in the management chain of the team, now we have to educate them too
    • 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"

Improve clarity on what we think we're doing and what other people think we're doing. This should be scaled to the level of autonomy and impact we identified above.

  • 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 "What we did"

  • 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 announcements than only highlight 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. When it's Organizational Misalignment

  • Support someone else solving it: if a sales leader has a different expectation about the product goals, then we can go to the product leader and offer to help the discussions or education efforts
  • Support someone owning it: if there isn't someone that owns product strategy, then we have an obviously interested party telling us they would like more of the right stuff done, which could be used to convince someone (CEO) that organizational clarity is needed (either "fix the alignment" or "let's build a strategy because we don't have one and it's causing alignment issues")
  • 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 specific points

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