Strategy for my development team

Posted by Amenel No comments yet

I am a software engineer. But I am also a software user. As such, there is one thing I can't do with: losing features and functionalities. One day, my workflow was perfect; I knew where to go and which buttons to click for a specific result. Then, a new version comes out. And it's a disaster: I can no longer do what I've been used to doing. My emotional range in such cases goes from annoyed to plain infuriated.

In software engineering, the loss of a feature is called “a regression.” Sometimes, it's the result of a conscious choice made by the product team and when that's the case, one can usually find a blog article, or announcement news or release notes that mention the choice, explain it and defend it. Other times, the regression is an unwanted result of the work done between the old version and the new one. Put plainly, it's a bug. I'm not a fan of software bugs. That's why my first and main strategic goal is stability.

How badly do you want what you say you want? Irrespective of what it is, you'd better be congruent with yourself, your hand better be where you mouth is. Life may be very simple with this postulate of mine: "When you really want something, you do whatever is needed to make it happen." Your actions are aligned with what you say you want. This is sometimes called “congruency”, other times, it's called “consistency”. But the name doesn’t matter. The concept does.

Just about everyone agrees with the concept. But with their mouths. Because obviously, actions speak louder than words, especially when it comes to doing the unpleasant, tedious, cumbersome tasks that are required in the given context. It's easy to book a vacation package, because, you know, we're talking about tangible instantaneous, relaxing, fun, good times. It's a lot less easy, if not impossible, to wait the time necessary to build rock-solid foundations that will make for larger benefits over time.

As a manager, I can feel and be impatient to see some task or project completed, or some goal reached. In such a situation, I ask myself whether I'd rather get that result now at the expense of larger future benefits or whether I'd be willing to wait some time, even some considerably larger time if need be, to have a sum total of benefits over time that is bigger than in the first option. If I were to ever get a tattoo, it would be "Play the long game, aim for legendary." In asking myself that question, I'm actually asking myself "What game are you playing, the right-now, short-term, half-baked solution game that you know in your heart isn’t that great, or the skilled, finessed, long-term solution game that will withstand the test of time?"

Given that I don't plan on dying tomorrow, I firmly believe that it's always better to play the long game. With the long term in mind, everything takes on a new meaning. The vision and strategy for my software engineering team takes on a new meaning when the long game comes into play.