Taking Responsibility for Yourself
Or, Why It’s Still Not Okay to Be An Asshole Even In Difficult Circumstances
Last week I was clickbait-suckered into reading this article about how this company fired their “top talent” and everything after was peachy keen. I was all ready to give the author a piece of my mind, but it turns out it was a misnomer. At the time, I commented on it on Medium (it’s still there!) and tweeted it, saying: “This is not top talent; this is an asshole.” Because actually firing your top talent is just plain stupid. The point is, being able to work well with others is an essential part of being “top talent” in our contemporary world of software development. Gone are the days when the isolated, misanthropic genius can produce much shippable value on their own (if such days ever truly existed).
Apparently in the intervening few days since I commented, things have blown up. I revisited the article and, much to my jaw’s pain upon hitting the floor, there were quite a few people jumping to “Rick’s” defense. And today, I was pointed to this response.
Now, I’d like to tell you that the author of the response is 100% wrong and everything wrong with the world. But that’s not true. There is truth in what he says. The business types, in my experience at least, tend to err on the side of “ship fast.” There is no doubt the pressure is on in that regard. And since managers report to “the business” and are responsible for their teams “delivering value,” the cards are stacked against us all. But as I’ve said, that doesn’t excuse us from being responsible developers. Nor does the need to get into market excuse the company/product leadership from cultivating responsible teams.
The author is right in that an ideal dev team leader would not have let things spiral out of control as they did for “Rick.” He would have put mechanisms in place to ensure that no one particular team member was put in that kind of position, that there was time to do things “the right way” and so on. The reality is, however, that managers are people, too. Just like there is no ideal individual contributor, there is no ideal dev team leader.
Being a leader is both very rewarding and incredibly frustrating and demanding.
Dev team leaders are put in the extremely uncomfortable position of being responsible for other people’s work. If you’ve never been one, you can’t appreciate this. I’ve been responsible for software teams as small as two and as large as 90+, some colocated and some spread across the globe. I’ve done what I can to learn about Good Leadership and to practice it. It’s all great insofar as it goes. Being a leader is both very rewarding and incredibly frustrating and demanding.
But at the end of the day, you’re entirely dependent upon your teams for success or failure, and all the day-to-day ups and downs we all feel as individuals get multiplied by the number of individuals in your teams. You get to manage not only your teams, but also are called on to deal with how your teams interact with other teams (which in my experience is the hardest part). Typically, you’re also expected to do a fair amount of individual contribution-type work, and by that I mean you have other things to produce on your own, in addition to ensuring that your team stays productive, people are happy, have the support they need, and work well with others.
You simply do not have time, especially as your team(s) grow, to personally monitor everything and ensure everyone’s situation is perfect. You rely at least in part on people making their concerns known. Otherwise, you are probably micromanaging.
There are more books on “good management” than probably any other professional topic — exactly that many opinions on the “right way” and that many tricks and techniques and so on. Like 10,000x more than there are opinions on how to run a dev process, if that puts it in any kind of perspective. The point is, there is no “just do good management” formula that solves for what it means to be or have actual good management in any particular team/company at any particular time in the company’s history.
The simple fact is, good leadership/management is many times harder than good software development.
The simple fact is, good leadership/management is many times harder than good software development, mainly because people are your medium rather than computers. Trust me. I’ve done both. A lot.
Now when you consider this in the face of the fact that developers seem to be innately introverted and that dev management almost always comes from being individual dev contributors, it’s no wonder why there is so little “good,” much less ideal dev team leadership in this world. And that’s for managers who actually want to be good. There are plenty who care more about climbing the corporate ladder than being good leaders.
Given all the above, it’s simply illogical to expect or even hope that “management” will solve issues for you like the ones described with “Rick.” And this is assuming that the story is an accurate reflection of reality — no doubt many salient details were omitted. We don’t know, for instance, if “Rick” ever bothered to raise a flag or not that there was a problem. I have little doubt that he relished the feeling of being the lynchpin. Everyone loves to feel valued — that’s a core motivator.
We don’t know if “Rick’s” immediate manager asked him, perhaps many times, if he’s okay or not, if he can handle more, etc. We don’t know if there were in fact conversations about his taking on too much, but Rick blew off those considerations, partly out of love of the challenge, partly of liking to feel valued, partly out of fear that he might be less valued if he didn’t. Human beings are complex balls of emotions, nerves, personal histories, etc., and even if a manager was doing the best practice of having regular 1–1s, it’s entirely possible and even likely that “Rick” blew smoke up the manager’s ass that everything was fine.
We don’t know if as one by one the little flags changed color, if “Rick” was blustering that, “just give me a little more time” to handle it. We don’t know if the “Rick” told his manager that “only he could do that part” (which seems likely that he did given how he’s painted). We do know other team members tried to jump in and were berated and shut down by “Rick,” who just couldn’t let go and let others “make mistakes” in his view.
“Rick preferred to work alone in his private work-space.”
“Rick didn’t need anything anybody else built. He built everything he needed from scratch because it was infinitely better than the paltry offerings of mere mortals.”
“Rick was right: no-one could possibly understand what Rick had created.”
“[Rick’s code] was all very idiosyncratic”
“He rejected repeated attempts to introduce free open source frameworks to replace his hard-to-maintain bespoke tools.”
“Rick rejected months of overtures by leadership. He refused to take time off or allow any work to be delegated.”
“He reverted code changes — including tested bug fixes — by other developers. He asserted that he wouldn’t be held accountable for supporting other people’s work. He continued publicly belittling his colleagues.”
All of these data offered by the original author support the notion that “Rick” was not amenable to any kind of management or leadership. And the sad thing is, I’ve known “Ricks.” This is entirely believable — and they exist regardless of the pressure or lack of pressure put on them. If you don’t put pressure, they will invent it from a need to feel like they are the rockstar-savior they imagine themselves to be.
By all these accounts, “Rick” is exactly the prima donna developer that he’s made out to be and deserved the sack. In fact, it sounds like he should have been sacked well before he was.
But here’s the thing. Even if “Rick’s really a great guy at heart” and it was evil management that created and maintained difficult conditions that “turned Rick into Mr. Hyde,” that doesn’t absolve “Rick” of responsibility. At the end of the day, “Rick” still acted like an ass. He refused help offered him. He actively interfered with the work of other teammates. He belittled others. And so on. Maybe you could forgive the singular outburst of someone under a lot of stress, but ongoing behavior like this is just plain not acceptable.
The dirty little secret of life is that “Rick” — you, me, everyone — is responsible for his behavior. Even if “Rick” had the worst management in the world, he — especially as an individual contributor — can only control himself and how he deals with it. He can’t change others; he can only change himself. “Rick” shouldn’t expect other people to solve his problems. “Rick” shouldn’t wait for “management” to intercede and see what a martyr he’s being. (I don’t think “Rick” was doing this, but it’s how his defenders try to paint him.)
In addition to being responsible for himself, he needs to take responsibility for his own good. “Rick” needs to raise concerns if he’s being overworked. If he’s unable to “do things the right way,” he should be making noise and pushing back about that. Someone with supposedly as much talent and experience as he should know how to be a responsible developer. And you can rest assured, if your “top talent” raises a flag like this, you’re gonna take it seriously and listen.
People don’t change their stripes when they’re under pressure. Rather, they show their true colors.
People don’t change their stripes when they’re under pressure. Rather, they show their true colors. Management didn’t turn “Rick” into Mr. Hyde. The conditions created there simply exposed “Rick” for who he really was. Anybody can be a saint without ever being tested, without ever facing difficulties. Sure, no doubt that it sounds like his management could have been more proactive (both in trying to help and dealing with “Rick’s” problem behavior sooner), but they didn’t make ”Rick” who he is. They didn’t make him act out. “Rick” did that.
Part of being a responsible developer, no, simply being a responsible human being, is that you take responsibility for your actions.
Part of being a responsible developer, no, simply being a responsible human being, is that you take responsibility for your actions. You can’t act out, throw tantrums, treat other people like crap, and generally make yourself difficult to work with and expect that being skilled and talented makes up for it. You might get by for a little while, but it will bite you in the end in an industry where teamwork is always key to success. You’re gonna have hard times in life, and it’s those times where you’ll find out who you really are. Don’t be a “Rick.”
