And all abstractions are leaky. This is true outside of software too. The point doesn't seem to me to be an absolute. It's simply saying that delegation to subordinates must be augmented by "in the trenches" knowledge and research by senior executives. That doesn't sound wrong to me.
And yes: if you have performance issues with your Lisp code and you're not looking at the generated machine code (or more likely in the modern world, doing tracing to identify bottlenecks which are probably in the IPC or I/O layers), you're not programming well. Continuing to whack around in your REPL is doing just what the JP Morgan executives were -- ignoring the details of the real problem in the hope that the abstraction will be sufficient.
Regardless, I'm not sure that CEOs should be told that "hey, you should definitely be micromanaging your team or you're not worth your salary" because some abstractions can be leaky when not designed well.
Asking tough questions about how the company operates and demanding to see the raw data rather than "executive summaries" isn't micromanaging. Micromanaging is telling your employees how they should do every little detail of their jobs when they're perfectly capable of doing them without your interference.
A CEO who doesn't have a deep understanding of how his company works is probably not worth his hefty salary.
This article isn't about micromanagement in any sense.
It's about management having the competency to perform and verify low level data analysis and come to agree or disagree with what they are being told.
I've worked with managers in the past who told their direct reports that they needed to do "selective analysis" (in other words, cook the books), because "people didn't want to hear bad news." Although this was egregiously disingenuous, I think the desire to put spin on bad news is innate.
It's up to management to smell if something's amiss, and to make sure that being honest and forthright is a requirement to maintain employment.
What he describes sounds like just plain management, not micromanagement. Micromanagement isn't productive involvement. It's over-bearing, time-consuming, counterproductive involvement.
The examples given were pretty much describing effective management - trusting lower-level staff to manage the day-to-day work but then stepping in to guide and advise when observations indicate that intervention is necessary.
Following up on what the reporting employees are doing, is the duty of any manager. However, telling them (if they are experts) how to do their jobs, might not be. A manager should:
1. Discuss what needs to be done and then maybe plan out a time frame/ chalk out a route.
2. Get the hell out of the employees' way and let them do their job.
3. Remotely monitor what they are doing. Should not interfere even if the output is not the "best", but should certainly do so in case some disastrous output, as mentioned in the article, is imminent.
4. When the task is done, should congratulate employees and then provide any negative feedback, if required.
This article shouldn't be taken as a lesson by the managers to start "micro-managing". This, as greenyoda, rightly said is not micro managing.
Not only is being able to get to the raw data not micromanaging, it's good management.
Richard Feynman spoke about how he stopped trusting values simply because they came from some authoritative source after getting burned once. After that he calculated things himself.
That lesson relates to the "global telecommunications giant" in the story, whose "critical network software upgrade" was turning into a disaster. In fact, I recently went through a similar situation myself at a job; well before I got there, technical leadership had planned out an overly-ambitious, complex and time-consuming whole-scale rewrite of a critical service, and when I arrived, they were chest-deep in shit creek. As the team sunk lower and lower, I felt compelled to reach out to higher-ups. That's how I lost my head. I hear their collective hair is still on fire.
Is the lesson there that I should have kept more quiet? I'm still not sure. But what is clear to me is that non-technical leadership need to be able to properly assess the risks of technical decisions. As the story mentions, one of the best ways to do that is to get someone from outside the team to analyze the process and the progress. Because even someone half-competent will be able to tell you when some major upgrade creates a major risk, and the best way to mitigate that risk is to divide-and-conquer the major task into minor ones.
Another key smell is how "the program managers' key performance indicator dashboards showed nothing alarmingly unusual". I would dare say that those dashboards are then fundamentally broken. One fix: edw519 has written about the need for task progress to either be 100% or 0%, as a way to flush issues out of the woodwork.
Fred Brooks is right: we're still stuck in the tar-pits. Maybe we'll find our way out in the next 45 years...
It's unfortunate that the author used the term "micromanagement". I realize it is to make the subject provocative and thereby capture readers, but it will also produce such a negative visceral reaction that the key take-aways will be missed:
1. The best leaders are capable of adding value to other people's jobs. You don't necessarily need to be able to do their job, but you need to be able to stand next to them.
2. There are times you need to step in and demand more detail to find out what is really going on.
3. Good leaders have the [skill|experience|6th sense] to know when they need to do that versus trusting their employees. Sometimes it may be never, sometimes it may be always.
4. Good leaders can do the above without losing themselves in the minutia of trying to do other peoples' jobs for them (or telling them what to do).
Perhaps "If you don't know the details, you can't effectively lead" would be better.
This is more of a story of how executives of large companies lose touch with customers and their raw business because they also have to manage strategically as well as management the entire business portfolio. This is why you hear of managers working the shop floor, answering support desks etc. It grounds them to their key business.
Schrage outlined how examples of how to manage crisis situations, not micromanagement.
If a manager does not delegate then he/she is not busy enough. That said, one needs to have a thorough understanding of the work of all subordinates, whether technical or not, in order to understand how to quickly ameliorate circumstances that deviate from an anticipated course.
The lesson here is that managers needs to be involved, at a high level, early and often to catch onerous situations before they evolve.
I have no objection to the rest of your comment, but I do wonder about the part I quoted. Hacker News isn't just, or even primarily, about programming, and articles shouldn't be judged based on their direct relationship with that field.
From the HN Guidelines[1]:
> On-Topic: Anything that good hackers would find interesting. That includes more than hacking and startups. If you had to reduce it to a sentence, the answer might be: anything that gratifies one's intellectual curiosity.
HN is primarily about programming because the majority of its users are programmers. The majority of hackers are programmers. The majority of hacks are program-related.
Lately, there's been way, way too much content that's horribly recycled, unfounded punditry and speculation, and a variety of very loosely business-related articles, like this one, that are terribly written. I'm perfectly content to use "programming related" as a first tier filter for content.
Edit: also, the piece itself was about management. What management, if not management of programmers, is relevant on HN? I would give allowance if it were an insightful piece on being a technical person managing creative or business types in a startup environment, but it wasn't.
22 comments
[ 2.6 ms ] story [ 104 ms ] threadLayers of abstraction exist for a reason.
And yes: if you have performance issues with your Lisp code and you're not looking at the generated machine code (or more likely in the modern world, doing tracing to identify bottlenecks which are probably in the IPC or I/O layers), you're not programming well. Continuing to whack around in your REPL is doing just what the JP Morgan executives were -- ignoring the details of the real problem in the hope that the abstraction will be sufficient.
Regardless, I'm not sure that CEOs should be told that "hey, you should definitely be micromanaging your team or you're not worth your salary" because some abstractions can be leaky when not designed well.
It's more like "If you're not checking that a creaky hand-rolled code-generator actually produces sane output, you'r not programming".
A CEO who doesn't have a deep understanding of how his company works is probably not worth his hefty salary.
It's about management having the competency to perform and verify low level data analysis and come to agree or disagree with what they are being told.
I've worked with managers in the past who told their direct reports that they needed to do "selective analysis" (in other words, cook the books), because "people didn't want to hear bad news." Although this was egregiously disingenuous, I think the desire to put spin on bad news is innate.
It's up to management to smell if something's amiss, and to make sure that being honest and forthright is a requirement to maintain employment.
The examples given were pretty much describing effective management - trusting lower-level staff to manage the day-to-day work but then stepping in to guide and advise when observations indicate that intervention is necessary.
1. Discuss what needs to be done and then maybe plan out a time frame/ chalk out a route.
2. Get the hell out of the employees' way and let them do their job.
3. Remotely monitor what they are doing. Should not interfere even if the output is not the "best", but should certainly do so in case some disastrous output, as mentioned in the article, is imminent.
4. When the task is done, should congratulate employees and then provide any negative feedback, if required.
This article shouldn't be taken as a lesson by the managers to start "micro-managing". This, as greenyoda, rightly said is not micro managing.
Richard Feynman spoke about how he stopped trusting values simply because they came from some authoritative source after getting burned once. After that he calculated things himself.
That lesson relates to the "global telecommunications giant" in the story, whose "critical network software upgrade" was turning into a disaster. In fact, I recently went through a similar situation myself at a job; well before I got there, technical leadership had planned out an overly-ambitious, complex and time-consuming whole-scale rewrite of a critical service, and when I arrived, they were chest-deep in shit creek. As the team sunk lower and lower, I felt compelled to reach out to higher-ups. That's how I lost my head. I hear their collective hair is still on fire.
Is the lesson there that I should have kept more quiet? I'm still not sure. But what is clear to me is that non-technical leadership need to be able to properly assess the risks of technical decisions. As the story mentions, one of the best ways to do that is to get someone from outside the team to analyze the process and the progress. Because even someone half-competent will be able to tell you when some major upgrade creates a major risk, and the best way to mitigate that risk is to divide-and-conquer the major task into minor ones.
Another key smell is how "the program managers' key performance indicator dashboards showed nothing alarmingly unusual". I would dare say that those dashboards are then fundamentally broken. One fix: edw519 has written about the need for task progress to either be 100% or 0%, as a way to flush issues out of the woodwork.
Fred Brooks is right: we're still stuck in the tar-pits. Maybe we'll find our way out in the next 45 years...
1. The best leaders are capable of adding value to other people's jobs. You don't necessarily need to be able to do their job, but you need to be able to stand next to them.
2. There are times you need to step in and demand more detail to find out what is really going on.
3. Good leaders have the [skill|experience|6th sense] to know when they need to do that versus trusting their employees. Sometimes it may be never, sometimes it may be always.
4. Good leaders can do the above without losing themselves in the minutia of trying to do other peoples' jobs for them (or telling them what to do).
Perhaps "If you don't know the details, you can't effectively lead" would be better.
If a manager does not delegate then he/she is not busy enough. That said, one needs to have a thorough understanding of the work of all subordinates, whether technical or not, in order to understand how to quickly ameliorate circumstances that deviate from an anticipated course.
The lesson here is that managers needs to be involved, at a high level, early and often to catch onerous situations before they evolve.
I have no objection to the rest of your comment, but I do wonder about the part I quoted. Hacker News isn't just, or even primarily, about programming, and articles shouldn't be judged based on their direct relationship with that field.
From the HN Guidelines[1]:
> On-Topic: Anything that good hackers would find interesting. That includes more than hacking and startups. If you had to reduce it to a sentence, the answer might be: anything that gratifies one's intellectual curiosity.
[1] http://ycombinator.com/newsguidelines.html - linked at the bottom of every HN page.
Lately, there's been way, way too much content that's horribly recycled, unfounded punditry and speculation, and a variety of very loosely business-related articles, like this one, that are terribly written. I'm perfectly content to use "programming related" as a first tier filter for content.
Edit: also, the piece itself was about management. What management, if not management of programmers, is relevant on HN? I would give allowance if it were an insightful piece on being a technical person managing creative or business types in a startup environment, but it wasn't.