6 ms·

> Business types with none to little engineering experience should never, under any circumstances, manage engineers In my experience as a developer at a bunch

> Business types with none to little engineering experience should never, under any circumstances, manage engineers 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.

derptacos 9y ago
Curious if you have any advice for engineer->Dev manager?
zebraflask 9y ago
I'll second that. The worst I've seen have always been engineers or developers who felt that seniority, in terms of years on the job, entitled them to a management role regardless of any ability or training for it. They inevitably engender a tremendous amount of friction and resentment in their peers and subordinates. 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.
scruple 9y ago
In addition to that, it's been my experience that their Engineering skill diminishes over time, like any other skill that isn't getting the maintenance that it requires, and they seem to be largely unaware of that. Despite their now-undersized technical knowledge / capabilities, they can still be found forcing technical decisions against the better judgement of their departments actual technical leadership. I've also had this same style of manager become a rate limiting bottleneck by forcing _all_ cross-team decision making to route through him. We gamed that, of course, because we had to, but it was still tacking days on to "decision making" that we had to suffer through just to do our jobs. 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.
- com2kid 9y ago
  > I've also had this same style of manager become a rate limiting bottleneck by forcing _all_ cross-team decision making to route through him. 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.
- bewo001 9y ago
  I had former-engineer managers, who were the first to acknowledge that their technical skills weren't up to date. It makes a huge difference if you can explain a technical problem to someone who has solid base skills in the field or if you have to dumb it down to layman level.
ordinaryperson 9y ago
Exactly. 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.
- brightball 9y ago
  Totally agree with you on this point. It’s easy til it’s your job. 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.
- flashman 9y ago
  > The biggest misconception engineers have when thinking about moving into management is they think it’s a promotion. > Management is not a promotion. It is a career change. http://fractio.nl/2014/09/19/not-a-promotion-a-career-change/ http://fractio.nl/2014/09/19/not-a-promotion-a-career-change...
  - qntl 9y ago
    “Not a promotion” except that you get more money, respect, influence...
paulddraper 9y ago
While I won't go so far as to say "never, under any circumstances", I don't think you have to choose between engineering and competency though. 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.
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.

derptacos 9y ago

Curious if you have any advice for engineer->Dev manager?

zebraflask 9y ago

I'll second that. The worst I've seen have always been engineers or developers who felt that seniority, in terms of years on the job, entitled them to a management role regardless of any ability or training for it. They inevitably engender a tremendous amount of friction and resentment in their peers and subordinates. 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.

scruple 9y ago

In addition to that, it's been my experience that their Engineering skill diminishes over time, like any other skill that isn't getting the maintenance that it requires, and they seem to be largely unaware of that. Despite their now-undersized technical knowledge / capabilities, they can still be found forcing technical decisions against the better judgement of their departments actual technical leadership. I've also had this same style of manager become a rate limiting bottleneck by forcing _all_ cross-team decision making to route through him. We gamed that, of course, because we had to, but it was still tacking days on to "decision making" that we had to suffer through just to do our jobs. 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.

com2kid 9y ago
> I've also had this same style of manager become a rate limiting bottleneck by forcing _all_ cross-team decision making to route through him. 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.
bewo001 9y ago
I had former-engineer managers, who were the first to acknowledge that their technical skills weren't up to date. It makes a huge difference if you can explain a technical problem to someone who has solid base skills in the field or if you have to dumb it down to layman level.

ordinaryperson 9y ago

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

brightball 9y ago
Totally agree with you on this point. It’s easy til it’s your job. 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.
flashman 9y ago
> The biggest misconception engineers have when thinking about moving into management is they think it’s a promotion. > Management is not a promotion. It is a career change. http://fractio.nl/2014/09/19/not-a-promotion-a-career-change/ http://fractio.nl/2014/09/19/not-a-promotion-a-career-change...
- qntl 9y ago
  “Not a promotion” except that you get more money, respect, influence...

paulddraper 9y ago

While I won't go so far as to say "never, under any circumstances", I don't think you have to choose between engineering and competency though. 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.

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.