71–80 of 148 posts
Enough already. The way to determine what kind of manager a person is, is to listen for the context they use. For an extreme hypothetical example, if you hear a manager talk about locking their team in their cells every night, you will know something about their context. 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 l…
>The most common reason companies fail is creating products that don’t deliver value to users, causing them not to pay. >“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 a…
I’ve never met a sales person as broadly capable as your average engineer.
The curse of competence is organizational as well
> Everyone needs to care about the Product 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 s…
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.
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 am an EM that manages several senior engineers currently. I find it super common for senior engineers to get promoted mostly on technical merit, we end up thinking the rest "can be coached". Or it's coaching to the next level. Here are some areas I coach them on: - influencing without authority. Managing up. Leadership. - getting work prioritized - providing useful performance feedback (promos etc) - coaching and g…
> 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?
>The most common reason companies fail is creating products that don’t deliver value to users, causing them not to pay. >“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 a…
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.
> Everyone needs to care about the Product 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 s…
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.
> 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,…
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.
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.