```yaml
---
slug: the-stairway-problem
published: 2015-05-26T00:00:00.000Z
description: How 12 steps can feel like 12 miles apart
changelog: ~
---
```

One of the biggest transformations a company goes through isn't financial, but physical. Adding, changing, moving, and creating new physical space in an office will change the dynamics of how work gets done. People are at new desks. Things feel fresh. There's reclaimed wood everywhere. There's also 12 steps between two teams that despite their new-found distance are still working on the same goal. It may as well be 12 miles.

Welcome to the stairway problem.

![image](https://user-images.githubusercontent.com/1795/146829468-ef2f5005-8090-43e6-ac9f-bd2957f167fe.png)

The addition of a stairwell in a company is the second biggest physical change a company faces. The largest is moving buildings, but that is more like an organizational blender with four walls and a roof. Physical space separates and divides. As shouting distance becomes impossible, the cracks in communication begin to show. Teams that are autonomous and given enough isolation will evolve independently. Soon the common thread everyone was working on gets lost. You'll find yourself with silos. Most companies solve this breakdown with, you guessed it, a [Status Report](./fix-the-status-report).

## Talent Transfusions

The solution that keeps everyone from building up silos is obvious in hindsight: shifting roles. If a company embraces having people try new things (and creates the means for them to go forth and do so), the silos never get a chance to form.

Transfusion in an organization has some hidden benefits. It forces you invest in onboarding, it makes you have come-together meetings so vision can be shared, and it creates deeper threads that run between the different parts of the organization. You may not have the answer to your scaling problem, but Sally does. And because of transfusion, someone that worked with Sally on another project knows she's a badass and can solve this exact problem you are having. Don't limit yourself to just contributors, either. Management should be moving around as well. Everyone should have the opportunity to see more of the organization.

That doesn't mean moving people ad-hoc and causing disruption. To make transfusion natural, there needs to be some lightweight structure or ground rules.

**Own the transfusion.** Tie up loose ends and provide enough time that leadership (tech and people) can try to find someone else who loves the role you are vacating.

**Be a knowledge bearer.** Understand that not everything is written down. Because you did good work, people will have questions you'll need to answer. There needs to be time made for these opportunities as part of your new role.

## Embrace Your Space
[![The GitHub offices boast casual spaces near meeting rooms, creating accidental spaces for creativity (and communication) to happen. Photo by Ben Scholzen CC by 2.0](https://user-images.githubusercontent.com/1795/146829512-4545e15b-2a8d-4f42-9663-0351477c99e8.png)](https://www.flickr.com/photos/dasprid/8148010408/)

Unless you're Apple, you're probably not going to have the resources to create a [campus free of physical space divisions](http://appleinsider.com/articles/15/02/09/exclusive-february-aerial-tour-of-apple-incs-campus-2-shows-spaceship-ring-rising-theater-progress-more). In addition to a healthy transfusion process at the heart of this, you can steal a page from Apple's philosophy. Make happenstance happen. The more chance encounters teams have, the more likely big problems get caught early.

If you're fortunate enough to be able to reconfigure your space, create natural space that people want to spend time in. Small (unbookable) 2–4 person areas will encourage people to go somewhere to talk, away from their team and into the big bold world.

If you can't knock down walls, you can at least put meetings on another floor. Getting out of your area means exploring and learning where other teams are and what they are doing.

## A Daily Habit

Transfusions and changes in physical space share a common goal: communication. Mixing people up through space, teams, and layout all contribute to the mesh of conversation in the company. It requires rigor until it becomes a behavior.

A post-it on your monitor serves as a good reminder. Make an effort every day. Spend at least a half hour making happenstance happen.

You won't fix all of a company's silos, but you can certainly reduce those that interfere with your team's ability to do amazing things.


How 12 steps can feel like 12 miles apart

Link

strong

Document

The Stairway Problem

```yaml
---
slug: mistakes
published: 2018-02-21T00:00:00.000Z
description: The obligatory new manager "three things I fixed" post
repost:
  url: https://simpleprogrammer.com/engineering-management-mistakes/
  text: This article was originally written for Simple Programmer, and appeared under the title _[Engineering Management Mistakes and What To Do Instead](https://simpleprogrammer.com/engineering-management-mistakes/)_. It has been reproduced here as part of my own writing.
changelog: ~
---
```

As a company grows, senior engineers are asked to be lead developers on key projects. You might even be one of these [Accidental Lead Developers](https://simpleprogrammer.com/accidentally-lead-developer/) who has unknowingly dipped their toe into the world of engineering management. When the company grows again, you may be called upon to make the single biggest change of your engineering career.

A change where you stop engineering.

Engineering management is daunting. Suddenly, you're no longer writing code. You're the one overseeing the team. As an engineering manager, in addition to project planning and resourcing challenges, it's your job to make sure everything and everyone is working at their best. A significant part of that directive is the role you play in growing the careers of the other engineers.

Regrettably, there probably hasn't been any training to help you with the basics. Even worse, you're also expected to be competent in this role from the very beginning. This lack of training with unreasonable expectations is likely why [60 percent of all new managers fail](https://news.cebglobal.com/press-releases?item=67148) within the first two years.

Every manager that makes it long enough will eventually develop their own leadership style. Unfortunately, "long enough" is defined in years, not months. While you find your footing as a manager, you'll still be expected to carry out the responsibilities of the role. Your team needs you to be strong today despite your lack of experience.

Let's not be the [bad managers](https://simpleprogrammer.com/dealing-bad-managers-development-world/) we hear so much about.

To help, we're going to dig into the three most frequent communications you have with your team, the One-on-One (1:1) Conversation, the Team Meeting, and our Email Habits. For each of these, we're not only going to cover the common errors but focus on changes we can make that will help you find your footing quickly.

## The One-on-One Conversation

Your current 1:1 meetings with your boss probably aren't great. If your meetings follow the pattern of nearly every other engineering 1:1, your boss asks how you are, you share your project status, and you both call it a day. If you're in the minority, your boss may have also provided you with some feedback. If you're really lucky, you've had in-depth conversations with your boss about your career, the company, and how those two align.

It begins with making enough time. The single biggest mistake engineers do with their 1:1s is to attempt to shorten their duration. Anything less than an hour is actually a waste of both you and the engineer's time.

In High Output Management, Andy Grove explains that the first 20–25 minutes of any 1:1 conversation are filled with the small talk of status reports, general sentiment, and light conversation.

That fact means that if your 1:1 is only 30 minutes long, then you are going to hear how your employees are burnt out, unchallenged, or excited about a new project in the final five minutes of your conversation — as a manager, that's not enough time.
This is why your 1:1s require an hour or more. With a large team, it may feel like weekly 1:1s consume your entire calendar, which is an indication of the second mistake: the frequency.

New managers assume that a 1:1 conversation must be weekly. They mistakenly believe that frequency is more important than depth, opting for shorter (and thus more frequent) 1:1s, when the opposite is more beneficial to the team.

Short 1:1s, no matter how often they occur, will do nothing to help employees work on the larger issues that they've entrusted to you as their manager, and repeating the same 30-minute conversation weekly is a fast way for both you and the employee to get caught in a rut.

The frequency of 1:1 conversations should be scaled based on how much support an individual employee needs. If they are a junior engineer or new to their role, weekly may make sense. However, if they're a senior engineer that knows what needs to be done, you can scale back your 1:1s appropriately.

A good 1:1 goes deeper than status reports and updates; it focuses on in-depth discussion. You'll even put your [coaching skills](https://simpleprogrammer.com/2018/02/07/coaching-programmers/) to use. Instead of asking how a project is going, ask the employee what the most interesting thing is they've learned while working on the project. Ask for the employee's opinion on recent news instead of sharing the news itself. If it helps, use a template to keep things on track.

Being subjected to bad 1:1s is why so many new engineering managers view and value 1:1s poorly. In truth, the 1:1 meeting is the one of the most important tools you have as a manager to help the individuals on your team through meaningful conversations.

## The Team Meeting

You get everyone into a room, and…? Nobody looks forward to a bad team meeting, yet everyone can cite an unproductive team meeting they've been party to. As a new manager bringing the team together to talk about issues, it's easy to devalue your own meeting by not planning it out.

The number one mistake new engineering managers make with their team meeting is not making it clear why a team meeting needs to exist in the first place. Meetings without a purpose often feel like a waste of everyone's time. Just like the rules for any effective meeting, the team meeting needs an objective.

A great objective for a team meeting not only outlines what you hope to solve, but makes it clear that every concern will get equal attention and be acted upon: *"The objective of this meeting is to discuss concerns and challenges within our team because the challenges within our team are best solved face to face. This meeting succeeds if every concern raised in the meeting has clear and actionable next steps."*

By setting an objective like the one above, you'll also go a long way towards avoiding the other mistake engineering managers make: excessive planning of their team meeting. As former engineers, there is strong temptation to plan out the entire staff meeting in advance, but doing so robs the meeting of the organic discussion and debate that a healthy team has.

It is impossible to know how much time a team needs for any given topic, and when we allocate 100 percent of the time, either the discussion is absent or the final agenda items never see light.

Having a rigid agenda neglects the natural way concerns get discovered and raised in a team setting. Frequently, these over planned meetings result in the engineering leader talking at the team instead of discussing topics with the team.

Instead of trying to architect the entire meeting, ask for topics ahead of time and place those on the whiteboard in the meeting room. Then, before the meeting begins, go around the room and solicit topics a second time.

When the team meeting is [owned by the team instead of the manager](https://www.amazon.com/exec/obidos/ASIN/B00DQ845EA), employees will be more engaged, discuss their concerns more openly, and offer suggestions to the team's challenges. You can then focus on facilitating the discussion and capturing the actions the team needs to take. As an added benefit, a healthy team meeting means that your 1:1s with the team no longer will require updates and project status.

When employees value their team meeting time, you'll know that as a manager, you're doing things right.

## Our Email Habits

Everyone can recall at least one evening ruined by an email from their boss. As a newly minted manager, the shoe is suddenly on the other foot. Yet despite our newfound responsibility, we don't stop. More than [50 percent of our industry](http://www.careerbuilder.com/share/aboutus/pressreleasesdetail.aspx?sd=7%2f23%2f2015&amp;id=pr905&amp;ed=12%2f31%2f2015) (including new managers) are guilty of sending emails outside of work hours. Looking to stay in good favor with you as a manager, expect your team to respond.

This always-on culture of email has two major negative impacts on the team. First, because folks are tethered to work 24/7, we've [erased their downtime](https://hbr.org/2012/12/the-upside-of-downtime) — a disconnection from work that's vital to healthy productivity and creativity. While we may believe that we are creating velocity by following up on things immediately, we're actually hurting our team's ability to tackle difficult problems.

The second problem with emailing after hours is that it is actively destroying your team. A [study by Lehigh University](https://www.sciencedaily.com/releases/2016/07/160727110906.htm) directly links after-hours emailing to emotional exhaustion and burnout. [Burnout is responsible for almost half of all employee departures](https://www.kronos.com/about-us/newsroom/employee-burnout-crisis-study-reveals-big-workplace-challenge-2017). So, the cost of sending emails and interrupting personal lives is high.

While the cost in productivity and attrition seem insurmountable, the fix is not. We simply stop sending email outside of work hours. However, that doesn't mean we can't work on email if the urge strikes us. [A quick search on Product Hunt](https://www.producthunt.com/search?q=%22send%20later%22%20email) reveals that there's an email client for nearly every platform that comes with a feature called "scheduled sending." The ability to schedule communications lets us delay our email, sending it out once the workday has started anew.

We have a fix for the timing of our emails, but the content is just as important as the delivery. Good emails make clear to the reader what they need and ask for accountability. This is especially critical when forwarding emails. Email threads are notoriously difficult to follow, and asking your email recipient to parse the thread and identify the action they need to take is fraught with assumption.

To make your emails clear and actionable, literally write down your expectation at the top of the email: *_"$name, can you $expectation."_* If you are having trouble nailing down the expectation, then maybe the content isn't meant for an email.

At a team meeting, inform your team of your new email habits. As you keep your commitments to the team, you will see a noticeable boost in creativity, productivity, and trust. When something comes up that requires action outside of the working day, you'll find that your emails are highly valued and acted upon quickly.

## Your Next Steps as an Engineering Manager

While there are dozens of areas a new engineering manager can focus on, these three communication points stand out because of the impact they can have on your team.

More importantly, once you have built trust in your 1:1 conversations, team meetings, and email rigor, these become the forums your team can use to help you become a stronger engineering manager.

Don't be afraid to use these channels to ask your team or individuals "how am I doing?" and listen to their feedback. Your team wants you to succeed, and once they know you're committed to helping them, they'll work to make you successful too.


The obligatory new manager "three things I fixed" post

This article was originally written for Simple Programmer, and appeared under the title _[Engineering Management Mistakes and What To Do Instead](https://simpleprogrammer.com/engineering-management-mistakes/)_. It has been reproduced here as part of my own writing.