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.
A few changes you could try: - have the developers make their own estimates - instead of explaining all relevant existing code, only point to where the relevant parts are or what terms to search for) - if there is a designer involved in the features, try to get them better at making specifications, so developers can work directly with the designer instead of having you in between doing 'translation'
1) Do they not propose tasks for bug fixes and refactors?
2) Are engineers encouraged to propose their own solutions?
3) Do you only assign tasks you know how to do yourself?
2. I am certainly listening to any suggestions, but don't necessarily actively encourage it before proposing a solution. Perhaps this is a direction I need to move towards.
3. Mostly yes, as overwhelming part of the complexity just comes from knowing how various parts of the system interact. From time we have an open-ended 'research' (where the outcome is not known upfront) project, but these have a very mixed success rate and tend to overextend the time budget.
I'd recommend looking into why the ramp up time is so long.
Especially if you only assign tasks you know how to do, you are likely hampering your systems ability to become simpler.
For example, recently we took away 1000s of lines of nuanced code by using an out of the box cloud service (which none of us knew how to use). It offers a similar interface, and it's cheaper and easier to use. Took a week to play around and research if something else was more appropriate, took another three weeks, and we deleted 10% of our code.
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.
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.