I write code.
The one requirement of making software is writing code. Code alone won't make great software, but without code, there is no software. As a maker, I learned code almost accidentally. It wasn't something I sought to learn, it was something I had to learn. Since it is a requirement of making software and I wanted to make software, it was required of me to learn it. A second-order problem, or hurdle, in the way.
Calling it a hurdle is poor word-choice because it makes it sound like an obstacle. This isn't fitting, considering how much I enjoy writing code. I found it by looking for something else, but so often we find hobbies serendipitously.
I design interfaces.
Code will produce software, but it alone will not prepare software for human usage. In the beginning, this is where I spent my time. I have long been fascinated by menus and graphical user interfaces. This may be the effect of frustrating video game interactions, or maybe it has to do with an innate desire for organization.
It didn't take me long to see the difference between making interfaces visually appealing and making interfaces effective. These are both important goals, but they are never solved in the same way at the same time. The relationship is symbiotic and can considered as a constraint problem.
Beyond the separation of aesthetics and utility is the separation of interface and visuals. The word "design" is used a lot, but I think it's generally used correctly. APIs are interfaces, and they are designed. CLIs are interfaces, and they are designed. Floor plans are interfaces, and they are designed. This is particularly interesting because it means interfaces can have poor design for completely nonvisual reasons. If the interface was designed with unrealistic expectations, these shortcomings are forwarded to the user.
I manage products.
Anyone who has worked on a large enough team has surely felt one of two pains. The first is aimlessness. The network effect of a large team without consolidated communication channels is an abundance of channels and an absence of a central message. The second pain is being excluded from the big picture. Large teams beget specialization. Without intervention, specialization begets isolation. The role of product management is cross-cutting diplomacy.
I find this cross-cutting diplomacy role uniquely interesting. As someone who started with interfaces, code, and interfacing with code, interfacing with humans has been a bit like exploring an uncharted planet. The challenges are different, the processes are different, and the day-to-day work is especially different, but the outcome when done well is definitely meaningful. As mentioned, when interfaces are designed with unrealistic expectation, the shortcomings are forwarded to the user. An unmeasured effect of a cross-cutting diplomat is ensuring all expectations are realistic.
Even if product management doesn't get shipped to production–and is therefore not required–the support the role provides creates an amplifying effect in both output and quality.
I lead teams.
The highest level of need for making software is strong leadership. This is what differentiates making software and making successful software. Immediately this is a contentious statement: what it does mean for software to be successful? The answer is a non-answer; success varies, but leadership provides this criteria and is focused on making it happen.
Leaving a dozen people to their own devices will more often than not result in a dozen directions. Good management may get the dozen people to conform to a single direction, but it's good leadership that will get the dozen people to commit to a single direction. There is a subtle but powerful difference between enforcing and influencing. Perhaps the measurable outcome of both is the same, but morale is not something that should be overlooked.