Gojko.net Website Review

Hi, I'm Gojko, and I help ambitious teams align software delivery with business goals, with the help of Impact Mapping Lots of teams today struggle with scheduling something usually called technical work: system improvements that the team finds important, but nobody actually asked for them. Do too little technical work, and you’re actively damaging the product by slowly turning it into an unmaintainable mess. Do too much of it, and you’re actively damaging the product by delaying important business features. It’s very difficult to get this just right. Some teams blame micro-management caused by task management systems. Others claim that close customer collaboration turned the delivery team into a feature factory, taking orders from people who do not understand the importance of technical infrastructure. Of course, it’s easy to blame someone else, be it tools or ignorant stakeholders, but the cause of this problem is more fundamental. On the other hand, this is not a particularly new problem, and good solutions have existed for a long time. Modern software delivery relies on close customer collaboration and transparency. Teams with remote members need digital work tracking tools. None of those factors cause problems with planning technical work, they just expose them more clearly. This is even more drastic with outcome-driven planning and measurable customer experiments from lean methods. With a laser-focus on a business goal, tech work will apparently always get postponed in favour of the stuff that actually brings in the money. This is a naive argument, of course, but after hearing it so many times following conference talks on impact mapping, it’s something I feel needs to be addressed. problem is the fact that a lot of work looks important to people working on software delivery, but it doesn’t seem that important to those paying for the whole process. Folks controlling the budget are also in charge of prioritisation, which is quite justified, so the