I actually planned on giving the post a shout out this week, not because I advocate for the mindset that might be implicit in his words—but most of what he says about optics is true.
For example, when he said, “whether you like it or not/however you feel about it, it’s how it is.”
Even if it’s not the world we want, he’s telling us the world we have. We can do a separate set of things to change and influence that, and choose to do the right thing, but it’s important to understand the environment you’re in, because a lot of what he says is unspoken and you’re left to realize it through experience.
To your point, I agree we shouldn’t solely optimize for optics, but it didn’t seem like he was arguing for people to do that either. It seemed like he was arguing for not being overly dogmatic on a set of idealistic “rules of engineering” and to instead be more pragmatic, realizing it’s just about understanding what your leadership cares about as your users
Where decisions are made by people, optics play a role I agree with that. What I don't agree with is going along with optics when its obvious the work isn't leading the group in the right direction, disagree with this take:
"If you ship something users hate and makes no money, but your leadership team is happy, you still shipped"
> a lot of what he says is unspoken and you’re left to realize it through experience.
Agree, there were some good points. I think if he left out some of the extreme points of pandering to optics to the companies detriment this would've been a much better writeup.
> realizing it’s just about understanding what your leadership cares about as your users
Yep it is important to understand what your leadership cares about, but he advocated blindly going with leadership regardless of if they are right or not. That felt off to me. Strong ICs should speak up when the ship is going in the wrong direction.
Makes sense and I think we are on the same page from a mindset perspective. I think we might just differ on interpretation of the article.
It mainly just seems like to me the author is sharing their experience of what they’ve seen, and not necessarily saying you _should_ do anything. More like a hard truths article rather than a “How you should work” article. But I also haven’t reopened it since the first read to re-analyze 😅
I agree that shipping is hard . I agree with you that you should “steer the ship” rather than “ship” to please.
Without impact, it’s less justifiable yes and less satisfying too .
But but but.. what about improvements that are “difficult” to tie to metrics , like refactoring? Or making your CI/CD easier to use. Or squashing bugs that reduce your “support burden” that no user or VP will ever think about. Or making your internal documentation better so you can onboard new team members faster, or less likely for them to leave.
This has been the biggest dilemma of my career. The gift and curse of software, is you can “ship” the first important thing quickly but then your user base or C suite will probably never understand all of the behind the scenes stuff needed to keep the ship operation a well oiled machine.
Yeah it can be tough to tie some improvements to metrics. If the improvements are minor but worthwhile, I usually just do it and thankfully had a manager that knew the value of work that wasn't measurable (he was our old tech lead).
Sometimes those hard to measure items have obvious impact. For instance, a refactoring that everyone has been begging for because the site keeps going down due to some dangerous pattern in the codebase. In those cases recognition isn't a problem regardless of the manager.
I think both articles are missing the bigger picture. Most development, at the leadership level, is about Promotion Driven Development. Maintenance and compliance projects just keep the machine going. They only matter when they aren't working right. Making people happy and efficient only matters when they hate something so much that it causes political problems. And then, making it better can come with funding and visibility.
This leaves the other category, cool stuff, to be the main focus of leadership. It may get funded based on how it will change the world, but I rarely see the results as a measure of success for the project. Delivery timeline and effectiveness of the demos, matter so much more. From a Staff Engineering perspective, the enterprise tour that follows showing how impressive your project was and how smart your team is, tends to be the most important thing.
I know this is a jaded view, but when you are in a large company where 95% of the development is significantly isolated from the bottom line (unless somebody screws something up really badly), the purpose of the software is not what it does.
Now, in smaller companies where you are closer to the profit lines, development is dramatically different, though not always for the better. The bad things you will do to your product for your top 5 customers can pale in comparison to the mess above.
Good leadership goes beyond what management says or wants. We all should “steer” our own ship with a focus on impact. That’s just good business.
Agree with this take
I actually planned on giving the post a shout out this week, not because I advocate for the mindset that might be implicit in his words—but most of what he says about optics is true.
For example, when he said, “whether you like it or not/however you feel about it, it’s how it is.”
Even if it’s not the world we want, he’s telling us the world we have. We can do a separate set of things to change and influence that, and choose to do the right thing, but it’s important to understand the environment you’re in, because a lot of what he says is unspoken and you’re left to realize it through experience.
To your point, I agree we shouldn’t solely optimize for optics, but it didn’t seem like he was arguing for people to do that either. It seemed like he was arguing for not being overly dogmatic on a set of idealistic “rules of engineering” and to instead be more pragmatic, realizing it’s just about understanding what your leadership cares about as your users
> most of what he says about optics is true
Where decisions are made by people, optics play a role I agree with that. What I don't agree with is going along with optics when its obvious the work isn't leading the group in the right direction, disagree with this take:
"If you ship something users hate and makes no money, but your leadership team is happy, you still shipped"
> a lot of what he says is unspoken and you’re left to realize it through experience.
Agree, there were some good points. I think if he left out some of the extreme points of pandering to optics to the companies detriment this would've been a much better writeup.
> realizing it’s just about understanding what your leadership cares about as your users
Yep it is important to understand what your leadership cares about, but he advocated blindly going with leadership regardless of if they are right or not. That felt off to me. Strong ICs should speak up when the ship is going in the wrong direction.
Makes sense and I think we are on the same page from a mindset perspective. I think we might just differ on interpretation of the article.
It mainly just seems like to me the author is sharing their experience of what they’ve seen, and not necessarily saying you _should_ do anything. More like a hard truths article rather than a “How you should work” article. But I also haven’t reopened it since the first read to re-analyze 😅
I agree that shipping is hard . I agree with you that you should “steer the ship” rather than “ship” to please.
Without impact, it’s less justifiable yes and less satisfying too .
But but but.. what about improvements that are “difficult” to tie to metrics , like refactoring? Or making your CI/CD easier to use. Or squashing bugs that reduce your “support burden” that no user or VP will ever think about. Or making your internal documentation better so you can onboard new team members faster, or less likely for them to leave.
This has been the biggest dilemma of my career. The gift and curse of software, is you can “ship” the first important thing quickly but then your user base or C suite will probably never understand all of the behind the scenes stuff needed to keep the ship operation a well oiled machine.
Yeah it can be tough to tie some improvements to metrics. If the improvements are minor but worthwhile, I usually just do it and thankfully had a manager that knew the value of work that wasn't measurable (he was our old tech lead).
Sometimes those hard to measure items have obvious impact. For instance, a refactoring that everyone has been begging for because the site keeps going down due to some dangerous pattern in the codebase. In those cases recognition isn't a problem regardless of the manager.
I think both articles are missing the bigger picture. Most development, at the leadership level, is about Promotion Driven Development. Maintenance and compliance projects just keep the machine going. They only matter when they aren't working right. Making people happy and efficient only matters when they hate something so much that it causes political problems. And then, making it better can come with funding and visibility.
This leaves the other category, cool stuff, to be the main focus of leadership. It may get funded based on how it will change the world, but I rarely see the results as a measure of success for the project. Delivery timeline and effectiveness of the demos, matter so much more. From a Staff Engineering perspective, the enterprise tour that follows showing how impressive your project was and how smart your team is, tends to be the most important thing.
I know this is a jaded view, but when you are in a large company where 95% of the development is significantly isolated from the bottom line (unless somebody screws something up really badly), the purpose of the software is not what it does.
Now, in smaller companies where you are closer to the profit lines, development is dramatically different, though not always for the better. The bad things you will do to your product for your top 5 customers can pale in comparison to the mess above.
it's a skill issue if u ship something that users hate and management likes