Ownership and Leadership

In Design, Code, Test, Repeat (which you’ve probably already read and if you haven’t, you should), a major theme in building a software career is “ownership and leadership”.  I’ve worked with many programmers over these many years and the one thing that seems to differentiate the excellent from the very good are these two qualities.

Let’s break them down as they’re different. Here’s a scenario: you get a new job.  You have a diverse range of technological skills and write code well, but even with that, you still have a new product or environment to learn.  It may take a while to get your footing in this environment and that’s okay.  But, after a while, you should have done a few projects and have some code in the system that you wrote.  If you haven’t, sign up for a project that will put you in this position.  Having code in the system that’s yours makes you the go-to person for that area of work.  It makes you an integral part of the organization.  Nothing can make you irreplaceable, but you still want to be recognized as a contributor – someone who can be given a project, complete it, and be willing to maintain it.  Once you’ve got an area that’s yours, go get another one.  Don’t become just a niche programmer, expand your knowledge and ownership.  Caution: you’re not doing this to be come a code hog or king of your own fiefdom, it’s because it will give you a higher-level perspective on the way everything works together.  It leads to leadership. It also looks better on a resume for your next position or when you want to make a case for a raise to say, “I designed and developed this feature or product” instead of “I worked on a, b, and c”.

It’s difficult when starting a new job to be a leader and even in a job where you’ve been for a while, there may be several leaders. Both situations are fine and normal. As I said earlier, you don’t want to become king of the fiefdom, you want to be a team player, but you want to be a top team player; a valuable one. Part of this comes from ownership. The more you know, the more you understand, and the more you see. At this point, you start seeing the bigger picture. Then comes the tough part: talking about it. I’ve worked in many places where the structure looked like a whack-a-mole game. Stand up to speak out, even when asked, and the next guy up the ladder would look at you like, “how dare you speak up”. This does nothing but keep your ship heading for the icebergs. If you work here, you might start sending out some feelers for a new place to work. I’m not known for my ability to keep quiet, however, so when I see things that I think need to be fixed or evasive maneuvers that need to be taken, I say something.  If there’s something I can do about it, I’ll offer to do it. Don’t be a pain in the butt about it, but I think that if you don’t say something, you’re just complicit in the disaster that you’re about to become a part of. In the end, sometimes these disasters can cost everyone their jobs (I’ve detailed a couple of these situations in the book, too).

Doing good work needs to involve trust. If you own something, and are willing to change it, maintain it, and speak up when you think you’re being asked to screw it up, you’ll become a trusted member of your team. You’ll have the chance to move up in the organization or move around. It’s a little more pressure than just being a code monkey, but it’s way more interesting, and probably way more lucrative.