|
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. |