26 Tips to Become a Better Engineering Manager
Published on Apr 23, 2026, filed under management. (Share this post, e.g., on Mastodon or on Bluesky.)
In Engineering Management ×12 I once shared 12 tenets for engineering management. In this post, I’m sharing a few more ideas, in a shorter format. As my focus is elsewhere right now—developing new tools and writing new books—, allow me to be brief, and understand any cross-post repetition as emphasis:
Organize yourself. “Organization is not everything, but without organization, everything is nothing.” As EMs, we cannot afford to be disorganized. I doubt it is for you, but if this is still challenging at times, I recommend reading or listening to a classic: Getting Things Done by David Allen. I believe the system he proposes is invaluable to make your own.
Attend team events. It may sound obvious, but I know EMs who for good or for bad reasons don’t attend (all) team events. Always go, unless there’s a fire elsewhere. Attending helps team cohesion and a strong connection.
Have weekly 1:1s. It’s tempting to go for meetings every 2, 3, or even 4 weeks, but even when you run several teams, I believe in the value of weekly meetings. It’s okay to keep them short or to bilaterally cancel them at times, but the point is to emphasize the relationship and to demonstrate availability.
Prepare meetings, even if briefly. In our work in which relationships are key and in which we live on a manager schedule, preparation is paramount. What I like to do is, every morning, go through my calendar and prepare agendas and talking points for each meeting. If the point of the meeting is unclear or there’s nothing to discuss, I clarify; for all other meetings, the notes make sure to always hit the ground running and to use the time well (unless deliberately used casually).
Align. A good part of EM work is alignment, which is to ensure everyone is working towards the same goals. Alignment requires translation, which requires interaction, which requires building relationships. (Here we can tell the point of all the meetings.) What I understand as “aligning” is the deliberate aim of making sure to understand stakeholders and to confirm understanding by the team(s).
Take notes on accomplishments. Every day, our teams create value. When we know a team very well, we may have a good understanding of that value, especially as it relates to milestones and accomplishments. But no matter how well we know the respective team, it’s important not to leave our knowledge of accomplishments up to chance—taking notes on them makes it easier for us to hand out compliments and bonuses and to support promotions. I’d go as far as saying that you owe it to your teams—and perhaps all colleagues!—to take notes on work well done.
Give room to fail. We don’t like failing and we like it even less if failure falls back on us through our teams. But here’s the thing: We need to allow to fail. Only this way can we identify gaps, gaps that we can then address adequately. Only this way can we also stay sane—constantly trying to prevent others from failing or, worse, covering up failures is extremely tiring and costly. It leads to micro-management and it leads to stress. Allow people to fail. Then, help them up.
Use icebreakers. Some dislike them, I believe they’re useful—icebreakers. They’re not only useful when starting somewhere or when welcoming new peers, they can also lighten the mood in other group settings. I maintain a short list of icebreakers, and believe them to be a useful tool in every EM’s (and perhaps any role’s!) repertoire.
Hire juniors. Hiring of juniors was 60% down, said a YouTube video heading I saw the other day. I didn’t check the video or the number because whatever it is, the number is going to be too high. For a good team dynamic, for career perspectives for your senior staff, for avoiding issues with seniority, for taking responsibility for our field you want to work with juniors.
Coach. If someone struggles, get them coaching—or coach them. From what I’ve seen it’s very easy to miss this entirely, easy to order coaching, and not at all easy to provide the coaching yourself. Keep an eye on what you can teach yourself.
Coach before you fire. Do not just fire people. Everyone can do that—qualification-wise, you don’t need to be a manager for that. As a manager, your goal is to make people better and form a strong team with your people. I know, this goes against many business schools and will not always work, for both people and business reasons. But the idea is important: Invest in your team(s) and if there is an issue, work with them, coach them, try to give them time, and only if everything fails, fire.
But if you must, fire early. If it’s clear that you can’t keep a person on—say, it’s necessary to part ways from a business perspective—, then don’t play a game. Be empathetic, be generous, but do proceed.
Share responsibility. It’s a manager anti-pattern to do everything ourselves. But even if we delegate well, we may still be reluctant to share or delegate full responsibility. I believe that’s a mistake, in that we end up as reluctant to allow our teams to grow. Make sure to delegate responsibility with the work.
Make what’s important to your team members, important to you. Any problem your team has, you have. This is not to suggest paternalistic micro-management in response, as a way of detecting and solving problems, but to encourage feeling out problems and ensuring they’re being handled.
Regularly review and adjust compensation. As managers, we’re representing the business. But whether you look at this from an altruistic angle or from an egotistic angle, we’re also responsible for our people. Now, the people in our teams do not only care about money. But fair pay is relevant to everyone. Ensure it is fair—across genders, across the company, across the market. Check this not only during performance cycles—but when you come in, and when this hasn’t happened for some time.
Look beyond salary. People aren’t exclusively driven by compensation. Understand what your team members are driven by—how big of a role does the salary play? How about free time (PTO)? Title? Other forms of recognition? This is invaluable to know because it can lead to packages that are good for everyone. (If you wonder where I got this from, I learned it in Getting More, one of my favorite books.)
Regularly give feedback. Feedback—and I mean predominantly constructive and positive feedback here—shouldn’t just be shared in a performance cycle, once a year, whenever. It should be shared frequently. It’s useful to take notes and to bring feedback up in 1:1s. This is hard though, and one reason why it’s useful to take notes.
Regularly ask for feedback. Also ask for feedback (grant people time for this, as few people can share meaningful feedback on the spot). I believe it’s useful to do this “360°,” too—ask your team members, ask your manager, ask other peers. People aren’t used to this so you may get puzzled looks (and well no feedback), but try!
Trust. “The way to make men trustworthy is to trust them,” I learned in a book (sleeper effect—on searching, this seems attributed to Henry L. Stimson). Believe in this, rather than “trust needing to be earned.”
Get a mentor. Regardless of whether your company pays for one or not, get a mentor—someone in a similar role as yours who is more experienced than you are. Regularly meet with them to discuss your work—come prepared. (This is super-short, but I warned about running through this 😉)
Throw books at it. Regardless of whether you have a mentor, stay sharp and keep learning. Now this point isn’t literal—maybe you prefer throwing excellent videos or courses at things—, but for both our technical and our people work, and for any challenge around this work, stay curious, and dive into the topic. For me, as a reader, I do throw books at things (and if you like to learn how I do that, I’ve shared tips on how to read more and read faster in the past).
Be googley (like, 2000s googley). I’ve produced one of the most popular definitions of what “googliness” means (cf. Business Insider), because I was lucky enough to work at Google at a time when googliness was alive and when Google was full of fantastic Googlers. Be 2000s googley, and ship great work with a keen eye for both your users and your peers.
Be transparent. Keep open documents and make your calendar internally visible. Share what you’re thinking, doing, planning. (Exceptions prove the rule.) Transparency builds trust, transparency fosters fairness, transparency enables initiative. Be as transparent as you can.
Respond. Don’t let people wait if they need something from you—regardless how tiny the request, regardless who it is. Responding includes delegating, so this isn’t a call to do everything yourself. Looping someone in who can help is a beautifully… googley thing to do.
Give room to ask questions and raise concerns. Make it possible and safe to learn more and to be critical. This doesn’t need to be public—but it does need some communication, that is, you will need to let people know how they can follow up with you. Bonus: Provide some anonymous options as well, like an anonymous feedback form, providing a channel for those who prefer to be cautious.
Ask performance- and stay-related questions. Every 4–6 weeks, ask specific questions geared at ensuring people are set up for success. This goes from ensuring people have what they need, that people’s talents are being used, and checking on people’s burnout status. I’ve written about my set of questions and the wider context: Performance and Stay Questions in 1:1s.
Here I’ll stop—there absolutely is more to our work as EMs (that’s why there’s need for more training), and I wouldn’t be surprised if I missed a forest for some trees. If you wrote something similar or write something else in response, let me know so that I can learn from it—or share it (here or on Frontend Dogma)!
About Me
I’m Jens (long: Jens Oliver Meiert), and I’m an engineering lead, guerrilla philosopher, and indie publisher. I’ve worked as a technical lead and engineering manager for companies you use every day (like Google) and companies you’ve never heard of, I’m an occasional contributor to web standards (like HTML, CSS, WCAG), and I write and review books for O’Reilly and Frontend Dogma.
I love trying things, not only in web development and engineering management, but also with respect to politics and philosophy. Here on meiert.com I talk about some of my experiences and perspectives. (Please share feedback: Interpret charitably, but do be critical.)