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.
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?
Be aware that this works only because you were technical lead of the project and recently active in a hands on capacity. It will likely fail you once you are on a new project that you don't know technically and your skills are years out of date. So learn to find, trust and nurture the experts on your team instead.
I say this because I was recently hired to work on a project where managers are obviously the only ones responsible for deciding how a developer should function within the organization. It is obvious the state of the project is anything but healthy at the moment. Attrition rates are astronomical and the code is beyond ugly in a lot of cases.
If you're suggesting a manager sometimes needs to self-reflect, sure, but a good manager does eventually have to make the call that someone isn't up to snuff.
There are several people in my department who probably should be "rethought" or let go, but management is too soft to make the call. It's actually more harmful to several, who could easily move on to other roles.
I've seen such a thing, taken to an extreme where lazy, underskilled developers were running the show; overcomplicating, underdelivering, yet showered with praise -- and it's horrible to witness. A word of warning for anyone entering such a world: you will not change this environment and any attempts to do so will trigger an immune system response. The developers and clueless managers will circle the wagons in defense of the existing culture.
Lesson learned: don't interfere with "resume-driven development" organizations.
I suggest the following interview question: "Tell me about the technical capability of your management chain."
What about managers who have had experience like a decade ago and don't do much tech experience anymore.
I am stuck in such management chain at work where some guy up top thinks he is technical enough to dictate solutions based on couple conference youtube videos that he watches.
Half knowledge and false sense of technical prowess is more dangerous imo.
A manager should have the big picture and communicate it to the team. Then you could avoid a team member wasting time on something that’s not in the greater objectives or roadmap.
Do you think any of the "bullshit engineers engage in with respect to fad chasing, bikeshedding and other negative practices." will change in 20 years?
Its been almost 20 years since first coined and we _still_ have bike shedding problems
I've worked along-side and led multiple managers and have experienced various types of managers.
The good ones usually stood out. A good manager is usually the ones that shield their teams from the onslaught of clients' un-managed demands. She is the one that liaises effectively between a looming deadline and the sanity of the team. She is the one making sure the clients are making their timely payments when the work is delivered/deployed or milestones met. She is the one who knows the right way to calm down an angry client when something is not happening the way it should - missed deadline, bug regression. A good manager knows her limitations, and also her power.
A bad manager is usually the one that instigates one against the other. Takes credit and sweet talks with the upper management. She blames the team when things go wrong. A manager, who reports to me, once told me, "why should I be the one to say anything now, the client is pissed and we missed the deliverables. I'm not responsible." (btw, he was fired the following month.)
I believe I'm technically sound, know a thing or two about design and I've led multiple projects with multiple project/product managers. I love the ones that are ready to go with me frontal assault on problems and challenges.
Engineering managers are a good fit for an all-out engineering team. But at the end of the day, I believe managers need to be better human characters, have empathy and have more of people skill than technical or design skills. Design/Engineering — that is what the team is for.
Edit: Plural/Singular Gender normalization.
The problematic ones i've seen had some people skills, or they were thinking they had. The problem was when they did not understand engineering problems, and were thinking that everything was a people problem/issue. So they either assume that the developers are lazy, or they simply can't accept that the engineer can have some real objective concerns. So its either they don't understand however hard you try to explain or they try to understand it is a people/personal problem, when it is not.
A manager has to answer to multiple people — clients, upper management, stakeholders, Jira. Unfortunately, she is totally dependent on this teams to get things done. She is utterly handicapped when it comes to doing anything useful, read, "engineering". Which is when most managers break and shows their character — they either break, blames people, do not listen, do not understand or they figure out who can help, seek help and find the right person to get things done.
Well, engineers, sometimes get it easy — they just have to solve a problem and make 2+2 = 4. They answer to one person; perhaps the manager. Think of the manager and to whom she is reporting and taking the fall. If the team does not get things done, they're the ones usually blamed.
In the early days of my career, I used to think that managers, middle managers are pretty useless. Now, I believe everyone has their roles to play a part in the whole machinery of 'the cogwheel'.
This is the opposite of people skills. If a report has a concern that doesn't seem to make sense, it is the manager's job to help them structure a clear explanation of the problem, help identify the best solutions for said problem, and collaborate with stakeholders to pick the right solution based on trade offs they are comfortable with. To be fair, to an entry level report, that process--unless done in a truly excellent way--often does seem like a lack of sympathy or empathy for the developer's challenge.
Anyway, made slight normalization to the plural/singular gender usage.
Yes. I'm usually called in when things escalate either with a team or with a client. So, one late evening (early morning for the client's timezone), I joined a client call with the team leads, including the project manager (hired about a month or so ago). The project managers keep eluding anything that goes to him, was evasive, keep blaming the team. I decided to cushion the blame, apologize to the client from the team and promised to be in direct call with him until the problems are solved. Luckily, I was able to rally the team, beg/borrow other guys from other team and turn around in few weeks. I confronted the manager (after talking to everyone in the project), asked him what he wants from the team, from his life, how does he really want to execute his role. Didn't go well. I think, I might have gotten him fired. In my defence, that was a good decision for the team and the company.
If you’ve ever been on a project with more than 1 or 2 people without a manager—or where the manager doesn’t do their job—you would know how insane this sounds. It does not work. Once you’re coordinating groups of people you need a manager to keep them working together towards a common goal.
On the very best projects, individuals will step up and lead for a while, then decide to do other things and let someone else run the show a little. Maybe it will be feature ownership, or to handle a different phase of a product in its ship cycle. (Meanwhile there will be managers behind the scenes, hopefully not many, making sure that forms are getting filled out, HR duties are attended to, and nonsense meetings are canceled and kept canceled).
Most of the places I've worked could have used less management. A lot less.
Someone has to set meetings, someone has to call out issues, someone has to communicate with upper management and other teams.
No-manager really means distributed management or an informal manager. Because the essential work a manager does has to be done by someone.
What is a manager?
I've worked on many successful teams (including projects with 100+ devs) without formal managers in the typical hierarchy sense.
You just need a combination of program managers, project managers, product managers, and architects.
No, you need someone to coordinate them. It does not need to be your manager. Plenty of matrix and matrix like organizations which have split the two.
Managers just need to enforce who that person is and resolve people (not product or business) disputes.
"You could prepend the words “it’s just” to anything, it’s not going to change the fact that you sound completely ignorant and will ignore any challenges that your team communicates to you."
I have often found it effective to counter "just-justifications" with the right representation of complexity. E.g.
"Yes, it's just an API change, but it requires 50 new test cases and impacts 120 existing test cases",
OR
"Yes, it's just a library change, but there are 450 sites in our code that use the library and out of those, 50 involve financial calculations"
Almost always, the manager appreciates this because you would have brought to his attention a problem that would otherwise gone under his radar.
"See, that's exactly why we shouldn't write any/so many tests!" - A product owner I know...
IMO, a manager should understand the complexity of the work of his employee at an approx. ball park level.
From what I have observed at one business, there is one scrum master on every team. Many of them know nothing about the business that business does, and have no technical background. I have seen developers spend sometimes an hour or more a day explaining to scrum masters what they just built, so that they can then go "communicate that up" to upper management or project management in opaque meetings developers aren't allowed to attend.
But what I can't figure out, is what they are actually supposed to do. At best, I see two points: 1. They do the traditional work of a project manager but on a team level, and communicate status up. 2. They are supposed to be some kind of "thought leader" on agile methodologies.
Can HN help shed some light on what this role should do? Perhaps my background has just been a bad experience in this regard. I suppose where I get stuck is, this seems to be the work that a dev lead used to do. Why make a full time job for a non-technical person to lead a technical team, below the management level?
- Give an organisation to the team, and make sure that this organisation does not decay with time - Help the devs work faster by helping them with the methodology - Help identifying & solving problems (a problem goes from "a dev spent one hour more than expected on this ticket" to "the client has no vision on what the product should be"). This is probably the most important task - Help the client to lead his project. This is a huge part too, the client does not know how to lead a project (they just came to us with a business problem they want to solve): there's no way the project will succeed if the client doesn't manage to have a clear vision for his product, prioritise tasks, build indicators, get user feedback...
Minor tasks: - Organise meetings/demos - Lead the meetings, make sure they're productive
We're a service company without management, "communicating status up" is a concept that doesn't exist.
For someone to do this, they would have to have client communication skills, at least somewhat thorough understanding of software development or the process, and an understanding of the client's business. I see this as a good thing. However, your example sounds to be a company that has external clients that you write software for. Do you not have account managers/principle types who interact with the clients, or is that more or less what a scrum master does there? Just curious, if you were an internal only dev shop that just develops software for stakeholders at your own company, would you see the role of a scrum master as significantly different?
Unfortunately I've seen people with it as a job title. They were the absolute joke you'd expect.
Your scrum masters really aren't. The SM role is supposed to be a few minutes a day, and focus more on how people work rather than the technical details.
Examples are things like telling management that the team has often missed deliverables because a key resource (some piece of hardware, etc) is often unavailable. Or even telling managers that their employees think one of the manager's policies sucks.
To an extent, it's about holding the team accountable as well: Why are some people working on a lower priority item when no one is working on a higher priority item?
Don't get me wrong - I'm no fan of scrum, and am not saying a SM is needed. But, as with management, a good SM is a valuable contribution to the team.
So what's the benefit?
It's a game mechanic that encourages people to be more thoughtful about how they think about a problem. Not perfect, like the swear jar, but it has some value in changing behavior.
Instead of an essay, I'll use a modern writing format: the pithy list.
1. This article gravely underestimates the difficulty of engineering management. One must simultaneously handle HR functions, he roadmap of their team and other teams, and their reportee's opportunities for growth and success. It's a very complex juggling act that most people are thrown into with no training, because training for the technical aspects is so bad.
2. This article's author forgets or is simply too lazy to look up previous examples of failure. Further, they're ignoring other attempts to systematize an "unmanaged" environment and what challenges people face there. It's unfortunate that they chose to pen such a long and effort-laden essay without doing sufficient research first.
3. The author of this article also seems to totally ignore the coordination and management functions required of microservice organizations. Presumably because as an engineer who specializes in delivering one single single-purpose executable on top of everyone else's microservice architectures, they may not have a ton of experience with it. Who is doing this if not engineering managers? Product managers can have some mechanical sympathy, but it's seldom their job to deeply roadmap out features.
4. This article ends suggesting that you don't need engineering managers to deeply understand the larger technical roadmap for your company and translate it to your team, but might find room for process custodians like scrum masters fix this problem? What? What even? This isn't even wrong. This is tantamount to suggesting the engineering itself doesn't even matter! It contradicts at least half of what the prior argument said.
Well, put it this way: I've worked in more- and less management-oriented companies, and have found that those that were less heavily managed were both better working experiences for me and more effective as businesses.
> 1. This article gravely underestimates the difficulty of engineering management. One must simultaneously handle HR functions, he roadmap of their team and other teams, and their reportee's opportunities for growth and success.
If managers fail because the role is too hard for them, we can't expect to get better people, we need to make the role easier. Some of those activities can be separated (e.g. having distinct "team tech lead" and "team line manager" positions), line employees can be empowered to do some of them themselves (personal development), and some simply don't deliver enough value to be worth doing at all (maintaining technical roadmaps).
> 2. This article's author forgets or is simply too lazy to look up previous examples of failure. Further, they're ignoring other attempts to systematize an "unmanaged" environment and what challenges people face there. It's unfortunate that they chose to pen such a long and effort-laden essay without doing sufficient research first.
I think it's entirely reasonable for them to write from their own experience rather than mixing first- and second-hand information in the same essay. Their essay makes a positive contribution to the conversation; concrete experiences of failure of alternative approaches would also be a positive contribution (far more so than low-content "they didn't research" complaints).
> 3. The author of this article also seems to totally ignore the coordination and management functions required of microservice organizations. Presumably because as an engineer who specializes in delivering one single single-purpose executable on top of everyone else's microservice architectures, they may not have a ton of experience with it. Who is doing this if not engineering managers?
You're putting the cart before the horse there; in my experience a vertically-layered "microservice organization" like you describe is the product of overmanagement (Conway's law in action). Better to give teams responsibility for delivery of client-facing functionality and have shared ownership of any common code; you write the functionality you need for the features you need. If you have a layer that really creates enough value to be worth other teams using it as a product, treat it as an actual product (ideally make it an actual product that you sell), and have a client-vendor-like relationship. Otherwise, a certain level of duplication of effort ends up being much less of a cost than constant between-team coordination would be.
> Product managers can have some mechanical sympathy, but it's seldom their job to deeply roadmap out features.
You don't need a deep technical roadmap, only a product roadmap, because you integrate with other teams at the product level, not the deep technical level. Even in the presence of relatively good management I've found that that's what works best. Think Amazon's famous "platform memo".
(Of course occasionally a specific feature will require deep technical coordination with another team. But that coordination is best done by the person with the responsibility for delivering that individual feature - the line worker.)
> 4. This article ends suggesting that you don't need engineering managers to deeply understand the larger technical roadmap for your company and translate it to your team, but might find room for process custodians like scrum masters fix this problem? What? What even? This isn't even wrong. This is tantamount to suggesting the engineering itself doesn't even matter!
Engineering matters, but planning of engineering has been a counterproductive activity every time I've seen it attempted. Planning and management should be done at the feature level; when it comes to the technical "architecture", trust your technical professionals to figure it out themselves - they're the people who will have the information they need to make those decisions. Software architecture is a lot more flexible than people tend to think; even on a large codebase delivering complex functionality, it's surprisingly easy to make radical architectural changes, and often the biggest impediment to those is well-meaning "architectural design" that exists solely due to management imposition rather than being driven by any actual functional requirements.
Or maybe we need to start recognizing that engineering management is a thing that has value, requires training, and is distinct from being an engineer with a strong personality.
It's telling to me that rather than elevate the role you're more inclined to destroy it.
> Their essay makes a positive contribution to the conversation
If this weren't a post-Zappos, post-Github, post-Uber world it might. As such it reads like a stale take from 2009, to me. But sure, we can just ignore the cycle of failure in the industry and keep writing the same stale think pieces. Hey check out my fresh new monad tutorial while you're at it, Monads are like burrito aquaducts where the black beans and delicious salsa flow from computation to computation across the continent.
> You're putting the cart before the horse there; in my experience a vertically-layered "microservice organization" like you describe is the product of overmanagement (Conway's law in action).
I've described, with the most pessimistic lens, 2 layers of management to the top of your company, with a focus on team collaboration. Having managers with strong engineering experience and technical sympathy decreases the depth of your organization, it doesn't increase it.
Please don't misrepresent my argument in your rush to dump on the idea of management.
> You don't need a deep technical roadmap, only a product roadmap, because you integrate with other teams at the product level, not the deep technical level. Even in the presence of relatively good management I've found that that's what works best. Think Amazon's famous "platform memo".
Funny then how Amazon has technical management. But as an example of planning, imagine a platform team runs a flight of APIs. There are multiple clients to these APIs all shipping products. Each has their own feature needs. If those teams collaborate on dependencies and optimize around what they need, everyone gets what they need faster. Not coordinating or planning provides a random outcome in a space dominated by sub-optimal outcomes.
> Engineering matters, but planning of engineering has been a counterproductive activity every time I've seen it attempted. Planning and management should be done at the feature level; when it comes to the technical "architecture", trust your technical professionals to figure it out themselves
This entire discussion is predicated on the notion that your managers are technical professionals facilitating this. It's weird how many people refuse to accept the idea that people can exist, while in the same forum glorifying hybrid roles like startup CTOs in the same forum who are obligated to do a lot of management functions AND be the basis of a strong technical department.
P.S., I apologise for the brevity and potential grammar errors. I wrote this on mobile, figuring a prompt response was more useful than an expansive response.
There needs to be a good balance (obviously too much red tape is counterproductive). Having managers can be nice when it explicitly assigns roles and responsibilities to a group, because that means not only are there dedicated people for certain tasks, but presumably they have a modicum of power to get things done. It also makes it plainly obvious whom you talk to if you need, say, a new laptop, or a printer set up, or a VPN account. Without managers you get company-wide emails like “who controls our website? I need to update something.”
In my experience managers from a software engineering background are usually lower skilled engineers who tend to overrate their own skill level and make bad technical decisions where a non-engineer manager would defer to the expert opinion of the people they manage.
However the timeline I've experienced is different:
* You have a great engineer or lead who knows the project inside and out
* They are promoted to management.
* They still know the project inside and out plus were recently coding so they dictate how things are done technically. It works great.
* They get put on a new project which they don't know inside and out.
* They dictate how things should be done technically because it worked for them in the past successfully. It works horribly.
The author conflates "all managers" with "project managers." and implies this is some artifact of the hegemony. My experience with project managers is that they are largely an artifact of waterfall-style software development and are not as necessary today in agile environments. But they can be helpful in the orchestration of large-scale projects.
I've personally never been in a situation (I've worked in software development for over 25 years) where we were hiring an engineering manager, and hired a "business type" instead. I'm hiring a development manager now, and the first step in that process is a coding interview. They cannot go further unless they pass that.
This whole article reads more like an us-vs-them rant than anything else.
My rule of thumb for "how you know you need a project manager": As a manager of engineers, if you find you have more E-mails than you can possibly respond to, or more meetings than you can possibly attend, or more people "pinging" you than you can possibly satisfy, then you need a project manager.
If you're an individual contributor engineer, you probably are not in the position to even know if you need a PM or not, especially if your manager is doing a good job.
I don't mean to be too flippant, but isn't this whole article an instance of exactly what the author is complaining about? Let's have good managers rather than bad ones. Good managers trust their reports to tell them the constraints of the work and factor that into the team's strategy. Being conversant in the underlying task helps a lot with that, but there are plenty of managers who come from an engineering background who make the same mistakes the author laments.
My schooling was Computer Engineering, my career started as a Software Engineer and has wound all the way up to Director level. I’ve been on both sides of this equation for a long time.
Your typical “just a manager” has to spin so many plates and babysit so many people that most real “engineer types” would loathe the job and frankly, not be very good at it. I struggled mightily as a team manager where there were a lot of competing priorities, personal issues, and directions that I needed to follow. As I got higher up the chain of command the job got easier, I had less direction I had to conform to, I was thinking architecturally and in longer terms– and I didn’t have daily interpersonal drama to deal with.
Management isn’t for everyone, engineer or not. It’s a lot like parenting: Most people are just making it up as they go, trying their best, and the best ones generally put others before themselves.
Put the idea that Engineers should be these lone wolf rockstars that just to get to do what they want, regardless of corporate objectives or market positioning is ludicrous.
As an engineer, I can confirm that we’re just as short sighted and dismissive of other people’s work as they are to us.
Great managers can manage things they don't understand and probably never will -- their role does not require domain expertise. I would argue that the hallmark of a poor manager is that they can't manage unless they are a domain expert, which they often use as a crutch to overcome lack of basic management skill. One of the greatest failure modes for software engineering managers with engineering backgrounds is the assumption that they can or will understand every part of the design they are managing. Not only is this unlikely in many cases but this delusion encourages them to dictate elements of engineering design that they are not intimately familiar with, invariably to the annoyance of the engineers that are tasked with doing the work and may have far more technical skill than the manager on the task at hand. For mundane software projects, an engineering manager with an engineering background may legitimately have the domain expertise, which is why it still gets things done despite being suboptimal for everyone.
This is really brought to light when doing complex, high-end software system engineering. In these cases my experience is that most experienced engineering managers with engineering backgrounds fail; because it is impossible to understand what your team does at a technical level, you can't lean on that. It is often difficult for very experienced engineers, now managers, to come to terms with the idea that someone working on "their" project has technical skills that they can't master or at least understand with a 15 minute explanation and a couple hours of research. Engineering managers, especially ones that were previously great engineers, must resist the instinct to technically master everything under their purview -- it doesn't scale. The advantage of non-engineering managers in these environments is that their management style doesn't rely on the assumption that they can technically master any part of the project, so they don't even try.
A big part of being a good engineering manager is letting go of what made you a great engineer. It isn't an easy thing to do.
A number of the examples in the article are just bad management, and things I’ve heard from managers with years of engineering experience.
YMMV
The fact of the matter is that management is its own skill, very contextual and difficult to master, and engineering experience is no silver bullet. Of all the best engineering managers I've worked with (both up, down, and lateral), only half had an engineering background. It depends on the project of course, but in general there are more important attributes than hard tech skills.
The author apologizes for speaking in unqualified absolutes, but does so constantly.
Even if the author is right, this article reads as pretty childish.
A good manager knows how to find the balance between “what engineering wants” and “what everyone else wants” and gets the best outcome. The best managers don’t need to be expert engineers themselves but they know enough to have a good BS detector and enough to make decent decisions.
I've worked with managers who thought they were somehow superior to the people they manage. This seems to be a common issue. They tend to experience a high attrition rate.
I recognize the feeling when tasked with bringing a new developer up-to-speed. They don’t know anything about our environment and the brilliant decisions that led us to our utopian way of working. They ask an honest question and I, having forgotten the ingredients, brush off the question because I don’t have time to explain. Welcome to the team noob.
I also recognize the challenge when speaking with practically every CEO, COO, EVP, VP, and Director in a mid-sized organization. And the challenge can grow exponentially when the business involved views technology as an expense. Somewhere in the building there are a number of idiots who think a pointer is a device used for whiteboard presentations. How is this company profitable?
But solace comes when I realize the issue is my own.
Technical expertise is not the only expertise required by a company. It is highly likely that your organization has executives that don’t need to understand the productivity differences between vim and emacs. Imagine how frustrating it would be when attempting to ensure the company has enough funding for the next four quarters and you can’t get a single developer in the world to provide a reasonable estimate that doesn’t have a sixty-percent margin of error. I dare you to argue the benefits of a scrum master.
Your manager is just as anxious about having to talk to you. Give them a break and help them do their job. They’ll appreciate it and may care to understand your concerns moving forward. Who knows, they may be willing to help you do your job better (as if that's possible). Communication will be less frustrating when you stop viewing others as inferior. They feel the hostility.
The most successful amongst us are those that communicate by simplifying complex subjects down to an intelligible analogy. They sell. The world rewards those who sell. Just find another way sell your complexity, patiently, and with a touch of empathy. The rewards will follow.
It always comes down to this (in technology): A good manager serves his team, a bad manager thinks his team serves him.
A good manager realises that his team members know more about the tech than he does (even if he is technical). To get estimates, he asks the people who know.
A good manager makes sure each team member can stay focussed on their job.
I didn't like being team lead too much, because I don't like administration, and I don't like to handle shit that you don't want to distract your team. At the end of the day, I was always happy when I could write code. Therefore I leave the 'shit' job for someone who likes it, but I'm glad some people prefer the other.
B. Are you an engineer or a technician. An engineer "just" creates fixes. A technician will implement it. Lines blur in programming more than other fields, but some "engineers" make a big deal out of just figuring out solutions that have been solved many times before, like making a backend call.
This is my perspective as an engineer.
I've worked with both engineers-turned-manager and "business" managers, and both have had ups and downs. But the tech industry's love of taking individual contributors and pushing them into management roles without any management training or even interest in managing people seems to be the failed experiment.
Project management - manage scheduling, deadlines, track progress, day-to-day or low-level interteam collaboration, resolve blocking issues. They'll usually use a bug tracking system and ensure that it's state reflects reality. They may also need to build out or modify various processes such as new releases or deployments, work with QA on a validation process, or when should code be considered good-to-merge into the repo. (Has there been code review done, CI testing, validation, etc).
Engineering management - HR functions (promotion, performance management), assignment of tasks or larger projects, working with project management on realistic schedule, working with product / business on requirements, interfacing with other teams on high-level matters, strategic work related to the team, and most importantly work that no one ever wants to or has any time to do. (This includes technical work.)
IMO you can have a small org without these two functions if everyone is a has extensive experience/willingness to managing themselves, but if it grows past that things will break very quickly. Modern large organizations deal with unfathomable levels of non-technical complexity.
Well, I've had engineer colleagues use that kind of language at me. It's a type of bullying really, and it doesn't necessarily correlate with technical cluelessness.
https://www.forbes.com/sites/meghancasserly/2013/07/17/googl...
https://hbr.org/2013/12/how-google-sold-its-engineers-on-man...
All my managers have been engineers in the past. And over half of them fit this description.
I don't want to downplay the benefit of having some domain knowledge, but the problems described are not a symptom of not having engineering experience. Management requires a good amount of nontechnical skills, and too often a high performing engineer is picked for becoming a manager, with no training whatsoever.
"... teams with great managers were happier and more productive..."
In my opinion, it's not about having no managers---it's about having managers with the right mindset, qualities, and behaviors.
From Google's study on managers reported in nytimes[2]
“In the Google context, we’d always believed that to be a manager,
particularly on the engineering side, you need to be as deep or deeper
a technical expert than the people who work for you,” Mr. Bock says.
“It turns out that that’s absolutely the least important thing.
It’s important, but pales in comparison. Much more important is just making
that connection and being accessible.”
[2] http://www.nytimes.com/2011/03/13/business/13hire.html?smid=...
edit for formatting
There Burke talked about automation (keep in mind this was recorded back in 1978), and how it would make management simply sit around waiting while the mainframe in the basement churned out the action plan for the next week (or some such) and then implement it.
Effectively he envisioned that computation could eliminate the managerial class.
However, and especially at scale, there is a humanistic factor in management that having technical background alone can't fix. How do you manage deadlines? How do you deal with engineers who over-engineer a feature and go down that deep technical rabbit hole, with no "done date" in sight? How do you deal with people having to take a sabbatical but having an important project deadline around the corner? Heck, I'd argue engineers like myself are pretty bad at this and still constantly learning. Don't forget that expectation vs reality distortion is real. Great managers are essentially brokers to keep expectation and reality in check.
This might not be the most effective way to run a company, but the members will all be self-sufficient, and we'll support ourselves with part-time contract work. Or some might have a full-time job and work on side-projects in their spare time. Eventually we might make enough money to pay for our living expenses.
The projects could be anything, and at the beginning we would focus on revenue. SaaS services, mobile apps, games, open source projects with some paid features (e.g. Sidekiq), or buying some websites from flippa.com.
Once we start making a bit of money, we can shift focus to non-profit work, and fun projects that are purely creative. I have a big list of things that I'd love to work on, and some of them are just fun ideas that won't make any money. But who knows, maybe those experiences will shine light on some new product ideas.
I want to find people who love learning and building things in their spare time. And I want to start a company where all the time is spare time. That's not to say that spare time is always fun. Responsible people use their spare time to do chores and fix stuff around the house. You wouldn't want to live with a roommate who always leaves dishes in the sink and leaves their clothes all over the floor. I want to work with independent people who don't need that kind of management, and build a lot of interesting things together.
[1] https://docs.google.com/forms/d/e/1FAIpQLScfFzyzCWPresTMPSb4...
I've seen my share of non technical product managers, project managers, etc. but not engineering team managers. In all cases my engineering leadership were technical all the way up to at least the SVP level.
EDIT: So, I got to the end of OP's rant and it looks like he's shifted his target from "managers" in general to project managers. He might even be confusing the two.
The issue is that, someone has to talk to the internal customer [0].
Now if a programmer do the talking with the internal customer, then I believe, he will naturally become some sort of a surgeon ala Mythical Man-Month [1].
Mills proposes that each segment of a large job be tackled a team, but that the team be organized like a surgical team rather than a hog-butchering team. That is, instead of each member cutting away on the problem, one does the cutting and the others give him every support that will enhance his effectiveness and productivity.
Problem is, I believe the surgeon method cant work in practice for 2 reasons, 1) programmers dont want someone who tell them how to code, 2) even if people would want a surgeon, since the surgeon both need to be a great programmer and a great politician because he will naturally speak to the internal customer (because eh, hes the surgeon), hiring for that position becomes difficult - and you'll end up generally with a great politician that sucks at programming, which makes (1) even more pronounced.
The only way you can get rid of the project manager is to make the team the internal customer. That's the case at Valve [2] I believe.
In the mean time, the best thing to do is to work with project managers who were engineers before.
[0] I know what you think: a project manager isn't only talking to the internal customers. Yes, that's correct but the rest of his job is similar the one of a secretary. Nothing that would put guy on top.
[1] https://ia801903.us.archive.org/19/items/mythicalmanmonth00f...
[2] http://www.valvesoftware.com/company/Valve_Handbook_LowRes.p...
A certain recipe for disaster in any development project is having no one who thoroughly understands the business and no one who can make a decision as to what gets developed and what does not. What this article is describing is just such a recipe.
Any significant development project which is attempting to address the needs of the enterprise needs an enterprise architect, and a project owner who can say no. If these can be the same person, all the better.
In some cases/team there is the need of an extra effort in order to balance resources AND people.
If I could pick a manager from a pool I will probably take someone with experience in people first and docker later...
At the end manager that are open to listen to the team and the customers will probably take the right choice in term of technology.
In fact sports and arts organizations have non-technical “managers”. In theater and film, they are called producers.
If a non-technical manager keeps to the “producing” stuff, that is, HR, resource acquisition, inter-company communication, I’ve seen it go well.
As soon as the non-technical manager starts making “creative”, ie technical, decisions, that’s when things go poorly.
You get into trouble with non-SME managers that start directing the way people solve a problem or prioritize what work gets done.
As a thought experiment, if management were 'just a role' and people could switch into for a period of time and then go back to their 'real jobs' with no loss of pay or prestige, that might lead to some interesting effects.
(warning, anecdata:I've worked on teams where the 'manager' role was cycled among engineers/testers/designers etc throughout the project lifetime, and it worked well. I've also seen managers come back to being full time developers, and their perspective from the time of being managers really helped with their effectiveness as developers)
Also, I feel like this (we don't need no stinking managers!) is a perennial meme that pretty much doesn't work in practice? Queue the Valve Employee Handbook: http://www.valvesoftware.com/company/Valve_Handbook_LowRes.p...
Some more articles:
- Valve https://www.inc.com/david-burkus/how-this-company-runs-witho...
- Zappos https://qz.com/161210/zappos-is-going-holacratic-no-job-titl...
- https://www.fastcompany.com/3045509/myths-of-companies-with-...
- ? https://www.fastcompany.com/3045509/myths-of-companies-with-...
PS: From my own experience, managers are invaluable at removing distractions, communicating with stakeholders, setting high level priorities, and assisting with career growth. But it's not hard to see the place of frustration where OP's point of view comes from.
Limit: CEO -- it is not possible and no one would seriously suggest that a CEO must be expert in all disciplines they manage. Therefore at some extreme we must admit that functions can be managed by non-experts.
Taken a step down, does the most engineering leader reporting to the CEO need to have been a practicing engineer? If we examine this carefully, this is also a kind of nonsense. Such a person is usually managing a wide array of engineers working across multiple disciplines. We cannot expect them to be an expert in all areas that they manage, given that these will likely include some element of infrastructure, quality, security, performance, front-end, back-end, mobile, and potentially other disciplines. Even if you had a mobile-only team, it's not likely to find a leader who is an expert in both iOS and Android.
Ok, let's go down another level, to a director that manages a given domain of engineering, for instance an iOS engineering team. First of all, at scale most companies I've worked with do not even organize in this way -- they find it most efficient to build high-functioning teams that have most if not all of the disciplines needed to ship product in a given business problem domain. Since this is simply a repeat of the above issue, I won't cover it again, in favor of focusing on the specific issue of someone managing a discipline that isn't matrixed out like this, perhaps a backend infrastructure team. In a reasonably-sized team (50+ engineers), such a person has no time to be actively involved in the development process, and likely has not had time for this in several years at a minimum. Even if they do maintain side projects that use the technologies of the team their efforts are at best dabbling and cannot be compared to someone who is full-time engaged with those technologies. I would not trust such a person to make a reasonable estimate for degree of effort when it comes to any given specific project -- they are simply too far from the current state of the codebase and technology, despite their having been an implementor in the past.
Now we get down to the case of a manager of a team. If they competently manage more than 6-8 or so people they likely have no time free to be actively involved in development and effectively are in the same situation as a director, hopefully with more recent context. If they actively involved in development, then they are probably operating in a role that is best described as "tech-lead / manager". I would trust and expect someone in a role like this to be able to judge level of effort for work their team is doing provided they are actively working in that discipline (cross-discipline teams as described above will include a solid percentage of work that they are likely not expert in).
Hopefully it goes without saying that this is a minority of engineering managers, even correcting for the tree-like structure of most engineering teams.
Finally, as other commenters have pointed out, managers are required to spend a great deal of time (often 100%) in meetings and dealing with personnel issues. These require skills that are not specific to engineering, and as managers grow in their career, they will get stronger in these areas (and weaker in terms of their ability to engage directly with the work that "line" engineers do).
You should work with the grain of a manager's natural skillset trajectory, not against it.