The author assumes his experience applies to all software development.
It really grates on me when people feel they know the only way to do software development and say you're doing it wrong unless it's their way.
The post might have been more effective had it been worded as an expression of his own personal experience and personal journey instead of telling the reader how to do it.
You don’t.
The leader’s job is being available, a high speed router constantly context switching. The IC’s job is the opposite.
Striving to be good at being available and not being available (what?) is like compromising when you can just find the answer. I think it’s 5 and you think it’s 7. Let’s just agree to disagree and call it 6. That’s mediocrity. You could just walk over there and measure it.
But measuring, in this case, doesn’t happen in a planning meeting. It happens when you give the user something to interact with, from which you can get feedback. You give them the thing that has 5 or 7 and let them say, ”what the hell is this? It’s off by a factor of 10. You’re using the wrong units” or whatever. Then you know.
Sitting in meetings and correcting people’s assumptions feels good. But here’s the thing: that’s not actually your job.
One common thing I've noticed over the years is APAC is always the most productive timezone from an engineering aspect because they don't overlap with the disruptive/time consuming meetings.
They get the most focus time out of any of the timezones.
Bad PM: I need to make sure I am not wasting time building the wrong thing. So I am forced to be "distracted" and play the role of a PM.
Good PM: I need to stay focused building. The PM has already done a great job figuring out what needs to get built. They have given me a good mental model of how the customer thinks.
Sure some facetime with customers is good but the article has a simplistic conclusion.
The question is whether focus time is the best way of doing this and I think yes it is. There are more engineers out there who care about outreach and feedback than the thought leader machine cares to admit. I think the one principle is minimise time to contact with users. As soon as its ready, release. Code that doesnt see the light rots.
I think AI has poisoned the waters here a bit. It’s brought a fear of relying on AI tools and losing pure skill versus raw productivity. Business folks used to be fussy about timelines, but now they feel even more empowered to push back because AI has brought code to their level. If AI can write code that fast, why can’t you?
The article reads like if someone in the C suite was trying to tell me how to work who has no idea what actually goes on in my day-to-day or willfully ignores my pleas for better system stability and security in lieu of only taking the highest “impact” work (I.e. money). It’s just a greedy algorithm: almost always guaranteed to be suboptimal, but any effort to chart a different, more measured approach is seen by leaders as perfectionistic or even sabotage.
I’m not jaded; you’re jaded.
A better long term approach would be to onboard people and give their time to lean in, understand practice and do their best work.
When deadlines are short, there needs to be a well defined practice and things to quickly execute on, with everything well documented.
