There are hundreds of books, blogs and training courses on how to be an effective manager. How to delegate, how to coach, how to verify information. Less has been written about the role of Engineering Manager, which as part of software R&D teams has a particular set of established techniques and processes the everyone is aware of but have different feelings about.

The main thing to understand is, part of leading is deciding how to lead. Just because you've always done standups a certain way, taken half a day per sprint to plan things in detail, had standardized kickoffs or checkins with product and design folk - this does not mean you have to continue doing things that way. Even the choice of whether to work in a strict scrum / sprint format or something looser is ultimately up to you*.

Your job is optimizing the productivity and morale of your team. They are the constant factors, and everything else is a variable.

*you may not have this flexibility at all companies as a brand new manager - some insist on proscribed processes. But once you get established you can absolutely argue for and make changes. The job is not about standardization, it's about shipping stuff. In these places, try to understand why they like to standardize and make sure whatever you propose addresses that.

Almost universally the first thing every new manager does is set up recurring 1:1’s with their team, usually weekly. It’s so default in the job, HR and management books will even tell you to do it. Ignore them. Because what also happens by default is you kill your calendar, and your teams, while that time quickly devolves into project status updates and social sessions. There just simply isn’t enough stuff to talk about on a weekly basis if you don’t fill that time with project updates and what you did on the weekend.

It’s better to think of 1:1’s as a tool to be used. A tool to help you develop your team and diagnose and unblock interpersonal problems (us humans are fickle, complicated creatures!). Use it when you need it - in some situations that might be more than once a week, and in others it’s much less frequent.

“But I want to be available to my team!” - Why do you need a recurring meeting for that? Just be available and encourage them to talk to you when they want/need to.

“But I won’t know what’s really going on!” - A series of 30-60 minute meetings with each person on your team seems like a horribly inefficient way to get this information. Look for better ways.

And discussing any project work in 1:1’s is equally inefficient. By definition they’re closed door meetings, with non-visible agendas. Project work is team work! Have one meeting with all the relevant people, don’t play telephone from 1:1 to 1:1.

One director with a pretty large team we know has no scheduled 1:1’s. He just keeps a spreadsheet of when he last talked to someone 1:1 and checks it every so often to make sure he doesn’t go too long without talking to them again. No clogged calendar, more time to focus, no having to juggle day’s full of 1:1’s to make room for other things to get scheduled, no more skipping them all the time and leaving a bad taste in someone’s mouth. This works because his teams know they don’t need to wait for a scheduled meeting to talk to him, then can just talk to him. And he’s available because his calendar isn’t clogged with 1:1’s.

Say it with us, 1:1’s are a tool, not a rule!

This is why we built our 1:1 tool into KATA, and why it doesn’t come with scheduling functionality! You can add to a 1:1 agenda with someone from anything and anywhere in KATA or Slack, so that you can have a data-driven conversation and avoid devolving into a social call. And only schedule it when you have stuff to talk about.

Okay we’re going to try and walk a tightrope here and avoid talking about capital letter development methodologies or giving history lessons. Let’s talk about the standups of today. For a group of people who live and breathe optimization and efficiency, they’re incredibly inefficient! By definition they’re repetitive, what did you do yesterday, what are you doing today, wait didn’t I tell you that yesterday? And no one is standing! Which is a cute way to say they very rarely only take 15 minutes. Not to mention the guaranteed context switch daily. Add that up across your team and it’s a lot. So why do we even do them (besides being creatures of habit)?

They’re occasionally great, you find out your teammate is stuck on something that’s a quick solution. You hear someone is over or under engineering a problem, or had a misunderstanding of what was needed, and can help course correct. Someone is finished early and you can work with them to find the best thing to dive into next. And of course it’s nice to interact socially a little. But the bulk of the time is spent regurgitating information already in the tools, or just “still working on”. Some teams have switched to doing them in Slack. You trade the social interaction and the quick question asking for a little more async. But are people reading them at this point or is it an exercise in writing and satisfying the inner micro-manager in our head? .

Without getting too heady about it, here’s what we’ve found to be a better way. For most teams in a steady state, weekly written updates are way better. There just simply isn’t enough to always talk about daily, whereas weekly they’re just more meaningful. People are more thoughtful about what they’ve done and are planning to do, phrasing things more in business value terms not tasks or implementation details. And it’s a good forcing function to think about your week, not just the immediate task in front of you.

So let’s talk about the downsides. Early blocker/rabbit hole detection is a big one, someone could be spinning for a whole week. A better solution here is the notion of a rubber duck debugging. Get a Slack channel set up for your team where it’s free reign on big and small problems, just post away. Alignment is actually better done on a weekly basis anyway, day by day details aren’t as good at shedding light on most of these types of problems, they get lost in the details. And you can usually tell when people are wrapping things up early from their weekly update too and just have them ping you/ping them if it’s not already obvious what’s next. And social time? Schedule a game night.

So should you never do daily standups? Au contraire they do have their place. They work really well at times when things are not in a steady state, when there is truly meaningful daily change in the system. And they’re another tool to help communicate and create this urgency with your team too. Whether it’s a critical time of the year and you have a big effort, or there’s a must ship project that’s key to the business. Save your daily standups for those and give your team more time for building in between.

And if you’re looking for a good way to facilitate all of this, we built the teams feature in KATA to operate exactly like this. Get weekly updates posted from team members, memorialize them for them (side benefit, very helpful for performance review season!), and let KATA fill in the details from all of the connected tools during the week.

Being an engineering manager can be very stressful. It's a position of very high responsibility and, well, let's be kind and say variable autonomy. The concept of the bullshit umbrella is very simple: craziness happens, and as your team's main interface to the company it's very much up to you to decide what to say, how to say it and how much detail to go into.

• Maximum umbrella is shielding your team from everything you possibly can. Creating an environment of sanity, consistency and calm where work is planned properly at a set cadence, delivered without too many incidents and priorities do not shift. To be maximum umbrella you will need to fight against incoming requests. You'll certainly be perceived as being inflexible and impractical by your peer group, and by product and business partners. This will not be great for your career, and ultimately isn't great for your team, as to a large extent your reputation is their reputation.
• Minimum umbrella is being a transparent proxy. You say yes to every new incoming thing, no date is set in stone, you have no agency over priorities. Software delivery will suffer because individual and team focus will move around rapidly. Frustration within the team will increase as things are left incomplete and anything that does get finished will be rushed out. You won't have to argue or make compromises around incoming work as you just say yes to everything. Short term this might work out for you, but the drop in output and inevitable staff unhappiness will bite you.

As with many things the correct approach is in the middle somewhere. Teams need stability and consistency but businesses need to change approach sometimes, often at short notice.

My preferred technique with my teams has always been to be honest about where the business is, what it's doing and what it's prioritizing. If you talk about that enough, while people may get pissed off that a priority change wasted some time, they'll at least understand why.

Outwards and upwards it's more a game of compromise. If new requirements can be fit into existing work that can help. If not, you need to barter a little. Help someone out this time and they'll help you in future. At the very least, saying "no" is easier if you previously said "yes".

And remember reputation is important, especially at larger companies. Your reputation and your team's reputation will become aligned.

A handy rule of thumb when creating or refactoring teams is to think about 2’s. Each primary domain should have at least two people as primary points of contact, and no person should be a PoC to more than two things. How you define a primary domain is up to what you own, it might be a full platform like Web, iOS, backend etc. or modules or services within those. Point being two primary PoC’s keeps things unblocked (time zones, time off, meetings, team changes etc.) and no more than two areas keeps people focused and not overloaded.

Not everyone needs to be a PoC but mapping this out for future growth is also a good way to stay on top of current and future areas of expertise and make sure your team stays durable.

The Fallacy of Servant Leadership:

A trendy but misguided “management book special” leadership style, it’s like pretending magic is real. Servant leadership says a leader's primary purpose should be to serve the growth and well-being of their team. Spot the problem? It’s subtle, sorta. Getting your team to be all they can be is great, having psychological safety is important, as is feeling supported, encouraged, and happy. But where’s the direction and alignment? The pace setting? The hard decision making? Who’s going to give critical performance feedback?

Take your favorite sports team. If the coach made sure all of the players had everything they needed, felt really glued together on the team, were happy and excited, and then just sent them all onto the ice or field, what do you think would happen? What about the strategy and play calling? Think the team will just figure it out? Well what happens when players disagree on it? You see where this goes.

Remember your job, build effective and durable teams. Effective teams need more than Kumbaya, there’s hard decisions and critical tradeoffs to make, and durable teams need a purpose and direction. So it’s not that the intention is bad, it’s just not the primary purpose. Another way to say it is that it starts with the word servant, not lead. So forget servant leadership, unless you're vying for the boss of the year mug at the team gift exchange this year.

Hire Smart People And Get Out of the Way:

This one has been written down already so we won’t restate it, check it out here.