I have to admit most of this went completely over my head. As a very junior developer, I like to read this type of articles as a way to understand what my managers actually want from me.
If I had to use this post as a guide on how to manage a team, I would not know how to materialize it's recommendations. Maybe it just goes to show how much of a gap there is.
It's not an especially crisp piece, but it comes down to this.
- Managers need to pay close attention to where they spend their energy (=time). For example, the CEO should not be spending time picking items for the company snack cupboard.
- At the lower tiers of management, the "what" necessarily becomes much more granular and task-oriented.
- The risk is that managers at this tier end up telling people precisely what to do and how to do it. This is not scalable, leads to frustration on the part of the manager and managee, and burnout.
Better is that the manager describe the desired outcome and set of standards, kpis, norms, etc, that must be met, and let ICs do it any way that fits. (Standards and norms enforce a culture that lets people collaborate more productively. No point letting a dev loose to code up a feature if they turn around a week later and tell you they did it...but in C#, when you're a Rust shop.)
An effective IC should aim to internalize the standards and norms that a manager (and their boss) use, which can be explicit or implicit, take the time to understand the manager's own targets, and offer up ways to make their work product make their life easier. For example, if you know that your manager has to write a weekly report with kpis like code coverage and test cases, then take care to produce easy-to-consume material that they can use. Eg text they can copy paste into an email, a dashboard they can screenshot or link to, etc. You want to be thought of as someone who they "dont have to worry about" and who comes to them with solutions and not just problems.
Sounds a bit Machiavellian to some, but a good manager relationship cam make or break your time at an org.
"An effective IC should aim to internalize the standards and norms that a manager (and their boss) use, which can be explicit or implicit, take the time to understand the manager's own targets, and offer up ways to make their work product make their life easier."
This always drives me nuts because it's the correct thing to do, but all the damn churn at modern software factories really gets in the way of building a long or even medium term relationship.
I've been at my current job 2 years and am on my third manager. 1 job ago, 3 years and 3 managers.
Prior to that, I was at 1 place for 6 years. I had 1 boss for the first five. I really want that kind of relationship again. It was productive, it was reassuring, it was empowering. Nowadays I hardly get to know a person before they rotate out for various reasons.
And to be clear, I had the exact same position for my whole tenure at all 3 jobs. It wasn't me moving around, just mgmt churn.
Indeed the ICs job is to get the job done in whatever way that is productive, hence with a good speed/quality balance. It is not ICs responsibility to make their manager's job easy.
I've had good, mediocre and evil managers.
The good managers try to understand you as a person and empower you to make things happen, using your own talents and passion. They also hold you back when you are exploring rabbit holes or dead ends.
The evil ones manipulate, make you feel of less worth and tell you how to do things. That where the micromanagent creeps in.
As a manager you must understand that every IC has a personality and adapt accordingly. Nobody said being a good manager is easy.
> Managers need to pay close attention to where they spend their energy (=time). For example, the CEO should not be spending time picking items for the company snack cupboard.
Last startup where I was working, I knew that the company was toast when the CEO was bragging in a company-wide call about how he designed the background mural for the new office entrance.
I'm pretty sure OP has more context, and that was "the last drop". Anyway, it is a big red flag without any context. But yes, it also could be ok, if that is a very particular important detail.
Steve Jobs knew that details matter (not just high level objectives). They key is to pick the details that actually matter and avoid focusing on those that do not.
> The risk is that managers at this tier end up telling people precisely what to do and how to do it. This is not scalable, leads to frustration on the part of the manager and managee, and burnout.
> Better is that the manager describe the desired outcome and set of standards, kpis, norms, etc, that must be met, and let ICs do it any way that fits. (Standards and norms enforce a culture that lets people collaborate more productively. No point letting a dev loose to code up a feature if they turn around a week later and tell you they did it...but in C#, when you're a Rust
shop.)
It is like the difference between imperative and declarative programming. Imperative programming is micro-management (bad), you should strive for declarative programming.
It is a bit too verbose, but the gist of it seems to be, that delegation is about giving goals and then giving freedom to the delegates to achieve those goals. The article discourages micromanagement(with some bad examples), and encourages that giving general tasks and giving some goals with little bit of hints should be the appropriate approach.
For example, you tell your delegate to post a link on HN, giving them goals that it is properly formatted and correctly posted, a hint that there should be a prominent “submit a post” link somewhere on the navigation bar, so that they can try to figure out about how HN works, how to post, figure out the formatting guide, check when their post was successful.
It is discouraged to set out the entire tutorial steps(micromanagement with too much how), like type this url in address bar, signup/login by clicking the anchor, click submit post/link, type in the content …
The aim is that, the delegate learns how to achieve the goals with as little hint as possible, so eventually if you ask them to post a link(say doing a SHOW HN) or a job, they can achieve the goals on their own.
I'm not the author, but thank you for sharing that this article is not landing clearly. I write pieces like this occasionally and your comment made me realize how easy it is to miss the point.
Here's how I would put it, looking at it from your perspective:
You are hired to do some work. Often, you know what needs to be done. Sometimes, your boss needs you to do something else. He needs to delegate that something to you.
When he delegates, it means he tells you to do it and explains what to do. You need to be clear what he wants done, when he wants it done, and how he wants it done.
To explain "how", he needs to tell you what he expects to use to get the job done. If there are limits, he needs to tell you what they are. He should not provide every details - that is micromanagement. He should think about what might not be obvious to you, and provide just those details. This is hard and bosses get this wrong a lot of time. It's also hard from your side, as it takes effort to really deeply understand what they want from you.
From your side, the most important thing is to listen, try to understand what he wants, and ask questions if something is unclear.
Example: build an integration with XYZ API. Don't use the REST library we've used so far, as we will be deprecating it in the near future. Find another library, but don't spend more than a day researching it, as the decision is not THAT important. You get to decide which library to use, but let me know, so that I have a chance to review it and comment in case it does not meet some of my requirements. If you don't hear from me, assume everything is OK. We need the integration to be ready for beta testing in 2 weeks. The functional specifications are in Jira, and XYZ Corp. has great documentation. Also, Bob Franklin from XYZ is really helpful in case the docs are missing something.
You responsibility is to see if this makes sense and gives you everything you need to get started. If any of this is unclear, contradictory, or weird, ask without delay.
This is hard. If you wait until you start to carefully read through what he delegated, and you have questions or concerns, it will delay the project. You can't start until those are cleared up. That is why it's super important to try to understand the instructions and think whether everything is clear as soon as possible.
>> take stock of the “what” you’re asking as well as the “how.”
I think a lot of errors stem from assuming that "what" and "how" are somehow distinct concepts. In reality they are the same thing, we are just describing objectives at varying levels of abstraction. There are important inflection points along the entire gradient.
Perhaps a better way to phrase what the author was saying is that you need to tell your reports the things that you know more than them about (which incidentally usually is direction), but should avoid trying to prescribe things that it is their job to know more than you about (which incidentally covers most things about the codebase they see every day).
"I'll run so far ahead of my team that I won't need their advice" - last spoken words of a new lead who died trying to do eight jobs faster than the people hired to do them. ;)
Although how and what are connected, they are not the same. For example, 'I would like to become fit and healthy.' 'What' is getting fit and healthy, but 'how' has almost endless possibilities, each with their own success level and compatibility with you and your lifestyle. Just like nouns and verbs are connected, they are not the same.
Getting fit and healthy is an objective, you now choose concrete sub objectives (such as running), more concrete objectives included buying a pair of running shoes. Like many things, inflection points along the way make all the difference. Details matter, just not all details.
Similarly, a higher level objective to "getting fit and healthy" might be "achieve long life" which in itself may have a range of sub objectives and varying levels of abstraction. So yeah, all just objectives, no "the what", no "the how".
The "what/how" distinction is fundamental. If the "what" is getting healthy and fit, that is a very high-level goal. Within your example, you choose the "how" through running
It could've been walking in nature, going to the gym, or doing calisthenics. all of them different "hows".
But since your example made a choice, we are now one level deeper and more concrete than before. The what/goal has in this level become to run a 5K, and the how/method is how you will train to achieve that goal.
"How" and "what" can be very conceptual, especially at a high level, and just like the 5 Whys technique, it could take a few levels to become concrete.
Top-down programming is often taught by separating the "how" and the "what."
For example:
customer = get_customer(id=id)
The "what" is getting the customer.
The "how" is not revealed, yet its intent is clear.
Within the function get_customer we could have another 'what' for example run_query
Top-down programming will often first skip the "how" and focus only on the "what" by writing the functions, methods, and classes later on.
I think objective is a better term. These range from high level (increase happiness) to very concrete such as physical movement. Basically we are solving optimization problems.
The NATO version of this is called Mission Command. You train the levels below you in doctrine and rules of engagement and big picture things like that, and then you give them an objective and let them figure out the best way to achieve this.
Put another way: you tell them what and why, and they go off and figure out how.
To do this, you need the training to be up to scratch that you can trust your underlings to be competent, and once you have that, you have to actually trust them.
With his first sentence, "I’m gearing up, like some kind of power washer, to spray new productized services into our operations group so they can SOP those services at scale." the author reveals his arrogance and poor communications ability.
First, a power washer is a violent device that strips the surface from its target. It's not something that you aim at people or animals. He needs a very different simile, maybe spreading seeds.
Second, must he speak only in non-English jargon? When did the acronym SOP become a verb? Does he want his Operations group to just "SOP" everything? Does he not want the group to do what we once called "kaizen", continuously improving upon the standard procedures?
His notions of how to delegate may be fine, but in my organization I'd want somebody other than him to be in charge of it.
This sounds similar to what Allen Ward prescribes in using ambitious but flexible targets (the what) to pull work products from teams, rather than pushing tasks (the how) onto teams.
One thing Ward emphasises that I often see missing in these discussions is the responsibility of the puller to perform demand levelling. Don't try to pull more work products out of teams than they have the capacity for. Spread the work out (over time and over teams), so that teams can focus on executing against targets rather than being distracted by competing targets that need to be traded off against each other.
I know it’s upvoted so the community must find it interesting but this is an article from a site called "Hitsubscribe" which could as well has been written by ChatGPT (and to be fair I’m fairly certain that ChatGPT would give a better answer to the question "How to effectively delegate?").
Intro to management is not a common topic on HN so I was wondering if something special was linked to it.
I like the ideas proposed in “Turn the ship around” - create a bottom up culture and a culture of over communication so as a manager you can just sign off instead of delegate.
"Savant" is an iffy word choice I'd agree, but lots of programmers tend to take instructions very literally. Strict logical thinking is part of the job, and most low and mid level managers are (or recently were) also programmers.
When people are giving me instructions that seem overly detailed to me, I usually assume they have a reason for giving those details because otherwise they would have left it up to me. If I disagree with some design choice or don't understand I'll usually challenge it or ask for that reasoning, but I don't always have time or energy to challenge every last thing. Nothing is more frustrating to me than when I ask for the reasoning and they can't (or won't) explain any motivation behind it. That goes both for my superiors and for my peers during architectural discussions and things like that.
And of course, there's a very high rate of autism in software engineering. Autistic people tend to take things more literally than most.
I don't think that was a typo, earlier in the article they classify planning as the domain of middle management, and judgement-based execution as belonging at the supervisory level. I think they are copying this from retail management, I have a hard time imagining a use for an engineer who didn't have the ability to plan or apply judgement.
I think what that commenter meant, and I agree, is that the "savant" in this case was referring to a literal computer; the programmer as an IC is "delegating" a task by writing a program and having the computer execute it.
That's literally what "senior engineer" is supposed to be doing according to what I hear are current industry norm, which makes as much sense as what your comment makes it sound. Basically a hidden management role, with all the responsibilities but none of the power.
I have to admit most of this went completely over my head. As a very junior developer, I like to read this type of articles as a way to understand what my managers actually want from me.
If I had to use this post as a guide on how to manage a team, I would not know how to materialize it's recommendations. Maybe it just goes to show how much of a gap there is.
It's not an especially crisp piece, but it comes down to this.
- Managers need to pay close attention to where they spend their energy (=time). For example, the CEO should not be spending time picking items for the company snack cupboard.
- At the lower tiers of management, the "what" necessarily becomes much more granular and task-oriented.
- The risk is that managers at this tier end up telling people precisely what to do and how to do it. This is not scalable, leads to frustration on the part of the manager and managee, and burnout.
Better is that the manager describe the desired outcome and set of standards, kpis, norms, etc, that must be met, and let ICs do it any way that fits. (Standards and norms enforce a culture that lets people collaborate more productively. No point letting a dev loose to code up a feature if they turn around a week later and tell you they did it...but in C#, when you're a Rust shop.)
An effective IC should aim to internalize the standards and norms that a manager (and their boss) use, which can be explicit or implicit, take the time to understand the manager's own targets, and offer up ways to make their work product make their life easier. For example, if you know that your manager has to write a weekly report with kpis like code coverage and test cases, then take care to produce easy-to-consume material that they can use. Eg text they can copy paste into an email, a dashboard they can screenshot or link to, etc. You want to be thought of as someone who they "dont have to worry about" and who comes to them with solutions and not just problems.
Sounds a bit Machiavellian to some, but a good manager relationship cam make or break your time at an org.
"An effective IC should aim to internalize the standards and norms that a manager (and their boss) use, which can be explicit or implicit, take the time to understand the manager's own targets, and offer up ways to make their work product make their life easier."
This always drives me nuts because it's the correct thing to do, but all the damn churn at modern software factories really gets in the way of building a long or even medium term relationship.
I've been at my current job 2 years and am on my third manager. 1 job ago, 3 years and 3 managers.
Prior to that, I was at 1 place for 6 years. I had 1 boss for the first five. I really want that kind of relationship again. It was productive, it was reassuring, it was empowering. Nowadays I hardly get to know a person before they rotate out for various reasons.
And to be clear, I had the exact same position for my whole tenure at all 3 jobs. It wasn't me moving around, just mgmt churn.
Indeed the ICs job is to get the job done in whatever way that is productive, hence with a good speed/quality balance. It is not ICs responsibility to make their manager's job easy.
I've had good, mediocre and evil managers.
The good managers try to understand you as a person and empower you to make things happen, using your own talents and passion. They also hold you back when you are exploring rabbit holes or dead ends.
The evil ones manipulate, make you feel of less worth and tell you how to do things. That where the micromanagent creeps in.
As a manager you must understand that every IC has a personality and adapt accordingly. Nobody said being a good manager is easy.
> Managers need to pay close attention to where they spend their energy (=time). For example, the CEO should not be spending time picking items for the company snack cupboard.
Last startup where I was working, I knew that the company was toast when the CEO was bragging in a company-wide call about how he designed the background mural for the new office entrance.
Steve Jobs was very involved in the design of Apple Park before he died. Hopefully you didn’t short AAPL because of that.
I'm pretty sure OP has more context, and that was "the last drop". Anyway, it is a big red flag without any context. But yes, it also could be ok, if that is a very particular important detail.
Steve Jobs knew that details matter (not just high level objectives). They key is to pick the details that actually matter and avoid focusing on those that do not.
In Apple's case, it is also a demonstration that leadership strongly cares about design (a core value of the company).
Steve Jobs didnt schedule an all hands meeting to tell everyone about it.
> The risk is that managers at this tier end up telling people precisely what to do and how to do it. This is not scalable, leads to frustration on the part of the manager and managee, and burnout. > Better is that the manager describe the desired outcome and set of standards, kpis, norms, etc, that must be met, and let ICs do it any way that fits. (Standards and norms enforce a culture that lets people collaborate more productively. No point letting a dev loose to code up a feature if they turn around a week later and tell you they did it...but in C#, when you're a Rust shop.)
It is like the difference between imperative and declarative programming. Imperative programming is micro-management (bad), you should strive for declarative programming.
Declaritive programming, without the programming part.
>> if you know that your manager has to write a weekly report with kpis like code coverage and test cases
The second illustration in the article seems very fitting here
It is a bit too verbose, but the gist of it seems to be, that delegation is about giving goals and then giving freedom to the delegates to achieve those goals. The article discourages micromanagement(with some bad examples), and encourages that giving general tasks and giving some goals with little bit of hints should be the appropriate approach.
For example, you tell your delegate to post a link on HN, giving them goals that it is properly formatted and correctly posted, a hint that there should be a prominent “submit a post” link somewhere on the navigation bar, so that they can try to figure out about how HN works, how to post, figure out the formatting guide, check when their post was successful.
It is discouraged to set out the entire tutorial steps(micromanagement with too much how), like type this url in address bar, signup/login by clicking the anchor, click submit post/link, type in the content …
The aim is that, the delegate learns how to achieve the goals with as little hint as possible, so eventually if you ask them to post a link(say doing a SHOW HN) or a job, they can achieve the goals on their own.
Some sound advice but too much text to explain.
(Edit: reduce word count and formatting update)
I'm a new manager and I'm really struggling.
Reading this article put into words my own struggles and the candid feedback I've received.
I'm certain that had I read this a few months or years ago, I would be completely lost.
But your instinct to use these pieces to understand your managers’ thinking is really cool
I'm not the author, but thank you for sharing that this article is not landing clearly. I write pieces like this occasionally and your comment made me realize how easy it is to miss the point.
Here's how I would put it, looking at it from your perspective:
You are hired to do some work. Often, you know what needs to be done. Sometimes, your boss needs you to do something else. He needs to delegate that something to you.
When he delegates, it means he tells you to do it and explains what to do. You need to be clear what he wants done, when he wants it done, and how he wants it done.
To explain "how", he needs to tell you what he expects to use to get the job done. If there are limits, he needs to tell you what they are. He should not provide every details - that is micromanagement. He should think about what might not be obvious to you, and provide just those details. This is hard and bosses get this wrong a lot of time. It's also hard from your side, as it takes effort to really deeply understand what they want from you.
From your side, the most important thing is to listen, try to understand what he wants, and ask questions if something is unclear.
Example: build an integration with XYZ API. Don't use the REST library we've used so far, as we will be deprecating it in the near future. Find another library, but don't spend more than a day researching it, as the decision is not THAT important. You get to decide which library to use, but let me know, so that I have a chance to review it and comment in case it does not meet some of my requirements. If you don't hear from me, assume everything is OK. We need the integration to be ready for beta testing in 2 weeks. The functional specifications are in Jira, and XYZ Corp. has great documentation. Also, Bob Franklin from XYZ is really helpful in case the docs are missing something.
You responsibility is to see if this makes sense and gives you everything you need to get started. If any of this is unclear, contradictory, or weird, ask without delay.
This is hard. If you wait until you start to carefully read through what he delegated, and you have questions or concerns, it will delay the project. You can't start until those are cleared up. That is why it's super important to try to understand the instructions and think whether everything is clear as soon as possible.
>> take stock of the “what” you’re asking as well as the “how.”
I think a lot of errors stem from assuming that "what" and "how" are somehow distinct concepts. In reality they are the same thing, we are just describing objectives at varying levels of abstraction. There are important inflection points along the entire gradient.
Perhaps a better way to phrase what the author was saying is that you need to tell your reports the things that you know more than them about (which incidentally usually is direction), but should avoid trying to prescribe things that it is their job to know more than you about (which incidentally covers most things about the codebase they see every day).
"I'll run so far ahead of my team that I won't need their advice" - last spoken words of a new lead who died trying to do eight jobs faster than the people hired to do them. ;)
Agree. However, avoid becoming an information gatekeeper. Usually higher level objectives can be explained in 30s or less.
Although how and what are connected, they are not the same. For example, 'I would like to become fit and healthy.' 'What' is getting fit and healthy, but 'how' has almost endless possibilities, each with their own success level and compatibility with you and your lifestyle. Just like nouns and verbs are connected, they are not the same.
Getting fit and healthy is an objective, you now choose concrete sub objectives (such as running), more concrete objectives included buying a pair of running shoes. Like many things, inflection points along the way make all the difference. Details matter, just not all details.
Similarly, a higher level objective to "getting fit and healthy" might be "achieve long life" which in itself may have a range of sub objectives and varying levels of abstraction. So yeah, all just objectives, no "the what", no "the how".
The "what/how" distinction is fundamental. If the "what" is getting healthy and fit, that is a very high-level goal. Within your example, you choose the "how" through running It could've been walking in nature, going to the gym, or doing calisthenics. all of them different "hows".
But since your example made a choice, we are now one level deeper and more concrete than before. The what/goal has in this level become to run a 5K, and the how/method is how you will train to achieve that goal.
"How" and "what" can be very conceptual, especially at a high level, and just like the 5 Whys technique, it could take a few levels to become concrete. Top-down programming is often taught by separating the "how" and the "what." For example:
customer = get_customer(id=id)
The "what" is getting the customer.
The "how" is not revealed, yet its intent is clear. Within the function get_customer we could have another 'what' for example run_query Top-down programming will often first skip the "how" and focus only on the "what" by writing the functions, methods, and classes later on.
https://en.m.wikipedia.org/wiki/Bottom%E2%80%93up_and_top%E2...
>> very high-level goal
I think objective is a better term. These range from high level (increase happiness) to very concrete such as physical movement. Basically we are solving optimization problems.
What and how are most definitely not the same thing. They aren't necessarily even related:
If you tell people where to go, but not how to get there, you'll be amazed at the results.
George S. Patton
Delegation doesn’t demand strict separation between "what" and "how"
>Delegation doesn’t demand strict separation between "what" and "how"
Sure, but a lot of times, figuring out the how is what takes the time, if you're figuring out the how you might as well not delegate it at all.
Delegation isn’t just about offloading tasks; it’s about leveraging team expertise
My point still stands.
The NATO version of this is called Mission Command. You train the levels below you in doctrine and rules of engagement and big picture things like that, and then you give them an objective and let them figure out the best way to achieve this.
Put another way: you tell them what and why, and they go off and figure out how.
To do this, you need the training to be up to scratch that you can trust your underlings to be competent, and once you have that, you have to actually trust them.
reference: https://www.armypubs.org/adp-6-0-mission-command-command-and... (PDF: https://armypubs.army.mil/epubs/DR_pubs/DR_a/ARN34403-ADP_6-...)
The bullet point principles at the top of page 1-7 sound a bit like the Army's version of the Agile manifesto.
When done right, delegation is as much about building confidence and competence as it is about freeing up time
With his first sentence, "I’m gearing up, like some kind of power washer, to spray new productized services into our operations group so they can SOP those services at scale." the author reveals his arrogance and poor communications ability.
First, a power washer is a violent device that strips the surface from its target. It's not something that you aim at people or animals. He needs a very different simile, maybe spreading seeds.
Second, must he speak only in non-English jargon? When did the acronym SOP become a verb? Does he want his Operations group to just "SOP" everything? Does he not want the group to do what we once called "kaizen", continuously improving upon the standard procedures?
His notions of how to delegate may be fine, but in my organization I'd want somebody other than him to be in charge of it.
This sounds similar to what Allen Ward prescribes in using ambitious but flexible targets (the what) to pull work products from teams, rather than pushing tasks (the how) onto teams.
One thing Ward emphasises that I often see missing in these discussions is the responsibility of the puller to perform demand levelling. Don't try to pull more work products out of teams than they have the capacity for. Spread the work out (over time and over teams), so that teams can focus on executing against targets rather than being distracted by competing targets that need to be traded off against each other.
Meta question, what is it with all this cookie cutter articles targeted towards new managers on HN at the moment?
I find it strange especially when you consider that these are not even particularly good or insightful articles.
IDK, but I appreciate the domain name being honest about the point of it all.
Well HN articles should be a good mix between serious, concise & boring on one side and on the other hand easy to read articles like these.
While reading I still have some cpu cycles left to think about the broader context and how this applies to my own situation.
I know it’s upvoted so the community must find it interesting but this is an article from a site called "Hitsubscribe" which could as well has been written by ChatGPT (and to be fair I’m fairly certain that ChatGPT would give a better answer to the question "How to effectively delegate?").
Intro to management is not a common topic on HN so I was wondering if something special was linked to it.
I like the ideas proposed in “Turn the ship around” - create a bottom up culture and a culture of over communication so as a manager you can just sign off instead of delegate.
>When you’re dictating tasks to a savant that takes everything extremely literally, like, say, a programmer programming a computer.
Has the industry really fallen so far that people who have straightforward skills like programming are seen like Rain Man?
"Savant" is an iffy word choice I'd agree, but lots of programmers tend to take instructions very literally. Strict logical thinking is part of the job, and most low and mid level managers are (or recently were) also programmers.
When people are giving me instructions that seem overly detailed to me, I usually assume they have a reason for giving those details because otherwise they would have left it up to me. If I disagree with some design choice or don't understand I'll usually challenge it or ask for that reasoning, but I don't always have time or energy to challenge every last thing. Nothing is more frustrating to me than when I ask for the reasoning and they can't (or won't) explain any motivation behind it. That goes both for my superiors and for my peers during architectural discussions and things like that.
And of course, there's a very high rate of autism in software engineering. Autistic people tend to take things more literally than most.
I believe the savant in this case is the computer that takes instructions literally?
I don't think that was a typo, earlier in the article they classify planning as the domain of middle management, and judgement-based execution as belonging at the supervisory level. I think they are copying this from retail management, I have a hard time imagining a use for an engineer who didn't have the ability to plan or apply judgement.
I think what that commenter meant, and I agree, is that the "savant" in this case was referring to a literal computer; the programmer as an IC is "delegating" a task by writing a program and having the computer execute it.
Yep this is what I was getting at.
Sounds like a pretty typical junior engineer to me.
Imagine the chaos that would ensue if each IC had four to eight juniors to supervise... :)
That's literally what "senior engineer" is supposed to be doing according to what I hear are current industry norm, which makes as much sense as what your comment makes it sound. Basically a hidden management role, with all the responsibilities but none of the power.
They effectively wouldn't be ICs anymore if an important part of their job is to supervise
The chaos would be great for the bean counters. "Productivity" will be up for a month or two. Until it isn't.
I think there’s a long-standing stereotype that programmers are "literal" thinkers who operate only with exact instructions
Note: effectively != appropriately != respectfully