5 ms·

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 manag

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.

CamelCaseName 2y ago
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.
n_ary 2y ago
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)
kjellsbells 2y ago
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.
- antupis 2y ago
  > 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.
  - reverius42 2y ago
    Steve Jobs was very involved in the design of Apple Park before he died. Hopefully you didn’t short AAPL because of that.
    - osigurdson 2y ago
      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.
      - nicd 2y ago
        In Apple's case, it is also a demonstration that leadership strongly cares about design (a core value of the company).
    - deleted 2y ago
      [deleted]
    - f1shy 2y ago
      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.
    - blitzar 2y ago
      Steve Jobs didnt schedule an all hands meeting to tell everyone about it.
    - 2y ago
space_oddity 2y ago
But your instinct to use these pieces to understand your managers’ thinking is really cool
koliber 2y ago
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.

CamelCaseName 2y ago

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.

n_ary 2y ago

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)

kjellsbells 2y ago

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.

antupis 2y ago
> 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.
- reverius42 2y ago
  Steve Jobs was very involved in the design of Apple Park before he died. Hopefully you didn’t short AAPL because of that.
  - osigurdson 2y ago
    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.
    - nicd 2y ago
      In Apple's case, it is also a demonstration that leadership strongly cares about design (a core value of the company).
  - deleted 2y ago
    [deleted]
  - f1shy 2y ago
    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.
  - blitzar 2y ago
    Steve Jobs didnt schedule an all hands meeting to tell everyone about it.
  - 2y ago

space_oddity 2y ago

But your instinct to use these pieces to understand your managers’ thinking is really cool

koliber 2y ago

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.