Engineering Leadership Tactics: Mind the Input

How an engineering team’s performance is defined by the work they take in

While talking about Systemic Leadership for software teams, one question that often comes up is how to apply it in practice. Yes, systems thinking makes sense, but how does an engineering manager (EM) use it in their daily work?

One often overlooked aspect is how essential are the team’s inputs quality. In other words, how we frame the work will impact how the team performs.

In particular, two cases commonly apply to software development: project definition and user stories.

Inputs Matter

While execution can define an Engineering Manager’s (EM) role, what their team is delivering might be the highest improvement leverage they have.

“The edge is in the inputs.

The person who consumes from better sources, gets better thoughts. The person who asks better questions, gets better answers. The person who builds better habits, gets better results.

It’s not the outcomes. It’s the inputs.”

James Clear.

It might be evident in theory. However, it is natural for people to focus on the immediate task in front of them. This situation is true for engineers who sometimes execute what is in a ticket without questioning it. And also, for EMs, managing without time to understand why that work is being done in the first place.

If an EM looks at their team from a systems perspective, they will find that everything is influenced by how the work is defined. And there are two aspects that I have found to be critical when managing software teams:

Have engineering involved in how projects are defined — A team’s unit of work might vary. It could be a project, a feature, an initiative, or a piece of research. Regarding how an organization defines it, engineering needs to be involved to a certain degree from beginning to end, ensuring that the work is framed effectively when it moves into development.

Have alignment and visibility on work items — On the other hand, an engineer’s unit of work is usually a ticket (or user story, amongst many other formats). The whole team, including product and design, should be aligned, understand, and be able to discuss every work item.

The Problem in Practice

The statements above are abstract, so you might wonder if this makes a difference. I will illustrate this problem with two cases (of many) in teams I’ve managed.

Project Definition Gone Wrong

In this situation, I oversaw a team building a new feature in a consumer platform. And the product director told me one day: “We need to release this feature in two weeks. The requirement came from the CEO, and there is no room to change the deadline”.

For context, our original estimate for a complete customer release was 4–6 weeks. When I heard that sentence, I could already imagine the conversation I was supposed to have with engineers: Deliver faster, work harder, crunch time. Luckily, before we stopped, I decided to ask why. Why is this important? Why does the deadline exist? That led to a discussion on the broad perspectives for the product and, ultimately, the insight that the CEO demand came from needing to report on a specific adoption metric that the new feature would increase.

The insight provided me with a new degree of leverage. Instead of asking the team to work harder, we discussed how to increase the metric. It meant we could have an empowering conversation about it, which led to the reprioritizing and redesigning of work. Ultimately, during that period, everyone worked (at a sustainable pace) towards a specific goal. As a result, we delivered our best shot at driving adoption, and while we didn’t achieve the number we hoped for, it was positive enough to be considered an excellent outcome by the company.

While the case above was extreme, this problem can happen in many ways. Some examples are:

• Projects are defined based on the tickets that are going to be delivered. Success means clearing the backlog.
• Initiatives where the outcome is binary, either the team delivered X, or it was a failure.
• Work planned without engineering involvement, leading to unrealistic expectations.

Lack of Alignment in Work Items

In this case, I joined a small team building a customer-facing product. Shortly after joining, I perceived that the engineers were competent and working hard. However, the delivery result could have been more effective, and improving it was one of my main tasks upon joining the company.

While working with the team, it became clear that we were executing the standard agile process with standups, sprints, and retrospectives. Still, there was low alignment and visibility on the actual work items. The tickets on our board were primarily technical, making it difficult for product people to understand what they meant. They were also sliced based on technical boundaries, making it hard to verify the work after being done. And they depended on each other, leading to engineers often being blocked by someone else.

In practice, while cards moved through the board daily, we operated without visibility outside engineering. We could only verify the result of our work after we delivered the whole project. As a result, releases were often late and contained many issues we only discovered at the end. And we drastically improved our results by changing one thing: how we wrote user stories.

How to define requirements is a long topic, but there are some common red flags I have seen:

• Tickets that are technically focused, and only people within the engineering team can understand them.
• Tickets that are hard to verify independently, creating uncertainty on their outcome.
• Tickets that are dependent on each other, leading to risk accumulation.

At this point, I have seen this problem so often that I have a strong perspective on it. Poorly defined work items will lead to individual performance challenges. It’s just a matter of time until the uncertain environment drives an engineer not to deliver effectively.

How to Make it Better?

You know this part if you have read any of my other articles. The highest leverage an EM can have is to deeply understand and act intentionally on the systems around their team.

When analyzing your projects, understand how initiatives are prioritized. Who is making the decisions? How are engineers involved in their definition? A team should aim for a process where:

• They center initiatives around customer problems rather than particular solutions. While a team might deliver a feature, the more everyone understands the problem they are trying to address, the better. Broader goals lead to more trade-off opportunities, and better chances of success.
• Engineering participates from planning to delivery. Participation should vary in different phases, with more involvement in execution and less in planning. But there should always be some.
• Deadlines can exist, but they should be around outcomes (or customer problems) and not delivery output. The less output-centric the work is, the more options the EM (and team) will have to tackle it, reducing the chances of failure.

When looking at work items, they should be easy to understand, agreed upon, and verifiable. A great way to analyze this aspect is to observe how often tickets move between product, design, and engineering. Although collaboration amongst disciplines to get work done is healthy and essential, tickets being passed back and forth between them is not.

A team should aim for the following:

• Items written from a customer’s perspective, having everyone understand them. PMs, Designers should be able to read a ticket and know what it means for it to be completed.
• Items that can be executed and verified independently. The easier it is for product and design to verify each ticket independently, the lower the risk will be in any initiative.
• Small items. While constraints will vary, the longer they take to execute, the more significant the risk the engineering team is taking.

In both these areas, if you’d like to research further, I still consider the User Story Mapping book as best in class. Follow it and you will be doing well.

Ultimately, remember that inputs matter. Get them better, and everyone’s work will improve.

If you have found this content interesting, this post is part of a series on Leading Software Teams with Systems Thinking. More broadly, I write about leading effective software engineering teams. Follow me if you are interested in the area.