Ask HN: Advice for newly promoted engineering manager?
I have joined a series A funded startup 4-6 months back. I have more than 10 years of experience as an engineer. The title I got here is engineering manager, and I am leading/managing a team of 10 engineers. I don't know what it means. I have been part of very small startups in the past and didn't have any mentors. I can code and help my team towards better practices, but I guess that's the job of lead engineers.
It would be really helpful if you can guide me on what is expected from this role and what else should I do. I love this team and I want to help them, but I don't know how and being a typical startup, right now the focus is more on feature development rather than the quality of the features.
2 comments
* Don’t let the children run the daycare.
* Set minimal standards. If people want to whine about that shut it down. If people want to threaten to leave then point them to the door.
* Measure things. Don’t guess. You will never know how slow or under performing your product/team/whatever is without numbers. Use that as evidence to protect your team.
* Protect your people from your boss and be very candid with your people. This is how you build trust and trust is the center of a strong team.
* Have clear goals.
* Build a love of writing. If you cannot communicate in writing you are not a real leader.
* Encourage automation and strong foundations. Most corporate software is shitty because untrained people are busy checking administrative boxes instead of writing software.
* Actually write software (your team). I know there are aggressive timelines and budgets and so forth, but you need to write original software. If your team expects to outsource everything to frameworks and third party packages your software will be shit and then you and each of your developers are fully disposable.
* Set minimal standards. If people want to whine about that shut it down. If people want to threaten to leave then point them to the door.
* Measure things. Don’t guess. You will never know how slow or under performing your product/team/whatever is without numbers. Use that as evidence to protect your team.
* Protect your people from your boss and be very candid with your people. This is how you build trust and trust is the center of a strong team.
* Have clear goals.
* Build a love of writing. If you cannot communicate in writing you are not a real leader.
* Encourage automation and strong foundations. Most corporate software is shitty because untrained people are busy checking administrative boxes instead of writing software.
* Actually write software (your team). I know there are aggressive timelines and budgets and so forth, but you need to write original software. If your team expects to outsource everything to frameworks and third party packages your software will be shit and then you and each of your developers are fully disposable.
Your role is to manage engineers. That sounds very simple, but let's break it down.
Starting with the term "management". The best definition I ever received was "management is getting things done through people". This is slightly distinct from "leadership", which is "influencing the way others think". One can lead without managerial skill, but its difficult to manage without leadership attributes.
There are therefore 2 parts to this role title:
(1) identify the "things", that need to be done. This will be different in almost every organisation, so it's difficult to provide a playbook here. But ensure it's crystal clear between you and your own management. Typically it will be some form of "ship features" and "report on progress". But do not be fooled: there is a long laundry list of "unsaid expectations" that you'll simply need to learn over time (recruitment, planning roadmaps, managing performance, foreseeing and eliminating all sorts of risks such as scheduling and resourcing risk). Be kind to yourself. You will be blindsided by things you weren't aware of. KEEP A BUFFER of time to allow yourself to be responsive. Slice up all the "things" and understand what needs more definition, what can be delegated, and what cannot. Get very good at managing others' expectations when things aren't going according to plan.
(2) Get it done "through people" (your team). It's up to you to set up the right structures, communication lines, to get your team working effectively. But the "right way" is completely dependent on what you discover in (1). Feel free to pick (start with) one or more of the many software development approaches on offer (SCRUM, Kanban, etc) and tailor as you go along. Whatever you pick, recognise that it will need to evolve over time.
Now this is a controversial point: I'd recommend to keep your hands dirty, without being on the critical path to delivery. But, be sensible and recognise what's possible within the boundaries of your available time. You won't be re-writing the company's caching layer single-handedly. But you might choose to fix a small bug.
Rationale here is 3-fold: firstly, it's a good break from some of the mundane "manager" stuff (you built that buffer time in, right?). Secondly, it's sometimes much easier than prescribing every fine detail of what you're require people to follow. As a personal example, I delivered a small module for which I included integration test evidence, so engineers could see/understand what I was asking for in the test evidence. Finally, your engineers will actually respect the rules/advice you're giving them, because you're fighting alongside them in the trenches, not "shouting out orders over radio".
Hope this helps.
Starting with the term "management". The best definition I ever received was "management is getting things done through people". This is slightly distinct from "leadership", which is "influencing the way others think". One can lead without managerial skill, but its difficult to manage without leadership attributes.
There are therefore 2 parts to this role title:
(1) identify the "things", that need to be done. This will be different in almost every organisation, so it's difficult to provide a playbook here. But ensure it's crystal clear between you and your own management. Typically it will be some form of "ship features" and "report on progress". But do not be fooled: there is a long laundry list of "unsaid expectations" that you'll simply need to learn over time (recruitment, planning roadmaps, managing performance, foreseeing and eliminating all sorts of risks such as scheduling and resourcing risk). Be kind to yourself. You will be blindsided by things you weren't aware of. KEEP A BUFFER of time to allow yourself to be responsive. Slice up all the "things" and understand what needs more definition, what can be delegated, and what cannot. Get very good at managing others' expectations when things aren't going according to plan.
(2) Get it done "through people" (your team). It's up to you to set up the right structures, communication lines, to get your team working effectively. But the "right way" is completely dependent on what you discover in (1). Feel free to pick (start with) one or more of the many software development approaches on offer (SCRUM, Kanban, etc) and tailor as you go along. Whatever you pick, recognise that it will need to evolve over time.
Now this is a controversial point: I'd recommend to keep your hands dirty, without being on the critical path to delivery. But, be sensible and recognise what's possible within the boundaries of your available time. You won't be re-writing the company's caching layer single-handedly. But you might choose to fix a small bug.
Rationale here is 3-fold: firstly, it's a good break from some of the mundane "manager" stuff (you built that buffer time in, right?). Secondly, it's sometimes much easier than prescribing every fine detail of what you're require people to follow. As a personal example, I delivered a small module for which I included integration test evidence, so engineers could see/understand what I was asking for in the test evidence. Finally, your engineers will actually respect the rules/advice you're giving them, because you're fighting alongside them in the trenches, not "shouting out orders over radio".
Hope this helps.