17 ms·

Introductory bullshit detection for non-technical managers

139 points by sambeau 9y ago

threepipeproblm 9y ago
This piece is chock full of ridiculous advice. >> “I’m making a generic version of…” >> It means: I don’t understand the constraints of the actual problem, so I’m going to design an even bigger problem that we have no way of verifying the efficacy of. Yes, just tell the non-technical managers that "generic" means technicians have no idea what they are talking about. No matter what the problem is. That should make for a better world. Whereas "refactoring" is only a "yellow flag". Run away.
- JonRB 9y ago
  This was my reaction. This article seems to be training people to get their engineers to devlop completely unmaintainable projects, and generally make the managers trust the engineers less.
- Tloewald 9y ago
  I think it's healthy to be skeptical of people claiming to be solving a more general problem than the actual problem at hand (which is a large fraction of the advice in this article). Unfortunately, a non-technical manager trying to drill down into an argument about cross-platform, generic, or framework solutions to problems is quickly going to get lost and/or piss off engineers.
  - xyrnoble 9y ago
    Non-technical managers often fail to account for the Inventor's Paradox [1]. They assume more general solutions will necessarily require more resources. This is often not the case even if you ignore the resources which would be allocated to problems (solved in the general case) that you do not yet have. 1: https://en.wikipedia.org/wiki/Inventor%27s_paradox https://en.wikipedia.org/wiki/Inventor%27s_paradox
- aatchb 9y ago
  Indeed. I have colleagues that end up writing the same god damn code over and over again because they fail to appreciate the idea of 'generic' code and 'frameworks'.
- rimliu 9y ago
  To quote ironic remark from "Uncle" Bob Martin: > Why do we write the code that slows us down? > And the answer to that is "Well, because we had to go fast! https://youtu.be/QHnLmvDxGTY?t=956 https://youtu.be/QHnLmvDxGTY?t=956
  - jaclaz 9y ago
    Which is probably a modern version of the classic Blaise Pascal's quote: "I'm sorry I wrote you such a long letter; I didn't have time to write a short one." https://www.quora.com/Who-wrote-the-quote-If-I-had-more-time-I-would-have-written-you-a-shorter-letter https://www.quora.com/Who-wrote-the-quote-If-I-had-more-time...
tentakull 9y ago
tl;dr. How about not having non-technical managers LOLOL
booleandilemma 9y ago
How do non-technical people become managers of engineers in the first place? It seems like something we should try to avoid.
- bdcravens 9y ago
  "We" should find managers that best facilitate the engineers meeting the objectives of the business, whether that person is non-technical or not. (though I tend to agree that some technical grounding is important)
  - brandonhsiao 9y ago
    You are technically correct, but unless you are building something where the technology actually doesn't matter much (e.g. a relatively simple web app where most of the business is done in the physical world), it will mostly be technical managers who best facilitate engineers meeting the objectives of the business, because they have such a huge advantage over nontechnical managers while there's nothing nontechnical managers have over them.
- gregmac 9y ago
  The non-technical person above them hires them -- probably because they "speak on the same wavelength" or something.
- IncRnd 9y ago
  Many times it happens due to the manager having a track record for getting projects completed on-time.
- imron 9y ago
  I disagree, one of the best managers I had was a non-technical manager. He was able to guide me back on track when I was veering too far into the 'interesting problem for the programmer, but not what the business is trying to solve' territory and also was able to clear obstacles out of the way to let me work on what it was I needed to be working on.
eight_ender 9y ago
As a technical manager this article bugs me because it's pointing to issues with hiring that are only being made worse by having a non-technical manager. You need to hire developers that are professionals capable of being independent, and most important, responsible. If you have developers that aren't accounting for simple things like memory or performance then you have a problem with that employee. It's something you can coach, and if that doesn't work out, then you let them go. Having a non-technical manager makes this worse because you can't spot the problem early, and the developer doesn't have the strong sense of oversight that comes from the boss being able to read your pull requests.
- kenning 9y ago
  Yeah but a good technical manager is out of most companies' budget.
  - techer 9y ago
    I think you've hit the nail on the head. Or they simply haven't budgeted for it. I was paid far far less but carried the fallout for not delivering.
analog31 9y ago
Ironically, pretending to ask intelligent questions when you're clueless about the subject matter is a form of bullshitting.
- ryanSrich 9y ago
  Yeah that's exactly how this article reads to me. Like here's a list of questions you can ask that you'll likely not understand the answers to...ok.
- gamesbrainiac 9y ago
  This nails the whole situation on the head. Understanding the context is really the most important part to solving the problem.
piyush_soni 9y ago
Ironically, this looks like a bullshit article to me. I have no idea what is the experience level of the author, but as a senior developer, several times I have "created a framework" (and a quite useful one at that) which not only made the problem solving manageable for myself, also resulted in clean readable code which is maintainable for others in the team as well. Also, don't underestimate the real need of refactoring at times. There's no red/yellow flag here. Sure, we can keep postponing that and create bigger mess - which is a decision we do have to take at times to avoid last minute bugs, but that still doesn't mean the developer is bullshitting when he says he needs to refactor some old ugly code.
- eddigo 9y ago
  If you're a competent programmer who uses these terms and phrases, then indignation is not an unreasonable reaction. However, I think it's a completely valid article if you've ever experienced the interactions between an unproductive programmer and their non-technical manager. I've witnessed this dance every week for the past 3 years. The programmer in this case has used every one of those phrases except "platform independent".
  - piyush_soni 9y ago
    The thing is, you just can't detect a programmer is bullshitting by just hearing those terms - thus making it a misleading article. There are all sorts of programmers out there - those who use these terms and work a lot (on those things), those who don't use them but still work on them, those who use these terms but don't actually work satisfactorily, and those who neither use these terms nor work. Correlation is not causation here is what I want to say.
    - eddigo 9y ago
      I took the article context as a non-technical manager wondering why a project wasn't complete after using a good deal of resources. Usually "bullshitting" refers to the tactics engineers, or employees in general, use to explain why they aren't done when they should be. If engineers are using these phrases and projects are being completed, then you can assume they're not bullshitting.
kpil 9y ago
Having worked 20 years, I'm getting me and more tired of one thing: a meeting that includes a manager that you need to explain every obvious thing to. It's no problem with clients, stakeholders, new hires, or even unreasonably thick coworkers, but a manager that having less than a minimal domain knowledge trying to 'summarize' or 'weigh together' a lot of things they do not understand is just so utterly unmotivating. I have the research on my side: the most influential factor on job satisfaction is if your manager can do your work. https://hbr.org/2016/12/if-your-boss-could-do-your-job-youre-more-likely-to-be-happy-at-work https://hbr.org/2016/12/if-your-boss-could-do-your-job-youre...
- smallnamespace 9y ago
  The flip side is that it seems very difficult to find competent coders that are both competent at and interested in managing other people. Good coders are expensive and rare; paying an even larger premium for a good technical manager is so painful for the bean counters that they inevitably push non-technical people into that middle management role.
  - troels 9y ago
    I'll wager to say that a good technical manager need not be a stellar coder. I've worked with people who were "business" people on the face of it - went to business school, had a career of management/administrative positions etc., but who had a deep technical understanding. All of them had at some point veered in the direction of becoming a programmer, but then changed course. I'm sure they would have become fine programmers, but they just chose not to.
  - usgroup 9y ago
    Think you might be talking about founders here.
  - sokoloff 9y ago
    I wonder how much of that might be people who realize they will never be a truly world-class technologist, and so try management as a path where they might make their next career progression. (IOW, a scheme on the part of the new manager not the bean counter, or at least a symbiotic scheming.)
learc83 9y ago
You wouldn't want a manager working in finance who didn't understand a bit about finance. You don't want senior programmers working in finance who don't have some domain specific knowledge. Then why is it OK for completely non-technical managers to manage programmers? I get it, management is a separate skill set, but spend some time and learn your domain.
- coldcode 9y ago
  I was once worked with a technology project manager (in this company they were more like junior CTOs) who said he didn't need to understand technology, he managed people. Of course he also made all the technology decisions.
- Theodores 9y ago
  This is an interesting idea that can be turned on its head. So if you are stuck with a 'non-technical manager' then you should be able to get that changed, if you would prefer the manager of the guys that do the office cleaning then you should be able to get managed by them, or anyone else with these 'manager skills' that so elude developers. Then you should be able to avoid being micromanaged by a non-technical who pretends they know something of your domain.
untangle 9y ago
If this methodology is overused, you will have your PM/dev team rebelling or leaving in a hurry. That said, I can see a trimmed-down of this used as an evaluation tool for more substantial product development decisions. Ideally, these questions would be posed to a PM or dev manager and not directly to a coding team. I also believe that the article is a good training piece for new(ish) general managers that have dev teams reporting to them. Along these lines, the listed criteria are a good thing to keep in mind for those GM's who (like me) sit in on product meetings while remaining fairly inactive. IOW, the GM can listen-in and try to passively assess whether the team has a handle on these points. If not, address surgically and offline with the right folks.
juiyout 9y ago
Can't non-technical managers study up? The wealthiest entrepreneur and fierce manager in Taiwan back in 60s/70s was a man who only finished elementary school during war-torn Taiwan. But he could detect bullshit miles away. After Chinese nationalist took over Taiwan from Japanese, he started petroleum cracking business. One interesting anecdote was that a science guy was presenting to him some shiny new process with some fancy reaction formulas. He frowned and whip out pencil and paper. He started to pick apart the scientist's formulas and mansplained to that scientist how that process may not work in his plant due to this and that in your equation requires this and that, which is too costly, etc. That scientist lived to tell the tale.
- chipperyman573 9y ago
  >He started to pick apart the scientist's formulas and mansplained to that scientist how that process may not work in his plant due to this and that in your equation requires this and that What does "mansplained" mean in this context?
- megablast 9y ago
  > Can't non-technical managers study up? Of course they can. Are they going to is the question.
mruniverse 9y ago
For the longest time I took it to be the norm that a manager is mostly there to pressure you to work, to get things done well and on time. Then I had a manager (he was technical) that actually helped solve issues. He didn't have to touch any code, but he had good suggestions. He knew what he was doing. He felt like he was in it. He was part of the team. He didn't just throw problems at you to solve. He was trying to help solve them himself.
ilyanep 9y ago
A lot of commenters here focusing on the non-technical manager bit and ignoring a lot of very good advice that's in here even for technical people. > Ask: Who specifically will represent the users of this system? You should expect your team to tell you who they are actually creating something for. Who will directly benefit from the work. And a real life individual person they will consult with on questions and who can verify it meets their expectations, at least. If your team is working in a vacuum, it’s a sure sign they’re working on the wrong thing. I've worked on teams where the person in charge of what features would be built had a "vision" and refused to ever actually iterate with users. Result: A thing gets built that nobody wants. > Ask: What are you not doing instead? Real life is all triage and trade-offs. You need to understand what’s not happening so you can communicate that to interested parties. And so you can make sure the right trade-offs are being made in this case. One of my biggest pet peeves in people making decisions is when they refuse to do the actual explicit analysis of costs, especially opportunity costs. Sure, you're laying groundwork for a good thing to happen in the future, but you're also costing that team the work of doing that and the rest of the group a bunch of work figuring out your new code layout. I can get behind it if I get a sense that people did the cost analysis but when the decision seems made willy nilly in a "this seems like it has a benefit" kind of fashion, it's really annoying that I'm spending time having to work with that.
deleted 9y ago
[deleted]
flohofwoe 9y ago
I think some context is needed: this post is written from the perspective of video game development where teams are composed of people with extremely broad skill sets (from the extremely artistic to the extremely technical to the extremely business side with everything inbetween). It is not uncommon to have managers there with a purely artist or purely business background working directly with the programmers. Also, the video game industry has its share of bullshitters like everywhere else, the bigger and more 'professional' the company, the higher the relative amount of bullshitters. Personally I think it's better to have no manager, than having a manager who doesn't have the slightest grasp of the areas the people in his team are working in, since there will just be too much time lost with communication and making sense of each other.
tilolebo 9y ago
I feel half of this article should be seen as project management basics for new technical managers with no PM skills. It's very easy to forget the goals, value and cost when you understand the technical part of a project.
DustinOfDenver 9y ago
Non-technical managers... needs to be a thing of the past. No one considers a guide for "Managers who cannot read, but must supervise writers" as meaningful article worth writing. Being "non-technical" should be synonymous with being illiterate (if you are in a technical field that includes supervising technologists). The topic is no longer something to be assigned to "nerds in the basement" is is the language of business and life.
- DannyB2 9y ago
  I was going to write something similar. A manager of anything, including technology, should have an understanding of what they manage. Not having that understanding is the fundamental problem. Any kind of "guides" to help such ill equipped managers is only a band aid that doesn't fix the actual underlying problem. Technical managers may cost more an be harder to find. That might just be the cost of not screwing up things in major ways. Including potentially business destroying ways. An additional clue: Not just the immediate managers of the worker bees, but going up the chain of management there should be people who understand the technology. Nobody would accept the idea of a manager that didn't understand the business they are in. If technology is part of your business, and you don't understand technology, then you don't understand the business you are in and shouldn't be a manager.
  - DustinOfDenver 9y ago
    Excellent follow up! I know a few product managers who think that managing a technical product can be reduced to entries in a backlog... and features are somehow separate from the technology that drives them. What the miss is... Technology "IS" the product.
    - DustinOfDenver 9y ago
      If what you directly manage is technical... then you must be technical and be able to communicate those opportunities up. I don't think anyone is suggesting that the entire management chain must be technical.
  - 9y ago
hartator 9y ago
Or "How to micromanage your engineers while not knowing anything technical."
infinity0 9y ago
Unfortunately this article is totally useless. A non-technical manager is going to read this: > When someone on your team says… >> “I’m making a generic version of…” >> “I’m creating a framework to…” >> “It’s platform independent.” >> “I’m adding this to make sure it’s future proof.” >> “I really need to refactor this bit…” and then assume that they should fire anyone that mentions these words. In reality, it's always dependent on context and the article specifically does not talk about the technical details that non-technical managers need to learn, in order to judge these situations correctly.
- sverige 9y ago
  I worked for a really outstanding manager. She told me stories of a previous job where she managed a help desk group for a database application. She does not know how to code, but she does know how to motivate people to do their jobs. She got the team to reduce the average time to close tickets by 75%. Customer satisfaction ratings vastly improved at the same time. The stories of the kinds of things she had to do in order to get a bunch of sullen, lazy, overpaid programmers to do their fucking jobs (her words) were hilarious. I learned a lot from those stories. And btw, she has never again wanted to manage "technical" people again. Every time one of these "how to" articles for middle managers pops up here, a variation of this response almost automatically appears. The truth is that most technical people know nothing about the nuts and bolts of management, but think somehow that they either do know or are exempt by virtue of knowing how to code. The only group that is worse for this sort of ignorance is lawyers, in my experience. I know it is somewhat unpopular to champion the value of having competent management, especially when companies reach a certain size. It's a lot easier for those who have never been managers to simply curse all of them as roadblocks to realizing the fruits of their genius.
  - Bartweiss 9y ago
    I don't disagree with you, but I don't really understand how this relates to the parent comment? It's certainly true that good management is a complex skillset, and if managers underestimate programmer's skills then the reverse is also likely. It's true that in some contexts non-technical managers can manage technical teams (and in some contexts they certainly can't). But... none of that makes this article good or useful. It doesn't negate the parent comment at all. This article is bad, and it's aimed at non-technical managers who aren't functional. I suspect your outstanding manager didn't use "what are the memory constraints?" like a magic spell of management, because despite the article's sweeping generalizations ("most common... any system"), there are a lot of contexts where that's literal gibberish. I'm willing to bet she didn't keep a list of words to interpret as "I'm a useless hack". That's basically what this article advocates. Like... "Generic version" translates to "I don't understand the problem"? Really? Last time I said that, it was "I'm making a generic version of our branded UI so the new clients can put their logo in it". That's not even a technical answer, but it still goes on the 'red flag checklist'. I could keep that list going. And the obvious reply is "these are just tips, don't overuse them where they don't apply!" But then what was the point? Knowing when to ask these questions is the entire task of management, and this article is aimed at people who can't do that.
kdelok 9y ago
I can't really comment on non-technical managers, as all of the management at my company are former (and current) developers. However, this list itself doesn't seem like a bad set of questions for a developer to ask themselves, let alone a manager ask the developer. We all know that it's all too tempting to fix the problem we want to fix, rather than the one that needs t obe fixed.
maxehmookau 9y ago
Oh great. Let's tell managers that wanting to refactor is a yellow flag. What a terrible idea.
scriptkiddy 9y ago
TLDR; How to be the Pointy Haired Boss.
jeffdavis 9y ago
Management is (and should be) different for businesses where engineering excellence is a necessity versus businesses that just need competent/efficient technical solutions to non-technical problems. This article is clearly about the second type of business. And it's designed to defend the second type of business against programmers who think they work for the first type of business.
- nartz 9y ago
  Kindly disagree. If a business has a need that is critical to the business, not hiring a person with technical experience to manage technical things is just a mistake (or the business being lazy). I dont understand the shying away from hiring a qualified individual here. The fact is, its 2017 and there actually are a fair amount of qualified technical managers who can communicate and fufill the role. Many other comments have pointed out various analogies in other fields that reinforce this.
  - jeffdavis 9y ago
    If the business's primary objectives are non-technical, there will be some level of management that is non-technical, and they need some guidance. This article isn't the greatest, but it doesn't seem terrible to me. Note that "technical" is a matter of degree and relative to the team being managed. It doesn't necessarily mean they dictate their emails to their secretary.
jorgeleo 9y ago
I was happy with the article content until I got to the examples. These examples promote been suspicious of everything and treat the technical people as non-professionals. So I took exception on it. “I’m making a generic version of…” It means: I don’t understand the constraints of the actual problem, so I’m going to design an even bigger problem that we have no way of verifying the efficacy of. BS. One of the most successful projects that I have delivery was so BECAUSE I started with a generic version of the core business concepts, and then I made a specific version for the different intra-department routings. There was more investment up on front, but it was recovered with gains at the end. Extracting the cross-cutting concerns into more generic versions is the right way to go. “I’m creating a framework to…” It means: I’m not interested in solving the actual problem, so I’m going to create something else so that the person that actually will solve the problem has to also fix the problems in my stuff on top of that. Same thing, is the cross-cutting concerns are implemented in a common framework, then you will have a high level of code reuse. “It’s platform independent.” It means: I literally have not spent two seconds thinking about what platforms this will obviously not work for. Sometimes you don't need to cover all platforms, but a few ones. So I might have to think what platforms will not work for and I still need to make it platform independent. “I’m adding this to make sure it’s future proof.” It means: I believe in fairies. One of the biggest compliments that I get from my work is exactly this: It has been 10+ years and we are still using what you created and finding gems in your code. If you have not received this kind of compliment either you are too young to write this article or know very little about architecture “I really need to refactor this bit…” When you hear “refactoring” it’s a bit more of a yellow flag. Technical debt is a real thing that needs to be addressed and that you should be aware of. I cannot count how many times I have found myself in front of the question "Can you fix it?" and answering "This is such spaghetti code that I would really need to rewrite it, let alone refactor it. I seem to me that these kind of recommendations are for a specific niche of software development. Enterprise (not enterprisey) level development, can have valid counterexamples for all and each one of what was described in the article.
draw_down 9y ago
That sounds like a very frustrating and untrustful interaction with one's manager. Good luck hanging on to your team members with all that. But the important thing is that you understand, because you're the manager! Right?!

139 points by sambeau 9y ago

This piece is chock full of ridiculous advice. >> “I’m making a generic version of…” >> It means: I don’t understand the constraints of the actual problem, so I’m going to design an even bigger problem that we have no way of verifying the efficacy of. Yes, just tell the non-technical managers that "generic" means technicians have no idea what they are talking about. No matter what the problem is. That should make for a better world. Whereas "refactoring" is only a "yellow flag". Run away.

JonRB 9y ago
This was my reaction. This article seems to be training people to get their engineers to devlop completely unmaintainable projects, and generally make the managers trust the engineers less.
Tloewald 9y ago
I think it's healthy to be skeptical of people claiming to be solving a more general problem than the actual problem at hand (which is a large fraction of the advice in this article). Unfortunately, a non-technical manager trying to drill down into an argument about cross-platform, generic, or framework solutions to problems is quickly going to get lost and/or piss off engineers.
- xyrnoble 9y ago
  Non-technical managers often fail to account for the Inventor's Paradox [1]. They assume more general solutions will necessarily require more resources. This is often not the case even if you ignore the resources which would be allocated to problems (solved in the general case) that you do not yet have. 1: https://en.wikipedia.org/wiki/Inventor%27s_paradox https://en.wikipedia.org/wiki/Inventor%27s_paradox
aatchb 9y ago
Indeed. I have colleagues that end up writing the same god damn code over and over again because they fail to appreciate the idea of 'generic' code and 'frameworks'.
rimliu 9y ago
To quote ironic remark from "Uncle" Bob Martin: > Why do we write the code that slows us down? > And the answer to that is "Well, because we had to go fast! https://youtu.be/QHnLmvDxGTY?t=956 https://youtu.be/QHnLmvDxGTY?t=956
- jaclaz 9y ago
  Which is probably a modern version of the classic Blaise Pascal's quote: "I'm sorry I wrote you such a long letter; I didn't have time to write a short one." https://www.quora.com/Who-wrote-the-quote-If-I-had-more-time-I-would-have-written-you-a-shorter-letter https://www.quora.com/Who-wrote-the-quote-If-I-had-more-time...

tentakull 9y ago

tl;dr. How about not having non-technical managers LOLOL

booleandilemma 9y ago

How do non-technical people become managers of engineers in the first place? It seems like something we should try to avoid.

bdcravens 9y ago
"We" should find managers that best facilitate the engineers meeting the objectives of the business, whether that person is non-technical or not. (though I tend to agree that some technical grounding is important)
- brandonhsiao 9y ago
  You are technically correct, but unless you are building something where the technology actually doesn't matter much (e.g. a relatively simple web app where most of the business is done in the physical world), it will mostly be technical managers who best facilitate engineers meeting the objectives of the business, because they have such a huge advantage over nontechnical managers while there's nothing nontechnical managers have over them.
gregmac 9y ago
The non-technical person above them hires them -- probably because they "speak on the same wavelength" or something.
IncRnd 9y ago
Many times it happens due to the manager having a track record for getting projects completed on-time.
imron 9y ago
I disagree, one of the best managers I had was a non-technical manager. He was able to guide me back on track when I was veering too far into the 'interesting problem for the programmer, but not what the business is trying to solve' territory and also was able to clear obstacles out of the way to let me work on what it was I needed to be working on.

eight_ender 9y ago

As a technical manager this article bugs me because it's pointing to issues with hiring that are only being made worse by having a non-technical manager. You need to hire developers that are professionals capable of being independent, and most important, responsible. If you have developers that aren't accounting for simple things like memory or performance then you have a problem with that employee. It's something you can coach, and if that doesn't work out, then you let them go. Having a non-technical manager makes this worse because you can't spot the problem early, and the developer doesn't have the strong sense of oversight that comes from the boss being able to read your pull requests.

kenning 9y ago
Yeah but a good technical manager is out of most companies' budget.
- techer 9y ago
  I think you've hit the nail on the head. Or they simply haven't budgeted for it. I was paid far far less but carried the fallout for not delivering.

analog31 9y ago

Ironically, pretending to ask intelligent questions when you're clueless about the subject matter is a form of bullshitting.

ryanSrich 9y ago
Yeah that's exactly how this article reads to me. Like here's a list of questions you can ask that you'll likely not understand the answers to...ok.
gamesbrainiac 9y ago
This nails the whole situation on the head. Understanding the context is really the most important part to solving the problem.

piyush_soni 9y ago

Ironically, this looks like a bullshit article to me. I have no idea what is the experience level of the author, but as a senior developer, several times I have "created a framework" (and a quite useful one at that) which not only made the problem solving manageable for myself, also resulted in clean readable code which is maintainable for others in the team as well. Also, don't underestimate the real need of refactoring at times. There's no red/yellow flag here. Sure, we can keep postponing that and create bigger mess - which is a decision we do have to take at times to avoid last minute bugs, but that still doesn't mean the developer is bullshitting when he says he needs to refactor some old ugly code.

eddigo 9y ago
If you're a competent programmer who uses these terms and phrases, then indignation is not an unreasonable reaction. However, I think it's a completely valid article if you've ever experienced the interactions between an unproductive programmer and their non-technical manager. I've witnessed this dance every week for the past 3 years. The programmer in this case has used every one of those phrases except "platform independent".
- piyush_soni 9y ago
  The thing is, you just can't detect a programmer is bullshitting by just hearing those terms - thus making it a misleading article. There are all sorts of programmers out there - those who use these terms and work a lot (on those things), those who don't use them but still work on them, those who use these terms but don't actually work satisfactorily, and those who neither use these terms nor work. Correlation is not causation here is what I want to say.
  - eddigo 9y ago
    I took the article context as a non-technical manager wondering why a project wasn't complete after using a good deal of resources. Usually "bullshitting" refers to the tactics engineers, or employees in general, use to explain why they aren't done when they should be. If engineers are using these phrases and projects are being completed, then you can assume they're not bullshitting.

kpil 9y ago

Having worked 20 years, I'm getting me and more tired of one thing: a meeting that includes a manager that you need to explain every obvious thing to. It's no problem with clients, stakeholders, new hires, or even unreasonably thick coworkers, but a manager that having less than a minimal domain knowledge trying to 'summarize' or 'weigh together' a lot of things they do not understand is just so utterly unmotivating. I have the research on my side: the most influential factor on job satisfaction is if your manager can do your work. https://hbr.org/2016/12/if-your-boss-could-do-your-job-youre-more-likely-to-be-happy-at-work https://hbr.org/2016/12/if-your-boss-could-do-your-job-youre...

smallnamespace 9y ago
The flip side is that it seems very difficult to find competent coders that are both competent at and interested in managing other people. Good coders are expensive and rare; paying an even larger premium for a good technical manager is so painful for the bean counters that they inevitably push non-technical people into that middle management role.
- troels 9y ago
  I'll wager to say that a good technical manager need not be a stellar coder. I've worked with people who were "business" people on the face of it - went to business school, had a career of management/administrative positions etc., but who had a deep technical understanding. All of them had at some point veered in the direction of becoming a programmer, but then changed course. I'm sure they would have become fine programmers, but they just chose not to.
- usgroup 9y ago
  Think you might be talking about founders here.
- sokoloff 9y ago
  I wonder how much of that might be people who realize they will never be a truly world-class technologist, and so try management as a path where they might make their next career progression. (IOW, a scheme on the part of the new manager not the bean counter, or at least a symbiotic scheming.)

learc83 9y ago

You wouldn't want a manager working in finance who didn't understand a bit about finance. You don't want senior programmers working in finance who don't have some domain specific knowledge. Then why is it OK for completely non-technical managers to manage programmers? I get it, management is a separate skill set, but spend some time and learn your domain.

coldcode 9y ago
I was once worked with a technology project manager (in this company they were more like junior CTOs) who said he didn't need to understand technology, he managed people. Of course he also made all the technology decisions.
Theodores 9y ago
This is an interesting idea that can be turned on its head. So if you are stuck with a 'non-technical manager' then you should be able to get that changed, if you would prefer the manager of the guys that do the office cleaning then you should be able to get managed by them, or anyone else with these 'manager skills' that so elude developers. Then you should be able to avoid being micromanaged by a non-technical who pretends they know something of your domain.

untangle 9y ago

If this methodology is overused, you will have your PM/dev team rebelling or leaving in a hurry. That said, I can see a trimmed-down of this used as an evaluation tool for more substantial product development decisions. Ideally, these questions would be posed to a PM or dev manager and not directly to a coding team. I also believe that the article is a good training piece for new(ish) general managers that have dev teams reporting to them. Along these lines, the listed criteria are a good thing to keep in mind for those GM's who (like me) sit in on product meetings while remaining fairly inactive. IOW, the GM can listen-in and try to passively assess whether the team has a handle on these points. If not, address surgically and offline with the right folks.

juiyout 9y ago

Can't non-technical managers study up? The wealthiest entrepreneur and fierce manager in Taiwan back in 60s/70s was a man who only finished elementary school during war-torn Taiwan. But he could detect bullshit miles away. After Chinese nationalist took over Taiwan from Japanese, he started petroleum cracking business. One interesting anecdote was that a science guy was presenting to him some shiny new process with some fancy reaction formulas. He frowned and whip out pencil and paper. He started to pick apart the scientist's formulas and mansplained to that scientist how that process may not work in his plant due to this and that in your equation requires this and that, which is too costly, etc. That scientist lived to tell the tale.

chipperyman573 9y ago
>He started to pick apart the scientist's formulas and mansplained to that scientist how that process may not work in his plant due to this and that in your equation requires this and that What does "mansplained" mean in this context?
megablast 9y ago
> Can't non-technical managers study up? Of course they can. Are they going to is the question.

mruniverse 9y ago

For the longest time I took it to be the norm that a manager is mostly there to pressure you to work, to get things done well and on time. Then I had a manager (he was technical) that actually helped solve issues. He didn't have to touch any code, but he had good suggestions. He knew what he was doing. He felt like he was in it. He was part of the team. He didn't just throw problems at you to solve. He was trying to help solve them himself.

ilyanep 9y ago

A lot of commenters here focusing on the non-technical manager bit and ignoring a lot of very good advice that's in here even for technical people. > Ask: Who specifically will represent the users of this system? You should expect your team to tell you who they are actually creating something for. Who will directly benefit from the work. And a real life individual person they will consult with on questions and who can verify it meets their expectations, at least. If your team is working in a vacuum, it’s a sure sign they’re working on the wrong thing. I've worked on teams where the person in charge of what features would be built had a "vision" and refused to ever actually iterate with users. Result: A thing gets built that nobody wants. > Ask: What are you not doing instead? Real life is all triage and trade-offs. You need to understand what’s not happening so you can communicate that to interested parties. And so you can make sure the right trade-offs are being made in this case. One of my biggest pet peeves in people making decisions is when they refuse to do the actual explicit analysis of costs, especially opportunity costs. Sure, you're laying groundwork for a good thing to happen in the future, but you're also costing that team the work of doing that and the rest of the group a bunch of work figuring out your new code layout. I can get behind it if I get a sense that people did the cost analysis but when the decision seems made willy nilly in a "this seems like it has a benefit" kind of fashion, it's really annoying that I'm spending time having to work with that.

deleted 9y ago

[deleted]

flohofwoe 9y ago

I think some context is needed: this post is written from the perspective of video game development where teams are composed of people with extremely broad skill sets (from the extremely artistic to the extremely technical to the extremely business side with everything inbetween). It is not uncommon to have managers there with a purely artist or purely business background working directly with the programmers. Also, the video game industry has its share of bullshitters like everywhere else, the bigger and more 'professional' the company, the higher the relative amount of bullshitters. Personally I think it's better to have no manager, than having a manager who doesn't have the slightest grasp of the areas the people in his team are working in, since there will just be too much time lost with communication and making sense of each other.

tilolebo 9y ago

I feel half of this article should be seen as project management basics for new technical managers with no PM skills. It's very easy to forget the goals, value and cost when you understand the technical part of a project.

DustinOfDenver 9y ago

Non-technical managers... needs to be a thing of the past. No one considers a guide for "Managers who cannot read, but must supervise writers" as meaningful article worth writing. Being "non-technical" should be synonymous with being illiterate (if you are in a technical field that includes supervising technologists). The topic is no longer something to be assigned to "nerds in the basement" is is the language of business and life.

DannyB2 9y ago
I was going to write something similar. A manager of anything, including technology, should have an understanding of what they manage. Not having that understanding is the fundamental problem. Any kind of "guides" to help such ill equipped managers is only a band aid that doesn't fix the actual underlying problem. Technical managers may cost more an be harder to find. That might just be the cost of not screwing up things in major ways. Including potentially business destroying ways. An additional clue: Not just the immediate managers of the worker bees, but going up the chain of management there should be people who understand the technology. Nobody would accept the idea of a manager that didn't understand the business they are in. If technology is part of your business, and you don't understand technology, then you don't understand the business you are in and shouldn't be a manager.
- DustinOfDenver 9y ago
  Excellent follow up! I know a few product managers who think that managing a technical product can be reduced to entries in a backlog... and features are somehow separate from the technology that drives them. What the miss is... Technology "IS" the product.
  - DustinOfDenver 9y ago
    If what you directly manage is technical... then you must be technical and be able to communicate those opportunities up. I don't think anyone is suggesting that the entire management chain must be technical.
- 9y ago

hartator 9y ago

Or "How to micromanage your engineers while not knowing anything technical."

infinity0 9y ago

Unfortunately this article is totally useless. A non-technical manager is going to read this: > When someone on your team says… >> “I’m making a generic version of…” >> “I’m creating a framework to…” >> “It’s platform independent.” >> “I’m adding this to make sure it’s future proof.” >> “I really need to refactor this bit…” and then assume that they should fire anyone that mentions these words. In reality, it's always dependent on context and the article specifically does not talk about the technical details that non-technical managers need to learn, in order to judge these situations correctly.

sverige 9y ago
I worked for a really outstanding manager. She told me stories of a previous job where she managed a help desk group for a database application. She does not know how to code, but she does know how to motivate people to do their jobs. She got the team to reduce the average time to close tickets by 75%. Customer satisfaction ratings vastly improved at the same time. The stories of the kinds of things she had to do in order to get a bunch of sullen, lazy, overpaid programmers to do their fucking jobs (her words) were hilarious. I learned a lot from those stories. And btw, she has never again wanted to manage "technical" people again. Every time one of these "how to" articles for middle managers pops up here, a variation of this response almost automatically appears. The truth is that most technical people know nothing about the nuts and bolts of management, but think somehow that they either do know or are exempt by virtue of knowing how to code. The only group that is worse for this sort of ignorance is lawyers, in my experience. I know it is somewhat unpopular to champion the value of having competent management, especially when companies reach a certain size. It's a lot easier for those who have never been managers to simply curse all of them as roadblocks to realizing the fruits of their genius.
- Bartweiss 9y ago
  I don't disagree with you, but I don't really understand how this relates to the parent comment? It's certainly true that good management is a complex skillset, and if managers underestimate programmer's skills then the reverse is also likely. It's true that in some contexts non-technical managers can manage technical teams (and in some contexts they certainly can't). But... none of that makes this article good or useful. It doesn't negate the parent comment at all. This article is bad, and it's aimed at non-technical managers who aren't functional. I suspect your outstanding manager didn't use "what are the memory constraints?" like a magic spell of management, because despite the article's sweeping generalizations ("most common... any system"), there are a lot of contexts where that's literal gibberish. I'm willing to bet she didn't keep a list of words to interpret as "I'm a useless hack". That's basically what this article advocates. Like... "Generic version" translates to "I don't understand the problem"? Really? Last time I said that, it was "I'm making a generic version of our branded UI so the new clients can put their logo in it". That's not even a technical answer, but it still goes on the 'red flag checklist'. I could keep that list going. And the obvious reply is "these are just tips, don't overuse them where they don't apply!" But then what was the point? Knowing when to ask these questions is the entire task of management, and this article is aimed at people who can't do that.

kdelok 9y ago

I can't really comment on non-technical managers, as all of the management at my company are former (and current) developers. However, this list itself doesn't seem like a bad set of questions for a developer to ask themselves, let alone a manager ask the developer. We all know that it's all too tempting to fix the problem we want to fix, rather than the one that needs t obe fixed.

maxehmookau 9y ago

Oh great. Let's tell managers that wanting to refactor is a yellow flag. What a terrible idea.

scriptkiddy 9y ago

TLDR; How to be the Pointy Haired Boss.

jeffdavis 9y ago

Management is (and should be) different for businesses where engineering excellence is a necessity versus businesses that just need competent/efficient technical solutions to non-technical problems. This article is clearly about the second type of business. And it's designed to defend the second type of business against programmers who think they work for the first type of business.

nartz 9y ago
Kindly disagree. If a business has a need that is critical to the business, not hiring a person with technical experience to manage technical things is just a mistake (or the business being lazy). I dont understand the shying away from hiring a qualified individual here. The fact is, its 2017 and there actually are a fair amount of qualified technical managers who can communicate and fufill the role. Many other comments have pointed out various analogies in other fields that reinforce this.
- jeffdavis 9y ago
  If the business's primary objectives are non-technical, there will be some level of management that is non-technical, and they need some guidance. This article isn't the greatest, but it doesn't seem terrible to me. Note that "technical" is a matter of degree and relative to the team being managed. It doesn't necessarily mean they dictate their emails to their secretary.

jorgeleo 9y ago

I was happy with the article content until I got to the examples. These examples promote been suspicious of everything and treat the technical people as non-professionals. So I took exception on it. “I’m making a generic version of…” It means: I don’t understand the constraints of the actual problem, so I’m going to design an even bigger problem that we have no way of verifying the efficacy of. BS. One of the most successful projects that I have delivery was so BECAUSE I started with a generic version of the core business concepts, and then I made a specific version for the different intra-department routings. There was more investment up on front, but it was recovered with gains at the end. Extracting the cross-cutting concerns into more generic versions is the right way to go. “I’m creating a framework to…” It means: I’m not interested in solving the actual problem, so I’m going to create something else so that the person that actually will solve the problem has to also fix the problems in my stuff on top of that. Same thing, is the cross-cutting concerns are implemented in a common framework, then you will have a high level of code reuse. “It’s platform independent.” It means: I literally have not spent two seconds thinking about what platforms this will obviously not work for. Sometimes you don't need to cover all platforms, but a few ones. So I might have to think what platforms will not work for and I still need to make it platform independent. “I’m adding this to make sure it’s future proof.” It means: I believe in fairies. One of the biggest compliments that I get from my work is exactly this: It has been 10+ years and we are still using what you created and finding gems in your code. If you have not received this kind of compliment either you are too young to write this article or know very little about architecture “I really need to refactor this bit…” When you hear “refactoring” it’s a bit more of a yellow flag. Technical debt is a real thing that needs to be addressed and that you should be aware of. I cannot count how many times I have found myself in front of the question "Can you fix it?" and answering "This is such spaghetti code that I would really need to rewrite it, let alone refactor it. I seem to me that these kind of recommendations are for a specific niche of software development. Enterprise (not enterprisey) level development, can have valid counterexamples for all and each one of what was described in the article.

draw_down 9y ago

That sounds like a very frustrating and untrustful interaction with one's manager. Good luck hanging on to your team members with all that. But the important thing is that you understand, because you're the manager! Right?!