The 10x Engineer and Delegated Responsibility(ianlotinsky.wordpress.com) |
The 10x Engineer and Delegated Responsibility(ianlotinsky.wordpress.com) |
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.
It is quite reasonable to ask 'why should I act as if I own think, when actually I do not?'
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.
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 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.
Lots and lots of people manage programmers.
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.
"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.
And if your devs aren't mostly competent, the best you'd get from any process would be mediocre code.
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.
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.
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.
Really? They wouldn't be interested in e.g. a talented django expert? Seems a rather closed-minded approach to recruiting.
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.
'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.
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.
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.)
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.
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).
"Ownership" is a poor way to express the differences in meaning(s) indicated in this article.