6 Methods To Manage Your Team Without Going Crazy In The Process

You have an entire team relying on you, so you have to get this right.

· 7 min read
Post-it notes of various colors covering a wall above a desk at an office. Some notes say some variation of "Don't go crazy."

As an engineering manager, think of yourself as the main conduit for your team. 

You communicate priorities, align your team with the long-term vision, and coordinate the process across teams. If there’s an issue on your end, it hinders your team’s work. 

So, it’s crucial for you to have an effective way of managing and leading your team. If you’re a former engineer new to the role, there’s going to be a learning curve – working with people is very different from working with tech. 

But you can succeed by taking the necessary steps, including admitting when you need help.

1 - Be honest about what you don’t know

If you don’t understand something, communicate the gap and ask questions to fill it – advice that also applies to engineers but is even more important for engineering managers

Unfortunately, we equate this advice with looking stupid or incompetent. So, when we don’t understand something, we’re tempted to say nothing or, worse, pretend we know what we’re doing. You might even get away with it at first, but your team, other managers, or stakeholders will figure it out sooner or later. 

Then, you will look stupid or incompetent and have lost an opportunity to deepen your relationship with your team. Being humble and open about where you need to grow creates a healthy work culture and encourages the same in your engineers. 

2 - Be solution-focused, proactive, and open-minded

I recently met with my engineers, and one said he was close to finishing a task. However, when I looked closer, I saw his work was barely functional.

I had a choice. 

On the one hand, I could have said nothing and come back in a few days, hoping it would’ve been in better shape. On the other hand, I could have talked to him about it. 

I chose the latter, initiating a quick conversation so he could take me through the task. Who knows, maybe I didn’t understand what I saw. He told me about the nearly finished parts but also about a big problem he hadn’t figured out yet. As a manager, it was like discovering a large hole right where you intended to set foot.

This doesn’t mean your engineers are hiding things from you – it could just be a communication problem. But if they don’t trust you, or if they think you’ll shout at them, they’re not going to be forthcoming with issues. 

It’s like having a kid. Yelling at or blaming them when they tell you they’ve done something wrong guarantees they won’t tell you anything again. 

It’s the same with managing engineers – you need to communicate clearly that you’re focused on the problem, not on the person having it. And if it turns out there are engineers who have issues communicating problems, don’t be afraid to follow up with them regularly.

3 - Create a system to manage the flow

Being your team’s conduit means you get to see the inner workings of the team as well as how it fits into the company as a whole. This also means one of your main tasks is learning how to juggle all the others, especially when it comes to communication.

But there’s only so much information you can take in, remember, and act upon. You’re not a robot – in fact, if your team could communicate with each other like robots, they wouldn’t need you.

But they do need you, and it’s easy to get overwhelmed without a proper system. Additionally, if you only work 40 hours a week, you’ll soon find all of them taken up by communication, leaving none for your other tasks. 

But this isn’t a communication problem – it’s a time management problem. Overcoming this requires designing a system to better serve you and your needs. 

So, maybe you love meetings, but you’ll never have time to meet everyone. Creating a process for async communication is a helpful option. If people aren’t sure when they need to do a task or in what order, create a ticket system.

The main thing to remember is that even when you find an improvement you like, it still needs your attention. For example, asynchronous communication feels exhilarating until you realize you have two hundred messages to address.

The trick is learning how to balance these different approaches into a rhythm that works for you and your team and to continue to iterate upon them.

4 - Model habits for effective communication

As with any attempt to make changes, everything starts with you.  

Implement communication improvements yourself and model good habits for your team. Don’t go to a meeting without an agenda – if you initiated it, prepare the agenda yourself. Don’t leave a meeting without notes, and block time in your schedule to review those notes. 

I like responding to async messages in batches so they get answered without distracting me as they come in. I try to dedicate 15 minutes to this for every hour of deep work I do. If I want my team to catch on, I have to show them these processes and encourage them to try them out.

This also means setting a standard for how your team should interact with you. Remember that you’re the conduit: if they’re blocking the pipe with every little request, you’ll be less effective at your job. 

I find minimizing ad-hoc meetings works well for me. I schedule all my meetings ahead of time. When someone asks for a spontaneous check-in, I tell them to reschedule. If it really is urgent, I try to keep it under fifteen minutes. 

It’s important for you to be consistent here. If you create a rule and then break it, it only encourages your team to do the same. Be open with your engineers about what you need and ask them to respect your protocols. 

5 - Learn to say no

This is the key to your survival.

I talked once to a manager who transitioned to the role a year and a half ago, but eventually, he found it unbearable. He was so overwhelmed and swamped with different requests that he was on the verge of quitting and returning to engineering.

I told him it’s normal to feel this way, especially at first. Your team won’t realize all the tasks you have to juggle when you become the conduit or how stressful it is to be one. Sometimes, they make it worse by just dumping things on you, and this might not change. 

There will always be a flood of messages, tasks, and requests heading your way because you’re responsible for your team. Surviving this requires saying no. 

At any time, I might have one hundred to-do items, but I can only act on 10-20 on a good day, sometimes less. In order to do those 10-20 tasks well, I have to say no to 90 other tasks. 

You have to accept there will be an infinite number of things to do, but you can’t expect to do all of them. You pick the most important few items, focus on them, and say no to everything else. Any other method is a quick road to burnout and resignation. 

6 - Get the information you need so you can say yes or no

Just this week, I had a situation where someone on my team said we needed to jump on a call. This goes against my protocol against ad-hoc meetings, but he said it was urgent. 

Okay, I told him, I can jump on the call. But you have to give me the context first: what decisions are on the table to discuss, what’s been done already, and what do other teams think of the problem? This way, we waste as little time as possible. 

This is about more than just saving time in a meeting: having context gives you the chance to decide if the meeting is worth your time. Remember, saying “no” can give you more focus. But first, you need to know what you’re getting into. 

Learn to ask your team members questions about what they need from you. I find that half the time, when people explain what they want, half the solution is just writing a quick reply. Sometimes, just letting someone talk it out helps them make a decision or solve a problem themselves.

I once had one team member who would just say “hi” to someone else without giving any other context. This was a trap – if you said “hi” back, he would get right into a problem, and it was often already too late to back out. People didn’t have enough information to decide if they wanted (or if it was worth it) to respond to him at that moment.

So, we sat down and explained we needed more context. We asked him to tell us, in a single message, what he wanted from us. This gave everyone involved more freedom and agency to decide where to direct their focus.

However you handle this part of being an engineering manager, it’s an important part of your communication process and one you’ll need to stay consistent with.

The short version: embrace being your team’s conduit

Engineering management is deeply rewarding, but only when you do it right. Having consistent, effective team protocols – especially for communication – is the key to balancing all your tasks without burning out. There are a number of techniques and practices you can use to do so. 

Some include:

  • Being honest about what you don’t know
  • Following up with your engineers
  • Creating a system to manage the flow
  • Setting and modeling consistent standards
  • Learning to say no
  • Getting the information you need to say yes or no to a task

Every manager has to find their own rhythm, so feel free to try out different styles and techniques to figure out what’s right for you. The most important thing is to remember that, now that you’re not an engineer anymore, you have an entire team relying on you. Taking care of your own work rhythms and communication protocols benefits the whole team.


Want more tips on leading effective software engineering teams?

Join my newsletter if you’ve found this content useful


Originally published on Medium.com