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?
I was a manager, so I had plenty of interaction with HR.
For the most part, they weren't actually bad people, but their job was to be fairly two-faced. I think it caused a lot of issues. HR had the highest turnover in the company.
The last time I had dealings with HR, it was because I had reported that my boss did something illegal, and I told the head of the company.
They tell me to deal with HR, and HR tells me that I should have talked to my boss first.
In short, the heads of the company didn't want to hear about the illegal stuff, and HR was their shield for it.
My boss actually told me, "I could get fired for what you said." It wasn't what he did that was the problem in his mind, but that I told people about it.
I didn't last much longer at the company. They didn't fire me, but they also stopped giving me raises. When I asked for one, I was asked if I could "wait a year". I found a new job for a 40% raise 6 months later.
* 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.
Maybe we should lighten up a bit and not bring in politics into everything. The writer could be a male and this would be natural for them just like it would be for a female and her.
Using male pronouns instead of genderless/more inclusive pronouns in your speech is indicative of a bad managing style (or just bad style all together). As a manager you should be inclusive of all genders both directly and indirectly, which includes how you use whatever language you speak.
The people you manage could easily identify with a gender that is not physically obvious and using incorrect pronouns leads to a less inclusive and potentially more hostile workplace. This is Management 101.
I think that is still poor and confusing English when not talking about a specific person. I notice people do this when trying to make speech more inclusive, and I still struggle with parsing the sentence because of the unnessisary gender being mentioned.
Oh but not trans of course, so polite of you to leave them out in your heteronormative take on the world.
I would have hoped most were aware of the pressures the transgender community is under and would offer more care than such casual takes on gender in the workplace.
Trans people can be women as well, so saying "Women can be managers as well" does not exclude trans people because female-identifiying trans people are still "women".
It's not totally inclusive of people who identify outside of the binary genders, but saying "women can be mangers" does not exclude men or people who don't identify as either. I hope my point still remains though that using "they" as a gender neutral pronoun is a perfectly easy way to be inclusive.
> your heteronormative take on the world
I mean i am a (cis) gay male, so I don't think I have a heteronormative take on the world, but you do you.
(acknowledging this comment seems to be puposefully trolly, like a "false flag" troll)
Oh so now you get to decide how they should self identify; how very generous of you.
At this stage you really need to stop and think about what you are doing and who you are hurting; they're just words to you but they're a lifetime of hurt to others.
Be . Better.
> I mean i am a (cis) gay male, so I don't think I have a heteronormative take on the world, but you do you.
You really want to call upon the equivalent of the "some of my best friends are black" excuse? I can't even...
If you have some constructive feedback on how I could have worded what i said to be better, I’m definitely open for it. I’m always trying to be better.
Perhaps it would be been better (for a number of reasons) to say “not all managers are male” instead?
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).
I didn't say that it was the only part of the job, just that it was the most important thing. Hopefully you have some knobs you can turn. At my current company if people can't deliver you try to hook them up with more mentors and if they still can't deliver, you stop giving them direct labor to work on and eventual force them out because they don't have any work and they stop getting pay raises (or you fire them usually they push them out).
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.
Yep, a manager can focus on climbing the ladder once they offload their responsibilities onto the people beneath them. If their boss can't detect this abdication, or worse, doesn't want to see it, then the manager's opportunism will naturally be rewarded, and will encourage the opportunism of other managers in the org.
I think in general most companies, especially large ones, reward managers who push crap onto their directs. Anecdotally, the best manager I've ever had viciously protected us from executive nonsense, and he's also the most successful by far (and he was before I started). I don't think that's the norm, though.
Management isn't math. It's not a science, and there are successful managers who push as much crap onto their directs as they can, and there are successful managers who take as much of that crap as they can to prevent it from reaching their teams.
>> 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)
Obviously there's a spectrum of management that an IC can undertaken, but this is typically based around their good will and soft powers, but the wider point is they're not supported to have direct reports.
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.
Sorry for the late reply, but for me: 1) ICs happy, learning, w/ good work/life balance AND 2) project work delivered at high quality in a reasonable time frame. Personally, when in doubt, I sacrifice #2 for a while.
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
`A good way to think about hiring and growing your team members is to think that they can replace you.`
This is really wrong.
Manager is a path, but an IC shouldn't need to become a manager to keep growing in their career.
> Manager is a path, but an IC shouldn't need to become a manager to keep growing in their career.
I 100% agree with this, but have never really REALISTICALLY seen any of this methodology in the companies that I've worked at. Here's what I usually see instead: if someone is a staff engineer, then they worked their ass off to get there and are generally really good coders, and have wrapped their heads around the business/domain really well.
The managers I've seen are generally skewed towards incompetence, which to me, shows that interviewing to become an EM is MUCH easier than it is to become a staff engineer, yet the pay is identical. So you mostly have staff/principal engs that are VERY smart, and more often than not, have EMs/directors who have stumbled their way upwards by being lucky.
The question is -- do you want to be a principal engineer when you're 45, know the business, the code, the domain inside out, be paid well, but STILL have to answer to directors/managers who are 15 years your prior, who are entirely incompetent and have essentially lucked/bullshitted their way into their roles, and deal with all of that crap on and endless basis or do you become that person and attempt to fix it from the top?
A different angle: most companies have no idea what a staff engineer is, and how to promote from within. However, I've seen midlevel engineers do some decent work, maybe complete a major project, and be promoted to EMs. What's the point of trying to become a staff engineer (assuming part of your goal is to grow your wealth) when you can just easily become an EM at most places and make the same exact amount of money, and just do what you love (i.e coding), on the side. Of course, to each their own and all of that. But at the end of the day, it is much much easier to go into management and incompetence your way around to the top where goals are nebulous and not super calculable compared to being senior IC.
I should finally note that I have had a couple of EMs that were really good. However, those are far and few between IMO.
Anecdotally, as a SWE who doesn't have personal interest in coding, I would be more likely to code if I were a manager and didn't have to do it in day to day life (to get the satisfaction of actually doing everything exactly how I want it). After staring at a screen and typing all day, the last thing I want to do is put more strain on my eyes and fingers after work.
Depends on the organization, some places managers don't have any involvement in anything technical, but at a lot of places they do. Managers are often involved with architecture/design decisions, resolving internal disagreements about technical matters, improving dev processes, negotiating with PMs to translate product requirements into concrete engineering tasks, etc.
These are all things a senior IC should be doing as well, and as a manager these are the kinds of things you can and should start having your team replace you on if they're up for it.
And then of course, some of your ICs likely do want to transition to the manager path. So you can involve them in hiring conversations, phone screens, conversations about team mandate/goals, team structure and head count, etc.
Article seems to omit one of the big issues I had with being an engineering manager and that was managing budgets (people/assets) and financial forecasts. I'll probably become a manager again, but I'm enjoying my break and doing "real work" again.
+1 - I had a discussion with one of my directs today as they were considering becoming an SDM. There are so many days as a manager where every moment of my time is filled with meetings and admin tasks and at the end of the day you feel like to accomplished nothing. Where as with coding you can feel like you built something and have something to show for your hours of time. I certainly miss being an IC, more and more each day..
You might individually feel like you've done nothing, but if tending to admin tasks enables your ICs to just focus on getting work done --without distraction-- you're actually a multiplying force within your organization.
This and also keep in mind that as mid mgr you become an IC to the business side of things, with its share of BS and politics. Now tell me, which one is "your team"... Mid mgr is not that much a position of power, more like a promise of decision control, but bureaucratic admin reality and twice expectations to meet.
Oh, well, there's some bright side to it too, it's all about the ppl sharing common goals, even if just for limited time. It can bring positive change.
I shifted from software engineering to technical program management because I was interested in the bigger picture of shipping software (after having been an engineer on a couple multi-year projects that floundered and failed due to mismanagement), but did not want to be personally responsible for hiring and firing people. I don’t have the constitution to make such big decisions impacting other people’s lives. :\
Dunno, but as a dev lead, onboarding new devs is huge - easing them into the project, make sure they get to do challenging work but aren't stressed too heavily or beyond their capacity, etc. Huge time commitment just to write clean, understandable stories for them to work while they are new.
>"Like if I were in his shoe, this is how I would treat myself."
This is a very healthy way to think about things as a manager. I like knowing why I have to do a task, to have the chance to give feedback, and to get leeway to push for what I think is best. I try every day to support those things for my team.
Growth is the greatest result of pain. I would especially listen to someone who learned lessons after having been burned themselves. I would take that over an armchair who was paid to write an article. Authenticity is an extremely valuable human resource.
I mean that overall they may be good takeaways, but managers don't do these things intentionally. They do it because they are trying to hold on to the other pressures of the job (meetings).
The management role is challenging and has affected me to the part where I go on continuous daily walks, thinking about what to do next. I mess up and have broken down on numerous occasions about tackling challenging topics that play out for both the business and the individual in contra. I still care.
Some things I missed doing well: Being a shield. Do this more. But more importantly to me: to leave engineers better than I find them. Ratcheting is the metaphor. I understand that I'm always asking for more.
It's a lot of meta and reflection while the delivering is or isn't happening.
Something which bothers me deeply is the disconnection between the fetishism of management which is the most apparent on this website and the endless misery caused by the outcomes of 20th and 21st century corporate culture.
In most western developed countries (and most recently developing countries too) depression and anxiety is shooting off the roof in every possible survey and study (yes, that can be attributed to social media and others too). According to OECD data the 25% of the working age population of those countries struggle with mental health problems. That's about 166 million people.
If everyone believes that good management is possible and just the matter of willpower, while the numbers all point towards the opposite direction then we're doomed. Too many people are indoctrinated.
Setting hard boundaries is completely absent from software management and so essential to productivity and job satisfaction. In the military we call this staying in your lane or knowing your left and right limits.
This concept is often easily achievable through automation by removing the flexibility to allow knowingly bad practices. Such techniques are code validation rules, interfaces, method removal/redefinition and so forth. It provides a clear sense of direction by removing distractions and bad conveniences as passable options.
The concept also sets hard business limits on what work a team performs without intermingling in the responsibilities of other teams.
I am amazed at how absent this concept is to software given that it is so foundational to project management.
How do you stay current on tech when you're doing mostly crap work and umbrella-ing and project managing, and your people are doing all the juicy innovative stuff?
That's my current struggle. I'm leaning on doing work for myself on the weekend and evenings, which will be brutal.
I am not an manager, and this is something that puzzles me too. For an engineer to respect his manager, you expect the manager to be technically competent and in tune with recent technological developments. But as a manger you are most likely to be bit removed from technological changes given that most of the time is spent in meetings, talking, keeping people engaged etc. A few things I can think of but I don't know how effective they could be:
* keep reading technical books, well-known/reputed engineering blogs with the intent of not understanding everything but atlas to get a gist of the technology changes
* be engaged and attend some of the technical discussion meetings (not as an enforcer of some decision) but mostly as a keen observer.
E. Kalliamvakou, C. Bird, T. Zimmermann, A. Begel, R. DeLine and D. M. German, "What Makes a Great Manager of Software Engineers?," in IEEE Transactions on Software Engineering, vol. 45, no. 1, pp. 87-106, 1 Jan. 2019, doi: 10.1109/TSE.2017.2768368.
> We conducted a mixed methods empirical study of software engineering management at Microsoft to investigate what manager attributes developers and engineering managers perceive important and why.
Turns out that engineers want their managers more technical and less inspirational. This is different for sales or marketing managers, for example, so if these transfer it might turn out well.
As someone who's spent a lot of time coaching new EMs, I agree with these bullet points. The thing that makes me sad is that this is only correct if the EM's director agrees with it. The true bullet point of what is expected of an EM: whatever the EM's boss expects.
I'm currently writing down a lot of the management lessons and coaching I usually give new directors as they learn their craft. It's mostly for my own sanity during startup building, since I miss coaching, but thinking of publishing it. There's a lot of EM guidance out there, but it's lacking for directors.
An ability for (which primarily derives from an actual interest in) actually solving -- as opposed to masking / deflecting / re-routing / siloizing -- so-called "communication issues" within and across teams.
Essentially a subset of "being a crap shield" as another commenter mentioned.
Personally I would prefer that the manager is someone who is an active engineer on the project. And I know that is challenging and won't work in a lot of organizations.
But before you dismiss the idea, look at open source projects like Linux, the D programming language, or Nim.
Is the engineering manager expect to proactively find work for their team? Are they responsible to keep the work pipeline full for the next upcoming cycles?
This is a product/project management responsibility, and in some organizations or teams some or all of this can fall on the engineering manager side. Doing a lot of both at the same time is typically a crummy gig, as you don't have time to do both successfully for a right-sized team (you'll be either a bad manager, a bad product manager, or mediocre at both), Uou'll either be overworked or feel bad at your gig all the time.
Helping the team proactively scope and prioritize technical debt work, as opposed to product work, is almost always a critical function of managers.
I would say yes on two counts, one for his/her own growth/benefit and other for the team's benefit.
If there is more work in the pipeline it keeps the team less worried about what are the future
tasks they can focus on, and this becomes especially important if the company is going through
a rough phase. In addition additional work also gives opportunity for the team members to
work across different projects and rotate people who are driven and want to work on different
projects/technologies a chance, and to retain them. Naturaally, when the team benefits and
succeeds it helps the manager and improves his standing in the organiaztion.
However the ugly side of this is office politics, where some managers continuously try to expand
their turf undercutting other teams so that they manage bigger teams and reap rewards.
(say a bigger title).
anyone use anything besides the usual suite of software (google docs, slack, JIRA, etc.) to assist with management? When I was a line manager, I felt like there was a lack of tools for engineering managers...
>> Dealing with underperformance/letting people go is a tough subject (which I don't have much experience): I highly recommend asking your HR Business Partner and your manager to help with that.
Yet another article written by someone without the requisite experience to be opining on the topic at hand.
HR tends to know nothing about solving "performance issues" -- especially since by and large, they tend to have next-to-zilch understanding of what the day-to-day work is actually about - let alone what constitutes good or bad "performance". So from there - their role pretty much boils down to:
"OK, so you've decided to start pushing this person out of the company's bowels. Let's make sure we do with with proper legal CYA and minimal side effects, otherwise. In fact we have system in place already - it's called PIP:"
"Ya see, you just gotta make up some quote-unquote 'goals' for the problem employee to 'agree to'. And then of course, don't actually support them (and just for fun, sometimes outright block them - subtly, of course) from reaching them. Whether they quit and/or have a nervous breakdown -- or inevitably fail at achieving the 'goals' we set out for them -- either way, in a month or two they'll be toast -- guaranteed."
The very essence of being a good manager, then -- is helping to resolve (or at least clarify) performance issues before they get "escalated" to that level (which is an ironic term, given that again, it pretty much always boils down to -- "how do we get rid of this person?")
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.