>> 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.
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.
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.
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.
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'.
"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)
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.
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.
Maybe, maybe not. I've had technical managers that weren't as good at that as this manager.
Now I'm sure maybe there are technical managers who can do this well too, but it's not an exclusive trait to them and my point (and experience) is simply that being non-technical is not in and of itself a disqualifying factor for being able to manage technical people.
Easy. If the person can do an engineer's work they will be kept as an engineer. If they can't, an alternative role will be searched for them, for example a manager role. It's all about keeping the people you have and finding them a place in the company. It's not good if you ask me, but this is how it's done.
A Lead is someone you look up to for programming advice. A Lead is someone you know will guide you in building the right architecture.
A Manager is there to help you grow in other ways. A Manager sets you up for success and ensures you have all the tools you need to be successful.
Granted, often you'll find that your manager is the team lead and fulfills both of these roles at once. However I think they can be two separate roles.
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.
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.
Refactoring as a "yellow flag" is not only dangerous, it's the opposite of how you should treat it. It's not just about cleaning up code that might not meet the bar on quality. Sometimes it's about challenging assumptions by the developer that were completely valid when they wrote the original code that aren't now through hindsight, technology changes, etc.
It's possible for a developer to write all-star top shelf code only for it to be significantly improved a year later with a few line changes. To not challenge all code, even the good stuff, is doing your codebase a disservice.
> Why didn't you just write it correctly in the first place?
For the same reason Bluray replaced DVD replaced VHS. "The better solution didn't even exist at the time" (new browser features) often coupled with the equivalent of "Now everyone has a Bluray player so we can start using Bluray features going forward." (ubiquitous browser support)
That tends to get understood by my management. Compare it to something they are familiar with - and anyone over the age of 25 will be familiar with the BR/DVD/VHS comparisons.
>Refactoring as a "yellow flag" is not only dangerous, it's the opposite of how you should treat it.
Hmm, I actually thought it was pretty reasonable. Refactoring is real and necessary, but it also gets thrown around a lot in order to mislead. Contractors who are overbooked and not working on your project always seem to be "refactoring".
Also, if you hear the term "refactoring" too much and the system being built still does not work, then that's probably a good indicator of bullshit. Engineers (and managers) need to be taught to resist the urge to refactor before the system solves the problem. Once you've solved the problem, you've connected things end-to-end, and only then will you know what refactoring makes sense.
Ugly code that works > pretty code that does not work
Having been both a manager and engineer for a number of years in a number of organizations, I can say with some confidence that an excess of refactoring is NOT the problem.
Having worked as a contractor for many years, I can say with absolute certainty that actual excess refactoring is not a problem, but that claims of refactoring very much are.
Again: when a contractor is backlogged, "we're refactoring" is the go-to justification for the delay.
Refactoring without a clear and stated purpose is bad. Refactoring WITH a clear and stated purpose may also be bad, if the purpose is bad; "Support some use cases we don't care about," etc.
There's a checklist in the "Value" section of the article than can help sort out what value (if any) the refactor has.
> I have no idea what is the experience level of the author
Acton is the engine lead over at Insomniac Games, and has been shipping that sort of work (routinely refactored/updated) for years. He's an exceptionally pragmatic tech lead.
Have you read the article? He's nuanced on refactoring in a manner that the originator of this thread doesn't describe.
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 recommend reading Paying Down Your Technical Debt to get a basic understanding of the concept.
However, it can also be just an excuse to change things to some conception of “better” for no real benefit. Whatever better means to that programmer today, you can be confident that they’ll think it’s shit in a couple of years as they gain more experience and skill. That’s totally fine, but you can’t afford to get caught up in a loop of always retrofitting everything to “better” every time the definition of better changes. Unless you’re Google, in which case you keep doing that until some other team solves the actual problem and your project gets deprecated.
The refactoring section is one of the better parts, though. The article is very black-and-white on "generic version", "framework", "platform independent", and so on.
I don't doubt that the author is good at this job, but I think we're seeing an 'unconscious competence' issue. If I say "Java is platform-independent while C++ isn't", the author probably knows enough to think "well, that's a factual statement, not a red flag". But the person reading the checklist he wrote probably doesn't.
Honestly, I got some value out of this article as a list of things to ask myself. But it seems to be aimed at exactly the people who won't be able to interpret it effectively, and will misapply the hard-and-fast rules here.
Right and I'm just pointing out that the part on refactoring is way more nuanced than people were giving it credit, very often in a manner that suggested they were commenting on something they hadn't even read!
It will always be possible to accuse an article or even a book of being light on details. It is after all some pointers and not a scheme to make a non-technical manager technical. Learning anything takes more than reading at surface level, particularly of a clearly introductory article. The principle of charity goes a long way to smoothing out the inner pedant.
> The principle of charity goes a long way to smoothing out the inner pedant.
Certainly true, and I do think people skipped the section on refactoring. But I guess my real complaint here is that the article itself seems to advocate against the principle of charity!
Asserting that generic versions and frameworks are inherently 'red flags' that someone doesn't know how to do their job doesn't seem like an inducement to more reading, it seems like a misleading absolute. I got that feeling throughout the whole piece, for instance with the implication that memory limits are key in all tasks.
It was either very domain-specific advice (I know the author came out of game design, which fits his list better than general software), or vastly overstated advice.
I come from a games background as well so am probably deaf to how domain specific things are. But people spending far too much time making something too generic or an extensible, pluggable doodad with its own DSL rather than creating the simple, dumb version you actually need is actually quite common IME. Engine code (which is partly framework building) is very susceptible to overengineering and attempted future proofing.
I don't think they're being introduced as red flags to say "call bullshit on this and don't do it" but to be aware in the following cost-benefit analysis.
Maybe it has something to do with the nature of the business of game programming, where most projects are only developed and maintained for a year or two and then the team has to move on to the next big project in order to pay the bills. In a context like that, it can be easier to make the case that monkey patching might be a better use of resources than refactoring.
Generalizing this to all of software development is still a bit presumptuous though.
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".
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.
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.
I am working on a code base where refactoring the code as the product grew was not even considered as most of the technical decisions somehow fell into the hands of non-technical business people (for the last ten years).
Just over a year ago the code base was handed over to a technical team (there used to just be one coder (never the same coder as they all seemed to hate the product and move on, now we know why)) to review, and fix to make it more scalable. Well to put it lightly it is a complete cluster fuck that has seen a couple people resign and it is not worth trying to fix.
Now the burden has become trying to convince the business people that drastic steps need to be taken (ie full re-write). They don't seem to want to even entertain the idea, so not sure what is actually going to happen.
Drive it until the wheels come off can be a valid decision. Just be aware that when the wheels come off, you will be without a car for some period of time.
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.
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.
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.
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.)
I could do your job. If I learned how to code. But as a product manager my duty is to act as a bridge betweeen you and my bosses and my customers and my customer service etc.
How skilled do you want me to be? It's very difficult dancing this dance. Fighting for resources.
I think the difference is most managers can be ignorant uncaring assholes.
Having a manager trust and listen to you and fight for you and defend you when necessary is far more important.
I'm my opinion the only non technical part of me is that I haven't learned how to code.
But the proof of the pudding is in the eating. I eat.
In any case, I don't think the point is actually being able to code. To me, the point is knowing enough to not be a burden in the conversation. If you can follow the high level technical details of what people are saying, you're good.
I have managers like that, and I love them. You sometimes need to explain some things but it doesn't take more than a sentence of "we can't do this because it would break the other thing".
You're totally correct. But I never wanted to. I do love technology and certainly try not to ignorant of current and future technologies. I respect the art of the programmer. But to be slightly rude just to make a point: an average or above average coder is a commodity. In theory many many people could do your job. But a great manager is not a commodity. They are highly prized and compensated. They can break down barriers and fight fight fight.
You are right not to be a burden in the conversation. You need to kill your Ego - talking endless confusing bullshit to make yourself seem important is a nightmare. But my MD could be accused of the same the way he had to realign my priorities with that of the company.
But when you understand that some of the people on the board of the company I worked for never even use a computer, a bridge is necessary.
You compared great managers to average coders. My experience with managers is like many people's. The "average" manager is pretty bad. The average coder is also pretty bad. Both the average manager and the average coder can be replaced pretty easily. The great manager and great coder can not. I can only speak for the programmer side of that though having been involved in interviewing and seeing how hard it is to find people to pass the simplest of questions. But, given my experience with managers I suspect it's just has hard to hire great managers.
The same can be said of bad managers hiding behind a good team of direct reports. We've all had the bad manager who the owners or higher ups loved to death yet everyone on the team can tell they are incompetent. I'm not talking about the boss you hate but the truly incompentant ones.
The place I work now doesn't really care about competence only a body filling a vacancy. Maybe it's time to find a new job...I digress.
I've worked with both, and let's agree that they are about equally hard to find, or more precisely hard to hire.
To the untrained, though, above average coders and managers may appear great. But only once you've met an actual great one, you can really have perspective.
I mean, almost by definition and in ANY profession, most people will be average and good people will be scarce. If everyone was good, then everyone would be average and only the outstanding ones would be good.
So, I respectfully disagree. I think it's as hard to find good coders as it is to find good managers, good opera singers, or good baby sitters.
> an average or above average coder is a commodity. In theory many many people could do your job. But a great manager is not a commodity.
I generally agree with greggman here, in the "average vs great" distinction.
However, this also reeks of "my job is more important than your job" bias. Everyone is a commodity (and jobs are too). It's just about how hard it is to find someone to replace them.
Sorry it sounds like that. Especially at HN. The coders are the most important. No doubt. But if you honestly think that all will be solved by having technical people in most positions, then that goes against my experience unless you are a pure technology company, started by technologists.
The company I worked for morphed into a juggernaut from retail beginnings. So the company was staffed with people so technically illiterate that it was amazing anything ever got done.
There should be a balance in everything. And generalists are sometimes just as important as specialists.
I think it's the individual that matters. An intelligent, the right amount of humble, responsible, and motivated person that is broad enough to grasp the bigger picture while understanding enough of details, and is interested in managing other people will do well as a manager, regardless of background.
We don't care why you can't code. We care that you can't, and therefore are unable to understand the work of people who do.
Again: the reason for your technical incompetence is not the issue. We're not passing a moral judgement on your inability to code. We're passing a professional judgement to the effect of "you are unable to understand our work and therefore cannot make sound judgements about it".
The fact that you confuse these two things is a succinct example of everything that is wrong with non-technical management.
The only thing, is that you can't code? By that do you mean your ability to type stuff into a computer? Being able to engineer software is quite different from "coding". This is typical case of not knowing what you don't know.
The manager is basically a group resource that _developers_ use. Instead of thinking of yourself as a boss of developers, think of yourself as a secretary that serves the developer team. For that you don't have to be very skilled, you just need to be able to communicate basic things, and know a little bit of lingo, which I'm sure you've been able to master.
I've never intentionally trolled in 25 years on the internet so apologies again.
I just know that I fight and deflect for the technical side, listen to their issues and do my best to let them do their jobs, while also have have to liaise with completely and utterly technically illiterate people, marketing especially.
As a manager you are also managed.
This is in the UK however, which is still relatively in its infancy in this regard.
You lost me here. If you can't do my job, you can't manage my job. Period.
This lax attitude towards manager competence is little more than forced, groupthink subjugation to the Peters Principle [1] and has created a 'management class' that is little more than a means to undermine the 'technical class' with bullshit, and it is a cancer on our industry.
> If you can't do my job, you can't manage my job.
Nonsense. Managing people is a whole other bunch of skills distinct from the skills you need for coding. I won't disagree that a good manager who can code is a bonus though.
I didn't say they're not mutually incompatible, just that if all you've got is so-called "manager skills", and you still can't do the job of the people you're managing, then Peters Principle is well and truly in effect and the situation is dire - whether you like to think of yourself as a special human for having special management skills or not.
Manage me, by all means, using the newest-fangled management psychology you think is necessary, but if you can't do even the most basic of my tasks, you're simply not qualified for the job and should quit.
Seriously, this factor is cancerous on the industry and is, I believe, one of the most significant causes of the loss of productivity, revenue and ultimately success in our industry. Its time for this attitude to die.
The only problem I have with what you are saying is that there do exist good or great coders who go into management and become average or even poor managers. To me this phenomenon would imply the existence of some tangible management skills, separate from technical skills.
Huh... I think you're actually talking about the Peter Principle, where skilled programmers are promoted to the point where they stop being skilled. The parent topic seems to be closer to the Dilbert Principle - people being placed in management who would never have gotten the job below theirs.
Unfortunately, both of those things are pretty common. Promoting "up the ranks" gets you Peter, and hiring "for management skills" gets you Dilbert. Avoiding both at once seems to be an almost unsolved problem.
I can think of three distinct dimensions; technical, planning and political/coaching. Maybe it's four but I think the last two are sides of the same coin.
"Management" skills and "Technical" skills are neither all-inclusive, nor exclusive, nor does the presence of one imply the other, but the most optimal scenario is simply where an individual is capable of competence at both.
> if you can't do the job of the people you're managing, then Peters Principle is in effect
Wait, Peter's Principle? If that's "promoted to their level of incompetence", shouldn't it describe managers who can do their subordinate's work but not their own?
This sounds closer to the Dilbert Principle, honestly - people who get hired as managers but could never have held the job below theirs.
They are incompetent managers, promoted up the 'management chain' to a position of incompetence, which is due to the fact that they can't do the job of the people they are managing. They are 'management people' who have gone as far necessary to be outside their competence level.
Managers at GameStop used to be the non-managers working there. Same in a whole host of other professions, where it is expected and required that you actually understand and have experience doing the work of the people you manage. Cos, you know, in those trades, managers often have to step in and do the work. Customer service managers have usually worked as CSRs. They know the work they manage. It has always baffled me that anyone ever accepted the idea a non-technical person could or should manage teams of developers without having written code, shipped an application, or even setup a server. They have no intrinsic experience or domain knowledge to inform their management of the coders, devops, or sysadmins. And they need it. You simply cannot manage people very well when you don’t understand the experience of doing their job. You can be the nicest, greatest person when it comes to dealing with people, but when it comes to hearing conflicts that are getting in the way of getting things done, when your team is blocked by things that you can’t understand, and you can’t actually see the way through the problem yourself, that’s not good management.
I've learned software development, software security, machine learning, data analysis, calculus, physical sciences and engineering, technical report writing, photography, the basics of design and colour theory, financial instruments, how to manage projects and people, and the basics of economics and law.
It is not too much to expect that a technical manager learn at least one real programming language and use it to ship one real app before they start to try to understand and coordinate developers and designers.
This is not too much to expect.
I've been learning Russian for over a year and I expect it will be at least another year before I can comfortably have a conversation.
You can at least do a Ruby or Objective C over a eight week bootcamp.
As a product manager, do you have developers formally reporting to you? That seems like a bad idea. If a PM doesn't have formal authority over developers but thinks of themselves that way, that's also bad.
No. They were not (although lines blur when an emergency happens!)
But I was certainly managing them.
It was my roadmap, so with nearly everything they worked on the buck stopped with me. I was the one who signed off on all their work, including testing. Including signing off on imperfect work in order to ship!
I don't want authority over anyone, I want to work in a creative, sane and pleasant atmosphere.
And I love to learn from people. Hopefully they can learn from me.
> [...] a manager that having less than a minimal domain knowledge trying to 'summarize' or 'weigh together' a lot of things they do not understand [...]
Sometimes managers need you to check their summary for correctness ("Can you say it like that?"), because they in turn have to supply it to their bosses or consumers.
Every project will always involve people with little technical understanding who still need or want summarisation of technical decisions.
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.
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.
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.
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.
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.
>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
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.
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.
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.
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.
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.
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.
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.
> 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.
There's a natural (and I think fundamental) inversion that happens as you go up the leadership chain. The first level of supervision almost inevitably knows more than the most junior employee about their area of work. (Think a senior developer mentoring a new college hire.)
That may hold for two levels, but at some point, management is about breadth and not depth. The head of technical operations probably came from networking or systems or storage or database or communications, but probably didn't come from ALL of those, so is unlikely to know more about networking than the head of networking AND more about databases than the head of databases, etc. In fact, they may know next to nothing about some particular field of ops and yet still be the right choice to lead operations. (I was in this position in a prior role.)
So you get this weird situation where at the junior levels, the supervisor knows more than the supervised. At the more senior levels, that's usually inverted. And then you get people who determine that the senior person is clueless because they know more about their specialized field than the boss.
IMO, it's unreasonable to expect the CEO of Boeing to be an expert in finance, operations, aerodynamics, manufacturing, supply chain, engine design, certification rules, avionics, landing gear, radar, flight controls, and the 100 other disciplines needed to make Boeing work. I see no reason to think that technology is extra-special in that all managers of technologists need to be world-class technologists.
> So you get this weird situation where at the junior levels, the supervisor knows more than the supervised. At the more senior levels, that's usually inverted.
And on some level, this makes sense. A completely junior employee may well need substantial guidance, and if they aren't reliable that won't necessarily be easy to predict - so you get them a supervisor who can evaluate their work in full. A midlevel or upper-level manager ought to be competent enough to perform reliably, and it's more useful to have someone above them with skills they don't have.
(Of course, hiring is a mess, and "senior staff ought to be qualified and reliable" is not the same as "senior staff are...")
I think you are correct and incorrect.. I am not suggesting "expertises". I am suggesting "Literacy"... at least enough to "detect B.S." of his immediate direct reports (and that part is also key).
In 4 levels of management the CEO is not to be the BS detector of the 1st level but most def. be "technical" enough to detect B.S. at the 4th and (maybe) the 3rd levels of management.
Those I admire and have studied: Disney, Elon, and Jobs (many others) could maybe detect down to the 2nd and 3rd levels. To do the impossible - you must have a grasp of the "possible"
Fair enough, but at the same time when you start getting to the level where they don't know about the details they need to start trusting the people below them to make decisions and take their advice. Far too often you see technically incompetent CEOs making far reaching decrees about technical issues they know nothing about because of some random brain fart they overheard on the golf course with one of their buddies.
> A manager of anything, including technology, should have an understanding of what they manage.
Sometimes I think software people are lucky in this. Sure, non-technical management is too common, but mostly it just makes our lives harder. Talking to friends who work in process chemistry, civil engineering, and other high-stakes fields suggests that this is rarer, but nowhere near rare enough.
Obviously software has consequences, but usually mistakes can be caught in testing or otherwise mitigated. After hearing stories like an unqualified manager deciding that a pressure release valve is 'optional', it sounds like this still happens in settings where even the test suite can kill you.
If you're equating 'management' with 'supervision' then it's no wonder you feel this way. All of our managers are non-technical and they really have no reason to be. Their skills are with people, process, and logistics and I wouldn't have it any other way. They have to deal with all the bullshit so I can sit in my office and actually do work.
You are supposed to be your management's bullshit detector. Sure, in an ideal world everyone in your office would be perfectly knowledgeable about all relevant topics but I would rather have management that's actually good at management, knows nothing about tech and knows they know nothing about tech over one that knows just enough to be dangerous.
"If you are in a technical field" Well, there's the rub, right? Not every organization that employs technologists is actually in a "technical field" and thus doesn't have the resources to aquire and deploy technical managers everywhere where they might be useful.
Unless your company's core business is software, eventually there will be someone who is non-technical who will be required to make business decisions.
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.
What's interesting is that there's nothing in the article that's actually specific to "non-technical" managers. In fact, reminding one to ask "what's the customer value here?" is advice that's probably more suited to highly technical managers rather than non-technical ones.
I agree... but it all depends on the role. Ideally, "management" can span the two buckets well. But, without understanding the technology, management is left standing on one leg.
Sometimes there just isn't anyone on the team with both the technical knowledge and management skills. In that case I would actually rather be supervised by a non-technical person who is nevertheless a skilled manager than a smart developer who is terrible at management.
Edit: since I'm downvoted, allow me to explain- a good manager knows how to delegate and stay out of people's way, so I don't necessarily care if that person is technical or not, but a bad manager who is also a developer is going to insist on coding all the most critical parts of the application him- or herself and leave you to clean up their messes when they're stuck in meetings all day. That person is really more like an individual contributor with special privileges and I've worked with quite a few of them.
(Good Manager + No Tech Skills) > (Bad manager + great tech skills).
I don't think that is the argument... I think it is:
(Good Manager + No Tech Skill) < (Good Manager + great tech skills)...
and on that point no one would disagree.
It is interesting how so many have tried to frame the argument the first way - perhaps they are more of a unicorn than one would hope... but it would still be better to have BOTH skills.
It is truly rare to find a person with both skills.
Usually what happens is the best coder in the bunch gets asked to manage the team but 1) doesn't know anything about management and 2) doesn't want to be a manager but likes the power and fancy title. So this person just keeps on coding but with less accountability to the other team members.
What the tech world needs is more skilled managers, not more technical managers. People overvalue the notion of calling developers' bluff because there is a basic level of trust that is missing.
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.
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.
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.
Totally agree with you on the value of good managers, but I can't imagine how someone with such a negative outlook on their workers can be considered an "outstanding manager," unless it was just tough love. If I worked for a supervisor who spoke about my team that way, I would take it as a sign to start floating my resume (assuming she was serious and not just ragging on them). And if she was so talented, why didn't she stick with it?
Yeah, the article would be much more effective and useful if the advice was "if you hear these phrases, don't assume the developers are lying/bad at their jobs/etc. but do take it as a cue to ask about the business/customer value of doing ____".
Being technical or nontechnical is orthogonal to being able to ask the right questions about customer value. Nontechnical managers will go "framework? well if you say so" because they don't understand the tech. Technical managers will go "new framework? well if you say so" if the plan is technically well thought out, ignoring whether or not it actually creates business value.
It's not orthogonal. Being technical, gives you the necessary knowledge to judge whether a claim that uses technical terminology to argue a business case, actually properly argues that business case or not.
There's an implicit misunderstanding here that engineers making technical arguments, are not making business cases. That is not correct. Good managers know how to interpret engineer arguments in a business context. Bad non-technical managers, will dismiss technical arguments because they aren't able to translate these arguments into a business context.
Sometimes good non-technical managers will nevertheless still do a good job by delegating this judgement based on people they trust. Someone with extra technical knowledge however, would have done an even better job.
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.
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.
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.
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.
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.
134 comments
[ 2.3 ms ] story [ 200 ms ] thread>> “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.
1: https://en.wikipedia.org/wiki/Inventor%27s_paradox
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'.
"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...
It seems like something we should try to avoid.
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.
Now I'm sure maybe there are technical managers who can do this well too, but it's not an exclusive trait to them and my point (and experience) is simply that being non-technical is not in and of itself a disqualifying factor for being able to manage technical people.
A Lead is someone you look up to for programming advice. A Lead is someone you know will guide you in building the right architecture.
A Manager is there to help you grow in other ways. A Manager sets you up for success and ensures you have all the tools you need to be successful.
Granted, often you'll find that your manager is the team lead and fulfills both of these roles at once. However I think they can be two separate roles.
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.
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.
It's possible for a developer to write all-star top shelf code only for it to be significantly improved a year later with a few line changes. To not challenge all code, even the good stuff, is doing your codebase a disservice.
For the same reason Bluray replaced DVD replaced VHS. "The better solution didn't even exist at the time" (new browser features) often coupled with the equivalent of "Now everyone has a Bluray player so we can start using Bluray features going forward." (ubiquitous browser support)
That tends to get understood by my management. Compare it to something they are familiar with - and anyone over the age of 25 will be familiar with the BR/DVD/VHS comparisons.
Hmm, I actually thought it was pretty reasonable. Refactoring is real and necessary, but it also gets thrown around a lot in order to mislead. Contractors who are overbooked and not working on your project always seem to be "refactoring".
Ugly code that works > pretty code that does not work
Again: when a contractor is backlogged, "we're refactoring" is the go-to justification for the delay.
There's a checklist in the "Value" section of the article than can help sort out what value (if any) the refactor has.
Acton is the engine lead over at Insomniac Games, and has been shipping that sort of work (routinely refactored/updated) for years. He's an exceptionally pragmatic tech lead.
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 recommend reading Paying Down Your Technical Debt to get a basic understanding of the concept.
However, it can also be just an excuse to change things to some conception of “better” for no real benefit. Whatever better means to that programmer today, you can be confident that they’ll think it’s shit in a couple of years as they gain more experience and skill. That’s totally fine, but you can’t afford to get caught up in a loop of always retrofitting everything to “better” every time the definition of better changes. Unless you’re Google, in which case you keep doing that until some other team solves the actual problem and your project gets deprecated.
I don't doubt that the author is good at this job, but I think we're seeing an 'unconscious competence' issue. If I say "Java is platform-independent while C++ isn't", the author probably knows enough to think "well, that's a factual statement, not a red flag". But the person reading the checklist he wrote probably doesn't.
Honestly, I got some value out of this article as a list of things to ask myself. But it seems to be aimed at exactly the people who won't be able to interpret it effectively, and will misapply the hard-and-fast rules here.
It will always be possible to accuse an article or even a book of being light on details. It is after all some pointers and not a scheme to make a non-technical manager technical. Learning anything takes more than reading at surface level, particularly of a clearly introductory article. The principle of charity goes a long way to smoothing out the inner pedant.
Certainly true, and I do think people skipped the section on refactoring. But I guess my real complaint here is that the article itself seems to advocate against the principle of charity!
Asserting that generic versions and frameworks are inherently 'red flags' that someone doesn't know how to do their job doesn't seem like an inducement to more reading, it seems like a misleading absolute. I got that feeling throughout the whole piece, for instance with the implication that memory limits are key in all tasks.
It was either very domain-specific advice (I know the author came out of game design, which fits his list better than general software), or vastly overstated advice.
I don't think they're being introduced as red flags to say "call bullshit on this and don't do it" but to be aware in the following cost-benefit analysis.
Generalizing this to all of software development is still a bit presumptuous though.
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".
Just over a year ago the code base was handed over to a technical team (there used to just be one coder (never the same coder as they all seemed to hate the product and move on, now we know why)) to review, and fix to make it more scalable. Well to put it lightly it is a complete cluster fuck that has seen a couple people resign and it is not worth trying to fix.
Now the burden has become trying to convince the business people that drastic steps need to be taken (ie full re-write). They don't seem to want to even entertain the idea, so not sure what is actually going to happen.
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...
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.
How skilled do you want me to be? It's very difficult dancing this dance. Fighting for resources.
I think the difference is most managers can be ignorant uncaring assholes.
Having a manager trust and listen to you and fight for you and defend you when necessary is far more important.
I'm my opinion the only non technical part of me is that I haven't learned how to code.
But the proof of the pudding is in the eating. I eat.
All that means is that you can't, though.
In any case, I don't think the point is actually being able to code. To me, the point is knowing enough to not be a burden in the conversation. If you can follow the high level technical details of what people are saying, you're good.
I have managers like that, and I love them. You sometimes need to explain some things but it doesn't take more than a sentence of "we can't do this because it would break the other thing".
You are right not to be a burden in the conversation. You need to kill your Ego - talking endless confusing bullshit to make yourself seem important is a nightmare. But my MD could be accused of the same the way he had to realign my priorities with that of the company.
But when you understand that some of the people on the board of the company I worked for never even use a computer, a bridge is necessary.
I could be wrong and totally appreciate your distinction.
Edit- and I say that having worked with great coders but not many, if no great managers
A mediocre developer can hide behind the team or other circumstances that can be more or less hard to evaluate.
The place I work now doesn't really care about competence only a body filling a vacancy. Maybe it's time to find a new job...I digress.
To the untrained, though, above average coders and managers may appear great. But only once you've met an actual great one, you can really have perspective.
So, I respectfully disagree. I think it's as hard to find good coders as it is to find good managers, good opera singers, or good baby sitters.
I generally agree with greggman here, in the "average vs great" distinction.
However, this also reeks of "my job is more important than your job" bias. Everyone is a commodity (and jobs are too). It's just about how hard it is to find someone to replace them.
The company I worked for morphed into a juggernaut from retail beginnings. So the company was staffed with people so technically illiterate that it was amazing anything ever got done.
There should be a balance in everything. And generalists are sometimes just as important as specialists.
That's not what I said, though. I said that, if your job is to know things about the product, it helps if you are somewhat technical.
We don't care why you can't code. We care that you can't, and therefore are unable to understand the work of people who do.
Again: the reason for your technical incompetence is not the issue. We're not passing a moral judgement on your inability to code. We're passing a professional judgement to the effect of "you are unable to understand our work and therefore cannot make sound judgements about it".
The fact that you confuse these two things is a succinct example of everything that is wrong with non-technical management.
Obligatory 'Office Space' Movie Meme => http://weknowmemes.com/generator/uploads/generated/g13847403...
The manager is basically a group resource that _developers_ use. Instead of thinking of yourself as a boss of developers, think of yourself as a secretary that serves the developer team. For that you don't have to be very skilled, you just need to be able to communicate basic things, and know a little bit of lingo, which I'm sure you've been able to master.
You lost me here. If you can't do my job, you can't manage my job. Period.
This lax attitude towards manager competence is little more than forced, groupthink subjugation to the Peters Principle [1] and has created a 'management class' that is little more than a means to undermine the 'technical class' with bullshit, and it is a cancer on our industry.
[1 - https://en.wikipedia.org/wiki/Peter_principle ]
Nonsense. Managing people is a whole other bunch of skills distinct from the skills you need for coding. I won't disagree that a good manager who can code is a bonus though.
Manage me, by all means, using the newest-fangled management psychology you think is necessary, but if you can't do even the most basic of my tasks, you're simply not qualified for the job and should quit.
Seriously, this factor is cancerous on the industry and is, I believe, one of the most significant causes of the loss of productivity, revenue and ultimately success in our industry. Its time for this attitude to die.
Unfortunately, both of those things are pretty common. Promoting "up the ranks" gets you Peter, and hiring "for management skills" gets you Dilbert. Avoiding both at once seems to be an almost unsolved problem.
I can think of three distinct dimensions; technical, planning and political/coaching. Maybe it's four but I think the last two are sides of the same coin.
You need all of them to some extent.
Wait, Peter's Principle? If that's "promoted to their level of incompetence", shouldn't it describe managers who can do their subordinate's work but not their own?
This sounds closer to the Dilbert Principle, honestly - people who get hired as managers but could never have held the job below theirs.
I've learned software development, software security, machine learning, data analysis, calculus, physical sciences and engineering, technical report writing, photography, the basics of design and colour theory, financial instruments, how to manage projects and people, and the basics of economics and law.
It is not too much to expect that a technical manager learn at least one real programming language and use it to ship one real app before they start to try to understand and coordinate developers and designers.
This is not too much to expect.
I've been learning Russian for over a year and I expect it will be at least another year before I can comfortably have a conversation.
You can at least do a Ruby or Objective C over a eight week bootcamp.
Sometimes managers need you to check their summary for correctness ("Can you say it like that?"), because they in turn have to supply it to their bosses or consumers.
Every project will always involve people with little technical understanding who still need or want summarisation of technical decisions.
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.
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.
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.
What does "mansplained" mean in this context?
Of course they can. Are they going to is the question.
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.
> 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.
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.
It's very easy to forget the goals, value and cost when you understand the technical part of a project.
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.
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.
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.
There's a natural (and I think fundamental) inversion that happens as you go up the leadership chain. The first level of supervision almost inevitably knows more than the most junior employee about their area of work. (Think a senior developer mentoring a new college hire.)
That may hold for two levels, but at some point, management is about breadth and not depth. The head of technical operations probably came from networking or systems or storage or database or communications, but probably didn't come from ALL of those, so is unlikely to know more about networking than the head of networking AND more about databases than the head of databases, etc. In fact, they may know next to nothing about some particular field of ops and yet still be the right choice to lead operations. (I was in this position in a prior role.)
So you get this weird situation where at the junior levels, the supervisor knows more than the supervised. At the more senior levels, that's usually inverted. And then you get people who determine that the senior person is clueless because they know more about their specialized field than the boss.
IMO, it's unreasonable to expect the CEO of Boeing to be an expert in finance, operations, aerodynamics, manufacturing, supply chain, engine design, certification rules, avionics, landing gear, radar, flight controls, and the 100 other disciplines needed to make Boeing work. I see no reason to think that technology is extra-special in that all managers of technologists need to be world-class technologists.
And on some level, this makes sense. A completely junior employee may well need substantial guidance, and if they aren't reliable that won't necessarily be easy to predict - so you get them a supervisor who can evaluate their work in full. A midlevel or upper-level manager ought to be competent enough to perform reliably, and it's more useful to have someone above them with skills they don't have.
(Of course, hiring is a mess, and "senior staff ought to be qualified and reliable" is not the same as "senior staff are...")
In 4 levels of management the CEO is not to be the BS detector of the 1st level but most def. be "technical" enough to detect B.S. at the 4th and (maybe) the 3rd levels of management.
Those I admire and have studied: Disney, Elon, and Jobs (many others) could maybe detect down to the 2nd and 3rd levels. To do the impossible - you must have a grasp of the "possible"
Sometimes I think software people are lucky in this. Sure, non-technical management is too common, but mostly it just makes our lives harder. Talking to friends who work in process chemistry, civil engineering, and other high-stakes fields suggests that this is rarer, but nowhere near rare enough.
Obviously software has consequences, but usually mistakes can be caught in testing or otherwise mitigated. After hearing stories like an unqualified manager deciding that a pressure release valve is 'optional', it sounds like this still happens in settings where even the test suite can kill you.
You are supposed to be your management's bullshit detector. Sure, in an ideal world everyone in your office would be perfectly knowledgeable about all relevant topics but I would rather have management that's actually good at management, knows nothing about tech and knows they know nothing about tech over one that knows just enough to be dangerous.
Unless your company's core business is software, eventually there will be someone who is non-technical who will be required to make business decisions.
Edit: since I'm downvoted, allow me to explain- a good manager knows how to delegate and stay out of people's way, so I don't necessarily care if that person is technical or not, but a bad manager who is also a developer is going to insist on coding all the most critical parts of the application him- or herself and leave you to clean up their messes when they're stuck in meetings all day. That person is really more like an individual contributor with special privileges and I've worked with quite a few of them.
(Good Manager + No Tech Skills) > (Bad manager + great tech skills).
I don't think that is the argument... I think it is:
(Good Manager + No Tech Skill) < (Good Manager + great tech skills)...
and on that point no one would disagree.
It is interesting how so many have tried to frame the argument the first way - perhaps they are more of a unicorn than one would hope... but it would still be better to have BOTH skills.
Usually what happens is the best coder in the bunch gets asked to manage the team but 1) doesn't know anything about management and 2) doesn't want to be a manager but likes the power and fancy title. So this person just keeps on coding but with less accountability to the other team members.
What the tech world needs is more skilled managers, not more technical managers. People overvalue the notion of calling developers' bluff because there is a basic level of trust that is missing.
> 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.
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.
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.
Being technical or nontechnical is orthogonal to being able to ask the right questions about customer value. Nontechnical managers will go "framework? well if you say so" because they don't understand the tech. Technical managers will go "new framework? well if you say so" if the plan is technically well thought out, ignoring whether or not it actually creates business value.
There's an implicit misunderstanding here that engineers making technical arguments, are not making business cases. That is not correct. Good managers know how to interpret engineer arguments in a business context. Bad non-technical managers, will dismiss technical arguments because they aren't able to translate these arguments into a business context.
Sometimes good non-technical managers will nevertheless still do a good job by delegating this judgement based on people they trust. Someone with extra technical knowledge however, would have done an even better job.
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.
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.
Many other comments have pointed out various analogies in other fields that reinforce this.
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.
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.
But the important thing is that you understand, because you're the manager! Right?!