12 ms·

Let’s have no managers, instead of managers with no engineering experience

• sidlls 9y ago
  I tend to agree that managers of engineers should have engineering experience. I think my reasons would differ from those of the author and many other engineers: it's much less charitable toward engineers. One of the best reasons to select managers who have been engineers, in my opinion, is because they know how much bullshit engineers engage in with respect to fad chasing, bikeshedding and other negative practices. It's important to know what the work of an engineer really entails: that includes the aspects of it that negatively impact the business and how as much as it does the aspects that contribute value and how.
  • atmartins 9y ago
    This is a valid point. In my mind, ideally, at least one or two trusted members on the team can help with this since they're even closer to the actual engineering taking place. It's helpful for management to understand the tradeoffs that are discussed, so I agree that some experience is very helpful, but hopefully the team has a few mature members as well.
  • jackhack 9y ago
    Yes, 100% agree! 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."
  • dominotw 9y ago
    > I tend to agree that managers of engineers should have engineering experience. 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.
    • euroclydon 9y ago
      A manager should not be dictating architecture unless it’s some really small operation, and even then, it’s dicey. Rather, anyone who is capable of writing up a white paper that describes the problem, solution and rational for the choices should be able to propose a solution, and then have a meeting to discuss and decide whether to move forward. 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.
    • sidlls 9y ago
      Most of the technology in use today isn't that different from what it was 10 years ago. It's a bit faster and has slightly different packaging. Any manager who last did engineering as an individual contributor ten years ago should be perfectly fine engaging in a technical discussion today at the level a manager should be doing so.
    • chrisan 9y ago
      > What about managers who have had experience like a decade ago and don't do much tech experience anymore. 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
• numbsafari 9y ago
  My own experience in this department has been managers with engineering experience but no management training or experience. Sometimes it’s orgs that promote bad engineers into middle management to get them out of engineering. Sometimes it’s orgs promoting their best engineers into management roles for which they are a bad fit, or just ill prepared. 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
• mcphage 9y ago
  > It’s better to have no management than unqualified management. 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.
  • TomMarius 9y ago
    That's not true in general, I've been in environments where a team of 10+ very motivated individuals worked together without a manager. It's not common though.
    • the-pigeon 9y ago
      But you still have people doing the job of a manager. 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.
      • mjw1007 9y ago
        Sure, that work still has to be done. But if you start off by thinking of it as "the job of a manager" then you're assuming your conclusion.
  • sheepmullet 9y ago
    > Once you’re coordinating groups of people you need a manager to keep them working together towards a common goal. 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.
    • mcphage 9y ago
      So you’ve worked on successful teams without managers—they just had... managers, managers, managers, and architects?
• plinkplonk 9y ago
  I don't think 'no managers' is a good idea. There are managerial 'things to be done' in every project. 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)
• tomrod 9y ago
  I find a good manager who facilitates the bureaucratic nonsense I don't want to deal with to be worth their weight in gold. They don't have to understand the details of what I do and build, so long as they support my work, are willing to shop it out, and give solid feedback. 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.
• akerl_ 9y ago
  Historically for me, any time I've worked with managers who either managed my team or projects I've worked on, whether they helped or harmed things depended pretty much solely on "does this person have management training/experience, and a desire to be a manager". 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.
• tyingq 9y ago
  Sounds like someone that hasn't ever had a good manager. A leader that can provide good air cover is a serious benefit in a large company. That ability has little to do with whether they have engineering experience or not.
  • humanrebar 9y ago
    There is value in keeping negative attention away. There is also value in attracting attention to technical needs. If you need someone in another part of the org to do something technical to make your life easier (or even unblock the project), it's difficult to get the job done without a technical manager. You can usually get the job done with a non-technical manager who can listen and delegate well to a good technical leader, though. The problem is that a non-technical manager won't necessarily know who is a good technical leader and who is just a loud engineer.
    • tyingq 9y ago
      My experience is that a good non-technical manager will develop a relationship with a member of their team that fills that gap. Most of the "good" manangers I've worked for were good because of their soft skills.
      • humanrebar 9y ago
        I mentioned that approach, yes. But it can backfire if the team member is makes big mistakes. The non-technical manager will have a hard time identifying bad decisions before they blow up.
        • marcinzm 9y ago
          >I mentioned that approach, yes. But it can backfire if the team member is makes big mistakes. The non-technical manager will have a hard time identifying bad decisions before they blow up. Why do you assume an out of date and no longer practicing manager will have a better chance of catching errors than causing them? There is a reason you hire experts and that reason is not so you can ignore them. If you're afraid of a single point of failure then you foster a collaborative blame-free culture where the engineers cross check each other. I've had managers who would agree with you and generally they were bad managers who hadn't realized they were no longer Senior ICs.
• Brajeshwar 9y ago
  It depends. 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.
  • Arwill 9y ago
    >have empathy and have more of people skill than technical or design skills 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.
    • deleted 9y ago
      [deleted]
    • Brajeshwar 9y ago
• saas_co_de 9y ago
  My experience is the opposite: I find that managers who are not from a software engineering background are generally better. 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.
  • hliyan 9y ago
    I've had similar experiences -- a little knowledge is a dangerous thing. Both non-technical managers and technical managers who entered management after reaching the top of the technical ladder, are better than semi-technical managers.
  • dominotw 9y ago
    This spot on. I would take a manager who knows how to get best tech decisions out of their engineers.
  • marcinzm 9y ago
    My experience agrees although proper management training/mentoring can alleviate some of the issues. 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.
• derrekl 9y ago
  I often institute a “just” $1 jar. Anytime “why don’t we just” or “it’s just” is uttered you have to put a dollar into the jar. This applies to engineers, managers, myself, everyone. The idea is breaking the habit of trivializing work that isn’t. Something like a dollar jar is fairly effective as a notifier but doesn’t necessarily replace the habit with a better one. Nevertheless the game itself seems to help even if dollars aren’t transferred into the jar.
  • the-pigeon 9y ago
    Hmm isn't that just like a swear jar? You don't get rid of the swears or the trivializing but rather you just replace the particular words being used for the trivializing. So what's the benefit?
    • derrekl 9y ago
      I think being called out for a bad habit is a step in the direction of replacing/improving it. In some cases it’s enough and the person caught figures out a better habit themselves. In other cases more techniques/actions are necessary. As it relates to this article the context was nicely set to illustrate the jar technique. Other contexts would need to be set to illustrate techniques related to situations where calling out is not enough.
    • zorak 9y ago
      Swear jar is a great analogy. Also, that'll be $2. 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.
    • BeetleB 9y ago
      You owe the "just" jar $2.
  • chuckcode 9y ago
    I like this idea. I wish more of the places I have worked had explicit guidelines around how to work as a team (e.g. don't trivialize work that isn't). It doesn't take many poor timed comments to shut down a team's discussion.
• hliyan 9y ago
  Sometimes we engineers do a poor job of communicating complexity: we have un-communicated assumptions that we think the listening party shares. Which sometimes lead to this: "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.
  • rnd33 9y ago
    > "Yes, it's just an API change, but it requires 50 new test cases and impacts 120 existing test cases", "See, that's exactly why we shouldn't write any/so many tests!" - A product owner I know...
    • jlg23 9y ago
      He might have a point if a simple API-change impacts 170 test cases. This sounds suspiciously like "no functional tests but let's go for 100% coverage with unit tests" - not necessarily the efficient thing to do, from a management perspective.
    • dasil003 9y ago
      "Manual QA then? That will be even slower than automated..."
    • sidlls 9y ago
      That product owner might have a good point. Far too many engineers I know think 100% coverage is a reasonable goal and spend way too much time writing unit tests that don't add much value or worse add negative value.
  • denzil_correa 9y ago
• b4lancesh33t 9y ago
  It's just management, after all. 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.
  • nathanaldensr 9y ago
    That's what I was thinking. Really, the problem with most managers is that they are not empathetic with both the business side and the tech side at the same time. Good managers know how to set expectations and communicate with correct language when talking to either cohort.
• mcs_ 9y ago
  In my experience management was either good an bad. I think that culture was the most important thing at the end of the day. Engineering is not everything when productivity is important as well as environment. 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.
• austinshea 9y ago
  This is just a rant. The author apologizes for speaking in unqualified absolutes, but does so constantly. Even if the author is right, this article reads as pretty childish.
• kapauldo 9y ago
  Seems unaware of what pays his salary.
• JohnJamesRambo 9y ago
  Stop calling it engineering...engineering is a degree that requires an incredibly rigorous formal training and education. Call it what it really is, there's no shame in the word developer or programmer, wear it with pride, but don't just appropriate words, it is beneath you.
  • andrewjl 9y ago
    What does formal training or education give you that many years of diverse and relevant experience coupled with professional mentorship and self-learning doesn't?
• manyxcxi 9y ago
  This sounds like the rantings of someone who has had some pretty bad managers and has never managed anyone else. 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.
• quadcore 9y ago
  I've thought about that a lot and my conclusions weren't what I expected as a programmer. 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/mythicalmanmonth00fred/mythicalmanmonth00fred.pdf#page=41 https://ia801903.us.archive.org/19/items/mythicalmanmonth00f... [2] http://www.valvesoftware.com/company/Valve_Handbook_LowRes.pdf http://www.valvesoftware.com/company/Valve_Handbook_LowRes.p...
• behindmyscreen 9y ago
  I think there is value of management in all cases wrt processing corporate beurocratic paperwork and even for resource allocation of staff to initiatives. You get into trouble with non-SME managers that start directing the way people solve a problem or prioritize what work gets done.
• y2hhcmxlcw 9y ago
  Something I have wanted to ask the HN community, that this article brings up: what exactly does a scrum master do? 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?
  • derwiki 9y ago
    I've never had a scrum master across 7-8 companies. Usually it was a rotating role, or a manager/tech lead. But certainly not one person dedicated to it.
    • cs02rm0 9y ago
      Yeah, it's supposed to be a role for a dev to play for 10 minutes a day. Unfortunately I've seen people with it as a job title. They were the absolute joke you'd expect.
      • swyx 9y ago
        spotify seems to have a few professional scrum masters and it seems to work for them. I'm less interested in typical cynicism and more interested in how this gets done -well-. Any spotifier's care to comment on having fulltime scrum masters? edit: It seems they are called "Agile Coach"es.. is that any different?
  • BeetleB 9y ago
• aviolette 9y ago
  You need experienced managers as the size of an organization grows. For development teams you need an engineering manager to work with product to design stories, orchestrate work with other teams, and to provide technical mentorship. 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.
  • ryandrake 9y ago
    Yea, I picked up on this too. I was pretty confused reading through the rant. Is his beef with his engineering managers or with his project manager(s)? It looks like he's frustrated with project managers. 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.
    • aviolette 9y ago
      Agree!
• mburger 9y ago
  This might be interesting in this context: https://rework.withgoogle.com/guides/managers-identify-what-makes-a-great-manager/steps/learn-about-googles-manager-research/ https://rework.withgoogle.com/guides/managers-identify-what-... "... 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.
• ryandrake 9y ago
  Maybe I've just gotten extremely lucky, but in the 15+ years I was doing software development, with one exception (a CEO where I was employee #1), I never had a "non-technical" manager to whom I reported. Where are these companies that hire someone who literally knows nothing about engineering to lead a group of engineers? I'm not saying it doesn't exist but I've never seen it. 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.
• Torai 9y ago
  Or just have managers with engineering experience. Just saying. Cause it seems pretty straightforward to me.
• kardianos 9y ago
  A. Engineering Management shouldn't micromanage, but a manager can be invaluable in helping resolve interpersonal conflicts and escalate issues. They can be the "bad guy" when dealing with someone the team reports is consistently underperforming or engaging in poor behavior. 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.
• digi_owl 9y ago
  Gets me thinking of one episode of the original Connections series. 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.
• EliRivers 9y ago
  Didn't Google try this? It didn't work out for them. https://www.forbes.com/sites/meghancasserly/2013/07/17/google-management-is-evil-harvard-study-startups/ https://www.forbes.com/sites/meghancasserly/2013/07/17/googl... https://hbr.org/2013/12/how-google-sold-its-engineers-on-management https://hbr.org/2013/12/how-google-sold-its-engineers-on-man...
• BeetleB 9y ago
  >But where they single handedly derail a project due to micro-managing and over simplifying developers’ implementation concerns. 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.
• code4tee 9y ago
  There’s a balance. A group run by clueless managers is bad. Equally through a group run entirely by engineers that don’t think about or consider anything other than their engineering concerns is bad too. 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.
• jandrewrogers 9y ago
  While I agree that it helps for a manager to have experience doing what they are managing, I would frame it differently. I've experienced poor engineering managers with engineering experience and good engineering managers with none, to the point that I've developed a more nuanced opinion about what makes a good (engineering) manager. 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.
• cdevs 9y ago
  I was recently a lead developer and asked to manage the team by the team. I noticed running the team can't be generalized in one size fits all, some people just want clear descriptions of projects to work and and some people want to over engineer and make a 1 day thing a 2 month job no matter how you say it should be done. Problem is how do you handle a engineer that says something can't be done in 2 hours? Well so far I have sat down with them and showed them it can be done in 2 hours, beyond that argue with me enough and I may be forced to rethink your employment. It hasn't come to that yet. most of the room follows my instructions and we are kicking butt, there's a small part of the room that wants to be dramatic about everything, their computer isn't good enough "needs 64 gigs of ram for their command line", the tools aren't good enough etc etc - basically they have management envy and that's my only struggle right now.
  • datashovel 9y ago
    Not particularly directed at you, but it's certainly a dichotomy in that managers are the only ones responsible for "rethinking another's employment". I'm curious to know how often you would consider reflecting on / rethinking your own employment? 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.
    • unethical_ban 9y ago
      "rethinking employment" was a clever way of "firing someone who cannot take direction". 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.
      • deleted 9y ago
        [deleted]
• ryen 9y ago
  How about no managers with no management experience. I've seen countless senior devs promoted to eng/dev management roles who were either clearly not ready for the role or were simply not the personality to "lead".
• dlandis 9y ago
  > 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.
• KKKKkkkk1 9y ago
  Example? I’ve experienced too many instances of just-justification, where a manager has said something like, “it’s just JSON”, or “it’s just UI”, or “it’s just talking to the backend”. This not only unravels their credibility in knowing anything about software, but it also devalues the work that a software developer needs to do to build a working product. 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.
• deleted 9y ago
  [deleted]
• tnolet 9y ago
  If there is one thing I learned it’s that “no managers” === “everyone is responsible”. That ends up as “no one is responsible”. Then chaos ensues due to no clear decision making and infighting because everyone is suddenly “boss”. As always YMMV.
• dasil003 9y ago
  This guy has clearly been bitten by one type of bad manager. But let me assure you, there are many other types, and they often come from engineering backgrounds. You'll get all matter of micromanagement and communication issues that come from someone who is used to knowing all the intimate nuance of every issue. Also, even if you think they are a great manager because you have a great individual rapport, they may end up getting steam-rolled from above because they are bad at cross-functional communication or managing up, and guess who pays the price for that? 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.
• KirinDave 9y ago
  I wrote 1000 words on this subject and prior spectacular failures of the "no management" style in Silicon Valley. I deleted it. No good can come of talking about it here. 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.
  • tachyoff 9y ago
    This is well-said. To add some anecdata, I work in a “managerless” organization. It sucks. It’s hard or impossible to make certain changes because nobody has any authority to do things that aren’t necessarily politically sexy (e.g. fixing bad security or setting up asset management). There’s also this expectation that if you want to do something, you can just do it. This sounds great on paper, until you realize that doing things like managing infrastructure is a full-time job for an entire team, and not a “once in a while” position for someone with little experience. I’d love to go the extra mile, but I only have 40 hours or so in my work week, and I’m busy with my actual assigned tasks. 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.”
• chuckcode 9y ago
  I think we can all agree that bad managers suck and managers who pretend to be technical particularly suck. However it feels the me though like we greatly underestimate the difficulty of being a technical manager and grievously under train them. Google has gone past the one-off personal experiences and studied across lots of teams and projects[1] and being a technical expert wasn't even close to the most important trait. I'd like to see us spend less time proposing "no managers" as current ones aren't good and more time on figuring out how to make them good and give them training and support they need. Most of the ones I know want to be successful and are trying in their own imperfect way. If you think the most important thing is technical prowess just take a look at any academic CS department, run only by super technical professors it is often a case study in anti-patterns. 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.” [1] https://rework.withgoogle.com/subjects/managers/ https://rework.withgoogle.com/subjects/managers/ [2] http://www.nytimes.com/2011/03/13/business/13hire.html?smid=pl-share http://www.nytimes.com/2011/03/13/business/13hire.html?smid=... edit for formatting
• teilo 9y ago
  No. Just no. I have been there to clean up the mess that results from this methodology. 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.
• jimbishopp 9y ago
  Communicating complexity difficult. 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.
• tzhenghao 9y ago
  I think there is a slight correlation between having some expertise in the team that you're managing and your overall performance as the manager. Some points along this argument include empathy for engineers' work, and I totally agree with you. 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.
• san_at_weblegit 9y ago
  This is indeed an important discussion. I was looking for some similar experience in the top few comments but couldn't find it, so I thought about writing my own. From my experience its about the person in the role, not the role itself. Two of the best managers I had were non-technical but they could read people. They kept their distance from the technical work but would step in when required to control. Ofcourse this also means that they hired good engineers to begin with. A good engineering team can run by itself when it comes to technical work.
• smnscu 9y ago
  Obligatory xkcd: https://xkcd.com/1425/ https://xkcd.com/1425/ 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.pdf http://www.valvesoftware.com/company/Valve_Handbook_LowRes.p... Some more articles: - Valve https://www.inc.com/david-burkus/how-this-company-runs-without-managers.html https://www.inc.com/david-burkus/how-this-company-runs-witho... - Zappos https://qz.com/161210/zappos-is-going-holacratic-no-job-titles-no-managers-no-hierarchy/ https://qz.com/161210/zappos-is-going-holacratic-no-job-titl... - https://www.fastcompany.com/3045509/myths-of-companies-with-no-management https://www.fastcompany.com/3045509/myths-of-companies-with-... - ? https://www.fastcompany.com/3045509/myths-of-companies-with-no-management 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.
• sulam 9y ago
  The article's argument is founded on the idea that non-engineers should not manage engineers. Since this idea reduces to nonsense at the limit, it seems worth being skeptical about it throughout its domain. 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.
• yuhong 9y ago
  This also reminds me of MBA CEOs that delegate everything, and that also reminds me of Jack Dorsey that is CEO of two companies.
• koonsolo 9y ago
  I worked for a lot of different managers in my career, both good and bad. At one point I was team lead, but didn't like it too much. 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.
• nathan_f77 9y ago
  I'm thinking about starting a tech cooperative where the members work on startup ideas [1]. Every member will have complete control to work on whatever they want, and there will be no managers or deadlines. I want to work with people who have enough motivation to fix broken tests and bugs by themselves. It's much easier when it's your own product. 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/1FAIpQLScfFzyzCWPresTMPSb4c13oUbcAZfeyit7muj5cCMvMu56Z2g/viewform https://docs.google.com/forms/d/e/1FAIpQLScfFzyzCWPresTMPSb4...
• jnwatson 9y ago
  The author’s example provide the counterpoint and the way forward with a non-technical manager. 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.
• andrewjl 9y ago
  Author seems to lose the distinction between project managers and engineering managers. The tricky thing is that some engineering managers do perform project management functions, but that will make for one overworked manager. In mainstream FAANG-type companies what you will see is: 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.
• deleted 9y ago
  [deleted]
• pankajdoharey 9y ago
  I have been saying this for years, but most consulting companies insist on managers who have no clue what they are talking about.
• temporallobe 9y ago
  On a related note, I just quit one of my contracts, but in this case a fellow developer was asked to become a SCRUM master a few months ago. The word "master" must have gotten to her head because that's what she thought she was. It turned into a micromanaging nightmare and she started trying to track my whereabouts and hours, even going so far as to tell me who I can and cannot talk to, as if she were a manager (but not even our CEO would treat me like that). I finally had to tell her she wasn't my manager and that we're equals. Well she didn't like that and told me "I'm the SCRUM master!" and that I don't understand the agile process. I had even talked to my actual manager about this the week before, who confirmed that yes, a SCRUM master is nobody's manager and cannot tell anyone one what to do. Things came to a head and now I'm outta there and all their objectives will now go red, all because someone who had some perceived power thought that they could skip years of training, experience, and wisdom, and go straight to "manager" (and a bad one at that).