Taking out the guesswork: How to set clear expectations as a manager

As engineering managers, we have core beliefs about what good delivery and communication look like.

We tend to assume the people we work with share these beliefs. But because of the diversity of experience within our teams, we’re often wrong.

Imagine an engineer who’s been working at a company that prioritizes the rapid delivery of new products and features. When faced with challenging deadlines, their team focuses on launching proofs of concept that customers can use, even if it means incurring tech debt. The engineer plans to refactor successful products and features in future phases.

Enter a new manager, who’s been burned by seeing riddled-with-tech-debt MVPs stuck in production for years. This manager prioritizes quality and is willing to slow projects down to make sure only maintainable, scalable products are launched.

They may not realize this cultural disconnect until it’s come to a head, with the manager perceived as unrealistic and the engineer perceived as underperforming.

Great managers know how to bring forward assumptions from both sides about what good looks like and turn them into a conversation.

By examining your own standards, evaluating how your team measures up to them, and socializing your expectations, you can save your teams from finding out your expectations by trial and error – and save yourself a lot of headaches.

Step 1: Look inwards

We all have a template in our heads for what a high-performing team looks like. Start putting yours into words by exploring your own assumptions about delivery and communication.

What standard of delivery do you expect from your team?

Consider:

• When you picture an MVP, do you expect a maintainable, well-tested product with minimal tech debt, or a proof of concept for rapid feedback?
• Are you comfortable relying on a few key experts to enforce unwritten rules within the team, or do you expect clearly documented coding standards and a mature code review process?
• Do you expect your team to have a QA strategy that makes use of unit tests, integration tests, and end-to-end tests? What types of tests do you expect to be included when new features are released?
• What ratio of time do you expect your team to spend on delivering new features vs. addressing technical debt?
• When problems arise, do you expect the leaders on your team to jump in right away to resolve them or treat them as a learning opportunity for others?

Many of us have strong feelings about which options are right and wrong in this list – especially when it comes to foundational engineering practices. This makes it even more frustrating when we see our teams not following them.

Articulating your expectations out loud, first to yourself and then to your team members, is a must for making changes on teams that haven’t prioritized these practices in the past.

How do you want your team to communicate with you?

Different managers have different communication styles – as you already know if you’ve had a variety of managers in your own career. Different teams do, too.

There is no single correct style. I’ve observed some new managers get frustrated with quiet teams that reached out only when things were off the rails (‘I can’t see the icebergs until it’s too late’), and others with teams that reached out too much (‘I wanted them to take this off my plate, but they’re consulting me so much it feels like my project, not theirs’).

To help alleviate communication woes, stop thinking of communication styles as right or wrong and start thinking of them as a spectrum. The ideal point on this spectrum is an individual preference. Finding the ideal style for your situation is about balancing what you need with what your teams need.

You can start the process by asking yourself:

• Do you expect your team to keep you in the loop on day-to-day project work, or to approach you only when they need advice or approval?
• Do you want your team to share their wins and their lessons learned with you, or to share them with the whole team as they happen?
• Do you prefer for your team to bounce early ideas off you as a sounding board, or to come to you with fleshed-out plans?
• Do you want to be the one managing stakeholder expectations if the team runs into problems, or do you expect your team to handle this themselves?
• When something goes wrong, do you prefer to get the details via Jira, Slack, or a call? How does this change depending on whether it’s a bug, incident, or customer complaint?

Your answers will vary based on the makeup of your team, the seniority of the people reporting to you, and how many teams you’re managing.

They’ll also change over time. My approach to communication as a director overseeing seven teams is now radically different than it was when I managed a single team of four. I suggest reevaluating this each time your role changes.

Step 2: Compare your team’s performance with your expectations

Once you’ve answered these questions for yourself, consider the current state of your team.

On delivery:

• How do they balance quality and speed, enforce coding standards, and safeguard stability?
• How does this match up to your expectations?
• What are the results, and how are their results perceived by stakeholders?
• What pressures from the top have influenced how they approach delivery?
• If you’re not confident in their delivery, what specific changes would earn your trust?

On communication:

• Are your team’s updates clear enough and frequent enough for you to understand their progress toward objectives?
• Do they usually approach you with early ideas or fleshed-out solutions?
• If you’re providing technical guidance to your teams, are you involved enough to give feedback at the right times? If there’s a technical lead providing it instead, does the team still over-rely on you?
• How often do team members ask your opinion before taking action, and how often do they act and then inform you afterward? In most situations, do you agree with their choice?
• If you’re not satisfied with how they communicate with you, what specific changes would earn your trust?

Once you’ve got a better view of how your expectations and team performance line up, take a look at the mismatches and decide how important they are to you.

For example, a mismatch on foundational engineering practices can have a dramatic impact and should be addressed as soon as possible. On the other hand, if some direct reports use you as a sounding board often while others don’t, you might find you’re happy to support each person’s needs differently.

Step 3: Communicate your expectations

Once you’ve decided what you want from your teams, choose the right forum to share it. For example, engineering standards need to be documented and shared publicly with all engineers, ideally after a collaborative process. Talking to your leads or senior engineers about taking on more responsibility is best done one-on-one.

Below are some common areas where you might need to reset expectations.

Setting engineering standards

Work with your team to document common engineering standards. Coding standards, a code review process, and code coverage targets are a good start. Agree on how these standards will be enforced.

Ideally, the team will collaborate to define this with you. If a major turnaround is needed, you might need to be more prescriptive; do this with caution, as it makes it significantly harder to get team buy-in.

Where appropriate, update (or create) the team’s definition of done based on these standards.

Encouraging ownership

If you’re juggling multiple teams or projects and need your leads to take more ownership of solutions before approaching you, tell them. Ask them what support they need to be successful. In some cases, they might need more help than you think; in others, they might need to trust themselves.

Consider encouraging them to bounce ideas off each other instead of relying on you, or point them toward colleagues who have subject matter expertise instead of helping them solve a problem yourself. In the past, I’ve kicked this off by setting up regular check-ins with a group of senior engineers and leads, encouraging them to bring up areas where they could use help, and sometimes bringing them up myself to get the discussion started.

This type of change takes time and patience. Don’t give up.

Increasing communication

On the other hand, if your team rarely updates you and seems hesitant to share details, let them know the level of detail you’re looking for and how regularly you need it. Invite them to share concerns if they have them. You might find that they’ve been micromanaged by previous managers, and that they’re happy to find a middle ground once they understand your intent.

Disconnects with stakeholders

Sometimes you’ll find a team’s underperformance isn’t because of their own values, but because of pressure from above. If you’ve got disconnects with your company about speed/quality tradeoffs or platform investments, don’t expect your team to solve them for you.

Instead, make your case to engineering, product, and (where appropriate) business leaders about the changes you want to make and their impact. Be ready to back it up with numbers. Data on bugs, incidents, rollbacks, and speed of releasing new features is a good place to start.

Reflections

When it comes to empowering our teams, what holds us back the most is the belief that all we’re expecting is good common sense. If I counted each time a frustrated engineering manager has told me this, I’d run out of fingers and possibly toes.

The truth is that communication and standards of delivery vary significantly across and sometimes even within teams. Making your directs guess what you want is frustrating for them and for you. By taking a thoughtful look at how you want your team to operate, you’ll reduce friction and foster better relationships with your team members.