…and what to do about it…
I wanted to map some classic business efficiency and software delivery books to derive meaning for a given business context. In other words, what book should you read when and why?
Coming from a tech/software angle, I’m keen to understand for my business (as well as for my client’s business) what move should happen next.
This is not an exhaustive list of books in the field. This is just a list of books that I’ve read recently.
You can call this ‘strategy’ if you like, but that word is so loaded that it has become almost meaningless. I’ve tried Wardley Mapping and I’ve sniffed at Cynefin and while they are useful tools – they are too oblique for me. Instead of strategy – let’s call this instead what it is – day-to-day decision making.
What decision should you make next? Perhaps you could scope it up to ‘business operations’ but that seems almost too short-sighted and reactive. Forward-looking operations might be more apt.
I started by plotting axes of Business Impact vs Software Specificity. This means how quickly the learnings could be turned into results for the business and how technical (or deep) the subject it was addressing.
For example, implementing Test Driven Development will improve your code quality, time to market, supportability and operational effectiveness. All of those can affect your business’s bottom line, but this change will take time to come into effect. Depending on your systems and size of codebase, it could take six months or a year or more to have a measurable benefit.
Conversely, something tactical around a key resource to limit Work In Progress (WIP) (as recommended in The Goal or the Phonix Project) could immediately impact speed of delivery and efficiency.
Likewise, some of W. Edwards Deming’s principles can have either short-term or long-term benefits. What is the context?
What is your approach?
Thinking about how we approach these books, makes it easier to understand what we’re going to get from them. For example, if your business feels like it’s sluggish, old-fashioned and difficult to adapt, then perhaps you are suffering from Legacy Systems. In this case you might benefit from reading “Out of the Crisis” or “The Goal” and find alignment with your situation.
Struggling with legacy systems and you want to find out more about them? You could do worse than reading “Thinking in Systems” and learning how adding more developers to a development project won’t improve your velocity (“The Mythical Man Month”).
Are you already technologically advanced as a business? Then try looking further right on the map. If you know you have technical debt, then learn about TDD and DDD. If you struggle to find your context, then find out why with case studies in “Accelerate” and “The Flywheel Effect”.
Context is Everything
We don’t start with blank sheet of paper – we always come in with an existing situation. We always come in with legacy that needs to be supported, understood, migrated, and managed. The level of legacy and its shape will determine what you’ll need to do first or next.
Therefore it’s useful to put your ideas in context with the information you’re receiving. This is what I’ve tried to do here, to give your existing situation a context for your learning. If the feeling is that of technical debt – then you’re already a long way down the path to understanding your technology stack. If the feeling is that of a more nebulous “legacy systems problem” then start with the business context.
None of these books on their own will solve your problems, but they will provide a perspective that will give you more insight into what needs to be done.
If you’d like a free high-resolution version of this infographic – go here.