Hello, new engineering manager! Have you recently stepped into the role from a developer position? Here are 6 tips that helped me in my first 2 years as a manager.
1. Keep a decision log
Originally, this was going to be, “Write everything down,” but if you’re not in the habit of keeping notes, at the very least write down the details of important decisions you make.
You’re going to be inundated with information, much of which you need to evaluate before filtering down to your team. It will be easy to forget details. Keep a log of your decisions in a searchable format (Evernote, Workflowy, a text file) for quick retrieval later. Write down the who, what, and why.
Review this log periodically, maybe with a mentor, to evaluate and improve your decision making process. Being able to reconstruct a timeline of your decisions is useful in all sorts of project and personel situations.
2. Stop coding
This is dependent on your team size, but if you have a team of 4-8 developers, you shouldn’t have bandwidth to write meaningful or critical code, at least not at first.
This may be hard to avoid. When it gets stressful, your first instinct may be to put your headphones on and go back to the comfort of writing code. Stay vigilant to this impulse and avoid putting yourself in the critical path of development. If you start dev work, it’ll need to be tested, reviewed, monitored, and you now have stakeholders, roadmaps, and a team of developers to care for.
3. Embrace processes
If your team is large enough that it needs an engineering manager, it’s large enough to need well defined processes.
You may get lucky and serve a team that operates like a well-oiled machine. If not, embrace the challenge to formalize a set of low-overhead process around your release schedule, development process, and work prioritization. Teams work best when there are well defined boundaries and agreements on how things are done and communicated.
If your organization allows, don’t be afraid to experiment. Observe how the team works and make tweaks with their input. Processes should be ever-evolving, just like code.
4. Block your calendar
Your time is the most valuable thing you have. If you don’t prioritize time to focus on the team or yourself, it will be prioritized for you by others.
At the very least, block out time on your calendar for the following, as allowed:
- “Weekly Plan”
- When: Monday morning
- Duration: 15 min
- Agenda: Write down the top 3 things to accomplish this week.
- “Weekly Review”
- When: Friday afternoon
- Duration: 30 min
- Agenda: Answer the following:
- Did you accomplish everything? If not, why?
- Who deserves kudos and what for?
- What can folks improve?
- What key decisions did you make?
- “Learning block”
- When: Any time
- Duration: 1+ hours
- Agenda: Read, think, improve yourself.
5. Eliminate distractions
With slight variations, your job will now consist of advising, making decisions, and sharing information.
To facilitate information sharing, get good at absorbing, storing, filtering, and retrieving that info. One way to improve on all fronts is by eliminating distractions. Leave unnecessary channels on Slack and customize notifications. Filter your email inbox ruthlessly. Turn off phone app notifications.
Establish boundaries and communicate those frequently (e.g., “Please file a JIRA ticket for all work requests,” or “I respond best by email/DM/in-person/etc.").
Your ability to do this may depend on your team/company culture. Strive for a high signal-to-noise ratio.
6. Learn how to say no
I’m convinced that being able to say no effectively is a manager’s most powerful tool.
Learn to say no in a way that’s appropriate for your company culture. When asked to take on work that shifts your teams roadmap, introduces scope creep, or threatens retention, a direct, “No, we can’t do that right now,” may work. Or, “I don’t want to promise you something we can’t deliver, let me discuss with the team and I’ll get back to you.”
Ultimately, this is going to depend on the culture, the ask being made, and the circumstances – but in general, it seems to me that the most successful teams I’ve worked on have been those with managers that default to no, only saying yes when it’s undeniably the right choice.
7. Underpromise, overdeliver
The inverse of this is: don’t overcommit yourself in the rush to please everyone. If you think you can deliver 7 tips, tell them you’ll give them 6 and then surprise them. :)
In your first couple of months as an EM, you should stive to build your reliability. In order to do this, you should have a high say/do ratio. It will be very tempting to overpromise. Don’t do this. Protect your time. Protect your team’s time. Get on your feet and establish credibility at the same time.