Hacker News Reader

Comment by awillen | Hacker News Reader

I think this is a great way of looking at it. Coming from the product side of things, I see developers who are vastly more productive than their peers because they have amazing organizational and communication skills. They help keep timelines on track, they keep their peers focused and identify potential issues that a PM without an engineering background might miss. Developers who can suggest small modifications to a product spec that will drastically reduce development time but not greatly impact the overall product are worth their weight in gold.

View on HN

You're comparing good / competent developers with developers who are either new or incompetent.

Being good at your job doesn't mean you're a "10x engineer".

Being good at your job is pretty much the definition of 10x developer.

This perspective saddens me because you’re not describing a productive developer, rather just some employee good at acquiescing to what product managers (often mistakenly) want.

10X developers aren’t wasting time debating scope with product managers. They are too busy doing things that directly help customers and stakeholders, generally as a direct result of flippantly ignoring what product managers say and the ensuing politics over who gets credit and what is politically allowed to be shipped.

One way to spot a 10X developer is that it’s someone getting lots of stuff accomplished despite product managers finding it universally frustrating to ask that person to take on the product manager’s agenda.

Honestly the reason why these people are so rare is not because they are too hard to find. It’s because product orgs can’t tolerate someone whose judgment supersedes their own in regards to what the customer wants. The 10X developer does product management circles around product managers all while getting their own software jobs done in the meantime.

In order for there to be possible options for politically arguing over bonuses & credit for what is shipped, you have to staff most of engineering with passive people who don’t push back on product management, hence very few 10X engineers.

I am not a developer, not a product owner and I have no down-voting privileges here, but as an IT manager with over 20 years of experience I think almost everything you wrote is wrong. There is no point in taking sentence by sentence and explain why they are wrong, the answer would take pages. Anyway, the very rare 10x developers I met were not writing 10 times more code in the same unit of time, they were doing things simpler, faster, avoiding unnecessary work and writing very good quality code with sound design and a very small number of bugs. This is how they get to 10x, it is 10x in total productivity and not lines of code.

Where did I say that 10X productivity means 10X more code? That’s pretty much the opposite of what I’m saying.

> This perspective saddens me because you’re not describing a productive developer, rather just some employee good at acquiescing to what product managers (often mistakenly) want.

This is straight up the opposite of what they're describing:

> Developers who can suggest small modifications to a product spec that will drastically reduce development time

Part of the whole 10x package is getting the manager on board and increasing trust, not going behind their back.

> Part of the whole 10x package is getting the manager on board and increasing trust, not going behind their back.

People are acting like everyone's rational, and all you need to do is just explain things properly. But that's not often the case.

Also, if you have to explain things to someone all the time, it starts getting uncomfortable for everyone.

It doesn't matter if your manager is rational or not. Establishing trust and being a good coworker also means getting them on board on an emotional level. If this is something that you cannot do yet, then this is definitely a skill worth polishing.

>Part of the whole 10x package is getting the manager on board and increasing trust, not going behind their back.

It's a bit of column A and a bit of column B. Organizational politics often blocks productivity. Often the it's better to ask forgiveness than permission is quite effective so long as you're reasonably astute about how much political capital you have, how much you will make from the move and how much you will spend by the move. Other times it's the ability to build consensus and gain buy in to remove the organizational roadblocks is what can really be a force multiplier.

Both of these dynamics are at play.

You say,

> “This is straight up the opposite of what they're describing”

but then your supporting quote below that suggests the opposite. The quote about cutting scope (from a product manager’s point of view) is about cutting useful scope, like paying down urgent tech debt, in order to cram in more features or hit a shorter artificial shipping deadline despite no actual impact on any bottom line.

My supporting quote is describing a developer who pushes back against bad requirements to find a better solution, not someone who just acquieses to what product managers want.

Sad that people downvote without bothering to reply. To me, it sounds like you either don't like your product team in general, or they ignore your ideas for reasons of territoriality, or you're doing a bad job expressing your concerns to them.

Frankly, I don't see why an engineer would know what the customer wants better than a product manager. I do see how an engineer would know the kind of corners they most want to cut, and of course how any human would want to present their self-interest as the group's interest, but I don't know anyone's specific circumstances.

> “Frankly, I don't see why an engineer would know what the customer wants better than a product manager”

The engineer usually spends much more time investigating customer usage data, help center feedback, product features and competitors, all while also having greater familiarity with the engineering implementation (to know what’s feasible / reasonable) and greater quantitative skill to determine the implication of evidence in terms of what actions to take.

One lesson I learned a long time ago is to develop product management as a career growth track for engineers who are interested, because the best way to be an effective product manager is first to be an engineer of that product for a long time and leverage the engineering skill set as the primary skill set for product management.

I've met great engineers who were great at driving product, and great engineers that were terrible at it, or uninterested in it.

I've met engineers who could invent a whole new product out of sackcloth to solve a customer need the business was only dimly aware of, and engineers who used all their knowledge of customer pain points and data to fritter around the edges of their systems, redesigning this or that but making little material progress in addressing serious issues.

I have little time or patience for "engineers > PMs" arguments or vice versa. You should be a team working together to solve important problems, and you should each recognize and celebrate the skills each of you as individuals brings to the table. If you're not doing that, the problem lies with your team or organization, not the profession as a whole.

> “I have little time or patience for "engineers > PMs" arguments or vice versa.”

But some skill sets are more effective at some tasks. You wouldn’t hire a stand-up comic to play quarterback on your football team. There are opportunity costs to doing so that make it a strategic blunder.

It’s really the same, only lesser in degree, when thinking about what sort of background & skill set someone should have when you hire them to manage your product development.

If you narrowly dismiss that consideration by acting like every skill set is equal & every type of person hired into the position of product management can do the job, it’s no less of a strategic blunder.

I think we agree?

Part of what I see emerging out of this whole 10x debacle is a critique of what makes a great engineer, and a realization that it means very different things to different people. Moreover, that one person's definition of a great engineer might come with some serious limitations baked in. For example, which keys on their keyboard are likely to wear out prematurely. :-P

The same is no doubt true with product managers. For example, a previous company I worked for divided up PMs into two roles – those who were experts at the business side and decided the larger direction of a product line, and those who were able to turn those directions into unambiguous specs for designers and engineers to produce. Different skillsets, both overlapping with each other and with other positions at the company. Considering those roles separately, you could be a great PM in at least two different ways at that company, but when you start taking leadership, teamwork, and mentorship qualities into account, it's clear that there were even more pathways up the mountain than that.

Reply on news.ycombinator.com