6 ms·

I think this illustrates a fundamental problem with the people being hired to manage programmers. I worked for a boss like this at Amazon. His degree wasn't ev

• herge 15y ago
  The term I recently discoved for these people is Non-Technical Middle Managers.
  • gte910h 15y ago
    I've worked with tons of non-technical middle managers. The real trick is to not budge on estimation math. P=Programmger M=Manager Bad one: P.Here is the estimate. M.I want it done faster. P.Okay cut things. M.No. P.Well, it will still be done according to the estimate, as that's math. We have to change what we're doing to shorten the estimate, we can't just arbitrarily shorten it. M. I expect it done in 70% of the time on the estimate. All Done. Or Else. Okay one: P. Here is the estimate. M. I want it done faster. P.Okay cut things. M.Take out so and so and do so and so less well. Good one: P.Here is the estimate. M.What are things we can do to shorten this? P. Okay, we can de-risk items 1, 2 and 17 by limiting the requirements to X, and we can save a ton of time if we drop the requirement we can display right to left languages as well. M. Let me run the first thing by the client. M. The second won't fly, but even 10% is good. I've worked with some EXCELLENT ones as well as some so so and some poor ones. The real trick is: Remember, their boss probably ALSO thinks they're not that good if they pull crap on their reports. Push back, and do well because of it.
    • tg3 15y ago
      It seems to me that the Programmer is also much better in the "Good one" scenario. Maybe not all the blame for a problematic relationship lies on one side?
      • gte910h 15y ago
        While your point is true, which is why I am encouraging programmers to say no to schedule lying, my point was poor non-tech managers talk down to and contradict their highly paid experts, rather than use them to solve their problems. Yes, programmers can fix this to some degree (the last chapter of the art of software estimation is great for teaching this), lots of these changes are something management has to do.
• nostrademons 15y ago
  Why don't you vote with your feet then and work for a company where your boss a.) knows how to write software and b.) knows how to manage software engineers. If a suitable company doesn't exist, why not start one? (Speaking to bystanders here, I know that your about page shows you're working on something cool.) When I look at my management chain at Google, it's engineers all the way up. My manager was a consultant for 20 years working on DARPA AI projects. My director wrote much of Google's critical early search infrastructure. My VP invented Google's ranking algorithm. My SVP used to work on chip design at Digital's Western Research Lab. My CEO invented PageRank. Things don't change unless people make them change. Where you see dysfunctional management, I see clueless lumbering behemoths that are tasty prey for a startup.
  • radog 15y ago
    But this isn't even true of many groups at Google, where people are managed by young (admittedly generally very smart) hotshot product managers without an engineering background.
    • nostrademons 15y ago
      I admittedly don't know everything that goes on at Google, but last I heard, a PM would never be people-managing an engineer (although there's a separate "manager" track that sometimes ends up managing engineers), and all PM hiring required a CS degree or engineering background. There was a period of time (roughly 2004-2007) where Google hired a bunch of managers without engineering backgrounds, but they discontinued that practice a long time ago because they found it doesn't work so hot. I've heard that many of the worst offenders have since attritioned away.
    • andrewflnr 15y ago
      How does one get to be a "product manager" without having an engineering background? Is there a degree for that? Mostly-serious question.
      • codeonfire 15y ago
• reinhardt 15y ago
  I am curious, is this a common and similarly frustrating experience for non-programmers? Are managers of, say, car technicians or accountants just as clueless about their subordinates?
  • sutterbomb 15y ago
    May be worse for programmers, but it all comes down to a lack of ground-level details. From 5,000 feet you can't see how thorny the bush is.
    • LearnYouALisp 15y ago
      As I read these comments, I was imagining a non-technical supervisor sitting down a programmer on a relatively small project to learn how their work is done, from start to finish. The project should be short enough for the manager or like person to see it completed over a few sessions, including the overview, the draft, and the testing and problem-solving. The programmer would explain the goal of the new project, like so: "We need to design a module that talks to the what-what the customer is using. It has to do three things: it must take an order from the what-what, then perform the appropriate action, and finally receive information back from the central system." "So, we begin with the first part of the module: the part that will take an order from the what-what. It needs to listen for a message from the unit the customer is interacting with. Then, it needs a rule concerning what to do with each order, that is, what instructions to follow." Once the basic form and actions of each section are established, then he or she can explain in more detail the actual working parts: "Now we need to step through the list of orders. With each order, we will check our rule set and perform the appropriate action. Once there are no more orders, we will tell the computer (or program) we are finished and it can proceed to the next step, which is receiving information back from the central system." Throughout, the programmer only needs to explain conceptually the work he is doing: Even the difficult or intricate concepts (details of network connections, perhaps) he may illustrate. The details of the actual programming language do not need to be explained for this purpose. (That is, he does not need to say, "Now we write 'Blob userOrders = new (Blob)' to create a new blob", or "We will receive the orders from the customer into an array ("What's that?") and step through them with a 'for' loop.") He or she might use a pen and paper to draw a diagram of the module as they design it. Once the manager has the overview of the system and knows how it is supposed to work, perhaps they can follow the writing of tests for it: "We will send it some simple test orders to see if it follows them correctly....And now we will give it an illogical order--did we check for a bad order?" Finally, the manager or supervisor can join the programmer as he or she goes back to the code to identify the source of the trouble. (More details could be added here.) The programmer does not need to oversimplify, but as they go deeper into the project together, the programmer can explain more technical details. Previously, these details would have been distracting, overwhelming, or incomprehensible to the the person they are teaching, but now they enable them and are necessary to see what the program is doing at this level, and why the problem occurred as it did. Could this be a realistic scenario, in certain cases at least?
• rickmb 15y ago
  How do you think this is ever going to change if programmers, some of the most sought after professionals in this economy, keep taking orders from these people? For a team with mature, responsible and professional developers, it shouldn't be such a big deal to have a non-technical manager anyway. Most management responsibilities have nothing to do with technical matters. A manager should serve the developers, not order them around. A good manager, technical background or not, will be glad to get out of the way of a good team. I myself am a manager with a technical background. I consider myself no more than mediocre as a manager. There are a lot of non-technical managers out there who could probably do a way better job managing , but they would have to be told by the programmers what they need from them. But most programmers don't speak up. Most programmers don't say no. Most programmers don't explain why interruptions are so costly, let alone outright refuse to let that ruin their work. Most programmers have never read pg's essay about maker time and manager time. A professional chef will walk out if his boss told him to burn every steak to a crisp, but most programmers will grumble a bit, get on with it and then (but only if they really care) bitch about it online. This despite the fact that chefs have way more to lose given the job market. With most programmers being so unprofessional, assigning a grade school teacher doesn't even sound like such a far fetched idea... It's not exclusively a senior management problem. Senior management doesn't know there is a problem unless they happen to have a technical background themselves, which is an unrealistic expectation, given that software is everywhere these days. It is first and foremost our problem. We're the ones that know what is wrong and how to fix it. We are the professionals this business relies on. Only assigning managers with a technical background isn't going to work anyway, because there are not enough of them to go round. As a programmer, you have to be a bit of masochist to put the peter principle to the test on yourself while your technical knowledge is still relevant, and people are willing to pay you good money just to code.
  • nirvana 15y ago
    "With most programmers being so unprofessional, assigning a grade school teacher doesn't even sound like such a far fetched idea..." Wow! FWIW, I am one who is genetically incapable of keeping his mouth shut. If something's stupid or sucks, I'll say so. If people disagree with me and have arguments to back up their disagreements I'll listen. I have zero tolerance for responses along the lines of "because I said so, just do it." In my experience, a lot of programmers are like this as well. There came a time when the CEO of the company where gradeschool teachers were the management was replaced... by someone who also knew nothing about development. She recognized all the problems with the product (which was being mismanaged) and I told her that the problem was management, how we'd tried to have reasonable practices, including repeated requests for a plan that we could stick to, and that the grade school teachers were in over their head. I recommend that they be put into a position to have input on the educational aspects of the product, but that engineering should be run by someone who understood engineering. She told me that there would be no management changes, and she wanted me-- given that I was the most senior engineer-- to give her a plan for fixing things. (Seemingly oblivious to the fact that I'd just given her the solution.) I told her I'd been working on a plan and that I'd give it to her in 30 minutes. Went back to my office, wrote a resignation letter, named the fact that management made product progress impossible as the reason, and handed it to her. She said "That was fast" and I said, it's not what you're expecting, and walked out of the office, never to return. (I had been on the bubble already, and would have resigned earlier if the events that led to her becoming the new CEO hadn't occurred.) I cannot think of anything more compelling than explaining why things were broken, making suggestions for how to fix it, those being rejected out of hand, and then emphasizing the point with a resignation. I was committed enough that I gave up my job, without a replacement lined up. I don't know what more could have possibly underlined the seriousness of my position to her. Do you think she learned anything by this? No management changes were made, but apparently I did have some impact: The gradeschool teachers got even more hysterical and neurotic after I left, starting to accuse employees of paranoid conspiracies, etc. More and more people started resigning. The company failed not long after this. It is my considered impression that most people who are clueless are not interested in thinking about things-- when something unusual happens, like my resignation-- they just assume that its a reflection on me, rather than the situation. Everyone working on the product knew the problem, there wasn't debate among us, but management was too ignorant to even understand that the problem was management. The grade school teachers saw everything thru that lens-- they thought "their kids" were screwing around or wasting time, or wanting to do thing their own way rather than the way they needed to be done, and so they believed it was just irresponsibility that was causing the product problems. Meanwhile we were getting whiplash as they changed their opinions and positions and demands for what the product would do on a weekly basis. One thing I've noticed in bad managers that is pretty consistent-- they tend to change their mind about what the product should do, and then think that their subordinates are slacking when the product doesn't do the new thing. Even thought they may have wasted 6 months under a prior plan, they don't account for that-- all those six months are credited towards the new plan, and why wasn't it done already if you had 6 months? In the case of the grade school teachers, this product was a magical wonderland where anything they could dream up could be created-- and any time their thoughts changed the product could change without any cost at all, cause to them it was totally plastic. So anytime someone said that these changes would take time and have impact on other things, they thought the person was just being lazy and didn't want to make the changes. I remember once, there was a rumor that a VC firm associated with Bill Gates might be investing, and so my boss came in and told me we had to replace all of our linux based infrastructure (file server, email server, web server, etc) with Windows. "If bill gate finds out we're using linux we won't get funded!" I told him it was silly as things were working fine... so he brought in a "windows consultant" who told us we needed to buy 4 new top of the line servers to replace our one spare developer PC that was doing all the work currently, cause "You can't run a web server and and FTP server on the same machine!" Naturally the grade school teacher believed his over priced consultant- who was telling him what he wanted to hear- over his engineer. How was he to know any different? He's a grade school teacher. (He now has a significant position at Microsoft, which I think is hilarious....)
• jrockway 15y ago
  Why does senior management at these companies think that programmers should be managed by people who know nothing about programming? Because most programmers don't want to manage. The few who do and are good at it are out of most companies' price range. Remember, as Random Educational Software Shop, you're competing in the same market as Google and Facebook. 99% of the good developers are going to go there instead, because they get more money and better work. You can't just wish people will work for you; you have to actively recruit them and make it worth their while.
• ameyamk 15y ago
  You seem to have awesome history of bosses!
• dkarl 15y ago
  Why does senior management at these companies think that programmers should be managed by people who know nothing about programming? A good manager can be good without knowing about programming. Right now I'm on a mixed team that is managed by a guy who has no background in programming. He trusts his people and delegates a lot of borderline managerial tasks, such as prioritizing technical work and evaluating the success of projects, to senior programmers. Apparently it's a viable way to manage programmers, because it works well for us. The manager lets technical folks make the technical decisions and backs his tech leads in cases of disagreement. It would all fall apart if he stopped trusting the judgment of his technical leads, but when management doesn't trust the judgment of their senior people, the situation is probably FUBAR anyway. Ditto if the senior technical folks behave unprofessionally -- it's a FUBAR situation until they act like adults or you get rid of them. Domain knowledge can help a constructive manager become a more valuable asset for his team, but any competent manager can at least learn to get out of his team's way and provide support in small ways. If a manager is an obstruction to getting work done, then he's a bad manager, and domain understanding won't turn him around. It might even make him more effective at being an obstruction.
• johnx123-up 15y ago
  Are you indicating Jeff Bezos?
• codeonfire 15y ago
  You're absolutely right and I know exactly what you are talking about. There is a crisis in software management and the people who run corporations don't and won't understand it. The problem is that lots of non-engineers want big money and are good enough bullshitters to get in over their heads. You get one in at a high level and of course someone with little to no experience is going to distrust the engineers who spent decades in universities and companies learning the field. Who are they going to hire for middle management, super knowledgeable trained engineering managers or other non-engineers who share their distrust? Their distrust is warranted as they are unqualified. The problem is only compounded by the fact that everyone can have a computer while not everyone can design and assemble a nuclear reactor or highway bridge. Therefore, people easily overestimate their understanding and abilities in being a dev manager. Add to this the fact that software is paying much better than many other fields including sciences, academia, and engineering and everyone wants in. The fallout is hellish work environments as programmers have to contend with these people (who bring over their outdated interpretation of the management role from their old careers), and a disengaged workforce looking for the exit doors. Long term this will only drive software costs up.