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.
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..
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:
- 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 CoachI 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.
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.
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.
https://news.ycombinator.com/item?id=18826015
It's quite critical of the position, and perhaps a bit negative, but captures the core strengths an EM needs to be successful
"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.
This article is one-sided.
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.
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.
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.
That's my current struggle. I'm leaning on doing work for myself on the weekend and evenings, which will be brutal.
* 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.> 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.
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.
But before you dismiss the idea, look at open source projects like Linux, the D programming language, or Nim.
Confining your knowledge of how you would do it, in a what/how functional separation is hard.
Time estimation is hard.
Under promise and over deliver is well known and you, the manager will get squeezed on it both sides.
Technical leads and senior engineers, however, seem to add a lot of positive value.
Helping the team proactively scope and prioritize technical debt work, as opposed to product work, is almost always a critical function of managers.
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).
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:"
https://en.wikipedia.org/wiki/Performance_improvement
"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?")