Means and Ends
Means and Ends
How often do we try to “improve” our product and services, and the revenue and profit therefrom (i.e. the ends), and how often do we try to improve the way the work works, the way we develop those products and services (i.e. the means)?
Folks have needs related to the way the work works, in many ways just as profound as the needs they have of the products and services (features, revenues, wages, …) resulting from that work.
To illustrate what I’m talking about, here’s a short list of some of the needs folks can have related to the way the (product development) work works:
- Ongoing information (development schedules, quality levels, costs, plans, etc.)
- Confidence (e.g. that milestones and Due Dates will be hit)
- Growth
- Learning
- A sense of purpose (are we spending our time on stuff that matters?)
- Integrity
- Connection (e.g. human connections, relationships between people)
- Appreciation
- Harmony
- Achievement
- Etc. (and lots more possibilities in e.g. this Needs Inventory)
This post is an invitation to apply the same considerations to the explicit and intentional design of the way the work works, as we do to the way our products or services under development work.
In my previous post, “Antimatter Evo”, I explored the twelve principles associated with the Agile Manifesto, and proposed a way to radically simplify those twelve principle down to, essentially, one (“Attend to folks’ needs”).
May I invite you to consider the impact on your development efforts of applying the same principle – the Antimatter Principle?
Does your current approach – to defining and improving the way the work works – attend to the needs of the people that matter?
Blind Spot
In the typical product development situation, each new product (or service) that enters development is handled much like all those which have gone before. Outwith major revisions to the way the work works (say, adopting a revolutionary new approach such as Agile), incremental improvements to the means of development can occur, and occasionally do. Yet with both Kaikaku (revolutionary change) and Kaizen (incremental change), change is rarely connected to better serving the needs of the “folks that matter”. Put another way, change most often serves the product and its users, and rarely the folks impacted by the way the work works.
How blind is your organisation, presently, to the ability of its development efforts to meet the relevant needs of the people involved in those efforts?
What if we applied ourselves to understanding the needs of the people that matter, as they pertain to the way the work works? What effect might that have on the social dynamic, the relationships between different people and groups, on productivity, and on the general success of our development efforts?
– Bob
Think Different
Ultimately, you’re encapsulating the debate between Type A and Type B management models – do you rule by fear (Type A), or do you think that happy employees produce the best work (Type B)? Do you crack the whip because people can’t be trusted and have to have the threat of sanctions to be forced to create the product, or do you trust people to produce new stuff because deep down, they enjoy making new and better stuff? Ultimately, which is the more important – profit or product? If profit is the more important, then the people who make the product become part of the problem, not part of the solution, because they represent a cost of doing the business. If the product is more important, then improving the physical and psychological conditions people work under will mean that a better product is the result.
Software is fairly unique; for the first time in human history, a large segment of the world’s economy is dependent, not on mass production turning out thousands of identical products on a daily basis, but a range of different and highly complex intellectual constructs that have little or no physical existence but instead make other things happen in the real world. These constructs – programs, apps, call them what you will – require a large number of talented and intelligent people to plan, create, generate, distribute and implement them. These are not people who work well under Type A management models, yet there are still plenty of companies who insist that that is the way they must be managed.
The whole Agile movement may be able to trace its origin back to a number of management techniques, including ones that have been used (or mis-used) by Type A managements in a number of organisations. But I see signs that the more inclusive nature of the Agile movement, especially its reliance on self-organisation, is changing mind-sets in a lot of different ways.
I think that this is causing change; that change is something that the IT industry has at its core; but the potential for that change goes well beyond just one sector. I see it in blogs, in accounts of conferences, and in social movements which have become powerful because of the very tools that the IT industry has created. There is a sudden appetite for discussing how we live and work alongside how we wield the tools of our trade and deploy our skills. I think it has a lot in common with the late 19th century, when an awareness of the need for improved political rights for workers went alongside the movements for self-improvement and education as well as the growrth of entrepreneurship. It is international; it is inclusive, because it relies on minds, not our physical forms; it is prepared to consider change because it has already seen how IT has changed our world in one generation.
Your blog is called “Think different” – I think a lot of your readers already there. If thought is transformed into actions, then we will be in a very different place.
Pingback: Five Blogs – 30 April 2018 – 5blogs