This pervasive corporate fiction tires me out so much. Everyone says they hire the best candidate, they are leaders in their area, etc. It feels very much like dystopian literature, where everyone knows the thing to be false, but is compelled to say it is true nevertheless.
If we had the best product engineering organization, what would it look like?
101–110 of 126 posts
Re: If we had the best product engineering organization, what would it look like?
#102Earlier quoted context omitted.
IMO metaverse was a bet. It's perfectly fine to take a bet that you're not 100% convinced will pay off (professional poker players and traders understand this on a very deep level), as long as the potential upside is massively larger than the downside. Zuck understood that Meta could take the hit if the metaverse bet didn't pay off, but that they'd be massively better off if it did, and they had their own platform. A…
> IMO metaverse was a bet. It was FOMO. They had no vision, they had no plan, it was clear that it was only a thing because it was a buzzword at the time. Just like every other company stuffing crypto-adjacent things everywhere. It might have been a bet, but it was obvious that it was a really terrible one.
I do not know where this notion that Meta has given up on the metaverse comes from. Mark continues to talk about AR/VR at every opportunity and Reality Labs continues to invest big on it. The metaverse is a bet but its a 10 year bet that has not been played out yet.
Re: If we had the best product engineering organization, what would it look like?
#103Earlier quoted context omitted.
IMO metaverse was a bet. It's perfectly fine to take a bet that you're not 100% convinced will pay off (professional poker players and traders understand this on a very deep level), as long as the potential upside is massively larger than the downside. Zuck understood that Meta could take the hit if the metaverse bet didn't pay off, but that they'd be massively better off if it did, and they had their own platform. A…
No. "Bet" implies some sort of clear vision or value proposition. Metaverse was a dream. It's okay to dream. It's not okay to burn billions of dollars on dreams with no proof of concept or business plan. Set aside the question of whether or not it's a bad idea - that's just plain bad execution.
The Orion is the proof of concept. The metaverse that Mark is thinking of is as ambitious as Musk's Mars plans. And it is something that requires large amounts of capital and time.
Re: If we had the best product engineering organization, what would it look like?
#104An article full of buzzwords and a semi-amusing story of how a manager successfully bullshitted a delusional CEO. Okay.
Re: If we had the best product engineering organization, what would it look like?
#105Saying that you can’t measure productivity is a pseudo-truism and a cop out of doing your job. How do you measure productivity = how do you decide whom to promote; how do you decide whom to fire; how do you decide how to distribute bonuses; etc. If you can’t measure productivity, you can’t do your job as an engineering manager. It’s not a question that should have been asked 3 months into a job. It’s a question that…
So... how do you measure productivity? The engineering managers you refer to probably attempt to measure productivity, but may well fail to correctly identify high and low performers.
There are quantitative measures like story points velocity, time to merge, code churn, etc. Those can be simply measured but also simply gamed, so they should be used with caution. There are qualitative measures like code maintainability, satisfaction of stakeholders, communication skills, system design skills, etc. Those have to be assessed using peer feedback, stakeholder feedback, 1-on-1's, activity during calls and meetings and so on. Those are harder to measure, but also harder to game.
Re: If we had the best product engineering organization, what would it look like?
#106Earlier quoted context omitted.
I'm glad that it works for some people, but I did not like the forced pair programming in XP at all. And I found adherents to XP were even more cult like than Agile teams.
Does XP and pair programming actually require two people to be simultaneously working together at the same time? My understanding is that this includes one person who codes while another person looks at the results and reviews them afterward. The two are still working closely together and exchanging feedback, just at different points in the process in an iterative loop.
No, the point is that both "driver" and "navigator" (as some pair programming referred to the roles) are looking at the coffee simultaneously, just one has the keyboard at the time.
This is extended to "mob" programming where you have whole team of "navigators" and one person at keyboard.
Re: If we had the best product engineering organization, what would it look like?
#107Earlier quoted context omitted.
No. "Bet" implies some sort of clear vision or value proposition. Metaverse was a dream. It's okay to dream. It's not okay to burn billions of dollars on dreams with no proof of concept or business plan. Set aside the question of whether or not it's a bad idea - that's just plain bad execution.
The Orion is the proof of concept. The metaverse that Mark is thinking of is as ambitious as Musk's Mars plans. And it is something that requires large amounts of capital and time.
[deleted]
Re: If we had the best product engineering organization, what would it look like?
#108Earlier quoted context omitted.
> Amazon does a good job of training new hire on the 'Amazon way'. Amazon does 6 pagers, they do design docs. Amazon does SOA. Amazon does not use relational databases. Everything has an API. Because of the 'Amazon way' and the training they do new team members understand at least some of the context and expectations. As a counterpoint, a huge part of Amazon's culture (or at least, AWS's) in my experience was the emp…
Which is the only way to learn tbh, you can receive as much positive reinforcement imaginable, nothing prepares you for a large scale incident like living through one, building the connections you need to solve it, getting the shame of your life, and losing sleep over your failure.
I'm not really sure what you mean by "positive reinforcement", but I don't think it's possible to disagree more with this sentiment. "building the connections you need to solve it, getting the shame of your life, and losing sleep over your failure" isn't a strategy for teaching for something; it's a coping mechanism for someone trying to brute force their way through something that they weren't adequately trained for.
Most people seem to think it's fine for companies to offload the entirety of the burden of learning to individual employees, and maybe I'm an outlier in this regard, but to me, this seems more like a cop out to avoid trying to actually solve the problem at the cost of the employee's emotional health. I'm not surprised that companies default to this, but it's also not surprising that burnout is so common in our industry when this is considered the "best" or "only" way to do things.
Re: If we had the best product engineering organization, what would it look like?
#109Earlier quoted context omitted.
> Amazon does a good job of training new hire on the 'Amazon way'. Amazon does 6 pagers, they do design docs. Amazon does SOA. Amazon does not use relational databases. Everything has an API. Because of the 'Amazon way' and the training they do new team members understand at least some of the context and expectations. As a counterpoint, a huge part of Amazon's culture (or at least, AWS's) in my experience was the emp…
My team didn't add new members to the oncall rotation for about 6 months to ameliorate this issue. But starting oncall at first is rough and even with months of context on our systems people usually take a few rotations before they really figure it out. We expected new members to have to escalate.
I don't think this really ameliorates the issue much; it just pushes the problem down the line. IMO this is a big part of why people transfer internally to different teams so much at Amazon, and that masks the problem even further. If by six months of on-call rotation you expect someone to be self-sufficient, but they only start after six months on the team, they'll have been on the team a year by that point, and people either transferring or leaving the company after a year on average isn't going to be immediately obvious as a problem, but if people start a few weeks in, you're going to have 5-6 months of noticing that there are issues when that person is on-call, and if that happens more than a few times, the trend will be noticeable.
Re: If we had the best product engineering organization, what would it look like?
#110Earlier quoted context omitted.
So... how do you measure productivity? The engineering managers you refer to probably attempt to measure productivity, but may well fail to correctly identify high and low performers.
There are quantitative measures like story points velocity, time to merge, code churn, etc. Those can be simply measured but also simply gamed, so they should be used with caution. There are qualitative measures like code maintainability, satisfaction of stakeholders, communication skills, system design skills, etc. Those have to be assessed using peer feedback, stakeholder feedback, 1-on-1's, activity during calls a…
In my experience, not only are quantitative metrics gameable, but they depend greatly on accurate estimates (which just shuts the problem along) and tend to bias towards rushed implementations. You also have to be very careful to consider what duties the person has beyond pure coding, which can become time-consuming as they grow in seniority, such as mentoring juniors, engaging with product teams, or supporting product enquiries.
The qualitative measures you mention describe "quality" rather than "productivity" (rate of good output). Both are aspects of performance, but are definitely distinct.
I suspect that the best you can do for productivity is kind of a halfway house, where - as part of their feedback - a more senior developer indicates whether the rate of implementation met/exceeded/fell below expectations.