The 10x Engineer and Delegated Responsibility | Hacker News Reader

The 10x Engineer and Delegated Responsibility

ianlotinsky.wordpress.com

78 pointsian_lotinsky43 comments

"They take ownership..."

Reminder: Unless you have an actual stake in the company, you do not own anything you produce for the company. Keep that in mind the next time code you worked on causes a 2am production server crash or is responsible for increasing revenue x10. It is not your code that caused the events but the owner's of the company.

I think that was a knee-jerk reaction to the word "ownership". That is not the sense used here. There is no contradiction in being given ownership of some task while having no ownership stake in the company; it's two quite different senses of the term.

I disagree - the distinction is still significant in that it's important not to let the responsibilities of ownership land on your plate when you're not getting any of the benefits.

You're not. It's two different meanings of the word. You aren't "responsible" for the running of the business because you've "taken ownership" of the autocomplete widget on the search page. You're getting paid for your ownership of the autocomplete widget, you're not getting paid for your ownership of the corporate direction.

If you're getting paid, you do need to be getting paid because of some responsibility you're discharging, after all.

You can tell it's two different "ownerships" by what happens if you quit. One you retain, the other is simply redistributed to some other developer. They're not the same thing.

I agree with both of you, and I wish there was a better word than "ownership". That term has implications that are inappropriate for a single feature. You don't own the autocomplete widget -- you're responsible for it but you don't own it, the company owns it.

You both own(1) the widget and do not own(2) the widget.

This is English. Multiple definitions for a word are common. Cases where only some definitions apply and not others are common. They happen in almost every sentence. Try to avoid letting that pollute your thought. (It is a challenge. No sarcasm.)

Amazon.com's second leadership principle:

Ownership Leaders are owners. They think long term and don’t sacrifice long-term value for short-term results. They act on behalf of the entire company, beyond just their own team. They never say “that’s not my job."

Unfortunately, we no longer live in a society where the employer-employee relationship is one of trust. The definition Amazon.com seems to be using is that owners do shit work and so should you, but maybe I'm misreading.

I think you could also say you manage instead of own and it would still make sense.

The word is "stewardship".

"Stewardship" might be the word we're looking for: it has some connotations of personally invested care, but it's also clear that it's done on behalf of someone else and there's no ownership.

Of course, it also has a history of association with servants of landed gentry, which might make people uncomfortable (for good reasons, to the extent the analogy holds up).

does a salary count as a benefit?

Salary is compensation for quantums of a person's life spent doing something for which he has (presumably) the skills to do. That's not a "benefit;" it's an exchange of value.

"Ownership" is a poor way to express the differences in meaning(s) indicated in this article.

Sort of. The sense that's being used here is a corporatism that means 'act with the level of commitment implied by owning something even though you have none of the rights benefits or responsibilities' - i.e. It is a form of doublethink required by the corporate hierarchy.

It is quite reasonable to ask 'why should I act as if I own think, when actually I do not?'

why should I act as if I own think, when actually I do not?

Because you get paid to?

Yeah - that is the usual reasoning, but acting as if does not make it so.

In my experience, people who are emotionally invested in their work tend to do much better work, and are worth proportionally more because of it. So whether this is correlation or causation, you are indirectly being paid to care as much as you do.

If you're not being paid enough to care that much, or you don't want to care that much, then it is what it is. From the hiring perspective, we should have negotiated a price that works for me and is enough for you to feel that you are fairly compensated for your ownership of the feature. It's a two-sided relationship where you have the ability to just back out of the deal if it isn't working for you.

True, but that generally isn't the stance that employers take when negotiating salaries - that they need to pay enough for people to feel ownership.

'You have the ability to back out of the deal if it isn't working for you' is a cop out for any failing that a corporation may have. It is true but also leads to no new understanding.

I disagree. I think its important to take 'ownership' of your work. Its the best way to obtain visibility in your organization and (for me at least) creates a sense of satisfaction and pride.

If I was just a cog in the machine of the corporate wheel churning through small tasks on a daily basis it would be hard to keep motivated. In fact a lack of ownership for work is what allows large companies to carry so much dead weight for so long. Employees stagnate and start coasting.

I do however take your point to heart and realize taking ownership does not mean I am up til 2am frequently trying to meet unrealistic deadlines.

This 10x rhetoric sincerely needs to stop, now. Recently, I have seen it creep into instruction manuals for program managers who have never written a line of code in their lives. "How to incentivize people to become 10x Developers" and suchlike.

Promote this meme much further, and essentially you will all be expected to do 10 times the amount of work you do because some mythical construct apparently does.

[Note: this does not mean that there aren't some people who contribute substantially more than others -- they definitely do exist. Just a prediction that putting the number 10 on it is going to lead the beancounters into massive numerical fallacies about the productivity advantages of such people.]

"How to incentivize people to become brilliant musicians"

"How to incentivize people to become world-renown artists"

"How to incentivize people to become best-selling authors"

"How to incentivize people to become Nobel laureates"

Yeah, none of those work. Why would program managers expect it to work for software developers?

On the other hand, there's probably a lot of money to be made in writing a series of books with those titles. They'd be utter garbage, but I'd bet they'd sell well.

Very few people manage musicians, artists, authors, and scientits.

Lots and lots of people manage programmers.

I agree with you 100%. Sure, there are 10x programmers just like there are 10x lawyers, politicians, analysts, doctors, nurses, teachers, administrators etc. They are good because A. they like what they do (10K hours rule and all that ...) and B. their personality/intelligence is in-line with their profession of choice. You cannot teach or mentor someone to become 10x in their field. Fortunately, not everyone needs such ground breaking abilities. Just a few are good enough. The rest of us will do just fine by showing up, doing good work, collecting our pay-check and go live a good life (defined by the individual).

a quote comes to mind: """ If you want to build a ship, don't drum up people to collect wood and don't assign them tasks and work, but rather teach them to long for the endless immensity of the sea. """ Antoine de Saint-Exupery

This was in Quick and Nimble in the second chapter. Always a good quote.

I am now incredibly sad that I have not come across that before and incredibly happy that I have now. Thank you!

How many ships did Antoine de Saint-Exupery actually build using this method?

i've been more and more inclined to write about engineering management myself.

if you think about this post, it's is essentially how big open source software projects work.

some open source projects have the responsibility to read commit logs once you gain commit access. that way the more you get involved into the project the more your responsibility to review your peers grows.

other projects like linux have people that are responsible for certain subsystems. oftentimes a BDFL can veto commits if he chooses to, but seldom does this ever happen, because he didn't like someone.

the thing strikes me as so interesting, because here you have hundreds, sometimes thousands of people working on high quality software together in a completely distributed, but not independent fashion, sometimes with people that can't even stand one another.

what you're describing here is very similar to this.

on the other hand we have big organizations explaining their hiring techniques, some only want people with a positive attitude, only a certain development methodology, and whatnot.

You are forgetting that open source projects don't have deadlines, pissed customers that might go elsewhere, people that get fired by not fulfilling the quarter targets, ...

i'm not so sure that's true. if you fail to deliver in time your open source project will become vaporware and people including developers will go elsewhere for satisfaction

Partly true, as usually there are no monetary consequences.

They most certainly have pissed customers that might go elsewhere, and they often do have deadlines.

That's pretty much not true of any widely-used open source project. They have deadlines and pissed off companies that take their money elsewhere.

Right, so you gave "cowboy coding" a different name, then.

"Not surprisingly, others understand their code. It integrates well with the code base."

Actually, that IS surprising. You are literally saying that if sic some engineer on a problem and tell them to think really hard before they commit anything, they'll get it right.

Maybe you got lucky and that's working out with the hires you have so far, or maybe your scale is still small enough that new features can be developed in isolation without becoming incomprehensible. But I wouldn't pretend this is a successful process.

The article also stated that all of the code is peer reviewed and QA'd. So it's not really cowboy coding.

I'd think "you broke it, you fix it" (same developer is responsible for the code all the way thru QA and deployment) with mostly-competent devs would actually lead to very good code. I would also think that trying to limit people's agency (most forms of "process") would reduce quality via lowered morale.

And if your devs aren't mostly competent, the best you'd get from any process would be mediocre code.

"The team is expected to churn through a backlog of dozens of insignificantly small bits of larger features, which often lack foresight into the constraints that will be discovered and the interdepencies between smaller bits that result in developer deadlock."

Yep. This is where a crappy product manager can turn "incremental" into "myopic and inflexible" under the banner of Agile. Just trust your engineers a bit already.

In other words, he doesn't micromanage engineers. Not that big a deal... most managers know not to do this.

It's a question of granularity. Can your developers deal with high level requirements and fill in the details, do they require every detail to be spec'd out? It's also a question of does the management trust the developers to fill in the detail without an agreed on spec or will management freak out if the developer decided to get creative? Ideally both developers and management are mature enough to trust developers to interpret needs and create solutions rather than grinding away at one small task at time.

> practices and processes that shift responsibility onto a team of replaceable cogs.

This.

So much of 'agile' in the business world, I see having become an effort to make developers into replaceable cogs or 'commodity' employees. It's not good for job satisfaction and pride, but I don't think it's good for the product either.

It's ironic, because I think most of the originators of the 'agile development' idea had almost an opposite intend, 'software craftsmanship' and all.

Very good article. This hinges on being able to screen for both technical ability (easy) and the intangible combination of initiative and drive (hard). It also requires that developers keep in synch with each other. I think it works well up to a certain size organization.

I've been looking for the term to use that has managed me for the past few years, and I have since passed on to my small teams.

Establish trust and delegate. If you can't trust the person to solve/implement the problem/solution you're going to have a bad time.

We are a Ruby on Rails shop, so extensive experience developing in or hosting Rails applications is required.

Really? They wouldn't be interested in e.g. a talented django expert? Seems a rather closed-minded approach to recruiting.

We're following a similar approach with a distributed team @ NakedApartments.com. So far, it's worked really well for us, especially with keeping moral high. Glad to hear we're not alone.

Reply on news.ycombinator.com