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.
