Why things just work around some EMs
20 questions to check if you're actually proactive
Most engineering managers wait for things to happen.
They wait for priorities. Wait for PMs. Wait for the roadmap, the designers, the feedback. Wait for problems to blow up.
The top 1% don’t wait.
They see what needs to happen and make it happen, even when it’s not their job. Actually, especially when it’s not their job.
Want to know if you’re one of them?
Here are 20 simple questions to ask yourself:
Do you fight for your team’s raises even in tough times, or just pass down what leadership says?
Do you give your manager action items in your 1:1, or just answer their questions?
Are you actively participating in non-engineering Slack channels, or assume it’s all noise?
Do you chase feedback from your team and peers, or hope they’ll tell you something in the next performance review?
Do you have strong relationships with stakeholders in various departments, or only talk with your engineers?
Do you push HR for better team activity budgets, or just do the minimum?
Do you train your engineers to step up, or complain that you don’t have anyone you can delegate to?
Do you actively look for the best candidates to hire, or just look through the CVs the recruiters send you?
Do you push back on unrealistic deadlines early, or only speak up when things are already on fire?
Do you show up to leadership meetings with answers and options, or with updates and problems?
Are you constantly asking PMs and designers to move faster, or does everyone in the org ask you to move faster?
Do you go talk to customers yourself, or just read the notes your PM gives you?
Do you take responsibility for the business results your team delivers, or are you satisfied with a good effort?
Do you fully understand how the company operates and makes money or just talk about engineering velocity?
Do you follow up on action items after meetings, or assume someone else will?
Do you actively shape the roadmap or just execute what the PM tells you?
Do you take ownership of company-wide problems, or do you assume they belong to someone else?
Do you try hard to help your PM understand the tradeoffs, or just silently resent their decisions?
Do you think beyond just engineering and contribute to the long-term company success, or do you just focus on technical debt?
Do you share your team’s wins and progress loudly, or assume leadership will just notice?
Let me know what I missed :)
Inspired by “ultimate employee: the one that is truly proactive” (thanks !)
Discover weekly
How to Avoid the 5 Biggest MVP Mistakes by
. With how easy it became to build an ‘MVP’, Yoskovitz covers how the term has evolved (and how it should continue to evolve).Developers don’t need more documentation by Dennis Pilarinos.
Docs get written, but answers stay hard to find. The problem isn’t the docs themselves. It’s that the context developers need is scattered, outdated, or missing entirely. Why does this keep happening, and what’s the alternative? (sponsored)
To instantly sound more sincere, do this by
. Another gem by Wes - loved the ‘One Extra Line’ rule.- . I really enjoyed reading the story of Yaron Gurovich, Head of AI Research and Applications at Vimeo, who spent three years leading teams while traveling the world with his family.