Matter of fact, I wasn't someone that I'd put in charge of a software project, like, 10 years ago. I'd gladly put me in that project as an IC, but certainly not in charge. Why? I think I got all the wrong ideas what actually matters overall.
When you start, it's about working on things that other people deemed important to be worked on – building a feature, building a feature in a certain way and so on. You're basically building experience by building small blocks, and then moving on to bigger blocks. That's a fairly normal progression – but your focus is on getting good at certain activities. Those activities vary, some are writing code, others are working on documentation, tests and so on – but all of them need to be done. But do they really?
There's probably three types of activities that regularly get done in most engineering groups – necessary things, interesting things, and valuable things. I don't want to spend a lot of time talking about necessary things – they are stuff like performing updates of critical dependencies, ensuring that whatever system exists is actually operational and so on – it's things you cannot put off for too long without having some bad effects.
Now, interesting things are something else. I recently was part of a discussion that focused on choosing a technical solution for a message broker. There were a few alternatives we discussed, one of them being Kafka, an industry standard for just that, and then some others. One of the options was writing one from scratch – and that's what I'd define as an interesting thing, and interesting activity.
If I could spend a few months and just write an enterprise message broker, that would be hugely interesting. It would probably also not be enough time, but that's another problem.
The biggest issue though is that, in an environment where established solutions already exist and are available, investing in building something that is at best equal in functionality is just not a particularly value-adding activity. It's fun, you might learn a lot, but you're spending a lot of time on something that can be achieved with a much smaller investment. Same result, orders of magnitude smaller invest.
Valuable Things. Those activities that get you closer to achieving the goal of what your team is working on at the moment. And that certainly doesn't mean just pushing for the fastest way from here to there – there are extremely valuable detours that you must take at times. But the crucial thing is to never really lose focus of what the actual goal is.
It's the one thing I struggle with the most at times in a leadership role - understanding that there is an incredibly interesting activity ahead – that we have to skip, because there's just very little value in performing it.
In a sense, software projects are the opposite of a road trip: The destination matters much more than the way there.