Helping how? Telling her boss to share control? Telling her where to click? There was absolutely nothing Ed could have done, and it's the expectation that he can fix every little thing that is the root of these problems.
This is what happens when there's no tech support people to interface with the users and translate the problem into engineering tickets. You either train the business users to be able to articulate the problem clearly and document the reproduction steps in the ticket, or the boss should have served as the interface to the business users to do the translation. Otherwise the engineers will be doing all the supports. As corporations continue to downsize, the remaining ones will take on more and more responsibility.
"I deal with the goddamn customers so the engineers don't have to! I have people skills! I am good at dealing with people! Can't you understand that? What the hell is wrong with you people?"
We all know that context switching is bad, and it's tough to switch so much, but did Ed really have nothing else to do? He seems bothered by what the boss was asking him, yet he blows most of the 3hrs not working on what he said he needed to work on originally? That just doesn't add up to me.
I get the point, and it's definitely true, but I spend those idle minutes doing mail and other short tasks. I don't see how one can justify "well I'm waiting for you so I'll just not work for a while."
Is this common outside of the computing industry? What do other people do in their 'in between' time?
A lot of times, there isn't anything you can work on that doesn't require a lot of concentration. I got an interrupt earlier today that put me on hold for an hour, while an email chain tried to sort out what was necessary.
How can I focus on implementing a hard feature when at any point, someone might pull me away from it and knock down my house of cards?
Hell, even if I'm writing code and suddenly I have to actually start working on a different project, I have to commit what I was doing, and try to squash everything later, or start stashing code around, and set up the other project's environment, etc. That's five minutes eaten up already.
I find learning something new doesn't require a lot of context switching, and while does not show immediate productivity, the long term gains to the organization are present and quite valuable. It beats just randomly surfing the internet anyway; bean counters may not agree.
Ed allocated his time according to his bosses request. During the entire time he was dedicated to making progress on his action item. If his company allocates time so poorly it is not Ed's fault. His boss clearly deprioritized his other tasks probably because he poorly estimated the time required by close to 2 orders of magnitude.
I can't imagine doing any useful work in the scenario being described.
If I'm being strung along like that, knowing that my attention could be required at any minute, it is extremely hard to load a chunk of code in my head because any spare brain-cycles are reflexively spent trying to figure out if my input is required yet.
This is very much like trying to read when you're tired. You'll read 5 pages and then all of a sudden realize you don't even know what you read in the previous paragraph.
Sure you can triage your mail and small tasks and quickly do the stuff that takes 3 or 4 minutes, but I find that I often have just a few of those tasks. Certainly not enough to fill 3 hours worth of time.
Great response. It's hard to get any real work done when you have to constantly context switch between different things. Ed didn't know that he'd have to waste 3 hours of his time. It was only supposed to take 10 minutes after all.
I've often had people ask me how I could context switch all the time like I did and stay sane and a bit productive. I usually reply this: "I might be a bit rusty but I can still dual task". It's generally enough for them to realize that they are asking me to do something that they would never accept to do themselves. They might not know the first thing about computer science, project management or actual IT work, but at least they understand that they're doing something wrong when they see me multitask only because of the additional work they give me.
Call that passive-aggressivity, social engineering or mind games, I call it just a game. Multitasking at work is tons of fun when you've practiced enough to recognize and leave all error-prone activities out of the picture. And it's very good to make people double-check their problem before they come bother you, even though you're behaving like an open and helpful guy all the time.
And if you do happen to try writing some code amid the constant interruptions, you stand a good chance of introducing some stupid error that could take hours to debug later. Best not to even try to code under such conditions.
I'll add that, after enough time, one can start to do this as a self-defense mechanism. Trying to switch back and forth -- and remember to keep switching back and forth -- becomes exhausting. And after this has happened to you enough in the first few years of your career, you can also start to get pretty pissed off. Deliberately "opting out" of the counter-productive switching, and/or of dwelling on its context, can be a way of retaining your sanity. Just document your time and how it was consumed, so that you can't be accused of being the cause of missing targets.
P.S. I'll add that if the boss had taken Ed's suggestion, all of this could have happened asynchronously in email or the ticket system. Especially if the user has been given a copy of SnagIt or similar screen capture software on their system (along with strong admonition to never "snag" confidential data) and been shown how to use it.
Screenshots (or these days I suppose, video) go into the ticket. Ed can see it's "really happening". Ed confirms and follows up with Fred. Fred responds the next time he reviews emails or tickets. Ed follows up with the boss.
Time for Sue: ~30 minutes
Time for boss: ~15 minutes
Time for Ed: ~15 minutes
Time for Fred: ~15 minutes
If Fred reviews at least once a day, boss would have his answer latest by mid-day of the following day. As compared to mid-afternoon of the same day while burning a lot of expensive time/resources.
I for one find it really difficult to context switch like that. I'd likely idly attempt to work on whatever I was doing to begin with, but it would be frustrating and not very rewarding:)
But, this should not have taken three hours. Seems like most of that time was spent waiting for unexpected[1] blocks. Why context-switch if it is possible that you'll need to do again in two minutes?
[1] Of course, when does web conferencing software work straighaway (whether it's a problem with the software or somewhere between the keyboard and the chair).
This is what I'm getting at. I don't believe most people are so laser-focused on a single one task that they have nothing else to do but read HN. If you have one and only one thing to do, you still might as well attempt to complete some facet of it. If you really can't find things to fill your time, perhaps you have a different problem. I don't see how reading HN is less frustrating than reading documents. It sure makes a nice excuse, but it's nothing more than an excuse to waste time.
Maybe I don't get it since I have a BigCorp job, but I've always got tons of little things I can do, if/when I want to. That sure seems like significantly better use of the companies time. Making the argument that "well this shouldn't happen!" is hardly solving any problem.
Interruptions are a fact of life, embrace them when they can't be avoided.
Ed, the funny thing is I have customers that end up paying to do this.
I give them an answer and then they take 3 hours going in circles to arrive back at my first email. I am slowly coming to see it as them paying for time towards their education when they decide to insist understanding the inner workings of something better than someone who has built it.
Despite my best to bring it to their attention to send me the information complete and once to get the quickest resolution, folks feel productive when going back and forth.
I squarely blame this on the Blackberry exec mindset. Talking all day by email or IM or phone doesn't mean you get anything done.
If you point it out, they won't like finding out they're the cause of slowing everything down, because they're so important.
It is often more effective to ask the right questions so that the other part can arrive at the correct conclusion by themselves instead of telling them the conclusion from the start.
Heh, I love the detail on all the confcall/web sharing problems.
Every conf call I join includes at least two of the following.
- The leader who is in the conf room calls in from the table phone and from their PC and can't figure out how to stop the screaming feedback. What's funny about this one to me is that the same people do it every time.
- Tom calls from his car. He must be on the interstate, judging from the road gradient we can hear.
- Dick joins from his laptop, where the microphone is conveniently part of the same physical device as the keyboard. CLACKCLACKCLACKCLACK.
- Harry is working from home. We become intimately familiar with his three-year-old daughter's escapades with Cheerios and love of Phineas & Ferb.
- Judging from the number of sirens, Jake apparently lives in a bad part of town or is watching Blues Brothers in the background.
- Lucy has apparently joined while sitting in a conference room, attending another meeting simultaneously.
- Robert joins 15 minutes late and would like everything he missed to be recapped.
- Mark absolutely will not let the meeting progress unless someone is recording. Everyone spends 10 minutes figuring out how to do this. No one can find the file at the end of the meeting.
- James calls in via a VOIP connection from India, introducing a slight delay. "Hello?" "Hellohello" "Hi James, can-" "Hello" "Hi James, we are-" "Hello, hi yes-" "Hi James-"
- Dave joins from the airport. According to the PA, someone named Janice needs to report to the ticket desk.
- Mike has apparently set his cell phone ringer volume to "over 9000" and has placed it next to his mic.
- "Can you see my screen?" "No". "How about now?" -cue pictures of cats- "Yes but I think you have shared the wrong monitor." "How about now?" -cue spreadsheet- "Yes." -cue scrolling that the video broadcast can't keep up with- "Now if you can see here, here and here..."
Mass meetings are the funniest. During one surreal leadership presentation where hundreds of people joined via a web meeting and many more were present in person, someone forgot to lock down presenter rights, and people kept drawing on the slides.
Hah! I've been on a conference call while in a building under an airport's departure corridor. If you're trying to talk, it sounds kinda like this:
"So, about that system rrrrrrrrrrrRRRRRRRRRRRRAAAAAAAAAAAAAGH and you think so?" (excuse the bad jet noises)
That was a fun hour or so - especially since, even muting the mic when you're not talking, when planes are taking off every 60 seconds, you're bound to get some background noise...
I've been dialing into conference calls all week from China, where it's still Lunar New Year. This means fireworks and firecrackers, from 8am til midnight. Sounds just like shells and machine guns.
"No, I don't live in a war zone, it's just Chinese New Year."
I have a hard believing that you'd be able to even do a conference call in the thick of it (especially the new year eve fireworks). I can barely have a conversation with the person in front of me, let alone do anything with the phone. Truly, a war zone isn't that bad.
We have a weekly seminar where many people call in. Without fail, every week, people must be reminded to mute their phone if they're not currently speaking.
There is a feature of dail-in meeting services (like Meetingplace, webex meeting, etc) that allow the host to auto-mute everyone... sounds like your organization might want to use that feature.
I know, and I've thought about telling the people who set the call up to do that, but our seminars also have regular, legitimate questions. We could have a protocol where questions come through IMs, but that's cumbersome.
Indeed, and in WebEx the host can auto-mute everyone, but then MUST tell people to unmute if they have a question, otherwise it is meeting #fail.
I've also had the opposite, where the host is UN-muting me, when I'm in the middle of eating my lunch during the meeting. I never got around to asking him WHY he wanted to hear me slurping my tea and crunching on my crisps (chips for the Americans).
Spot on. My favorite moments are when the person joining an in person meeting via conference call tells everybody that they can't hear. Usually, everyone just looks around awkwardly and somehow silently agrees to ignore that person.
During our first Livemeetings, I would draw pictures all over the slides. Little did I know, what I saw drawing was visible to everybody! Luckily, no one knew who was creating the drawings. Good times.
During our first Livemeetings, I would draw pictures all over the slides. Little did I know, what I saw drawing was visible to everybody! Luckily, no one knew who was creating the drawings. Good times.
sometimes during a call a music starts to play pretty loud from one side of the call, which renders the conference useless. I still wonder how that happens.
I was on a conference call once where that happened. It took over 20 minutes to figure out a) who the heck was doing that, and b) how to eject them from the call.
I never understood why people think it's acceptable to join a work call with kids screaming in the background. These are the same people who smugly ruin other people's flights and restaurant meals. You bred; congratulations. But you really, really shouldn't have.
The narrative of the webcast/screenshare and conference call difficulties describes virtually every such event I've been involved in. The 15 minutes wasted getting everyone online, the ad-hoc troubleshooting for people who can't seem to get signed in, or cant see the screen, or cant share their screen, etc. Are there any screen sharing technologies for quick ad-hoc sessions like this that JUST WORK?
Collective problem solving over group voice communications is a universal skill. Our dev team got really good at it when we all started playing Counterstrike together. MMORPG raiding would be a good place to learn this as well.
If nothing else, they'd be guaranteed to learn proper etiquette by learning what not to do.
He nailed it. I've experienced situations like that many times in my career. I'm now trying to live a life where I minimize my exposure to such Dilbertesque phenomena. Life's too short to piss it away on stupid people and inefficient processes.
I had something similar happen to me earlier in the week. The conversation went something like this:
Boss: Hey, we've got an urgent production issue that needs to be looked at. I'm getting some heat on this one and I need someone to diagnose it to see if it's a blocker for our release.
Me: Would you be able to ask X and Y to investigate? It seems they are on the support rotation for production issues. It'll take me at least an hour to clean up what I'm doing and switch over to run the old production instance locally.
Boss: It's urgent, I think you need to drop whatever you're doing and look at this.
Me: OK, sure.
(50 minutes later, as I'm almost done building the old production instance)
...
X and Y come back from a meeting.
Boss: I'll have X and Y look at this, you can go back to working on your stories for this sprint.
One of the advantages of doing eXtreme Programming with lots of pair programming is that we eventually setup machines to be assigned to certain branches. Costs more computers, but is more productive. The best thing ofcourse is to reduce that buildtime, but not a whole lot you can do there.
Funny... I assumed the punchline was going to be about the hours it takes a developer to get back into high productivity mode after interruption.
Sure, bosses and customers frequently underestimate the amount of time these sort of calls take and an intermediary (support) ought to take a stab at pulling a clear issue out first, but they're not always wasted time. There's a lot of value in getting devs and customers talking directly. It just needs to be (and can be) planned in a way that avoids breaking up the developer productivity curve unnecessarily.
This true for non-coder creatives, too. I can't count the number of times I've been asked to "look at a design" or "go over some copy" because three other employees had some feedback in some meting I wasn't a part of, but no one can remember exactly was "off" with the deliverable. We then have to do the SKype/email round robin until everyone has given their comments again.
This gets even worse when we, the creatives, get feedback about functional changes.
"When I click the checkout button, it goes to the shopping cart."
"Uh...yeah."
"Could you have an upsell page pop up between the two."
"I can write the copy and spec the creative and functional design, but I can't change the button functionality. You'll have to get that prioritized in the next sprint."
"We don't want to bother engineering. We need to get this done quickly."
"It's a functional change. We have to involve engineering."
"So you can't write the page."
"I can write the page. I can spec the page. I can't build or deploy the page."
Hmmm, lots of "yeah, I hate it when that happens" comments. Does anybody have ideas on how to fight this? Does anybody keep track like edw did, and then use it to defend themselves for the next "just ten minutes" task? Successfully?
I haven't been able to make a point about how it's not "just ten minutes" without coming off as rude/unhelpful/lazy. I've tried to explain the cost of context-switching, or push it off until I'm not being interrupted, or at least have other people do pre-requisite work first (filing a bug would've fast-forwarded to somewhere between 12:14 and 12:38 here).
In my dream world, a manager respects (or fears) you enough that you can say "you sit right here with me through this whole ordeal, and every minute of mine we waste, you owe me after 5 o'clock" and pull it off. Out here in the real world?
Sorry to say this, but I think that the 'just ten minutes' task is a symptom of a much deeper corporate problem.
For example, consider the boss in this story. Why does he/she think a task like this will only take 10 minutes? Is he a developer? Does he keep track of what is going on in other departments? Does he understand how a (seemingly simple) bug like this fits in the context of the whole project?
Or, here's another question. Why is a developer sitting on that particular conference call? Doesn't the company have a QA department, or an internal support department that documents the issue and provides steps to replicate?
Forgive me if I come across as being somewhat dismissive, but when I hear stories like this, I see signs of a very sick company that needs life support.
There is definitely a corporate problem (or many) here. At least the manager deciding that "this needs to be looked into right now" above edw's opinion, and the idea that the whole conf call + webconf dance was a better move than filing a ticket.
> Why is a developer sitting on that particular conference call? Doesn't the company have a QA department, or an internal support department that documents the issue and provides steps to replicate?
Exactly. How should one fight that these steps be taken, when your manager is trying to skip them? The thought process that I expect led to this situation were similar to "I could file a ticket, which will take me 5 minutes, or if I just show it to someone, it'll only take me 3 [not voiced: if nothing goes wrong.] That's working smarter!" Similarily, how do you convey to people the true cost of asking for something like this, instead of them treating everybody else's time and effort as externalities.
Yes, there are signs of a sick culture. Culture is fluid though, so how does one push it back towards health? Preferrably without getting classed as difficult/rude/not-a-team-player and then having any argument you bring ignored.
You might be shocked to hear this but the vast majority of businesses in the real world have such huge process issues that you'd diagnose most of the economy as full of "very sick companies that need life support".
I'm often on the other end of this; assigning "10 minute" tasks to people. What I try to do is have a common place where I will put these with the expectation that it is checked at least once per day; normally OneNote. I don't expect all of the tasks to be done each day, but I also don't want them sent into a black hole. I leave it up to the team to figure out when they can accomplish the tasks based upon when I need the work done or to provide me with feedback on feasibility.
If I have an urgent item that has to be done RIGHT NOW there may be an exception but in four years of being in this job I've only had a few of those. Those types of events are usually patient safety events where a patient's life is literally on the line and some piece of technology is acting up.
The first few times this may be followed by an explanation.
But if you don't say no, if you don't show that you are a serious professional who takes responsibility for his work, everything else will sound like whining.
Yes, there a lots of clueless non-technical managers out there, but most of them are neither complete douchebags, nor are they too thick to understand the problem.
Most of them will listen if you show them you're serious and not just trying to weasel your way out of something. If only because it is in their interests to take you seriously.
I think there are four recurring mistakes that cause these comical situations. Two are technical and two are social.
The first technical mistake is using communications tools with built-in latency: e-mail instead of IM/IRC, conference call that everyone must dial into at a specific time instead of starting with at least two people on a call and calling others to join in real time. E-mail and scheduled dial-in conference calls must be just about the least efficient methods of professional communication ever invented.
The other technical mistake is not having software for remote communications, particularly desktop sharing/presentations, that is readily available at the click of a mouse and familiar enough for all participants to set it up in moments. (A related mistake is using a dial-in conference service that isn't actually reliable. If you can't find one that works as it's supposed to -- and a lot of them don't, IME -- then you can at least ask someone to spend a bit of time and money installing an in-house solution if you need this facility often.)
The first social mistake is allowing one person's lack of preparation to waste time for everyone in the group. There is no excuse for coming to multiple people and asking them to set up a call to discuss a bug when you don't know the bug number, nor for them not to have the details in front of them when joining the call. It's basic good practice for any meeting that everyone know in advance who will be attending, why, and what the goals of the meeting are, that someone lead the meeting efficiently, and that the results be circulated promptly afterwards. If you get to the scale where you have to involve multiple people at the same time, failing to do these things will almost inevitably waste time, and again it will often be the whole group's time while one individual sorts out something they should have done earlier.
The second social mistake is being accepting of people who are late when a large meeting has been scheduled. Whenever possible, the meeting should start precisely on-time, and should not deviate from the published agenda to bring latecomers up to speed. If they miss out, it's their job to catch up afterwards, not the entire group's job to spin its wheels while someone recaps. If key people are consistently late and wasting others' time in this way, that is a serious management issue and someone needs to address why it is happening. Otherwise, you get to having a dozen people on the call, and if one key person is 10 minutes late because they were "just finishing an e-mail" then you've found another way to turn 10 minutes into two hours...
If it was 10 minutes to investigate and fix an urgent production bug, it would be OK. But he was asked time to join a teleconference in order to listen to a bug report! You can say "no" right there. A bug should be reported via a bug tracking system, maybe email for redundancy. There's no justification whatsoever to jump into a teleconference for a non-critical bug. Besides they got a QA department, so surely they have someone else (more technical than the bug reporter) who could look at it first to determine if it was really a bug, etc.
> "you sit right here with me through this whole ordeal, and every minute of mine we waste, you owe me after 5 o'clock"
That's not very savvy, to say the least. You sell your time to the company. The manager is not wasting your time, they're wasting the company's time or the "team's time" if you prefer. So you have to let him know when they're making decisions against their own best interest: "look, we have tasks A, B, and C, currently A is high priority, if you wish me to do task D, I'll be happy to do it, but it will delay A for n hours. And which of B or C should we re-schedule? I think it's C because blablah".
The thing is, it really did take about 10 minutes, but they weren't consecutive. Yeah, it's a bit of a smartass comment, but also true.
Some people really can be as productive (or close to it) doing 6 10 minute tasks in an hour, switching every few minutes between those 6. To them, they still just spent 10 minutes on each task, and they're oblivious to the fact that not everyone's work can be sliced around like that with the same degree of quality that theirs can.
The hardest part is making sure no one finds out about all them, and that information doesn't leak between those discreet tasks. Indiscretions are killer.
If this is happening frequently, then you need a support stuff. The support stuff will spend those 3 hours to get the actually problem and explain it to you in 10 minutes at the end of the day.
If you want to focus, and your work is programming then you should delegate support to someone else. Probably a knowledgeable person about the software and some programming/technical skills to solve trivial problems.
Ed really wasn't working but just reading HN. He is one of those guys who is always busy but doesnt do anything. The problem is Ed's boss thinks that he is actually good. The problem is not just with Ed though, his boss should have had Sue on call before get Ed on. Sue is lazy too. This is a company that is not getting anywhere. :)
I think it's a disgrace that your comment is near the bottom of this thread. Ed's attitude sucks and he will cost the company money. The people down voting you don't seem to care much for having a work ethic.
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 even in business, but in criminal justice-- he was trained to be a prison guard and acted like it. His boss was even worse- I swear she must have been an ex-DMV employee, all attitude, no knowledge. (I forget her area of study but it had nothing to do with management, business or computer science.)
A previous boss was-- and I am not kidding here at all-- a grade school teacher. He was in charge of the programmers. Knew nothing about programming but since the company was making educational software, obviously an gradeshool teacher should be running the department, right? The person running the art department was also a grade school teacher. They all had mastered that patronizing "settle down children" tone, and used it constantly. When we'd tell them that what they were asking wasn't practical or would take extra time, they'd be patronizing like we were trying to lie about having spilled milk. It is hilarious in retrospect.
Why does senior management at these companies think that programmers should be managed by people who know nothing about programming?
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.
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?
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.
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.
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.
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.
"... 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? ..."
To me that's the difference between "developer, technologist, engineer" & "entrepreneur". The former will simply be happy if the conditions are suitable. The later wants to build their own company to create the conditions they want. In effect be their own boss.
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?
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?
"Could this be a realistic scenario, in certain cases at least?"
No, the supervisor's primary motivation is to avoid blame while gaining power. If they know how everything works, there is no deniability when their plan fails. The game they play is to promise the impossible to their bosses in hopes of promotion and blame the 90% that didn't go to their plan on the programmers while trying to take full credit for the 10% that was pulled off by heroic coding. To this end, no supervisor will be caught in a 'code' conversation. If they understood software engineering they would be on the hook for the 90% as well.
Where an honest supervisor needs to learn the fundamentals of software engineering is at the school and then later as a software engineer. You can get a BS in software engineering in many places and go on to obtain a Masters in technology management. Also work 5-10 years in deliberate practice as a software engineer. There is no 'sit down for an hour and learn software engineering' just like there is no 'sit down for an hour and learn how a nuclear reactor works'. What you are talking about is remedial training, but none of these guys would go for it. Their philosophy is that people willing to do technical work are simple fools to be exploited. Usually they are very glib about the idea that they skipped all the hard technical stuff.
In my experience no, but that doesn't necessarily mean they were better managers.
The specific problem with programming is it's pretty much invisible - the end result, when well done, hides the enormous levels of complexity it takes to create it. It's just 'another website' or whatever.
That's compounded by the problem that, in the U.S. at least, managers seem to think their job is having influence/power over people, and telling them/making do things. In fact, management is supposed to be a support role. Managers should be creating an environment that enable their employees to do their job as best as possible.
In my experience -many- managers exist to please the person above them, and think very little (or, at best, simply are unable to see) how their actions effect their employees happiness and productivity.
Having worked in the service side of a BMW dealership, the service manager there was a tech who got promoted into the position. He was the go-to guy whenever there was a hard technical problem to solve. Some companies Do It Right, others don't.
A friend of mine is a pipeline engineer, and he said all their middle management (his boss, his boss's boss, and possibly higher up) are mostly promoted from engineers.
Their team lead is generally the most experienced/capable person on the team.
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.
"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 ...
Although I can completely identify with your story (been there, done that, more than once), you have to realize that you haven't given her a solution, nor have you taken responsibility (except for your own career, which sometimes is of course the best thing to do).
You've only told her management is the problem, that "engineering should be run by someone who understood engineering", not that the engineers can run the engineering part themselves.
"We need better managers" is just as non-constructive as "we need more programmers to make the deadline". You cannot open a can of competent managers just like you cannot open a can of competent programmers and everything will be alright.
You want to convince management you can do a better job? Show them. Sure, it means sticking your neck out. It means you may fail. Hell, it means you may get fired for even trying, instead of being allowed the dignity of quitting yourself.
But that is commitment. That is putting your ass on the line because you believe in what you stand for. You want good engineering practices? Start applying them. You want a realistic plan? Make one. (One caveat: incumbent managers may turn out not be your main impediment. Some coworkers who will gladly join you in bitching sessions will run for cover if you actually try to change things from the inside. You know, the guys that stayed when you quit and continued to take it up the ass without protest.)
It's only when clueless management insists on telling you how to do your job and prevents you from doing it right is when you run out of options.
Don't get me wrong, I'm not saying that is what you personally should have done. Most of the mismanagement you're describing is just pure mismanagement, nothing to do with being technical or not.
But just doing it is the best chance of actually changing things, rather than to wait for a that rare manager-with-technical-background to come and rescue you.
Or of course start your own company. In which case, unless you prefer to go solo, you may at some point find yourself dealing with the same issue from the other end.
I think that you are taking it a bit too far here. If the new CEO couldn't pick up after he had laid all of that out, it was most likely hopeless. After years and years of banging my head against walls, I have learned that sometimes people are just not capable of processing what you're talking about, and that the best course of action is to leave these people totally alone and try again in 2-3 years and see what has changed.
Sure, he could have tried to lead an internal revolution or whatever, but the reality is that after he hurt the wrong person's feelings on the third day he would have been fired anyway. He could have spent a few days laying out a very formal reiteration of everything he had just told the new CEO, but after she discarded the executive summary so flippantly, what would have been the point?
He's passing judgement on a situation he wasn't present at, based purely on his projections onto it. Essentially everything he said is false, but he's got an axe to grind and he's grinding it. I'm not needed for it, and there's not much point in debating him on events he has no knowledge of.
In fact, this is part of the reason I think engineering managers should understand engineering. Its not that one who doesn't can't be a good manager, its just that by understanding engineering they understand the consequences of the decisions they make. If a manager simply trusted his subordinates, then knowing engineering might not be necessary.
But the bad managers generally don't. They think that engineering explanations that go over their head are BSing because the engineer is lazy or doesn't want to do the work, or is padding the estimate or whatever. The tend to project onto engineers all the fault, and blame them for "not speaking up" (when in fact they did speak up but were ignored) or whatever rationalization is convenient at the time. They project this worldview onto actions to explain them, when in reality, what they're trying to "explain" has been already explained to them-- only in engineering terms.
I think bad managers also often have a superiority complex where they see a class divide between "management" and "workers". And they think that they job is to keep workers working, as if we're orcs in Warcraft who have to be beaten with a stick or we'll lie down and take a snooze.
Now I'm on the other side of the table. I am the manager. I've had challenges with employees, and they are always interesting and different.... but none of them are lazy, and none of them were making shit up to get out of work.
I'm not passing judgement on you personally. In fact, I twice emphasized that I'm not saying that is what you should have done.
You may have had a Very Bad Manager. There may have been nothing you could have done about it, other than walk away. I totally accept that.
But you write: they (managers) see a class divide between "management" and "workers"
When what I see in your words is you (the programmer at the time) seeing (and reinforcing through your actions) a class divide between management and workers. You blame the bad managers for a behavioral pattern that you were just a as much a part of. At least that's what I read in your words.
And that's what I see in many other programmers. They act like children with zero responsibility, and then complain about being treated as such by evil pointy haired bosses.
It's a two way street. And given that we, the engineers, are the ones who know how it should be done, we have a considerable responsibility in changing it.
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.
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.
I think you should cut her a little slack and take into account her job. You're concentrating on her rational evaluation of your arguments, but that skips right past the hard part of her job. She was still trying to figure out if she could trust your characterization of the facts. Really, if you were her, would you completely reorganize management on the say-so of a single individual before getting a more complete picture?
And if you decided to completely reorganize management, would you tell people about it the instant you made your decision, or would you keep it under your hat until you figured out 1) how to present the decision to the board (or whoever she answered to), 2) how to manage the transition so a bunch of people with institutional knowledge didn't disappear before she could replace them, and 3) how to avoid getting undermined by the people she was plotting against, who may have had significant credibility with the board and with management in other parts of the company?
And if you decided to essentially demote some people by sidelining them in the org chart, would you give one of their subordinates a heads-up before you had a chance to tell them about it?
Finally, it's reasonable to ask you to come up with a solution that differs from the optimal one. You do it in engineering all the time, and management isn't any different. You would say, "Licenses for this software account for 30% of the project budget. Suppose the license fees doubled -- can we design a solution that doesn't use this software?" She might have been thinking, "Gosh, I hope I can get some real development managers in here in three months, but what if it takes a year? I better have a plan for getting products out in the meantime."
* Most management responsibilities have nothing to do with technical matters. A manager should serve the developers, not order them around.*
Exactly. That's what good management does: insulate the programmers from as much nonsense that is possible. A good manager has some grasp of the field so that he can block at least the most outrageous feature requests from the devs or at least delay asking about them until a weekly meeting or something. If the devs have problem, the manager will drive the issues through the cogs and clogs of the organization and bureaucracy instead of using valuable developer time to track those issues.
An anecdote: I have had travelling arranged by a competent office manager and a company-wide travel reservation and approval system. Guess which saved so much time from everyone, sending an email to the office manager "I need to fly to X next Tuesday, my boss on Cc: with this" and afterwards dropping a stack of receipts back to her for filing reimbursements, or a dozen people trying to figure out what's the best way through the travel system without sacrificing too much work time on that and still ending up scanning individual receipts for uploading to the system.
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.
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.
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.
This has a lot to do with the claim that some programmers are 10x more productive than other programmers.
If this happens to you more than once a month, you're not in the 10x club. If you want to be in the 10x club you need to avoid this at all cost. Otherwise you're just another muggle chafing at the bit.
I think the message is to change your environment such that you're not getting this sort of interruption.
I interviewed, three times (and turned down, three times) with a firm that apparently really wanted me. Why?
1: They were a very small vendor working for a very large client. The client is a household (swear) word, and behaves in a gratuitously overbearing manner to its customers and other vendors.
2: Everyone I spoke with admitted that this relationship lead to many, many last-minute changes in spec requiring much overtime and pain to make things just so. All while praying that things wouldn't change yet again at the next last minute.
Dear programmer: If the Boss asks you something, it's okay to say "no".
Since your boss is apparently unaware of the problem, who's going to solve it if you don't speak up? There are no magic hacker fairies on HN that are going to do that for you.
Be careful about how you phrase "no". Sometimes an explanation of what's involved, previous times on similar tasks, and a question ("sure, would you like me to go ahead and start now?" after explaining that it will likely take two hours instead of two minutes) goes a lot further.
I agree with you and the parent. It's a conversation you need to have at least once. Explain your workflow, getting in the zone, etc. Explain why there is a ticketing system. Explain the disruption to the productive day that interruptions like this bring.
It totally sucks that you can't just be a semi-independent craftsman who works on what comes their way in a nice orderly queue, but that's the reality of today's workforce. If the interruptions keep happening time and time again after having this conversation and following up on it, then at least you know where you stand in this company.
The problem is, you suddenly have an onus to be polite about it.
"I have a concern that this may not be feasible".
"No, you just have to try harder!"
"Sorry, I wasn't very clear: This is flat out impossible".
"Are you sure?"
"Yes, because google tried, and couldn't do it. You see, it's actually impossible to get the (technical mumbo jumbo) so it will take literally years to run a single query."
And this isn't a typical case. The most likely case is you suspect that the boss is leading everyone into the valley of death, but can't prove it. Do you confront them yourself, try to sound out other colleagues (who may have other concerns, since it's not their problem), or just warn them that there's likely to be problems, and gradually manage their expectations?
In an ideal world, bosses are good at both ferreting out concerns fro indirect hints ("I'm a bit worried that"), and dealing with direct statements ("It's impossible, you git!"). In reality, they are often just wage slaves who kiss up and kick down, and don't really care if the project flops as long as someone else is to blame.
Dear programmer, when your boss says 'can you spare 10 minutes for me' he probably means 'can you help me take care of this exceptional situation'. The bug was probably severe and the boss wanted a dev to confirm that it was live before taking it to the steering commitee. The only slight wtf is how the boss worded that request. But taking something to the steering committe is a pretty big deal, so I understand that he would want to confirm it!
168 comments
[ 6.7 ms ] story [ 256 ms ] threadHey now, what are you trying to imply? :)
I get the point, and it's definitely true, but I spend those idle minutes doing mail and other short tasks. I don't see how one can justify "well I'm waiting for you so I'll just not work for a while."
Is this common outside of the computing industry? What do other people do in their 'in between' time?
How can I focus on implementing a hard feature when at any point, someone might pull me away from it and knock down my house of cards?
Hell, even if I'm writing code and suddenly I have to actually start working on a different project, I have to commit what I was doing, and try to squash everything later, or start stashing code around, and set up the other project's environment, etc. That's five minutes eaten up already.
If I'm being strung along like that, knowing that my attention could be required at any minute, it is extremely hard to load a chunk of code in my head because any spare brain-cycles are reflexively spent trying to figure out if my input is required yet.
This is very much like trying to read when you're tired. You'll read 5 pages and then all of a sudden realize you don't even know what you read in the previous paragraph.
Sure you can triage your mail and small tasks and quickly do the stuff that takes 3 or 4 minutes, but I find that I often have just a few of those tasks. Certainly not enough to fill 3 hours worth of time.
Call that passive-aggressivity, social engineering or mind games, I call it just a game. Multitasking at work is tons of fun when you've practiced enough to recognize and leave all error-prone activities out of the picture. And it's very good to make people double-check their problem before they come bother you, even though you're behaving like an open and helpful guy all the time.
P.S. I'll add that if the boss had taken Ed's suggestion, all of this could have happened asynchronously in email or the ticket system. Especially if the user has been given a copy of SnagIt or similar screen capture software on their system (along with strong admonition to never "snag" confidential data) and been shown how to use it.
Screenshots (or these days I suppose, video) go into the ticket. Ed can see it's "really happening". Ed confirms and follows up with Fred. Fred responds the next time he reviews emails or tickets. Ed follows up with the boss.
If Fred reviews at least once a day, boss would have his answer latest by mid-day of the following day. As compared to mid-afternoon of the same day while burning a lot of expensive time/resources.[1] Of course, when does web conferencing software work straighaway (whether it's a problem with the software or somewhere between the keyboard and the chair).
Maybe I don't get it since I have a BigCorp job, but I've always got tons of little things I can do, if/when I want to. That sure seems like significantly better use of the companies time. Making the argument that "well this shouldn't happen!" is hardly solving any problem.
Interruptions are a fact of life, embrace them when they can't be avoided.
I give them an answer and then they take 3 hours going in circles to arrive back at my first email. I am slowly coming to see it as them paying for time towards their education when they decide to insist understanding the inner workings of something better than someone who has built it.
Despite my best to bring it to their attention to send me the information complete and once to get the quickest resolution, folks feel productive when going back and forth.
I squarely blame this on the Blackberry exec mindset. Talking all day by email or IM or phone doesn't mean you get anything done.
If you point it out, they won't like finding out they're the cause of slowing everything down, because they're so important.
0.02
It is often more effective to ask the right questions so that the other part can arrive at the correct conclusion by themselves instead of telling them the conclusion from the start.
Every conf call I join includes at least two of the following.
- The leader who is in the conf room calls in from the table phone and from their PC and can't figure out how to stop the screaming feedback. What's funny about this one to me is that the same people do it every time.
- Tom calls from his car. He must be on the interstate, judging from the road gradient we can hear.
- Dick joins from his laptop, where the microphone is conveniently part of the same physical device as the keyboard. CLACKCLACKCLACKCLACK.
- Harry is working from home. We become intimately familiar with his three-year-old daughter's escapades with Cheerios and love of Phineas & Ferb.
- Judging from the number of sirens, Jake apparently lives in a bad part of town or is watching Blues Brothers in the background.
- Lucy has apparently joined while sitting in a conference room, attending another meeting simultaneously.
- Robert joins 15 minutes late and would like everything he missed to be recapped.
- Mark absolutely will not let the meeting progress unless someone is recording. Everyone spends 10 minutes figuring out how to do this. No one can find the file at the end of the meeting.
- James calls in via a VOIP connection from India, introducing a slight delay. "Hello?" "Hellohello" "Hi James, can-" "Hello" "Hi James, we are-" "Hello, hi yes-" "Hi James-"
- Dave joins from the airport. According to the PA, someone named Janice needs to report to the ticket desk.
- Mike has apparently set his cell phone ringer volume to "over 9000" and has placed it next to his mic.
- "Can you see my screen?" "No". "How about now?" -cue pictures of cats- "Yes but I think you have shared the wrong monitor." "How about now?" -cue spreadsheet- "Yes." -cue scrolling that the video broadcast can't keep up with- "Now if you can see here, here and here..."
Mass meetings are the funniest. During one surreal leadership presentation where hundreds of people joined via a web meeting and many more were present in person, someone forgot to lock down presenter rights, and people kept drawing on the slides.
"So, about that system rrrrrrrrrrrRRRRRRRRRRRRAAAAAAAAAAAAAGH and you think so?" (excuse the bad jet noises)
That was a fun hour or so - especially since, even muting the mic when you're not talking, when planes are taking off every 60 seconds, you're bound to get some background noise...
"No, I don't live in a war zone, it's just Chinese New Year."
I've also had the opposite, where the host is UN-muting me, when I'm in the middle of eating my lunch during the meeting. I never got around to asking him WHY he wanted to hear me slurping my tea and crunching on my crisps (chips for the Americans).
He never fails to do it.
If nothing else, they'd be guaranteed to learn proper etiquette by learning what not to do.
Boss: Hey, we've got an urgent production issue that needs to be looked at. I'm getting some heat on this one and I need someone to diagnose it to see if it's a blocker for our release.
Me: Would you be able to ask X and Y to investigate? It seems they are on the support rotation for production issues. It'll take me at least an hour to clean up what I'm doing and switch over to run the old production instance locally.
Boss: It's urgent, I think you need to drop whatever you're doing and look at this.
Me: OK, sure.
(50 minutes later, as I'm almost done building the old production instance)
...
X and Y come back from a meeting.
Boss: I'll have X and Y look at this, you can go back to working on your stories for this sprint.
Me: !@#?$
Sure, bosses and customers frequently underestimate the amount of time these sort of calls take and an intermediary (support) ought to take a stab at pulling a clear issue out first, but they're not always wasted time. There's a lot of value in getting devs and customers talking directly. It just needs to be (and can be) planned in a way that avoids breaking up the developer productivity curve unnecessarily.
This gets even worse when we, the creatives, get feedback about functional changes.
"When I click the checkout button, it goes to the shopping cart."
"Uh...yeah."
"Could you have an upsell page pop up between the two."
"I can write the copy and spec the creative and functional design, but I can't change the button functionality. You'll have to get that prioritized in the next sprint."
"We don't want to bother engineering. We need to get this done quickly."
"It's a functional change. We have to involve engineering."
"So you can't write the page."
"I can write the page. I can spec the page. I can't build or deploy the page."
"That's disappointing."
"You have no idea."
I haven't been able to make a point about how it's not "just ten minutes" without coming off as rude/unhelpful/lazy. I've tried to explain the cost of context-switching, or push it off until I'm not being interrupted, or at least have other people do pre-requisite work first (filing a bug would've fast-forwarded to somewhere between 12:14 and 12:38 here).
In my dream world, a manager respects (or fears) you enough that you can say "you sit right here with me through this whole ordeal, and every minute of mine we waste, you owe me after 5 o'clock" and pull it off. Out here in the real world?
For example, consider the boss in this story. Why does he/she think a task like this will only take 10 minutes? Is he a developer? Does he keep track of what is going on in other departments? Does he understand how a (seemingly simple) bug like this fits in the context of the whole project?
Or, here's another question. Why is a developer sitting on that particular conference call? Doesn't the company have a QA department, or an internal support department that documents the issue and provides steps to replicate?
Forgive me if I come across as being somewhat dismissive, but when I hear stories like this, I see signs of a very sick company that needs life support.
> Why is a developer sitting on that particular conference call? Doesn't the company have a QA department, or an internal support department that documents the issue and provides steps to replicate?
Exactly. How should one fight that these steps be taken, when your manager is trying to skip them? The thought process that I expect led to this situation were similar to "I could file a ticket, which will take me 5 minutes, or if I just show it to someone, it'll only take me 3 [not voiced: if nothing goes wrong.] That's working smarter!" Similarily, how do you convey to people the true cost of asking for something like this, instead of them treating everybody else's time and effort as externalities.
Yes, there are signs of a sick culture. Culture is fluid though, so how does one push it back towards health? Preferrably without getting classed as difficult/rude/not-a-team-player and then having any argument you bring ignored.
If I have an urgent item that has to be done RIGHT NOW there may be an exception but in four years of being in this job I've only had a few of those. Those types of events are usually patient safety events where a patient's life is literally on the line and some piece of technology is acting up.
The first few times this may be followed by an explanation. But if you don't say no, if you don't show that you are a serious professional who takes responsibility for his work, everything else will sound like whining.
Yes, there a lots of clueless non-technical managers out there, but most of them are neither complete douchebags, nor are they too thick to understand the problem.
Most of them will listen if you show them you're serious and not just trying to weasel your way out of something. If only because it is in their interests to take you seriously.
The first technical mistake is using communications tools with built-in latency: e-mail instead of IM/IRC, conference call that everyone must dial into at a specific time instead of starting with at least two people on a call and calling others to join in real time. E-mail and scheduled dial-in conference calls must be just about the least efficient methods of professional communication ever invented.
The other technical mistake is not having software for remote communications, particularly desktop sharing/presentations, that is readily available at the click of a mouse and familiar enough for all participants to set it up in moments. (A related mistake is using a dial-in conference service that isn't actually reliable. If you can't find one that works as it's supposed to -- and a lot of them don't, IME -- then you can at least ask someone to spend a bit of time and money installing an in-house solution if you need this facility often.)
The first social mistake is allowing one person's lack of preparation to waste time for everyone in the group. There is no excuse for coming to multiple people and asking them to set up a call to discuss a bug when you don't know the bug number, nor for them not to have the details in front of them when joining the call. It's basic good practice for any meeting that everyone know in advance who will be attending, why, and what the goals of the meeting are, that someone lead the meeting efficiently, and that the results be circulated promptly afterwards. If you get to the scale where you have to involve multiple people at the same time, failing to do these things will almost inevitably waste time, and again it will often be the whole group's time while one individual sorts out something they should have done earlier.
The second social mistake is being accepting of people who are late when a large meeting has been scheduled. Whenever possible, the meeting should start precisely on-time, and should not deviate from the published agenda to bring latecomers up to speed. If they miss out, it's their job to catch up afterwards, not the entire group's job to spin its wheels while someone recaps. If key people are consistently late and wasting others' time in this way, that is a serious management issue and someone needs to address why it is happening. Otherwise, you get to having a dozen people on the call, and if one key person is 10 minutes late because they were "just finishing an e-mail" then you've found another way to turn 10 minutes into two hours...
> "you sit right here with me through this whole ordeal, and every minute of mine we waste, you owe me after 5 o'clock"
That's not very savvy, to say the least. You sell your time to the company. The manager is not wasting your time, they're wasting the company's time or the "team's time" if you prefer. So you have to let him know when they're making decisions against their own best interest: "look, we have tasks A, B, and C, currently A is high priority, if you wish me to do task D, I'll be happy to do it, but it will delay A for n hours. And which of B or C should we re-schedule? I think it's C because blablah".
Some people really can be as productive (or close to it) doing 6 10 minute tasks in an hour, switching every few minutes between those 6. To them, they still just spent 10 minutes on each task, and they're oblivious to the fact that not everyone's work can be sliced around like that with the same degree of quality that theirs can.
What is hard if you have one four hour task, and one task that requires your attention every fifteenth minute. It completely ruins the four hour task.
So thank you.
If you want to focus, and your work is programming then you should delegate support to someone else. Probably a knowledgeable person about the software and some programming/technical skills to solve trivial problems.
(Stolen from the Reddit thread: http://www.reddit.com/r/programming/comments/p9mxq/dear_boss...)
Ed is a bad employee not because he is wasting time, but because he is publicly cultivating a culture of blaming time sink on others.
A previous boss was-- and I am not kidding here at all-- a grade school teacher. He was in charge of the programmers. Knew nothing about programming but since the company was making educational software, obviously an gradeshool teacher should be running the department, right? The person running the art department was also a grade school teacher. They all had mastered that patronizing "settle down children" tone, and used it constantly. When we'd tell them that what they were asking wasn't practical or would take extra time, they'd be patronizing like we were trying to lie about having spilled milk. It is hilarious in retrospect.
Why does senior management at these companies think that programmers should be managed by people who know nothing about programming?
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.
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.
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.
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.
To me that's the difference between "developer, technologist, engineer" & "entrepreneur". The former will simply be happy if the conditions are suitable. The later wants to build their own company to create the conditions they want. In effect be their own boss.
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?
No, the supervisor's primary motivation is to avoid blame while gaining power. If they know how everything works, there is no deniability when their plan fails. The game they play is to promise the impossible to their bosses in hopes of promotion and blame the 90% that didn't go to their plan on the programmers while trying to take full credit for the 10% that was pulled off by heroic coding. To this end, no supervisor will be caught in a 'code' conversation. If they understood software engineering they would be on the hook for the 90% as well.
Where an honest supervisor needs to learn the fundamentals of software engineering is at the school and then later as a software engineer. You can get a BS in software engineering in many places and go on to obtain a Masters in technology management. Also work 5-10 years in deliberate practice as a software engineer. There is no 'sit down for an hour and learn software engineering' just like there is no 'sit down for an hour and learn how a nuclear reactor works'. What you are talking about is remedial training, but none of these guys would go for it. Their philosophy is that people willing to do technical work are simple fools to be exploited. Usually they are very glib about the idea that they skipped all the hard technical stuff.
The specific problem with programming is it's pretty much invisible - the end result, when well done, hides the enormous levels of complexity it takes to create it. It's just 'another website' or whatever.
That's compounded by the problem that, in the U.S. at least, managers seem to think their job is having influence/power over people, and telling them/making do things. In fact, management is supposed to be a support role. Managers should be creating an environment that enable their employees to do their job as best as possible.
In my experience -many- managers exist to please the person above them, and think very little (or, at best, simply are unable to see) how their actions effect their employees happiness and productivity.
Their team lead is generally the most experienced/capable person on the team.
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.
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 ...
You've only told her management is the problem, that "engineering should be run by someone who understood engineering", not that the engineers can run the engineering part themselves.
"We need better managers" is just as non-constructive as "we need more programmers to make the deadline". You cannot open a can of competent managers just like you cannot open a can of competent programmers and everything will be alright.
You want to convince management you can do a better job? Show them. Sure, it means sticking your neck out. It means you may fail. Hell, it means you may get fired for even trying, instead of being allowed the dignity of quitting yourself.
But that is commitment. That is putting your ass on the line because you believe in what you stand for. You want good engineering practices? Start applying them. You want a realistic plan? Make one. (One caveat: incumbent managers may turn out not be your main impediment. Some coworkers who will gladly join you in bitching sessions will run for cover if you actually try to change things from the inside. You know, the guys that stayed when you quit and continued to take it up the ass without protest.)
It's only when clueless management insists on telling you how to do your job and prevents you from doing it right is when you run out of options.
Don't get me wrong, I'm not saying that is what you personally should have done. Most of the mismanagement you're describing is just pure mismanagement, nothing to do with being technical or not.
But just doing it is the best chance of actually changing things, rather than to wait for a that rare manager-with-technical-background to come and rescue you.
Or of course start your own company. In which case, unless you prefer to go solo, you may at some point find yourself dealing with the same issue from the other end.
Sure, he could have tried to lead an internal revolution or whatever, but the reality is that after he hurt the wrong person's feelings on the third day he would have been fired anyway. He could have spent a few days laying out a very formal reiteration of everything he had just told the new CEO, but after she discarded the executive summary so flippantly, what would have been the point?
In fact, this is part of the reason I think engineering managers should understand engineering. Its not that one who doesn't can't be a good manager, its just that by understanding engineering they understand the consequences of the decisions they make. If a manager simply trusted his subordinates, then knowing engineering might not be necessary.
But the bad managers generally don't. They think that engineering explanations that go over their head are BSing because the engineer is lazy or doesn't want to do the work, or is padding the estimate or whatever. The tend to project onto engineers all the fault, and blame them for "not speaking up" (when in fact they did speak up but were ignored) or whatever rationalization is convenient at the time. They project this worldview onto actions to explain them, when in reality, what they're trying to "explain" has been already explained to them-- only in engineering terms.
I think bad managers also often have a superiority complex where they see a class divide between "management" and "workers". And they think that they job is to keep workers working, as if we're orcs in Warcraft who have to be beaten with a stick or we'll lie down and take a snooze.
Now I'm on the other side of the table. I am the manager. I've had challenges with employees, and they are always interesting and different.... but none of them are lazy, and none of them were making shit up to get out of work.
You may have had a Very Bad Manager. There may have been nothing you could have done about it, other than walk away. I totally accept that.
But you write: they (managers) see a class divide between "management" and "workers"
When what I see in your words is you (the programmer at the time) seeing (and reinforcing through your actions) a class divide between management and workers. You blame the bad managers for a behavioral pattern that you were just a as much a part of. At least that's what I read in your words.
And that's what I see in many other programmers. They act like children with zero responsibility, and then complain about being treated as such by evil pointy haired bosses.
It's a two way street. And given that we, the engineers, are the ones who know how it should be done, we have a considerable responsibility in changing it.
http://en.wikipedia.org/wiki/Fundamental_attribution_error
I think you should cut her a little slack and take into account her job. You're concentrating on her rational evaluation of your arguments, but that skips right past the hard part of her job. She was still trying to figure out if she could trust your characterization of the facts. Really, if you were her, would you completely reorganize management on the say-so of a single individual before getting a more complete picture?
And if you decided to completely reorganize management, would you tell people about it the instant you made your decision, or would you keep it under your hat until you figured out 1) how to present the decision to the board (or whoever she answered to), 2) how to manage the transition so a bunch of people with institutional knowledge didn't disappear before she could replace them, and 3) how to avoid getting undermined by the people she was plotting against, who may have had significant credibility with the board and with management in other parts of the company?
And if you decided to essentially demote some people by sidelining them in the org chart, would you give one of their subordinates a heads-up before you had a chance to tell them about it?
Finally, it's reasonable to ask you to come up with a solution that differs from the optimal one. You do it in engineering all the time, and management isn't any different. You would say, "Licenses for this software account for 30% of the project budget. Suppose the license fees doubled -- can we design a solution that doesn't use this software?" She might have been thinking, "Gosh, I hope I can get some real development managers in here in three months, but what if it takes a year? I better have a plan for getting products out in the meantime."
Exactly. That's what good management does: insulate the programmers from as much nonsense that is possible. A good manager has some grasp of the field so that he can block at least the most outrageous feature requests from the devs or at least delay asking about them until a weekly meeting or something. If the devs have problem, the manager will drive the issues through the cogs and clogs of the organization and bureaucracy instead of using valuable developer time to track those issues.
An anecdote: I have had travelling arranged by a competent office manager and a company-wide travel reservation and approval system. Guess which saved so much time from everyone, sending an email to the office manager "I need to fly to X next Tuesday, my boss on Cc: with this" and afterwards dropping a stack of receipts back to her for filing reimbursements, or a dozen people trying to figure out what's the best way through the travel system without sacrificing too much work time on that and still ending up scanning individual receipts for uploading to the system.
A good manager has to have a minimum of understanding and/or a maximum of trust in some of his subordinates. Far too many in our field have either.
A good manager has to have a minimum of understanding and/or a maximum of trust in some of his subordinates. Far too many in our field have either.
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.
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.
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.
If this happens to you more than once a month, you're not in the 10x club. If you want to be in the 10x club you need to avoid this at all cost. Otherwise you're just another muggle chafing at the bit.
But you've got to have dedication if you truly want to "Have Fun At Work"
I interviewed, three times (and turned down, three times) with a firm that apparently really wanted me. Why?
1: They were a very small vendor working for a very large client. The client is a household (swear) word, and behaves in a gratuitously overbearing manner to its customers and other vendors.
2: Everyone I spoke with admitted that this relationship lead to many, many last-minute changes in spec requiring much overtime and pain to make things just so. All while praying that things wouldn't change yet again at the next last minute.
I said "thanks, but no".
Since your boss is apparently unaware of the problem, who's going to solve it if you don't speak up? There are no magic hacker fairies on HN that are going to do that for you.
It totally sucks that you can't just be a semi-independent craftsman who works on what comes their way in a nice orderly queue, but that's the reality of today's workforce. If the interruptions keep happening time and time again after having this conversation and following up on it, then at least you know where you stand in this company.
"I have a concern that this may not be feasible".
"No, you just have to try harder!"
"Sorry, I wasn't very clear: This is flat out impossible".
"Are you sure?"
"Yes, because google tried, and couldn't do it. You see, it's actually impossible to get the (technical mumbo jumbo) so it will take literally years to run a single query."
And this isn't a typical case. The most likely case is you suspect that the boss is leading everyone into the valley of death, but can't prove it. Do you confront them yourself, try to sound out other colleagues (who may have other concerns, since it's not their problem), or just warn them that there's likely to be problems, and gradually manage their expectations?
In an ideal world, bosses are good at both ferreting out concerns fro indirect hints ("I'm a bit worried that"), and dealing with direct statements ("It's impossible, you git!"). In reality, they are often just wage slaves who kiss up and kick down, and don't really care if the project flops as long as someone else is to blame.
Managing experts in a field means using their expertise. I'd call not using that clueless, so you'll usually only get fired by the clueless.