As I’ve decided to switch over from being an software engineer to technical product management, I found my theoretical knowledge lacking. Having worked in software companies big and large, I knew the basics. Agile this, MVP that. I knew how prioritize things, and how to get things out the door. But largely, I was repeating what I’ve seen to have worked. The lack of a mental framework left me unprepared for novel problems where I’d need to make ad-hod decisions. I never failed miserably, but it seemed imminent. Continue reading “Books for Software Engineers switching to Technical Product Management”
One of the most high-leverage work in a technical organization is building shared libraries or frameworks. A common library, a piece of code that can be used as is, or a framework, a system that codifies certain decisions and allows further work to be built on top, has the opportunity to benefit many people at once. Not only that, they also institutionalize shared knowledge, put knowledge that’s in people’s head in code for future employees. And of course, there are other benefits such as possibly open-sourcing such work, which comes with its set of benefits to hiring and on boarding. Continue reading “Developing Shared Code with Principles”
One of the main tenets of agile methodology is working software trumps extensive documentation. You get something to work, and then iterate based on the quick feedback. It sounds great in theory, and in my experience, works reasonably well in practice. All software estimates are wrong, so agile is also wrong, but it produces software and does it without inflicting too much damage on those who build it.
But how do you square this way of working with a long term vision? If an organization is aligned towards a vision, there has to be a roadmap that people follow. And a roadmap, by definition, is a long term plan. It guides what needs to be done months, and sometimes years in to the future. Continue reading “Planning for Agile”