I'm absolutely going to steal this metaphor going forward.
Being a "transparent umbrella" does require knowing the personalities of your reports, some people do get distracted when they think higher-up decisions or unhappiness are going to affect their team. Most people, however, really appreciate the transparency. It helps them feel more in control when they know what is happening around them, and when things do change they can tie it back to something that was said previously.
I was going to highlight this as well, but it is also one of the trickiest parts of the equation, because by definition this inevitably involves a lot of politics and social implications.
What I have learned over the years: let the overall direction, and also the overall competitive pressures, filter down through your umbrella. But shield them from the details and your specific efforts here, unless it is relevant.
Maybe even more important, though - recognize inflection points in your company and your group. How you manage during routine times and during stressful times may well be very different. If they're not, then you have a serious problem.
A "shit umbrella" was a manager who protected the development team from all the politics, blame, and mismanagement coming from above.
A "shit funnel" was a manager who directed all the shit coming down, directly onto the team.
If I know what was going on transparently I am stressed. As an ordinary employee, I don’t need to know everything and therefore don’t need to worry about it.
If you're genuinely stressed with that, talk to your lead about it and they'll find a way to filter a little more while not giving you the feeling of being left out.
There’s a point buried in it that I increasingly come to believe is missed in nearly every single management book and management advice I’ve read. It’s almost there in point 1, but under “don’t have a PM”.
None of these points matter if you’re not creating value for your company. That is the job of a manager - get your team to create value.
I’ve been increasingly disgruntled with most management advice because it overlooks this key point.
I felt like one of the biggest steps back I took in my career was when one of my companies had our management attend training that taught these skills and then the company emphasized these skills repeatedly. Suddenly my career stagnated. I had managed before, I had led before, I had delivered results before. But my growth came grinding to a halt. I was following all of these tips and tricks while overlooking the implicit thing - deliver value.
In many, the same ways, I’ve become wary of any company beliefs, values, or guidelines that aren’t clearly working towards making the company money. They’re really just distractions for the underlying goal.
What can a career EM, or even an engineer-to-EM convert who has been out of the coding game for more than a few years, teach a non-junior engineer on their team?
I understand we can talk and exchange our concrete life experiences, same as I would talk to and listen to any other person, but the word "coaching" implies one party is superior to the other in one very concrete area.
For engineers aiming to move into management or staff engineering, you can assign them a project at the level they aspire to reach and give feedback once they complete it. For example, for an engineer aiming to be an EM, I expect them to lead not only meetings but also all communications related to this project, while I act as their director. Afterwards, I provide feedback.
It doesn't have to be that extensive right away. You can start small, like asking them to lead a roadmap meeting, and then increase responsibilities as they improve. Essentially, create a safe environment for them to grow.
- influencing without authority. Managing up. Leadership.
- getting work prioritized
- providing useful performance feedback (promos etc)
- coaching and giving feedback to early career engineers
- communicating ideas effectively
- developing 1YP+ plans for their areas.
- idk, there are a lot, senior engineers are rarely "complete"
> Getting work prioritized
> Developing 1YP+ plans for their areas
I was a little surprised by your list. Aren't these normally the responsibilities of a team lead or a manager? If I were hired as a senior engineer, I'd expect to be involved in group decisions about cross-cutting technical concerns (architecture, choosing languages and frameworks, the code review process), but changing my team's priorities would fall well outside the job description.
If somebody has the power to tell me what to prioritise, it feels topsy-turvy for them to ask me to tell them what they should tell me to prioritise. At that point, why have a leader at all?
For work coming from outside the team, it’s sort of upto your management chain and team lead to prioritise. But for internally driven work (tech debt reduction, reliability/efficiency improvements etc) often the senior engineer has a better idea of the priorities for their area of expertise.
Prioritisation between the two is often a bit more collaborative and as a senior engineer you have to justify why thing X is super critical (not just propose that thing X needs to be done).
I view the goal of managers + lead as more balancing the various things the team could be doing (especially externally) and the goal of a senior engineer is to be an input to the process for a specific system they know most about.
There is always opportunity for growth in this dimension. For example even the CEO has to build the right skills to convince the board of their priorities.
As an example, I attended a coaching training session and when we broke out in groups I played the coach role. The other individual brought up a concrete issue they were having and I was able to unblock them and I never met that person before. I was their guide even though I had no context (but I have experience mentoring and coaching).
I've been a manager for years and there's a lot outside of raw technical ability that a good coach and mentor can keep you honest on. Rarely will you find someone who's reached full potential or who doesn't want to improve at all (maybe surprisingly based on your comment but I have found seniors to be the most eager to grow)
In practice: Start a note for each engineer you manage. Fred Brooks called this a "career file". Start by writing down things that frustrate them enough to complain about publicly. Add hurdles that come up in their one-on-one. Identify problems you can solve, problems you understand but cannot solve right now and problems you do not understand.
Then put on your PM hat; sort by priority and execute.
I haven't written any production C++ in about 2-3 years and honestly lost track of all the language updates since c++14. But when I explained how the code they write gets translated to assembly and runs on the machines, that's what i felt demystified the large codebases to my younger colleagues.
Same with many other topics - the event loops behind the JavaScript async/await, memory mapped io behind every read/write calls their operating system syscalls, basic data structures/algorithmic complexity behind their DB queries, scenegraphs and graphics APIs behind user interfaces etc... especially when pair programming.
I don't think I'm superior to them in any of these areas. I feel I'm fairly slower than them when writing code in any of these things. I definitely haven't kept up with all the changes in web frameworks or CLI tools or vim plugins. But sharing the behind the scenes knowledge helps them write better code is what i felt.
I break things down into coaching vs training vs mentorship.
Training is when you need to learn a very specific skill from someone that knows more than you. A great example is learning how to drive - it requires training from someone who knows more than you.
Mentorship is when you need to grow more holistically and are learning from someone that is significantly more advanced in your chosen area of study than you. Usually this involves not just technical training, but also a mindset that you wish to learn. Examples of this are apprenticeships or when you seek out a mentor that you think has done well and wish to learn from.
Coaching is when someone may not have more technical skill than you, but is still able to help you improve by probing, prompting, reflecting, or observing. A great example are sport coaches, who are not necessarily more skilled than many of the players they coach.
These are loose and blurry definitions, but I hope it helps frame another perspective on coaching.
Unlike coaches for kids/ novices these folks aren’t necessarily better at the craft.
Yet, they (ideally )have a outside perspective that would improve an individual in their craft.
I’ve got a senior IC who is always hesitant to reach out to non-engineers, so to coach him I’m constantly asking him to reach out directly. It will improve his impact if he does so.
It is not uncommon to end up in situations where there are not clear right answers and developing the techniques as an individual, and as a technical contributor to navigate these well is tricky.
I don't think this is an EM specific function at all though and is just something more experienced people should be doing for their team. I think the EM definitely has a role in making sure people identify that they could benefit from that kind of help and make sure they find it, but doing the actual coaching is optional.
I guess the "coaching" is to understand that mindset shift.
I think there's another key here - Don't assume someone else knows something. If you don't know why something is done some way, find out who does and make sure they do. I've been in so many situations where the organization gets complex - person A is loaned over here or person B is working on project X because team Y needed feature Z. So frequently you'll find out that core assumptions have been made because everyone involved was only half-involved and either kind of assumed someone else was taking care of it, or (more frequently) knows the assumption is wrong but is choosing not to say so for political reasons.
This is complicated by the fact that Marines deploy as MEUs, MEBs and MEFs [1] which aren't "pure" echelons, but it's a rule of thumb and guiding principle more than a hard and fast requirement.
I've ALWAYS been annoyed by engineering organizations that don't think developers at the leaf nodes of the org chart need to know what's going on. Devs may not do anything with the info, but letting people in on what's happening seems to send the message that "management thinks you're important enough to hear what we're working on" and every now and again, individual devs need to make decisions that depend on these more abstract / higher-level goals.
1. https://en.wikipedia.org/wiki/Marine_air%E2%80%93ground_task...
Servant leadership works really well when you have high agency individuals, and can grow high agency individuals. I have definitely been on the other side of that with control freak machiavellian / nearly adversarial leaders as well.
This. Every time I've lead people, IF they were already or were able to become high agency, we were efficient and capable. Control freak managers were usually guilty of what they obsessed over before they became managers. Good workers always leave bad managers in time, which always hurts the company.
>“Oh, but I have a PM for that,” you might say. But having a PM is not enough.
It should be, that's literally their job. Developers and EMs shouldn't be doing that part for them.
In the same way developers need to know how to ifs and loops, Product Managers need to find out which features to build and user pains to fix.
Maybe, just maybe, we need to stop raising the bar for interviewing developers and start raising the bar for the other people working with developers, instead of getting developers to compensate for shortfalls.
The least productive tech companies I worked for in the past decade had a nearly 1:1 ratio of engineers to different manager types. Our teams of 3-4 engineers had to work with our engineering manager, a product manager, a project manager, and a program manager at minimum. If you did UI work you would work with another UI/UX manager.
The minimum timespan to get anything done was measured in quarters. You could expect to have to spend more time scheduling meetings and following up with all your different managers by a factor of 10X or more than time spent doing anything related to code.
Contrast this with another employer I had who was very clear about the fact that we were not a big tech company and we were not going to structure our teams like one. We kept team units small and made them work together as a unit, not a disparate collection of managers that had to be appeased. We shipped a lot and we shipped fast.
We need to stop trying to use complicated and divided management structures everywhere. Companies with small teams and clearly unified management structures will always perform better than the management styles where responsibilities are divided across 5 different people and even basic work requires coordinating all of them through meetings
I’ve never met a sales person as broadly capable as your average engineer.
The curse of competence is organizational as well
Customer relationships are certainly more important in some categories than others but sales is certainly key in a lot of B2B organizations.
It also sounds like he is talking mostly about external projects. For internal projects, you really do serve as a shield. One project, I spent my first months teaching the internal customers that they were not allowed to talk to my people. They had become accustomed to telling individual developers "I want feature X", which cause total chaos.
I stood between the customers and my developers - at the beginning, sometimes literally blocking the office door - and said: my team, my job, you talk to me.
This isn't the first time I hear this, but I always have a bit of trouble with this one. It's one thing to take a step back and think about the actual product and how it'll be used, but I think it's presumptuous to think that software engineers know what makes a product good or not. We don't say "Everyone needs to care about software architecture, even Product", so I'm not sure why we think the flip side of that is true.
For software engineers, our goal isn’t to necessarily know what makes good product or not - but we do need to make sure that what we’re building solves an actual customer problem or need.
These are all things I have seen in my good managers over the years when I had them.
I spent a lot of time also playing a Scrum Master role in addition to my regular duties. So much so that some managers asked me to pursue this full time. I always explained that my goal is to be there just as a point of contact and that the team should be able to manage itself.
Sadly, I see so many managers, scrum masters, or even regular engineers consider this as a dumb approach to make yourself replaceable. If you don't hoard knowledge then you'll be laid off when the company's numbers look bad.
As always the difficulty is in getting people outside your team to realize that the 60% cheerleading bit is crucial, many will see this as a waste of time that doesn't create "business value", as if the only business value was measured in lines of code.
I've seen so many teams treat process as a pure 'fix', ignoring that it's always a trade-off: you are explicitly trading velocity for consistency. Sometimes that trade is worth it (e.g., payments), but often for internal tools, you're just paying a tax for consistency you don't actually need.
If the manager says "They look to you for leadership and clarity", you know something.
It they quote Jeff Bezo, that provides more definition.
The lesson to learn from this article is not the words, but the context. What is the context you find in this article? How does this person talk about other people? What assumptions are inherent in this article? If you find this normal, what does this say about your assumptions?
What I have learned from my years of being an engineering manager is that the corporate model of software development is fubar.
The comment above is just talking about determining whether someone is a good manager. Sure, a basic measure of their actions (which you describe as "context" but I don't think that's what you really mean) is enough. Do they care about the people they manage?
But this article is about how to be a good manager. Assuming you already do care about the people you manage there's a lot more detail to deal with. So yes, the lessons of this article really are in the words. I found it very interesting.
I find myself referring to my contractors as: Workers.
What does that mean about me?
I can't call them employees. I read the communist stuff a while ago and decided I didn't want to be exploited, so I thought this was just the proper terminology.
But people on the internet loath being called a worker and have called me out on this.
Meanwhile I yoyo between to nice and too hard... I think I'm naturally too nice to the point of failure. I seem to only be 'too hard' for a few months before I go back.
Thank god my industry is high demand, I think even with bad management we will survive. (I got a masters in Engineering Management + read 10 books, but management/supervision orthodoxy is diverse and contradictory.)
Because being humble makes you more receptive.
Oh yeah. To be fair, it's not only the case for managers. If a colleague lies to me, they lose my trust. But I have never had that... why would a colleague lie to my face or withhold information? That's a thing bad managers do.
When a manager lies to me (or withhold information), it's never one time only; it's the way they work. And when they work like this, they are not in my team. They play against me, so I play against them.
This bit is useful to everyone, and many people never learn it and get jaded about work itself! They paint themselves into a dilbert strip without realizing. And then of course there's also bad bosses, but any work advice is like relationship advice, it really depends on the specific people involved.
Truer words have never been spoken. Note the OP put the word "Most" in there. Sure... there are a few ping-pong fanatics, but not as many as there are humans who like an emotionally fulfilling work environment.
A related sentence I've uttered is "Most engineers prefer more control over their daily tasks than cash bonuses." But again, the word "Most" is doing a lot of heavy lifting here. My experience is no more than 25% of devs will trade cash for micro-management. YMMV.
Mind you, we have piles of both kinds of PMs: product, project. Best I can tell, they play video games between calls/status updates. Forgot the blur on more than one occasion. Clownshow, myself included.
My goal is to help my team succeed in such a way as to keep my job or else get a better one. Being “not needed” hardly serves that goal.
Look around you. We are in a world that is turning away from middle managers. Don’t play into their hands.
My teams would slow down without me because I can due process tasks more efficiently, but nothing demands me to be in the loop.
If your teams fail to function without your help then you're clearly not supporting them well enough, and you can't take a vacation or go off sick or be promoted. That is not optimal for anyone.