51–60 of 148 posts
> A good manager is more like a transparent umbrella. They protect the team from unnecessary stress and pressure, but don’t hide reality from them. 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,…
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.
This kind of EM-focused articles often mention "coaching" and "career growth" -- I always wonder what does this concretely mean. Are they all managing teams of juniors straight out of college? 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 experienc…
I guess the "coaching" is to understand that mindset shift.
> A good manager is more like a transparent umbrella. They protect the team from unnecessary stress and pressure, but don’t hide reality from them. 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,…
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 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.
Why do people espouse goals like “not to be needed?” I never understood that. It sounds like LinkedIn virtue signaling. It’s a capitalist talking point along the lines of “I seek to be good and inexpensive capital for my corporate masters.” 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…
“Don’t be needed” isn’t “don’t be valuable.” The EM should not be a bottleneck. The EM should be able to take a vacation without being paged. (So should anybody on the team!) My teams would slow down without me because I can due process tasks more efficiently, but nothing demands me to be in the loop.
> A good manager is more like a transparent umbrella. They protect the team from unnecessary stress and pressure, but don’t hide reality from them. 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,…
Kinda like; You got to do, what you got to do.
> A good manager is more like a transparent umbrella. They protect the team from unnecessary stress and pressure, but don’t hide reality from them. 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,…
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.
>I wondered, “Who is this feature even for? Who will use it?” No one on my team knew. 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…
When I was in the Marines, we had a rule of thumb that every Marine needed to know their own mission and the mission of units two or three echelons above them. So individual Marines needed to know their mission, their platoon's mission and their company's mission. Company commanders needed to know their mission, their battalion's mission and the division's mission. More specifics for echelons closer to you. This is c…
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 kind of EM-focused articles often mention "coaching" and "career growth" -- I always wonder what does this concretely mean. Are they all managing teams of juniors straight out of college? 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 experienc…