9 ms·

Developers, your manager is likely clueless

• eljimmy 5y ago
  The best managers I have had were ones who had previously worked as developers. While the most clueless ones had zero programming background. I tend to encounter the latter in smaller companies that have revenue pipelines outside of tech and aren't entirely tech-oriented.
  • Trasmatta 5y ago
    A trend I see in tech is product managers who have zero technical experience or knowledge. I find this somewhat odd, and difficult to deal with as a team member. While it doesn't need to be their core competency, I feel like some background knowledge in the tech should almost be a necessity if you want to be leading development.
    • deleted 5y ago
      [deleted]
    • dpeck 5y ago
      Product managers aren’t (or at least aren’t supposed to be) developer managers and is not what is being discussed in the article.
      • deleted 5y ago
        [deleted]
      • ricardobeat 5y ago
        Depends entirely on the company, the titles and roles are frequently mixed up.
        • dpeck 5y ago
          Really? I’ve often seen HR not really understanding it, but engineering leadership ceding the people management aspects of the job to a PM is next level neglect.
      • cmiles74 5y ago
        I think the line is little more muddled and mushier than that. Where I work, the product manager runs the stand-ups and is responsible for writing and prioritizing stories as well as grooming the backlog. They seem a lot like the project manager to me. :-P
        • dpeck 5y ago
          The writing and prioritizing stories and backlog grooming is exactly what a PM should be doing. Leading the standups seems to happen often but I see it as an anti pattern. But talking about how the team builds systems, who’s doing the building, and things like that should never be within the domain of a PM.
      • oytis 5y ago
        Can't agree more. Product manager, product designer/architect, engineering manager and a team lead are distinct roles with totally different competences required. Companies that don't understand that are rarely good places to work.
    • fidesomnes 5y ago
      This is borderline sexism, report to HR immediately!
  • dmitriid 5y ago
    The best PM I had came from Customer Support, where he learned some scripting to automate tasks. So he wasn't really a developer, but understood the technical side of things. And he was really good at prioritising stuff.
    • ratww 5y ago
      People able to empathize with Customer Support or with Customers are always good at prioritising, IMO. You end up doing more bug-fixing and less architecture astronautics.
  • Waterluvian 5y ago
    Mostly true. Except that time I had an engineering manager who previously did embedded dev in the 90s and obsessed over all the wrong things for a bunch of Python and javascript projects.
    • dmd 5y ago
      Been there. I had a manager who would obsess for weeks about trimming a byte or two here or there in the metadata of a multi-gigabyte file.
      • dr-detroit 5y ago
        This line of thinking is demonstrably weak and yet I encounter it in 99% of pseudodevelopers I work with.
  • Alex3917 5y ago
    > I tend to encounter the latter in smaller companies that have revenue pipelines outside of tech and aren't entirely tech-oriented. These are often the best companies to work for though, because the tech teams are outside of the normal management structures and can do whatever.
  • wil421 5y ago
    My current manager was a dev for an old ASP stack. He may not be up to date on the newest stacks but is miles better than non tech/IT managers. When he needs to get out of the way he does and isn’t a micromanager. He also knows databases really well which helps out the team. Our former VP was a securities trader turned IT manager, who knows how he probably knew people, and was terrible.
  • lmilcin 5y ago
    > The best managers I have had were ones who had previously worked as developers. That is not my observation. Having some ability to program can definitely be a plus, but it is also frequently a hindrance, if the manager is not aware of the dangers. Best managers I had were just good at managing. They did not try to make technical decisions but instead tried to figure out a process to work with a collection of various experts that would let these experts to make best use of their expertise in context of the project. In other words, they were focused on making right conditions for people, team, project to succeed rather than focusing on making technical decisions. They tried to complement the team with their management expertise rather than trying to be lead developer. Ability to program (as in developer who has just been promoted to management role) is frequently a hindrance. It is a crutch that the new manager uses which prevents him from learning his new trade well. It lets him understand stuff without needing to communicate with the team, it lets him see through bullshit without having to build rapport and honest relationship and it lets him make passable decisions without consent from the rest of the team. Which works fine for a while but in the end tends to result in mediocre manager and team. Also a programmer manager frequently only ever learns to work with other programmers. This might be fine for strictly development team but leaves the manager out of the water when interacting with non-development teams, clients, etc.
    • silicon2401 5y ago
      I've also had a bad experience with a programmer turned manager. He micromanaged to a frustrating degree, almost checking things in as much detail himself as if he was the actual engineer working on the task. Additionally, he had a very hard time adapting his working and communication styles, and instead asked for a lot of things to be done his way or recommended his way instead of understanding and trying to help me with the things I was struggling with, which I always found backwards. My previous manager never even coded, while the manager before that was also still actively developing, and both had a much more personable yet effective style. Everybody has their pros and cons, but I just wanted to agree that being a programmer manager isn't necessarily good or bad.
      • lmilcin 5y ago
  • Frost1x 5y ago
    >I tend to encounter the latter in smaller companies that have revenue pipelines outside of tech and aren't entirely tech-oriented. These orgs also tend to treat all tech as cost centers (perhaps, correctly in their context of business). The more non-technical the manager, the more likely tech is a cost center and necessary evil, usually resulting in toxic development cultures.
  • dragonwriter 5y ago
    > The best managers I have had were ones who had previously worked as developers. I’ve had a few managers that did that, one of whom was very close to the absolutely worst manager I’ve had in any job. Understanding the work is a useful thing for a manager, and having done it is one way to get there. Understanding people is more important, and working as a developer is not much of a way to get there.
    • Trasmatta 5y ago
      Technical experience is naturally not going to turn a bad manager into a good one, but a good manager will always be better if they have technical experience as well
      • skeeter2020 5y ago
        IF they can resist the urge to jump in the pool with the developers, IF!
        • pc86 5y ago
          If there's enough work to actually justify a manager, they shouldn't have enough time to do much of anything. Maybe a bug or two that would otherwise go to a junior/weak mid.
          • eropple 5y ago
            I've found this to be a function of the team and the culture to too much of a degree to make a sweeping statement like that. If your team is one you can trust, and your managerial responsibilities align more with what I tend to call a "producer", you can be surprisingly personally productive. But it requires a team that requires guidance rather than motivation and a company that doesn't impose structure from above, and those are admittedly pretty rare. In some management roles I've had too many reports or too many reports who expected hands-on management and yeah, it becomes a full-time, full-time thing. In others--and, to no surprise, my preferred situation--it's much more of a "first among equals" situation where, yeah, a good chunk of my time is spent in meetings (clustered early in the week when I could) to firewall off my team, but it'd be rare to not be able to carve off a full day or two afternoons for deeper work, whether it's code or architecture or analysis. And in those roles it was usually necessary to write a good bit of code, because I'd been an IC before a manager and had done most of the work--and one of the artifacts of doing more work on it, then, was documentation and making it accessible for the next person.
  • irrational 5y ago
    I had a manager for the better part of a decade who was non technical (this was a Fortune 500 company). He was awesome. Anything we said we needed, he would get to us. Any technical decisions he 100% left up to us and trusted we knew what we were talking about. He mainly left us alone and spent his time trying to get us more money and running blocking to keep us from being disturbed. My current manager has a technical background. I now spend the vast majority of my work week in meetings. Not because my job has changed, but because they have so many meetings that we never had under my previous manager. Scrum, backlog, retrospective, one on ones, touch bases, etc. I seriously maybe have 5 hours a week to actually program these days. If we want anything, he is likely to say no and that we can get along with what we already have. He often has opinions on how we should do things based on how he did things years ago instead of modern best practices. Give me a non-technical manager any day.
    • sdoering 5y ago
      I learned long ago, that it really depends on the manager's personality and his/her understanding of the role. But also on the expectations being transported down from above. The problem is, imagine a company with your second managers mindset and his/her boss takes a look into the calendar, sees there are no management meeting tasks (Jour Fix, standup, and so on) in there. His/her boss would think he/she is not doing anything, because the signifiers that declare a manager actually managing are missing. I don't see these signifiers as actually managing - I see them as creating disturbance - but modern management culture seems to be seeing these signifiers as sign of real managerial work. I also find a lot of managers need to please their own ego by feeling they do something. They often need to feel important - hence too many meetings as signs of them having control.
      • irrational 5y ago
        I’ve come to the same conclusion. So many of these meetings seem to exist merely to give him the appearance of doing something and therefore justifying his job and salary.
    • skeeter2020 5y ago
      It doesn't really matter which perspective a manager comes from people or technical-oriented, their job is shield you from disruptions and remove roadblocks. Some of these are going to fit certain skillsets better but I think it's a mistake to define one or the other as universally "better".
  • NikolaNovak 5y ago
    Looking over the comments here I feel there's a lack of common definition and thus expectation. I've always personally found it useful to make a distinction between team lead and manager. The way I define them is team lead is the or among the most senior and experienced team members. They still do some hands on work, the high value stuff, and they support, coach train the team on technical stuff, do high level design and ensure it all adds up to coherent working quality something. Manager understands people, client, goals, process, company - how to support their team, how to protect the team, and how to get shit done - and crucially, how to get the right shit done based on company's and user's priorities. I find its crucial to distinguish the roles and expectations. One of the best managers I ever had I did not respect at the time - I judged them as a team lead and their tech knowledge was limited...but when they left - team fell apart, and shit I didn't know existed started hitting us and we got torn seven different ways.
  • skeeter2020 5y ago
    This is true and obvious, but before I became an EM I had great managers who were either technology or people-focused. Both can be good IF they recognize their skills & gaps, and mitigate accordingly.
  • cmiles74 5y ago
    Having worked with a lot of managers, it can cut both ways. Perhaps it's the lessons these managers learned (or chose to learn) when they were more directly involved in the development process that really matters. The people who came away from the experience with something like "the pace of change is rapid, keeping up is difficult, and some core problems may never be solved" seems to be much easier to work with than someone how chose to learn random facts like "caches are bad" or "caches are good" or "Oracle is the only real database server" or "Java is the only proper language."
  • Cthulhu_ 5y ago
    I think it's hit and miss. Yes developers will know the field, but they may lack the interpersonal and management skills needed, and they may not have the right personality; as a manager, you need to let go of technology, and you have to be able to deal with people all day long, sometimes with overtime as well. I mean not to generalize, but a lot of developers are neurodiverse introverts, the flavor that doesn't go well with typical management skills. I mean managers and sales and the like also have their own flavors of neurodiversity - to generalize, it's things like psychopathy (or the ability to suspend their own moral compass) and high extroversion.
  • deleted 5y ago
    [deleted]
  • corpMaverick 5y ago
    To be a good Technical Manager, you have to be good a the technical stuff and also good at the management stuff. You can also be mediocre at the technical stuff if you are really good at the management stuff or viceversa.
  • kiawe_fire 5y ago
    I thought the same when starting my current job (small company co-owned by two software devs), but this has proven false for me. The biggest problem I have is that, while both managers are OK software devs (but not great), anything I advocate for that is above their skill level is perceived to be “too complicated”, or “takes too long to do, let’s just get it done quickly for now”. So, instead of proper config files or method dispatching for client-specific behavior, we end up with if/else and switch statements with hard coded client primary keys. Then, when a huge bug comes along on a Friday at 5pm as a result of how we built the thing, I get to be the one to dig us out of the hole while my managers are busy “working on the next big feature” which will almost certainly be done just as poorly. So, conveniently, only myself and our customers ever get to experience the consequences of their decisions. And what can I do? I can fight to get my way, sometimes, on new features, but when “their way” becomes a problem, I can’t use it as an example to support my ideas or say “I told you so” without hurting feelings or going against the people signing my paycheck.
    • pc86 5y ago
      The Venn diagram of "OK software devs" and developers who think config files are "too complicated" are two circles a couple city blocks apart.
• deleted 5y ago
  [deleted]
• tyingq 5y ago
  Feels a bit cynical. Sure, it's annoying if your boss says: “So listen, I keep hearing about all these bugs. And I really think we need to put a stop to it.” Doesn't really mean he's clueless though. He's probably telling you that he is getting shit for bugs, and there's a company perception that the product is buggy. Ask questions and find out. And if that's the perception, help him with a pragmatic way to share the real story. My experience is that if the team isn't translating what they are doing, why, etc...upwards, then the boss eventually makes up something to measure.
  • dpeck 5y ago
    That’s probably a fair, if charitable, assessment. But if the IC is having to dig to understand what a manager means then the manager has failed at one of their core duties, being communication channels through the company. If someone isn’t a good communicator they’re definitely not going to be a good manager.
  • alistairSH 5y ago
    He's probably telling you that he is getting shit for bugs But being a "shit umbrella" is literally part their job. A good manager should be filtering inputs from external sources, tossing out the useless input, and translating useful inputs into actionable tasks or discussion points for the team. Instead of "stop coding bugs", the manager should be having a discussion about defect escape, test quality (across the spectrum of test types), and doing some self-reflection on whether or not task descriptions are adequate (if they only ever capture the "happy path" and don't describe desired failure behavior, it shouldn't be surprising there is undefined behavior in the software).
  • quadrifoliate 5y ago
    > Doesn't really mean he's clueless though. He's probably telling you that he is getting shit for bugs, and there's a company perception that the product is buggy. Ask questions and find out. And if that's the perception, help him with a pragmatic way to share the real story. I think this means he is clueless in the way that a developer asking "what is a for loop" would be considered clueless. Managing company perception of what your team is working on, and advocating for their work both in terms of features and fixing bugs is like Engineering Management 101. Doing all this "asking questions to find out" stuff is what the manager should be doing. > My experience is that if the team isn't translating what they are doing, why, etc...upwards, then the boss eventually makes up something to measure. Again, managers doing this are clueless in the same way that a developer "making up" syntax would be. They should be replaced by better, more clueful managers. I have absolutely no idea why we as an industry tolerate arduous coding tests and take-home projects for "individual contributors", but have a propensity to give people managers a free pass on obvious stuff like this.
• zerr 5y ago
  I hope orgs without managers will become more and more popular.
  • YPPH 5y ago
    Am I missing sarcasm or is this some reference I don't understand? The most successful organisations have managers, they just know how to manage properly. To state the obvious, an organisation of any significant size needs management.
  • ebiester 5y ago
    It's conceptually interesting. I'm curious as to what you believe a manager does, and how you think the 40-60 hours of work should be distributed throughout the organization.
  • eropple 5y ago
    "Organizations without managers" of any significant size invariably develop a shadow hierarchy where some people do the work of managers and end up in meetings of people who are Not Managers, except that they're, surprise--actually managers, without the title. I consulted for quite a while and have worked at my share of companies and I have never seen implicit shadow hierarchies result in healthy dynamics in and across teams.
    • YPPH 5y ago
      Well put. I can see those shadow hierarchies exploding when somebody who is de facto manager eventually (and inevitably) has their de facto authority challenged. A transparent hierarchy is not only more workable, but it seems to me to be a lot fairer.
    • refsab 5y ago
      I'm guessing he means something like this https://hbr.org/2011/12/first-lets-fire-all-the-managers https://hbr.org/2011/12/first-lets-fire-all-the-managers Or any of these https://www.happy.co.uk/blogs/16-companies-that-don-t-have-managers/ https://www.happy.co.uk/blogs/16-companies-that-don-t-have-m...
• alistairSH 5y ago
  Are there any name-brand companies (or even largely unknown but reasonably successful companies) that have managers as described in this blog? Does this tend to be a big consulting problem vs "pure software" companies? I can certainly see this being the case someplace like Booz or Deloitte, based on anecdotes from friends that work at those companies. I've been with the same employer for ~20 years, so obviously a limited experience, but I'd guess 80% of our SDMs were developers themselves and the remaining 20% had complementary roles within dev teams. I've yet to find a manager who was "just an MBA" with little experience as a development team member. Maybe I just lucked into one of the good companies?
  • junon 5y ago
    > Maybe I just lucked into one of the good companies If you have a good manager, then yes. You did.
• rmnclmnt 5y ago
  And then there is the manager in the middle that had a previous tech background from 10 years ago but never took the opportunity to keep up. This type of guy tries to explain to you the task at hand used to be done in a matter of hours when he was still coding himself, and does not understand why it can’t be the same now. Yead grandpa, I know, I’m stupid. So here you go, here is the keyboard, show me your skill so I can learn from the best! (Actually the best manager I ever had was really technical and was showing and teaching me stuff in a peer programming fashion!)
  • halfmatthalfcat 5y ago
    Absolutely the worst and most of them drove me out of the company due to their incompetence.
  • flohofwoe 5y ago
    It's a valid and interesting question though why the same task implemented in a 'professional environment' today sometimes (often?) takes many times longer with worse results than 20 or 30 years ago in a small team and with development tools that were much more primitive than what we have today. Why can't it be the same now, indeed? Everything should be faster and easier in modern programming languages, frameworks and tools, but very often it isn't. Why?
    • grandpa23515 5y ago
      To be fair, some of the "bloat" can be the fault of developers who wants to use the latest framework that requires a lot of time to learn how to use correctly. New frameworks also often has bugs, issues and poor 3rd party support. I'm not against learning new tech as part of the job, as it can be a motivating factor for the developers. At the same time we can't ignore that for a startup, it is probably better to use a known technology so that they don't end up fighting the framework as their needs grow beyond the basic tutorial/blog post Here's a suggestion: If someone finds themselves sending multiple patches to the framework or implementing missing database libraries, they may have chosen the wrong framework/language. It can be very motivating, but the time could have been spent on improving the product.
• Taylor_OD 5y ago
  Most managers are bad because most managers core skills are not management. Many engineers complain about non technical background managers but many people will note that even managers with technical backgrounds skills soon become irrelevant. It's the ability to actually manager people, and further projects, that actually makes a manager good or bad. Unfortunately you rarely get to evaluate your manager properly before starting a new job and there is no guarantee that they will be there for any length of time once you do start. Having a good manager feels like winning the lottery.
  • halfmatthalfcat 5y ago
    I feel the opposite, most (engineering) managers/directors are bad because they've either lost their edge and having coded in years (or decades) and cannot appropriately respond to team issues or they were never technical to begin with. Easiest way to lose a locker room is having a manager/director who is technically inept.
    • libertine 5y ago
      Now I'm confused: is the manager supposed to solve technical problems? >Easiest way to lose a locker room is having a manager/director who is technically inept. For example, there are plenty of excellent soccer coaches that have never played soccer. This type of thread shows up every couple of months here, and people use their anecdotal experience to define a whole role (which is different within itself and between organizations), which just feeds prejudice about a particular type of people, non-dev managers. When in reality you have great managers from both technical and non-technical background.
      • halfmatthalfcat 5y ago
        Depends more on the team than the person tbh. Sure you can have a great manager in either lane but if they don't gel with the team, it's ultimately going to fail. Most of the teams I've worked on don't want people managers in the chain of command, obviously anecdotal.
    • 5y ago
• pmjones 5y ago
  See also "All You Jokers, aka How To Train Your Manager". Slides: http://paul-m-jones.com/talks/how-to-train-your-manager.pdf http://paul-m-jones.com/talks/how-to-train-your-manager.pdf Video: https://vimeo.com/80271777 https://vimeo.com/80271777 (I am the author/presenter.)
• OneTimePetes 5y ago
  My manager is clueless, but sets me up with doomed projects, where he then sweeps in to save the day, by changing the scope and removing features or renegotiating goals with the customer. PS: Most management gets there coding experience from excel. So copy & pasta code is good.
  • jf22 5y ago
    Scope negotiation and changes happens at every org.
• fatboy10174 5y ago
  A colleague and i literally going through this now, as im reading .. just ticking boxes. haha
• ramijames 5y ago
  This is something that we talked about during our last podcast where we interviewed our CTO. He believes that a flat hierarchy in an organization is a way to solve for this. There are good and there are bad managers. An organization needs to compensate for this. If you're interested: https://www.youtube.com/watch?v=AflK5qst1qc https://www.youtube.com/watch?v=AflK5qst1qc
  • skeeter2020 5y ago
    IME flat hierarchy == shadow hierarchy. You're still going to get one and I believe intentional > accidental, even when it comes to making mistakes.
    • ramijames 5y ago
      The thing is that a strict hierarchy is enforceable. A shadow hierarchy is one that can be circumvented if needed. If the organization encourages lower level devs to "skip" up hierarchy levels if needed then they do. If a bad manager doesn't like it, they can take it up with the dev but in that case the dev hasn't really done anything wrong at all. It's largely an issue of company culture.
• dboreham 5y ago
  Kind of a low-value article full of Dilbert-style foibles. I've observed managers who had very little knowledge of the tech, but were excellent at critical thinking, sensing BS, and "managing up".
• davidivadavid 5y ago
  Pretty low-effort blog spam stroking developer ego about being (yet again) the smartest people in the room and everyone else being monkeys. The inferiority complex is kind of tiring.
  • JeremyBanks 5y ago
    Aye. The folks I've worked with who most insisted that managers were useless were the ones who most badly needed supervision.
  • _hao 5y ago
    Classic case of https://www.urbandictionary.com/define.php?term=STEMlord https://www.urbandictionary.com/define.php?term=STEMlord
• skeeter2020 5y ago
  If all us managers are going to get painted into this very unflattering box I guess we can do the same with the developers we're expected to manage. Prior to my management life I completed an applied Comp Sci degree and a MSc in SW Engineering. I have 10+ years of development experience, code regularly and obsess of staying technical relevant, while stile recognizing my huge weaknesses and leaning on domain experts whenever possible. Contrast this with the coding bootcamp grads with < 2 years experience who think they're "Senior Software Engineers". #PROUD-DINOSAUR
  • jtdev 5y ago
    You're clearly not the manager that this article is referencing.
  • tluyben2 5y ago
    They do say 'likely'. 'Likely' your devs are clueless too. Competent people vs incompetent people is not 50/50.
  • iratewizard 5y ago
    I'm in a similar boat with 16+ years experience and 3 directing a department. The vast majority of candidates are contemptible. The good candidates that get hired are not without their own problems. Creating a "fuck the management" or "fuck these talentless kids" environment only ensures that the generation that takes over after us will not be prepared. I hope agitprop articles like OP's will be replaced with a little bit of common sense.
    • slantyyz 5y ago
      > ensures that the generation that takes over after us will not be prepared Recently there was a post on the front page here about managers making jokes about firing their employees. From what I remember, most of the comments were a variant of "that's great advice". I'm older than the average demographic here, and I have to say I was taken aback by those comments, because I thought that type of thing would be common sense (the Golden Rule).
  • 5y ago
• wppick 5y ago
  For a software project, you need 2 main people to run it effectively: - a tech lead who is intimately familiar with the code being written, who keeps the code design/architecture on the right path, and oversees all the work being done. This person can make great strategic decisions about how to schedule the work to find opportunities to group common work together, divide the work so that people are not working on top of each other, and make decisions taking in the long term health of the codebase and short term delivery pressures. - a business/product expert. This person prevents the tech lead from being in endless meetings. They sit down and figure out the requirements for the product/project. The clearly communicate these requirements in documents condensing the endless meetings into a coherent clear vision for the product with the long term vision and short term priorities being made clear. The tech lead uses this condensed information to plan the software development. You cannot have one person do both of these things. The tech lead cannot be in endless meetings and keep the needed level of intimacy with the codebase and properly direct the work being done. The business/product expert needs to be an expert communicator, to make that interface between the tech lead and business/product requirements effective. They need to be able to ask the right questions to get the information about what needs to be built, and then clearly paint that vision to the tech lead. The business/product expert does not create tickets of work to be done! They just communicate the vision. The tech lead breaks the work down strategically.
  • bgroat 5y ago
    This is the best case for a CEO/CTO relationship. The CTO shouldn't be writing code, it's too low leverage. But they must be ABLE to write the code at least 80% as well as the best person actually writing. The CEO should be speaking with all of the key stake holders, and then having strategic conversations with the CTO as equals
    • aiisjustanif 5y ago
      > But they must be ABLE to write the code at least 80% as well as the best person actually writing. The CTO? The CTO of what type of company? You’re having a laugh if it’s anything other than a startup or medium sized tech company.
• sidlls 5y ago
  My current manager is very technical, we work in a FAANG level company, and he was an IC not so long ago. He's a micromanager sort, suggests it's okay if people want to work over holiday days, and tells people regularly they should be thinking about how to contribute at all times (while they're home eating dinner, taking a shower, on the commute, etc.). He's the second worst manager I've ever had. The worst was also a former engineer, but he liked to play politics, lied about just about everything, and regularly blamed delays and failed projects on his team. No engineer was spared--every single one of us ended up with negative comments on our performance reviews for periods where we were assigned to high visibility projects. It got to the point where nobody on the team wanted to work on any such project. This guy was promoted to a director position eventually. Some managers suck. Some don't. And it doesn't matter if they've ever been an engineer or not. Also, engineers aren't special here: talk about egos and negative, hyper-competitive behavior....
  • commandlinefan 5y ago
    The managers who are most liked by their subordinates are the ones who are the least jerks. The managers who are most liked by their superiors are the biggest jerks.
• slantyyz 5y ago
  If your manager is clueless, doesn't it mean that the person who hired the manager (presumably the manager's manager) is clueless too? That would strike me as the larger problem, since the manager role is likely going to be filled by the same type of person over and over again.
• WaitWaitWha 5y ago
  I will be counter argumentative. In general, I think developers make even worse managers. I will not discount that there are many 'managers' who, despite their college degrees, lack the ability to manage. That said, managers do not need to know how to do what their staff does in a nuanced details. If they do, the manager is prone to micromanage, or second guess their staff. After decades, I still have to bite my tongue in meetings where there are two-way, technical decisions and allow my teams to come to their conclusions. (edit: wow. Turns out not so counter after-all.)
• 13of40 5y ago
  Kevin replied, “Stop the bugs, we need to stop putting bugs in...and the way we're going to do that is first, stop paying lip service to code reviews, second, actually take some time to write unit tests for each feature, and third, quit deploying to production from your freaking dev box, Hank!"
• daseong 5y ago
  While there are some good observations in the article, and while I agree with the detrimental effects the observed behaviours have on the effectiveness of teams, I feel there is also a missed opportunity of understanding the manager's perspective. If we start with the basic assumption that people will rarely try to do intentional harm, we can conclude that most harm is done unintentionally. So while the choice of the term "clueless" might apply, it also doesn't help with creating a path towards mutual understanding. My current perspective on how we think and work is that we all have a mental model of how the world works. It is modified and reinforced by our actions and the effects we perceive. We will then try to apply our model to novel situations. I find the term "clueless" to not be accurate. It is more that people act mostly based on clues. But it might very well be that the mental model is inaccurate or even inadequate. I don't think the simple quality "has been a developer" is a sufficient indicator to predict a manager's success. I find the trait "is flexible adjusting the mental model" might be more fitting, but also harder to discern from a CV. So my critique to the author would be in a similar class of error. Applying an inadequate mental model to solve the problem. I believe we could all benefit from more goodwill and empathy towards our team members (and I am including the manager in the team, as well as the whole organization). Asking "what is our mental model and where does it break down?" has been tremendously helpful for me in the past.
• eeZah7Ux 5y ago
  > “Stop the bugs, we need to stop putting bugs in.” > Focuses on Jira metrics, praises people for completing “lots of Jira tasks” This is not a problem of ignorance. It's a problem of micromanagement VS trust. Managers create arbitrary requirements and productivity metrics in order to apply the carrot-and-stick method. It's about power and control. > So, as a developer, what can you do? Not much, unless you have a good shot at getting the manager removed without hurting your career. You might be tempted to somehow educate your manager Not at all. A team of developers can go very far in pushing back against micromanagement. But only if you stick together and send the same message, consistently: 1) trust us to do our job and organize our priorities, as you would expect from any other professional 2) trust us to peer-review our work and productivity 3) provide us with training, time and resources as requested 4) protect the team from unreasonable pressure from upper management and other teams 5) if you provided 1,2,3,4 and we fail systematically, move people to other teams or fire them
• emma-w 5y ago
  LOL, why is my article flagged? I mean, I sort of love the notoriety, but still, why?