So if I weren’t practicing reasonably decent op-sec (please state actors don’t take this as invitation to diminish my use of the adjective “reasonably”) you would know that I have worked at my fair share of different places over my career as a Software Developer. Over the course of this career I have worked in all kinds of different scenarios which range from being the single IT resource that does it all for the client to playing a part on a well organized SCRUM team.
Which scenario do I prefer? Well if you had asked me this ten or even five years ago I would’ve probably told you that working as a solo practitioner was my preference and that would not have been a lie. For a very long time I very much preferred working directly with clients and establishing a relationship with them. This made it easier to understand their problems and adjust my work to their perspective of the world.
You see, every client / customer sees IT a bit differently. Some see IT as a gateway drug to a promised land in which all of their problems are solved. Some see IT as a merciless source of cost overhead that must be contained and curtailed at all costs. Most clients are somewhere in between. For most IT is a necessary evil that they need to interface with to remain productive.
However as I have gotten older and the reality that I can’t possibly know all the things and be all things to all the people has begun to make its presence known in my life, my preference has shifted. I realize now that this is probably how most of the people approach it most of the time. The circumstances around my entry into this career differed from most due to how I grew up. Which mostly revolves around the fact that my father was a software developer long before it was cool and I was inundated from a very early age (started writing code at six) with programming related materials and tech. In any event, time catches up with everybody even good ole ITF.
This isn’t just about me getting old and my brain failing to meet expectations though. It’s also about the fact that IT today is so much more complicated that it used to be. Building software is not nearly as simple and quick as it used to be. I can remember sitting in meeting rooms at my job over twenty years ago literally live coding feature requests as the users gave them to me. But this was being done on a Classic ASP / VBScript codebase and I was modifying the prod version of it directly. I wasn’t even using source control back then. Just zipping up archives of the code a few times a day so that I could roll back in the event I decided that my recent modifications weren’t actually such a great idea after all.
Software today doesn’t work that way. The things we build now generally aren’t standalone applications with a single local / on-premise data source to draw upon. They are so much more than that because everything now revolves around the cloud. The cloud makes its nut by locking their customers into a series of forked and / or proprietary services. Every single cloud vendor service, while similar to services you can setup yourself or get from another cloud vendor has its own unique quirks and challenges.
At some point, even a cotton headed ninny muggins like myself has begun to see the truth in it. Solo practitioners crafting elaborate systems designed to cater to the specific needs of their narrow band of users is not the way of the future. That approach is dying for better or for worse. Combine that harsh reality with the fact that I am personally deficient in cloud technologies and the core truth reveals itself:
Adapt or Die.
Okay so yeah I want to be part of a team again. This is one reason why I took the second job offer I mentioned last week. It was with a previous employer and when I worked there they really put a huge emphasis on teams. I didn’t appreciate it at the time. Because I was still suffering under the delusion that I could do it all.
Sadly I acted accordingly. I took on as much work and closed as many tickets as possible for years while working there prior. This made for some great raises and accolades, but it made my life on the teams I was part of more difficult. I only realize this now when I look back because let me assure you: I didn’t realize it at the time. Now, this wasn’t because my teammates weren’t trying to tell me this but it was more along the lines of that I wasn’t ready to hear it.
The harsh lesson of those years for me is this: In order for a team to be great, it can’t be polluted with any so-called Rockstar or 10x developers. Individuals who work this way are almost always expressing the presence of some sort of serious deficiency by attempting to maliciously comply in this fashion. I know I was. For years I wanted to always be perceived as the best. This was very important to me. However as I have aged, as I have changed my lifestyle and as I have become more self-aware I have begun to appreciate this old adage (apparently African in origin, though I’m too lazy to actually confirm it):
“If you want to go fast, go alone; but if you want to go far, go together.”
The core point here is that in a well balanced team, each member has to put the needs of the team over their own needs, at least most of the time. Rockstar and 10x developers don’t do this. They are obsessed with individual achievement and their behavior reflects this prioritization. For example, if you are a junior developer on a team with a Rockstar developer, anytime something difficult comes up, what is going to happen? Is the Rockstar developer going to sit down and take you through it patiently and capitalize on the opportunity to turn a problem into a teachable moment or are they going to simply seek an opportunity to take the task away and render the problem null and void?
Spoiler: They will always choose the latter.
I did that so many times and looking back it makes me sad. I wasn’t a collaborator. I wasn’t a team player. At best I was a force of nature hellbent on exercising my influence over a project and a codebase so that I could use it bolster my own individual accomplishments. This of course denies other members of the team the ability to grow and to learn. This also effectively creates a situation where the deficit between me and them would always remain relatively consistent as my behavior was basically sucking all of the oxygen out of the room for them. This of course feeds the desired outcome in which I would be ranked or rated higher than other members of the team because I basically engineered a situation in which I was robbing them of opportunities to excel.
Did team velocity suffer? Probably not. However if the rate at which the work gets down is the primary metric you use to judge the effectiveness of a team, you have failed to appropriately judge the team. There is more to it than that. Just as a body cannot remain in good health if one organ consumes all of the resources and leaves the other organs to subsist on mere scraps, the same is true for a team. This also creates a problem when the Rockstar developer decides to leave the team. They are left with mere scraps and blindly grasping for straws when it comes to maintaining and working with whatever the asshole leaves behind.
Consider this my apology to all of the teams I worked on in the past: I failed you. I am so very sorry for that. I am also sorry to my current team with whom my time is growing short. Not because I denied anybody opportunities in this case, but because I’m leaving you all a mess of stuff behind that you will struggle to maintain. I wish it didn’t have to be that way. But the company insists on keeping headcount as minimal as possible so there just aren’t enough resources to allow for the same level of opportunities.
Regardless of circumstance, future ITF can and must do better.