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.
There is the expectation that the manager knows who will be distracted. This is a basic part of knowing your people. I know which of my colleagues is going to get distracted without having the level of communication that my manager has. On one extreme, they just forward information knowing a report can work with it. One the other, the manager has to translate and communicate every element.
Ideally, the manager is already working on a way to ensure their report can handle transparency because that means they can work autonomously. You can't have individual contributors lead, if they are going to run into issues as soon as they discover what is going on overhead. They may not understand it yet, but they should have coping and mitigation strategies.
Engineers can be the worst group you could deal with when it comes to overhead conversations when they expect things to be orderly. Your organization is failing when everything has to go through managers and people can't operate independently.
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.
I think this an underrated quality.
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.
If you get stressed about that, imagine finding yourself redundant by close of business today, and job hunting from tomorrow.
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.
- 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?
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)
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.
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.
What engineers usually struggle with as they grow into more senior roles is the transition from being primarily a technologist to being a leader. This is such a huge shift for a lot of engineers and requires soft skills and communication style adjustments. The more senior you are the more your focus shifts from coding to listening, networking, influencing, selling the technical vision, building trust relationships, understanding what other engineers need and want, to mentoring, to raising the quality of the team around you through influence to motivating others as well. Being able to influence the product direction, being able to express in business terms why something has to be done or should be a higher priority etc. Also, understanding the organization and becoming organizationally savvy is important.
All of these skills take time and practice to achieve, and good managers can guide their people through the journey.
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.
I guess the "coaching" is to understand that mindset shift.
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’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.
The opposite seems obvious to me. After all, your manager isn’t writing the code. He’s not your boss because he’s a better coder than you are, but because he’s a better boss.
(If this does not fit your experience, I’d recommend quitting your job as soon as practicable).
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.
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.
The other thing I've seen incredibly less of in software than in uniform is a bias for action at all levels. Combined with understanding the mission, a mentality that "in the absence of being told what to do, I will act." Better to ask forgiveness than permission, etc. etc. So many people in the private sector just wait for the boss to push them around like chess pieces, and I can't understand how they're OK living like that.
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.
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.
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.
>“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.
Very well put
I like the umbrella callout especially, that one took me a few years to really internalize. "Protection" isn't as beneficial as "good stress" is. You don't just protect muscles, you use them in a responsible manner to get stronger. I've started trying to ensure my team gets a lot of "good stress" (so projects that grow careers, develop expertise, etc), while getting some concentrated down time after to rest, reflect and grow (often it manifests as time to fix bugs and just not be the star of the show).
A few examples of things I heavily influenced:
- reduction in investment of time, effort, and cost going to offshore engineering. We’ve reduced bugs and effort from our engineers in coordinating between disparate time zones.
- advocacy of a design system shared between design and dev teams. We now have one.
- reduction in the amount of meetings our devs are expected to attend weekly, increasing time they can spend building
- heavily advocating to reduce number of clicks for our users to get where they need to be, benefit UX greatly
- better defined incident management process
It’s not perfect though, the amount of control I have is still limited, and I am in meetings basically all day sometimes.
While I will say that would have sounded like hell to me a couple of years ago as an IC, I have been able to sway the direction of the company meaningfully in ways that feel ultimately more impactful than what I could have done jamming on some code in the same amount of time. The cost of doing so is a little more stress, but hey I get to do so from the comfort of my home and I’m allowed a good amount of schedule flexibility outside of some specific meetings each day. It’s definitely not for everyone though!
The biggest lesson for me was that your job as a manager is to be the soft power representing the authority of the investors. Everything else you hear about management is people rationalizing their role and figuring out how to tow the line. That's why it's so hard and stressful.
The hardest lesson comes when you're ordered to fire someone from your team. HR has decided to implement a performance rubric and wants to maintain the company's position in the hiring market place as a competitive place to work. You must fire the poorest performing member of your team. Who do you pick?
That's the essence of management. Who do you reward, who do you punish, how do you show that you're towing the line?
Most folks, myself included, are promoted into an EM role. No training. No certifications. If you're lucky you get a few training videos from HR if the company you work for is big enough to have an HR department. As an EM you are now in charge of the careers of the people who work under you.
This is why you get such a high variation in the quality of EMs. Some people are a nightmare to work with. If they get a bad impression of you there's nothing you can do. You're cooked when it comes time for that manager to let someone go. There are no objective metrics. They have to pick someone and they will find the reasons.
I left management because I couldn't handle it. Too stressful.
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.
We absolutely should say that. I was an engineer for 13 years and have now been in Product for 8 years. I work on a highly technical Product team, and it is absolutely an expectation for myself, my peers, and my reports that we should ensure we fully understand our Product, including its software architecture, and have an opinion about it. Engineering ultimately decides the "How", but they cannot do that effectively if Product cannot articulate an opinion about the architecture guided by an understanding of things like expected scale, potential future integration decisions, and other cross-organizational expectations that may not yet be codified. In general, Product should have an educated opinion on anything that is a one-way door, and so should Engineering. It should not be a unilateral decision, and if either party is unable to form an informed opinion, that's an organizational miss.
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.
I was in an interview and asked this, and the interviewer got annoyed and wouldn't give me an answer. It sounds like this sort of experience may be more common than I thought.
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.
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.
> A few times in my career as a developer, I wondered, “Who is this feature even for? Who will use it?” No one on my team knew. We were doing it because we were told to. Morale was low. We felt we were working on things that didn’t matter - and we were. Eventually, our team disbanded, and engineers scattered across other projects.
There's no way they had no idea what it was for. They thought the idea was dumb, and they wanted off a sinking ship.
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.
- Be Risk Aware - know them, quantify them, manage by mitigating or having contingencies
- Don't be Risk Averse - Averse means being avoidant of risks or disinclined, it's safer, but it means risks aren't taken.
- Don't be Risk Paranoid - Protecting against unseen risks wastes time and efforts.
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 was expected to do some programming, and so the "failures" of the team (which were often just normal human limitation) I would deal with by personally doing all the work myself.
Has anyone else experienced this?
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.
Your role is to improve your staff to be better in their jobs. Ignoring the Manager/Engineer caste system, there is a lot general leadership in both roles.
You want your staff to be able to integrate and find information that allows them to make decisions, you don't lose accountability or responsibilty.
There is a big difference between
- "I've looked at the details, and I think we should do X, what do you think?"
and
- "What should we do about this?"
In the former, you can add extra context, and help your report understand details that may have been hidden or unknown to them. In the latter you are allowing your report to shift all the burden to you.
A good manager I had once had the approach of setting guidelines and "just getting out of the way" and I try to follow that, it works well for most people.
Is your goal for the software you write to need constant intervention, or would you say you'd aim for it to run smoothly with few bugs?
The team is akin to a piece of software architecture, only much more complex and comprised (partially) of humans.
You want someone to build that team and then have the team up and running, delivering value. When it breaks, or you want it to do new/different things, you need someone to step in to fix it or change it.
I saw a wonderful interview with a former commander of an aircraft carrier. (https://www.youtube.com/watch?v=b9rGATwZRr0) Rear Admiral Mike "Nasty" Manazir speaks of his main job as being clearing away obstacles that no one underneath him could clear. That's a service that no "self-managing team" can do for itself. A good manager also serves as a focus for the strategy, and deals with conflicts that would otherwise become impasses.
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.
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.
I once had a senior engineer blatantly say: “that means you’re just being lazy, your team should be dependent on you”.
Scary to think that engineer was a manager earlier in his career.
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.
