5 ms·
I would like to get a bit of HN feedback on the matter. I am exactly the person mentioned here - an engineer who knows nothing about the management, but because
by jrx 9y ago
I would like to get a bit of HN feedback on the matter. I am exactly the person mentioned here - an engineer who knows nothing about the management, but because company is growing and we're hiring new people I'm slowly transitioning towards a management position. Just like you've stated I know nothing about the management and all I have is a common sense to guide me which I'm afraid is not enough on multiple occasions.
I'm especially afraid of too much micromanagement, but I don't really know how to handle the process better. Here is my style of management, briefly summarized:
I have a very deep and detailed knowledge of all of our codebase, which is in it's entirety shared by noone else at the company. I've written half of it myself and the other half has been written by other people. Most of our hires have been hired between a year and few months ago (company is very young by itself).
What is the usual process for me is that I discuss the general direction and required features with top-level management, who is entirely nontechnical and make a roadmap in my head with plans for the "subprojects" which are more or less self-contained units of work, their time estimates and relative priorities with respect to company-wide deadlines.
Based on the last two, I dispatch the tasks to relevant people, waiting when they finish previous tasks. I try not to stress people with too many tasks at once, but treat "tasks" more like a priority queue, where when a person becomes available a current highest-priority task is taken out from a queue and assigned to a person, taking into account personal technical strengths and weaknesses as well.
Most of the time, when giving a task to a person, I already have solution implemented "in my head" and the process mostly revolves around me explaining the relevant part of the codebase to a person and detailing the solution I've envisioned with special emphasis on the parts where a mistake is more likely to be made. After the implementation is done, I take part in testing and perform a code review before merging the code in the production branch.
Sometimes I wish I would give people more freedom, but on the other hand maintaining project coherency and keeping a single direction for the whole team I feel requires for me to make final decisions quite often. I plan to hand off ownership of certain "modules" in some time in the future, but first I'm waiting for deeper understanding of the codebase to develop in the reports.
On the outside, to me, it seems that the process works. People are not complaining, team makes progress, features are done on time and seem to be of satisfactory quality. But like you can read above, I'm base strongly on detailed technical knowledge and basically "planning the work ahead" for the people.
I would really appreciate if anyone could share their experience with making that transition.
- k4rel 9y agoI would suggest to you that perhaps a good place to go from where you are is to start getting input into your solution from your new team mates. This allows you space to guage their quality, and make them feel like their input is important, as time moves on, you will then be able to understand where the good people lie, and hopefully allow you to give them more control. This is the kind of thing that will probably lead to your team being able to grow and feel empowered, and hopefully mean that you can take more time to carry out more managerial responsibility, and give you trust in your team. A secondary advantage is that you let go of being the some holder of all knowledge, which could burn you out in the long term. Also, perhaps allow code reviews in both directions, as it means that you can see how your input had made them look at other people's code and choices, hopefully giving your business the ability to self manage and to ensure that practises are followed consistently, even if your eye is not on the ball at all times. This kind of thing had helped me make the transition, although I have to admit that taking my eye of the ball sometimes for too long has led to bad code in our projects and codebase. But that's where you go back and share that with your team, and those that may need greater support. Just remember you are one person, so don't expect to carry out all the work by yourself, empower those around you and give them greater fulfillment over time.
- jrx 9y agoThank you very much for sharing. I can see quite a few very valuable suggestions here. I'll try incorporating that in my way.
- mratzloff 9y agoI gather those who report to you are on the junior side?
- jrx 9y agoJunior to mid-level.
- mratzloff 9y agoWell, the real answer is years of on-the-job experience, but to give you a super-brief version: It's a common pattern that new managers want to treat direct reports as a set of extra hands. That's fine for the purpose of getting code out the door when developers are junior, but it's irritating at mid to senior level, and it doesn't help anyone grow or think for themselves. Your job is to train them to do those things. Ask questions. Wait for the answers. Then ask follow-up questions to help them identify problems with their solutions. Self-discovery is more powerful than being told the answer. Think about their career growth. Ask them about what areas they want to grow in and then try to give them those things. Fill in the gaps on the team. Let others fill the gaps where they can.