
The 10x Engineer and Delegated Responsibility - ian_lotinsky
http://ianlotinsky.wordpress.com/2014/02/14/the-10x-engineer-and-delegated-responsibility/
======
brewski
"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
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
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
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
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.

~~~
jerf
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.)

------
parennoob
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
"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
Very few people manage musicians, artists, authors, and scientits.

Lots and lots of people manage programmers.

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

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

------
rjzzleep
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
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
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
Partly true, as usually there are no monetary consequences.

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

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

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

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

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

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

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

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

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

