6 ms·

The 10x Engineer and Delegated Responsibility

78 points by ian_lotinsky 13y ago

rjzzleep 13y ago
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.
- pjmlp 13y ago
  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, ...
  - rjzzleep 13y ago
    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
    - pjmlp 13y ago
      Partly true, as usually there are no monetary consequences.
  - steveklabnik 13y ago
    They most certainly have pissed customers that might go elsewhere, and they often do have deadlines.
  - weland 13y ago
    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.
NDizzle 13y ago
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.
brewski 13y ago
"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.
- jerf 13y ago
  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.
  - GeneralMayhem 13y ago
    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.
    - jerf 13y ago
      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.
      - Domenic_S 13y ago
        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.
toolslive 13y ago
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
- alttab 13y ago
  This was in Quick and Nimble in the second chapter. Always a good quote.
- sanderjd 13y ago
  I am now incredibly sad that I have not come across that before and incredibly happy that I have now. Thank you!
- twic 13y ago
  How many ships did Antoine de Saint-Exupery actually build using this method?
Sivart13 13y ago
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.
- scrabble 13y ago
  The article also stated that all of the code is peer reviewed and QA'd. So it's not really cowboy coding.
- tbrownaw 13y ago
  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.
tdumitrescu 13y ago
"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.
mathattack 13y ago
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.
hashberry 13y ago
In other words, he doesn't micromanage engineers. Not that big a deal... most managers know not to do this.
snorkel 13y ago
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.
jays 13y ago
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.
parennoob 13y ago
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.]
- DougWebb 13y ago
  "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.
  - marcosdumay 13y ago
    Very few people manage musicians, artists, authors, and scientits. Lots and lots of people manage programmers.
- whatthefox 13y ago
  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).
jrochkind1 13y ago
> 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.
babyturtle 13y ago
He delegates and then goes masturbate in his cubicle. Arent we all sick of this manage speak/ideology BS??
Myrmornis 13y ago
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.

78 points by ian_lotinsky 13y ago

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.

pjmlp 13y ago
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, ...
- rjzzleep 13y ago
  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
  - pjmlp 13y ago
    Partly true, as usually there are no monetary consequences.
- steveklabnik 13y ago
  They most certainly have pissed customers that might go elsewhere, and they often do have deadlines.
- weland 13y ago
  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.

NDizzle 13y ago

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.

brewski 13y ago

"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.

jerf 13y ago
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.
- GeneralMayhem 13y ago
  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.
  - jerf 13y ago
    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.
    - Domenic_S 13y ago
      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.

toolslive 13y ago

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

alttab 13y ago
This was in Quick and Nimble in the second chapter. Always a good quote.
sanderjd 13y ago
I am now incredibly sad that I have not come across that before and incredibly happy that I have now. Thank you!
twic 13y ago
How many ships did Antoine de Saint-Exupery actually build using this method?

Sivart13 13y ago

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.

scrabble 13y ago
The article also stated that all of the code is peer reviewed and QA'd. So it's not really cowboy coding.
tbrownaw 13y ago
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.

tdumitrescu 13y ago

"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.

mathattack 13y ago

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.

hashberry 13y ago

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

snorkel 13y ago

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.

jays 13y ago

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.

parennoob 13y ago

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.]

DougWebb 13y ago
"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.
- marcosdumay 13y ago
  Very few people manage musicians, artists, authors, and scientits. Lots and lots of people manage programmers.
whatthefox 13y ago
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).

jrochkind1 13y ago

> 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.

babyturtle 13y ago

He delegates and then goes masturbate in his cubicle. Arent we all sick of this manage speak/ideology BS??

Myrmornis 13y ago

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.