3 ms·
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, th
by 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 agoSteve Jobs was very involved in the design of Apple Park before he died. Hopefully you didn’t short AAPL because of that.
- osigurdson 2y agoSteve 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 agoIn 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 agoI'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 agoSteve Jobs didnt schedule an all hands meeting to tell everyone about it.
- j45 2y agoExcept not everyone is Steve Jobs with billions to do what he wants first. Nice to imagine maybe.
- atomicnumber3 2y ago"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.
- nuancebydefault 2y agoIndeed 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.
- osigurdson 2y ago>> 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
- f1shy 2y ago> 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.
- nuancebydefault 2y agoDeclaritive programming, without the programming part.