99 The Letting Go

Ego Driven Development: The Dark Side of Ownership

Reading Time: 9 minutes

I was fired yesterday [March 2019], but that’s not what caused me to reflect on my career, but only to start writing this piece. Months ago I already realized I will eventually quit and most probably I will not be the one to deploy my life project, to deploy my code to production, my masterpiece

I don’t know if my “situation” is considered rare. My career spans a little bit less than 10 years, not sure even if it’s a lot or not, but at the time of writing this – no code I ever wrote is running anywhere in production in the entire world. Almost every startup I worked for, ended up dead in the water. Even the one time I worked for a big company, the product I was working on was canceled by someone in Seattle which got me fired in Israel. Funny how small the world is. One must ponder – were the last 10 years of my life actually worthless? How did I end up here? What made me choose this path? How do I avoid it and how do I as a manager make others avoid it as well?

During reflection a few things occurred to me but the main insight was – my code was never mine to begin with. Neither is yours.

Pay per Code

(or did you forget you are also a hired gun?)

Ponder on this: If you really are the owner of the code, will it stop running when you quit?

Today  as I’m looking for a new position, the job ads promise me “an end-to-end ownership of your code”. Heck, even the jobs I posted as a CTO promised exactly the same thing. That’s an empty promise that always made me choose my next position, as I needed to satisfy my hunger and my ego for always learning and to always create “the best product” I can – and in order to do that I must be the one to own it. Why me? because it takes someone who doesn’t settle on mediocrity or as a manager, someone who recruits the people that know how to take ownership just like me. Seriously, ownership and ego were a main cause for me to grade down other important aspects such as who I’m going to work for and with.

While considering quitting on my life project and on my team, I read an article that made me start to look at things differently, at least from an economical point of view. Have you ever noticed that your code works far longer than you? The following example will quickly answer this question and summarize the article:

You’re earning 100K a year. Each year, your code makes the company 100K. This is what’s called “break even”. After three years – you quit. So far the company has made zero dollars. Unlike you, your code did not quit and is still making the company a 100K a year – but at no costs as you’ve already quit. The company you worked for ends up with a profit while you end up somewhere else. Everybody wins and that’s okay. From an economical point of view, if the code has an owner it is the company who pays you. You may have forgotten that and that’s okay too.

Unit test yourself: Will you delete all the GitHub repositories you created when you quit? Obviously you won’t thus the code is not yours.

Unit test yourself: If someone tomorrow offers you a job at Google for twice what you’re making now – will you ask yourself “but what about my code”? Doubt it. You’ll tell yourself “I got paid for this until now it’s time for me to get paid for something else”. And that’s okay. That’s just how work is.

Self git-blame

(or who is at fault when your bug reaches production?

Years after I’ve left one of my previous positions, I kept blaming myself that I could have done something else. As I was a team leader in charge of an entire product which I owned (and delegated ownership), I always thought there was something I could have done to prevent the company from nearly going bankrupt, the event which caused my firing. It wasn’t even about the code, but about the product architecture which I inherited but failed to fix it. I am the one who failed to convince my manager to invest the time needed to fix it as my team and I were always overwhelmed with developing new features. The real problem was that I had no one to share the blame with as I was given ownership over it. That may also be what I did as a manager to my employees until lately.

Endless self blame is quite reasonable when you own your work and given ownership on it. The thing is, when you own something you truly are solely to blame. As making mistakes is inevitable so does the guilt and blame that comes along with it. These are the two worst things you can do to yourself and they can go miles and years with you even after you quit. 

Blaming someone else is no good either. You’re just taking your own bad feelings and burden it on someone else. That’s even quite egoistic as you prefer to cause harm to someone else instead of feeling bad for yourself. As a manager to delegate ownership is to tell your engineer  “I don’t want to deal with it anymore, that’s on you from now on.”. That’s the manager focusing on his own needs instead of his employee.

That’s the true dark side of ownership. The burden.

Unit test yourself: do you continuously blame yourself for your mistakes?

Unit test yourself: do you wish you had someone else to blame but yourself?

Unit test yourself: do you actually blame someone else or your CI/CD systems for not catching a bug?

From Blame to Shared Responsibility

(or is blame and guilt a must?)

As a manager how do you cease from burdening guilt and blame (past, present and future) on your teammates? how do you stop feeding their egos with ownership but still get the job done?

If Ownership is “I don’t want to deal with it anymore, that’s on you from now on” then Responsibility is “I trust you with that”. Shared Responsibility is “I trust you with that and we’ve got your back”. Read that again as this is not a subtle difference. With some small changes done, it may improve your development culture.

To say “I’ve got your back” is one thing. To provide one on a daily basis is another matter but maybe easier than you think. It starts with a simple change in phrasing. There is no longer “your mistake” (the employee) and “my mistake” (the manager). There is only “our mistake” and “we have made a mistake”. That will unburden both your employees and yourself as whatever happens – you are in this together. That’s what a team is for and it goes both ways.

Saying “we” and “our” is one thing but to put real essence into it is another. Fortunately the solution is right underneath your nose. If your team is not already doing this as a practice – do Code Reviews. Code Review is your way to share a teammate’s responsibility with you. Although he’s the one who actually coded it, if it has passed your review the mistake is also yours thus not his alone and no longer a burden. Emphasize and repeat this every time a bug has been discovered and/or has reached production. Remember that it is only natural to make a mistake and it’s okay to make one as you are here to watch their back.

There are other practices that you’re already might be doing that can be leveraged for this – automation, unit/integration testings and Continuous Integration. Remind people of the following: we (yourself, the team and the company) have invested much time and resources to catch our mistakes before they reach production. That’s actual money paid so that we can have your back. That’s putting money where your mouth is.

If there is a QA personnel (automated and/or manual) in your company, add this to their objective: “You are our last line of defence in making sure that our mistakes will not reach our users” and again remind everyone that’s actual money paid on personnel to have their backs. Leverage unit tests again to share the responsibility between QA and the developers: you are coding tests to reduce and catch bugs prior to QA work, to ease up their work so they focus on being the last line of defence.

Unit test yourself: What do you share with your teammates? Burden or Responsibility?

From Ownership to Professionalism

(or do you better code the projects that you own than those of your colleagues?)

It is humanly natural to take better care of things that you own than that of others, but my grandfather had a saying: “You will only truly care for your own money once you truly care for other people’s money”.

As a manager when I grant someone ownership over a project I do expect him to do his best on it. I ask myself, do I expect him to “not do his best” when I give him a task that’s outside his project? The answer is a definite – I expect him to do his best whether he owns the project or not. That’s a contradiction as when I’m the one to give ownership, I’m also the one feeding my engineer’s ego and making him think that his project is far more important (to himself, in his own eyes) than those of others..

I expect him to be a professional as I expect myself to be one as well. Luckily, I don’t have to define what a “professional coder” is. The famous Uncle Bob already did so. Most engineers talk about Clean Code, but do not talk about Clean Coder, a book about how to treat your code and work as a practice and a career, not only as “a paid job”. It also talks about how to correctly behave in a working environment, what is expected of you to behave like and the ethics of the profession and what is professionalism. A must read for every coder.

Unlike my previous suggestions, I won’t get the chance to do the following as I was fired, but luckily there’s always going to be a next job where I would like to take the culture (if needed) from a Clean Code one to a Clean Coder one. I plan on letting all my engineers read Clean Coder in the office during work hours – so all the teams can see that their colleagues are reading it. Remind them on a daily basis or whenever I can, during Code Review and 1:1, that this is what is expected from them from now on – hopefully dissolving ownership through it.

Unit test yourself: have you read Clean Coder?

Should I stay or should I go

(or does it matter if you deploy your code?)

There were several triggers that got me considering quitting. The first that the platform I was working on was 90% done. The second is that I recruited someone who can finish the job by launch time and maintain/extend the platform when needed. It happened quite naturally because it was my responsibility (not ownership any more) to make sure that in my absence, as I may get sick or take some personal time off, the job will still get done.

I kept on wondering.. should I stay put and wait for several months for the launch just to be the one who presses the deploy button, to cost my company who is running low on resources a huge sum of money just to feed my ego again? Will it make any difference in the world and on my career if I’ll quit and my replacement, who I’ve been training just for this for several months now, will do it instead of me?

As I looked back on my career I noticed that in the end, it never really mattered who delivered or worked on “my” platforms, if it was me or someone after me – as it was never mine to begin with. You, just like me, will also eventually quit or get fired because that’s how life is. It is not a question of if but a question of when. No matter when I quit the only difference is that I may not be able to say ‘I made this’ but I can always say ‘I made this happen’ which will always be true, even years after my code is deprecated.

It was time to let go.

Leave a Reply