I think the article misses what I think is a vitally important part of the job: being a crap shield.
A lot of the work of an EM is wading into the slurry pit with a shovel so your team are free to get the job done: bashing your head against InfoSec teams stuck in the '80s so the CI/CD toolchain can deploy to production, negotiating freedom with a CTO who wants to specify everything to the level of individual data structures, convincing HR that no, we really do need to pay for a good senior and not hire someone with 2 years experience in a configuration galley because they're cheap.
On top of that there's the process battles; in older firms, all those interminable "but can't they just use Waterfall?" meetings that go on for hours and are spawned every time there's a minor project manager reshuffle. In newer ones, the ongoing fight of, "you can't address debt or build foundations for the future, we need features, if it can't be done in less than a week it's not MVP enough"
There's a fine balance in that I think a good EM lets their team know this is going on and get involved where they want without dumping all the crap downward. Not least because they should be coaching their team leads in that responsibility, so they can take the career step when they want.
Going back to the article, as others mentioned it does read a little bit more like a "why I'm frustrated with my manager" than a "how to be a good EM", but it's easy to misconstrue the meaning of text.
Absolutely. This is especially relevant, these days, when HR departments are basically taking an actively adversarial role towards employees.
I used to get crap from HR, if I chose to resolve personnel issues without involving them.
The problem was, they had only two speeds: Do Nothing, or KILL ALL THE BABIES. Nothing in between; despite their constant harping about how they were "on our side." Their job was to keep the C-suite happy. It was absolutely amazing how many rules that were "hard and fast," and "applies to everyone here," would suddenly fail to be implemented, when it was a C-suite doing the rulebreaking.
There were also companywide policies, meant to appease union employees, that would also apply to the other 90% of the company that wasn't union (and thus, did not have the mitigating benefits), or that were in place to manage hourly employees, but also applied to exempt (from a life) employees.
It was my job to try to mask that kind of crap from my employees, and I got called on the carpet a few times, because of it. I would do it all over again, if I had to.
Maybe I'm just extremely lucky, but I think in 20 years of working at multiple companies (as an IC), I've never really even had contact with HR besides my first and last days. I don't think I could even name a single HR person I've ever met. They tend to be there to hand me the benefits literature, then at the end I give my badge back to them, and that's it. What on earth is happening in companies where HR is part of the daily life of a standard "3rd engineer from the left" employee?
* the crap shield is made of Gor-tex so you need to protect the team but also expunge the toxins that build up within. Not all crap is generated outside of the team but you need to get ride of it.
* the crap shield is transparent so the team can see what's happening outside without being covered in it
* the crap shield is retractable so you can let some into the team's atmosphere. Not enough to cause harm, but keep them grounded in the imperfect world in which their work will live.
* the crap shield has a window lock, and you the manager are in control of it. This is for the same reason the driver of a car can lock the windows in the back seat to stop the kids from opening them when you're in the car wash.
Agreed. The end goal is usually to make developers as productive as possible, which means a) giving them large contiguous blocks of coding time, and b) removing roadblocks (i.e. crap)
The "crap" can be politics, legal, ancient IT practices, useless meetings, constant demands for status/updates, bickering around cost/budgets, hiring, buying time to fight tech debt, and a whole bunch of other things.
The #1 job of a manager (in all fields) is to keep his people working. It doesn't matter if it is engineering, manufacturing or the local burger joint. A managers #1 job is to keep his people working.
To keep their people working. Women can be managers as well.
Edit: I understand other languages might have gendered nouns for words like Manager, and when learning English it can be difficult to break these habits.
In English, we have gender neutral pronouns to use when were talking about "generic people" where the gender isnt known. Managers are not just male, so when a sentence is gendered like that I struggle to parse it because I think I've missed a the reason why this hypothetical manager is male.
But you need to take a very long position on this.
Someone's beloved cat died? That's your problem, because it's affecting the way they work. You need to help them through it.
Someone's working well? That's great, but you can't rest on your laurels. You need to help them grow into a more senior position so they don't get bored or disillusioned.
That’s a “utilisation” view, and it’s a terrible model.
People who already have work to do are not responsive to new input.
By ensuring everyone is working all the time you also ensure nobody can respond to the unexpected.
The counterpoint to utilisation thinking is latency thinking (“how fast can our team respond to requests”).
An instance of utilisation thinking: “Our roads are not always full of traffic, how can we get more cars onto them?”. This is clearly absurd; why is “developers have work to do” a goal when “roads have cars on them” is not?
What to do when people dont deliver ?
In my current company mgrs say “we did our best”, when in fact I see ppl slacking as hell (days of doing nothing).
Hmm. I think the #1 job of a manager is to hire, motivate and let go of people the right way. It's up to them to keep working, and it's up to the manager to figure out how to do that no more often than required.
If you do it right, it's like 90% teambuilding and 10% line management, IMO. When that ratio is inverted is where you see mediocre management.
Absolutely! A manager can either be an umbrella to shelter under, or they can be a shit funnel.
Great work gets done when you can give your engineers a hard problem (or a long list of easy problems) and let them put their nose to the grindstone to get it done, while deflecting the rabble of inane ideas for new features, shifting deadlines, office politics, customer/supplier relations, etc. etc. etc. If a manager sidesteps all those, and passes them to the engineer, there will be have no time or energy for the actual work. If they are a single point of contact where an engineer can pull in a prioritized task list and push out questions and results, that's an ideal environment to get things done.
Unfortunately, other managers which interact with these EMs can sometimes have a hard time telling the former from the latter, and have a hard time evaluating the quality of the work/difficulty of the problems being solved, so the only visible difference is the happiness of the engineering team and the accomplishments that were made.
I used to think that then I burnt out. When the manager does nothing but the crap, the manager is going to leave. The proper way is to distribute the crap evenly.
This is why I decided to stopped doing engineering manager roles. Working on the crap stuff all the times is no fun. And the longer you do it the more your technical skills fall behind. I'm fine with the technical roles along with mentoring the new engineers.
"The proper way" is not an objective thing and to present it as such is disingenuous.
The best managers I've ever worked for have all, without fail, worked daily to keep as much nonsense away from the team as possible. The worst have either only been concerned with their personal advancement, or would just make the team basically fend for itself.
>> The proper way is to distribute the crap evenly.
This is true of "crap work" (i.e. stupid bugs, wading through documentation) but not of the crap external to the team. Your job as the manager is to deal with it all. You can either work to slow it's generation or suck it down, but it's all on you.
Maybe it is different in Software engineering than in Hardware, but if you have a team developing hardware and they encounter a problem they cannot solve they have to turn to their manager. So the manager also gets technical crap/difficulties to solve. The 5% he cannot solve goes one level higher, so basically the higher you get, the more distille/purerd crap you get.
> I think the article misses what I think is a vitally important part of the job: being a crap shield.
One of my first jobs, it was described colourfully (it was in the UK) as being the team umbrella. i.e. Protects the team from the ever circling pigeons from above that like to frequently 'deposit'. :)
All of the managers I’ve worked with on the “great” end of the quality spectrum have excelled at being sh*t umbrellas. Perhaps that speaks also to the quality of the orgs I’ve been in, as well...
This is a (the?) differentiating quality between effective management and not.
In Office Space, one thing that makes Lumbergh the manager so distasteful is you just know he would never do one thing to help anyone reporting to him.
My interpretation of this is a junior SDE position where you mostly update system configuration parameters all day instead of writing code or designing systems. People in these positions still get paid SDE salaries but aren't gaining any useful software development experience.
A galley was a large-ish, primarily oar-powered ship.
However it also refers to the kitchen on certain even larger boats.
So, it's kind of ambiguous what GP meant - either picking a cook out of a galley-kitchen (who is not the best chef, but rather someone making huge amounts of food for a ship's crew), or picking a slave off of the oars in a galley-ship.
One thing missing from my recent engineering managers is lack of relevant coding experience.
You don't need to be an great engineer to be a good manager, but it definitely helps when your manager knows enough about the battles fought in the trenches and can offer actual feedback/support instead of nodding for 30m, then going to another 1:1.
At my last job I had an interesting (nice) experience. My boss wasn't an engineer, he was a project manager, but that didn't hinder him. I think what made him successful was that he cared. He'd say over and over, "I'm not a developer, I need help understanding." We would sit in a meeting and walk through problems. He was very calm and patient and acted genuinely interested in what the problem was. He would ask questions about what he didn't understand, and trust us on the things that we would say. It was a great experience. When we said we had a problem, he tried to understand and relay that to the necessary people. When he couldn't we'd accompany him to explain the details.
Yeah, I've definitely worked with non-engineers (project managers, designers, QA, etc) who are more than capable of understanding technical issues even if they don't get the details. They're usually great people to work with, and I try to extend the same courtesy to other parts of the business that I work with.
My current manager is a lot like this. He has never written a line of code but is surprisingly good at scoping work and understanding how important various tasks are. I think that any manager who is smart, cares about the work, and has good discussions with their engineers can develop a solid understanding of software projects.
There's no magic to it but, sadly, that combination of qualities is a lot less common than I would like.
My current and former manager are exactly like this, except that both of them do know SQL, really great guys that try their best to help guide the project.
As a little anecdote, my first boss was a technical manager with many years of experience in programming but unfortunately not very good managerial skills. The biggest problem was that he had a clear image of the big picture but when we try to explain to him that "No, we can't do X because Y" then he said, "what are you talking about? Of course, we can It's a simple queue/query/function call", and he would not listen until we show and explain him the code or he tried to do it himself.
It's definitely better to have an empathic and cooperative manager even if he or she lags the technical knowledge
Companies really struggle with this, and in both directions. Startups and scale-ups tend to overcompensate to the point management hires get interviewed as super-ICs, where they'll be expected to answer technical stages at (or even above) the company's top IC standard, but only get a couple of basic scenario questions about management that anybody could answer. Sometimes you get lucky and they're good at both, but it's a big source of the "management by yelling at people" and "I can't have a 1:1 with you, I'm fixing a production issue" schools prevalent in such environments.
It's rare to find a company balanced in the middle where they're looking for someone who clearly "gets it" and can talk about technical solutions, but also has the ability to solve the people problems. (Often good managers were also skilled ICs before they made the jump, but lack of everyday practical use leaves them with a layer of rust. In an hour interview with someone you've never met before it's hard to tell the difference between "rust" and "has heard of the concepts but doesn't really understand them" though)
I think that would be covered under the idea "Lead by example". When the manager is competent to understand, console and provide guidance to the team when they're struggling - even slight slivers of technical skills and knowhow, the rapport they build is unbreakable.
The idea is to genuinely belong to a team, not just on an org chart. When troops are in the battle field, they form unbreakable bonds because they have trust, got each other's backs and there is absolutely nothing artificial about it - life is on the line. More often than not, I've seen managers appear genuine but are not internally so and it will surface in future if not now.
Also, corporations, midsized companies and even small companies have this idea of not speaking the mind. Instead, massive amounts of bullshit corp speak and lipstick is put on the pig to do a quick dog and pony show for the upper management. Managers that suck up to upper management lose their support from the troops. Once that's done, there is no going back.
This is a really tricky thing to nail down as an EM. My first eng leadership role I was promoted out of the team. Everyone already knew I had what it took (I was one of the core group pushing hard to get the product out the door) so "engineering respect" came naturally. Fast forward to being hired as an EM - I realized I had to earn this all over again AND I couldn't do it just be being another peer in the trenches. Being an authentic leader is _hard work_, but it pays off when you see your team succeed.
I've had EMs who who really well versed in the team's technical work, because they were an IC on the team, and the complete opposite: EM was external hire
One downside of relevant coding experience is that the EM will get involved in more and more little technical details, which bleeds into micromanagement territory.
Yep, that's what I'm experiencing. There isn't a requirements analysis or design review where he doesn't insert himself into the low-level details, right down to class/data specifications and even lower. Instead of bringing his knowledge of how our stuff has to integrate with other teams' work to inform the design, he acts more like an IC colleague participating in its construction. Then, when engineers come to design reviews with designs that are relatively under-specified (knowing he'll just start making decisions during the meeting) he complains.
It's a bit grating to be told that "you're the expert, I expect you to decide these things" and then have every detail nitpicked over and argued with anyway.
I guess I'm just cynical, but every time I see a post on "How To Be A Great Manager", I only see "Look At Me, I'm A Great Manager!".
Why the cynicism? Because in my career across many companies and many teams, I can count the good managers on one hand, but have seen people "playing manager" everywhere -- and these are the ones who like to espouse theory.
* Frequent one-on-ones! (yeah but everyone on your team is demoralized and trying to switch out)
* Shield the engineers from crap! (but you still let your team struggle to take care of everything while you're busy "aligning" with the other managers)
* Help the engineers grow! (are you actually giving them more responsibilities in a way they can deliver and actually get promoted this year, or just dispensing cheap advice every week?)
* Resolve conflicts! (do you personally take it upon yourself to settle issues with your peer managers, or do you co-miserate with your directs about how political everything is)
Really, there's dozens and dozens of things a good manager will need to do, and it's far from a solved problem. Drawing up a list of desiderata is not the hard part. The difficulty is how to actually enact them, how to actually impact the team, how to actually drive the project forward. You tell me your secret and I'm all ears.
2. Shielding their team from crap (as someone mentioned already)
3. Don't pitch one team member vs another - this is toxic. Instead nurture their strength. Our competitors are outside the team, not inside
4. Cheer lead/Sponsor for the team outside. Genuinely back your team.
5. Always expect your team members are smarter than you - give them that trust. Thank them for things they teach you.
6. Managing is more like parenting college kids (not toddlers/middle schoolers). You want them to survive worst and replace you if needed. So you too can grow. But avoid micro managing.
7. Learn to have tough conversations - This could be for their/team's improvement.
Your company expects that you follow along the deliveries, setting quality standards, making sure the team has the support they need and upper management the feedback they need.
This part seemed a little weakly worded to me. An engineering manager should make sure their team gets things done. It isn't enough to "follow along the deliveries".
Sometimes that is things like setting standards and communicating. But it's also things like firing underperformers and hiring for open headcount. It's making sure you have enough budget and support from other teams to get the job done. Whatever it takes. It isn't enough to say "Well, communication was great, I gave the team a lot of support, but we didn't make very much progress."
I think it's the wording like you mention, in Lat-Am countries it is common to say "darle seguimiento a las entregas" or "rastrear entrega" as a way to signal that the person is responsible of making sure that things workout well including handling or helping out with any technical or communication roadblocks for the team.
One thing I noticed is that a lot of managers create an environment they would not want to work in themselves. A good manager should not just pass on orders from above and report back but try to shape the work environment so their reports can work well.
A lot of managers in my company only ask “when” but never “how” or “why”. It doesn’t help to constantly remind people of deadlines without listening to and implementing suggestions for improving the work environment.
I think this is because in most cases, the "when" is what their bonuses/promotions are based on. Managers don't get promoted because the code is great or the architecture was elegant, they get promoted for raw delivery and being able to say "my team delivered X in only Y days".
I recently told my manager ‘we have literally never delivered a project on time because of process deficiencies, you expect me to believe the next project will be any different?’, only to be told that we had to deliver this one on time, because it was for a client (all our previous projects were too).
Lots of great comments so far, but I'd like to toss mine in: showing up. As an EM for a few years now, showing up consistently, being available, always making time to talk or hear someone out.
The best managers I've had also always told the unvarnished truth and empathized with what all the folks "in the trenches" had to do day to day.
I recommend all of the books referenced in the original post. They are all very good. But the expectation of an engineering manager is fairly simple:
Do whatever it takes.
Way back in February or March, when we were still working from the office, I walked to the drug store on the corner and got Lysol wipes and hand sanitizer for everyone. Because, do whatever it takes.
I once had a report who demanded, snarkily, all the things be listed on the whiteboard (as opposed to just getting them in Jira) and the meeting was set for the next day...
Knowing the team was one of those that is constantly using nearly-depleted markers and hating life, I thought to check. Sure enough... all empty, nothing to replace them with.
I thought to just let said report arrive at next day's meeting, ready to whiteboard it up only to look woefully unprepared, but I waited. I waited until about an hour before the meeting to see if they might have clued-in and sorted the problem for themselves...
An hour later I returned from a slushy 2km walk, soaked, with a box of markers that I just placed in the drawer, unbeknownst to all.
I would recommend that you read a book a week, every week, for the rest of your life. :)
Just start with the ones in the article and Amazon/Kindle will get good at recommending books.
Here's some books recently read on my Kindle:
- No Rules Rules
- Never Split The Difference
- The Manager's Path
- The Almanack of Naval Ravikant
- Ultralearning
- The Hard Thing About Hard Things
- What You Do is Who You Are
- User Story Mapping
- Inspired
- The Lean Product Playbook
- Competing Against Luck
- Domain Driven Design
- Patterns of Enterprise Application Architecture
- Data-Driven Marketing
- Designing Data-Intensive Applications
- Monetizing Innovation
- Super Thinking
- The Great Mental Models
- Nonviolent Communication
- High Growth Handbook
- Powerful
- Trillion Dollar Coach
Readit News
A lot of the work of an EM is wading into the slurry pit with a shovel so your team are free to get the job done: bashing your head against InfoSec teams stuck in the '80s so the CI/CD toolchain can deploy to production, negotiating freedom with a CTO who wants to specify everything to the level of individual data structures, convincing HR that no, we really do need to pay for a good senior and not hire someone with 2 years experience in a configuration galley because they're cheap.
On top of that there's the process battles; in older firms, all those interminable "but can't they just use Waterfall?" meetings that go on for hours and are spawned every time there's a minor project manager reshuffle. In newer ones, the ongoing fight of, "you can't address debt or build foundations for the future, we need features, if it can't be done in less than a week it's not MVP enough"
There's a fine balance in that I think a good EM lets their team know this is going on and get involved where they want without dumping all the crap downward. Not least because they should be coaching their team leads in that responsibility, so they can take the career step when they want.
Going back to the article, as others mentioned it does read a little bit more like a "why I'm frustrated with my manager" than a "how to be a good EM", but it's easy to misconstrue the meaning of text.
I used to get crap from HR, if I chose to resolve personnel issues without involving them.
The problem was, they had only two speeds: Do Nothing, or KILL ALL THE BABIES. Nothing in between; despite their constant harping about how they were "on our side." Their job was to keep the C-suite happy. It was absolutely amazing how many rules that were "hard and fast," and "applies to everyone here," would suddenly fail to be implemented, when it was a C-suite doing the rulebreaking.
There were also companywide policies, meant to appease union employees, that would also apply to the other 90% of the company that wasn't union (and thus, did not have the mitigating benefits), or that were in place to manage hourly employees, but also applied to exempt (from a life) employees.
It was my job to try to mask that kind of crap from my employees, and I got called on the carpet a few times, because of it. I would do it all over again, if I had to.
Susan Fowler's story can give you an idea of how HR works... https://www.susanjfowler.com/blog/2017/2/19/reflecting-on-on...
* the crap shield is made of Gor-tex so you need to protect the team but also expunge the toxins that build up within. Not all crap is generated outside of the team but you need to get ride of it.
* the crap shield is transparent so the team can see what's happening outside without being covered in it
* the crap shield is retractable so you can let some into the team's atmosphere. Not enough to cause harm, but keep them grounded in the imperfect world in which their work will live.
* the crap shield has a window lock, and you the manager are in control of it. This is for the same reason the driver of a car can lock the windows in the back seat to stop the kids from opening them when you're in the car wash.
Individual Contributors usually do not want ambiguity or to have a lesser impression of the company or of someone, it isn't good for anyone.
They also lack the context you have and jump to a lot of conclusions that are usually unfair.
It's a hard job!
They don’t? In my experience IC’s do most of this venting about horrible processes.
The "crap" can be politics, legal, ancient IT practices, useless meetings, constant demands for status/updates, bickering around cost/budgets, hiring, buying time to fight tech debt, and a whole bunch of other things.
Edit: I understand other languages might have gendered nouns for words like Manager, and when learning English it can be difficult to break these habits.
In English, we have gender neutral pronouns to use when were talking about "generic people" where the gender isnt known. Managers are not just male, so when a sentence is gendered like that I struggle to parse it because I think I've missed a the reason why this hypothetical manager is male.
Someone's beloved cat died? That's your problem, because it's affecting the way they work. You need to help them through it.
Someone's working well? That's great, but you can't rest on your laurels. You need to help them grow into a more senior position so they don't get bored or disillusioned.
People who already have work to do are not responsive to new input.
By ensuring everyone is working all the time you also ensure nobody can respond to the unexpected.
The counterpoint to utilisation thinking is latency thinking (“how fast can our team respond to requests”).
An instance of utilisation thinking: “Our roads are not always full of traffic, how can we get more cars onto them?”. This is clearly absurd; why is “developers have work to do” a goal when “roads have cars on them” is not?
If you do it right, it's like 90% teambuilding and 10% line management, IMO. When that ratio is inverted is where you see mediocre management.
Great work gets done when you can give your engineers a hard problem (or a long list of easy problems) and let them put their nose to the grindstone to get it done, while deflecting the rabble of inane ideas for new features, shifting deadlines, office politics, customer/supplier relations, etc. etc. etc. If a manager sidesteps all those, and passes them to the engineer, there will be have no time or energy for the actual work. If they are a single point of contact where an engineer can pull in a prioritized task list and push out questions and results, that's an ideal environment to get things done.
Unfortunately, other managers which interact with these EMs can sometimes have a hard time telling the former from the latter, and have a hard time evaluating the quality of the work/difficulty of the problems being solved, so the only visible difference is the happiness of the engineering team and the accomplishments that were made.
The best managers I've ever worked for have all, without fail, worked daily to keep as much nonsense away from the team as possible. The worst have either only been concerned with their personal advancement, or would just make the team basically fend for itself.
This is true of "crap work" (i.e. stupid bugs, wading through documentation) but not of the crap external to the team. Your job as the manager is to deal with it all. You can either work to slow it's generation or suck it down, but it's all on you.
One of my first jobs, it was described colourfully (it was in the UK) as being the team umbrella. i.e. Protects the team from the ever circling pigeons from above that like to frequently 'deposit'. :)
When teams don't see (and/or frame) those things as key part of achieving their goals the results aren't gonna be great for anyone.
This is a (the?) differentiating quality between effective management and not.
In Office Space, one thing that makes Lumbergh the manager so distasteful is you just know he would never do one thing to help anyone reporting to him.
> configuration galley
I like that. "Ramming speed."
What does this mean?
However it also refers to the kitchen on certain even larger boats.
So, it's kind of ambiguous what GP meant - either picking a cook out of a galley-kitchen (who is not the best chef, but rather someone making huge amounts of food for a ship's crew), or picking a slave off of the oars in a galley-ship.
I don't know.
Dead Comment
You don't need to be an great engineer to be a good manager, but it definitely helps when your manager knows enough about the battles fought in the trenches and can offer actual feedback/support instead of nodding for 30m, then going to another 1:1.
There's no magic to it but, sadly, that combination of qualities is a lot less common than I would like.
As a little anecdote, my first boss was a technical manager with many years of experience in programming but unfortunately not very good managerial skills. The biggest problem was that he had a clear image of the big picture but when we try to explain to him that "No, we can't do X because Y" then he said, "what are you talking about? Of course, we can It's a simple queue/query/function call", and he would not listen until we show and explain him the code or he tried to do it himself.
It's definitely better to have an empathic and cooperative manager even if he or she lags the technical knowledge
It's rare to find a company balanced in the middle where they're looking for someone who clearly "gets it" and can talk about technical solutions, but also has the ability to solve the people problems. (Often good managers were also skilled ICs before they made the jump, but lack of everyday practical use leaves them with a layer of rust. In an hour interview with someone you've never met before it's hard to tell the difference between "rust" and "has heard of the concepts but doesn't really understand them" though)
The idea is to genuinely belong to a team, not just on an org chart. When troops are in the battle field, they form unbreakable bonds because they have trust, got each other's backs and there is absolutely nothing artificial about it - life is on the line. More often than not, I've seen managers appear genuine but are not internally so and it will surface in future if not now.
Also, corporations, midsized companies and even small companies have this idea of not speaking the mind. Instead, massive amounts of bullshit corp speak and lipstick is put on the pig to do a quick dog and pony show for the upper management. Managers that suck up to upper management lose their support from the troops. Once that's done, there is no going back.
One downside of relevant coding experience is that the EM will get involved in more and more little technical details, which bleeds into micromanagement territory.
It's a bit grating to be told that "you're the expert, I expect you to decide these things" and then have every detail nitpicked over and argued with anyway.
Why the cynicism? Because in my career across many companies and many teams, I can count the good managers on one hand, but have seen people "playing manager" everywhere -- and these are the ones who like to espouse theory.
* Frequent one-on-ones! (yeah but everyone on your team is demoralized and trying to switch out)
* Shield the engineers from crap! (but you still let your team struggle to take care of everything while you're busy "aligning" with the other managers)
* Help the engineers grow! (are you actually giving them more responsibilities in a way they can deliver and actually get promoted this year, or just dispensing cheap advice every week?)
* Resolve conflicts! (do you personally take it upon yourself to settle issues with your peer managers, or do you co-miserate with your directs about how political everything is)
Really, there's dozens and dozens of things a good manager will need to do, and it's far from a solved problem. Drawing up a list of desiderata is not the hard part. The difficulty is how to actually enact them, how to actually impact the team, how to actually drive the project forward. You tell me your secret and I'm all ears.
1. Managers need to be human & kind.
2. Shielding their team from crap (as someone mentioned already)
3. Don't pitch one team member vs another - this is toxic. Instead nurture their strength. Our competitors are outside the team, not inside
4. Cheer lead/Sponsor for the team outside. Genuinely back your team.
5. Always expect your team members are smarter than you - give them that trust. Thank them for things they teach you.
6. Managing is more like parenting college kids (not toddlers/middle schoolers). You want them to survive worst and replace you if needed. So you too can grow. But avoid micro managing.
7. Learn to have tough conversations - This could be for their/team's improvement.
You don't have to (and shouldn't) tell them you are doing this - word will get back to them.
This part seemed a little weakly worded to me. An engineering manager should make sure their team gets things done. It isn't enough to "follow along the deliveries".
Sometimes that is things like setting standards and communicating. But it's also things like firing underperformers and hiring for open headcount. It's making sure you have enough budget and support from other teams to get the job done. Whatever it takes. It isn't enough to say "Well, communication was great, I gave the team a lot of support, but we didn't make very much progress."
I think it's the wording like you mention, in Lat-Am countries it is common to say "darle seguimiento a las entregas" or "rastrear entrega" as a way to signal that the person is responsible of making sure that things workout well including handling or helping out with any technical or communication roadblocks for the team.
A lot of managers in my company only ask “when” but never “how” or “why”. It doesn’t help to constantly remind people of deadlines without listening to and implementing suggestions for improving the work environment.
I just don’t follow how that logic works..
Deleted Comment
Setting in place and maintaining a system like that is hard. Telling people what to do is easy.
Do whatever it takes.
Way back in February or March, when we were still working from the office, I walked to the drug store on the corner and got Lysol wipes and hand sanitizer for everyone. Because, do whatever it takes.
Knowing the team was one of those that is constantly using nearly-depleted markers and hating life, I thought to check. Sure enough... all empty, nothing to replace them with.
I thought to just let said report arrive at next day's meeting, ready to whiteboard it up only to look woefully unprepared, but I waited. I waited until about an hour before the meeting to see if they might have clued-in and sorted the problem for themselves...
An hour later I returned from a slushy 2km walk, soaked, with a box of markers that I just placed in the drawer, unbeknownst to all.
Just start with the ones in the article and Amazon/Kindle will get good at recommending books.
Here's some books recently read on my Kindle: