Recently I interviewed with a company that had promoted their Senior Dev into a management role.
When a company VP emailed this guy to say a website form wasn't working, costing the company tends of thousands of dollars every day it was down, his response was, "Thank you for alerting me to this situation. I will process your request and respond within 2 business weeks."
Obviously, they'd taught him that boilerplate to help him adjust to interfacing with the business, but he lacked the common sense to realize the house was on fire.
They also said he preferred honing his coding skills and being perceived as a 'master developer' but couldn't quickly produce a list of in-flight projects, and that things were way behind schedule.
Having a bad manager who's a business type does not mean you don't need managers or all business types are bad managers. I mean, what's the sample size you're working off of? Less than 10?
I know it's unpopular on HN and elsewhere to stick up for business types at the perceived expense of engineers but managing people is a very hard thing to do, and the skills that make a great engineer too often make for bad middle-management, IMHO.
I’ve seen so many programmers put in positions of authority that were just disasters because many programmers are used to having full control of a system.
The transition usually boils down to people who believe in rigid control vs people who believe in tuning the environment to help others be more effective.
Rigid controllers are generally terrible managers. Environment tuners are essentially trying to serve other employees and the business by making it easier to do their jobs.
> Management is not a promotion. It is a career change.
http://fractio.nl/2014/09/19/not-a-promotion-a-career-change...
Want to watch an Engineering team go from: can produce and deliver to doesn't have a clue? Just get yourself a couple of these jokers to be your Engineering teams management.
I've seen that work incredibly well when the manager in question did keep up on his technical skills.
It can result in a very well designed and consistent system.
It also burned out the dev manager in question after two and a half years.
A strong talented leader can make a huge difference. Applying the lessons of the past means a lot of engineering mistakes can be avoided.
Also, at some point, decisions do have to be made. There will be a disagreement on the team about a direction to take, and having a benevolent dictatorship becomes very useful. Especially in a corporate setting where forking and doing both paths can be disastrous (both paths get underfunded and fail), or just not viable.
As for younger developers, I manage several right now. Showing them that a management role isn't about "bossing people around for the sake of it," but more about handling different areas of responsibility needed for projects to succeed - some technical, some not - really works.
In a reasonably varied group of 6-8 engineers, one in the course of his career will have both desire and aptitude for management.
Probably even more than one.
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.
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.
In my experience as a developer at a bunch of different companies, the worst managers have actually been the opposite -- they were ex-engineers who knew nothing about management and decided to become managers for the wrong reasons (small raise, more power, etc), and had no passion for management. The longer one's career, the more one comes to respect managers, I think, and understand what a skill it is unto itself. Many young engineers have times when they feel hostile towards management or even the idea of having a "boss" at all, but that just makes the situation worse. One needs to have a more collaborative attitude to succeed. Again, it's the ex-engineers who think managements is just "common sense" are the ones you need to steer clear of.