I first hit on the notion “Attend to folks’ needs” – only very recently named by me the Antimatter Principle – back in 1996. We had just launched Familiar Ltd, and our first big commercial project was to build a self-service web application for the corporate customers of a large Telco. As one of the first Agile software houses in Europe, we of course applied Agile principles (although not the label) in the conduct of the project.
Aside: Yes, we were still “doing projects” back then.
One key aspect of the project was discovering just what our Telco client – and, by proxy, their customers – wanted us to build. Most of us has been around the block enough times to know the importance of “building the right thing™”. Regular interim releases of the evolving product was one of our primary means to this end. But from the outset we also began asking, recording and sharing what all the folks involved in the project needed from it.
You can see a very simplified example of this approach described in the post “Nonviolent Project Management“.
Not Just Customer Work
We did not apply the Antimatter Principle just to our customer projects, though. We used the same principle in the inception and evolution of the whole company, too. For both our customer projects and the company, we sought the needs of everyone involved – developers, customers, suppliers, channel partners, everyone. Everyone, that is, that was willing to have a say.
Of course, it was early days for these ideas. We made some mistakes. And some useful discoveries along the way.
Since those days, I’ve applied much the same Antimatter Principle in just about every engagement and role I’ve had. Sometimes it’s coincided with stellar success (like the aforementioned Telco project). Sometimes it’s coincided with a train wreck. Most often, the latter has been in organisations where attending to folks’ needs has been unimaginably alien. I’ve learned some lessons from that, too. (And see cautions, at end).
Some folks have responded to my recent posts suggesting that they couldn’t imagine an organisation that cleaved to the Antimatter Principle. What it might look and feel like. How it might work in practice. Having not only imagined it, but experienced it for real, I thought some pointers might prove valuable. Here’s some of the things that made it not only possible, but a joy to be part of:
Quantifying folks’ needs – even in the most rudimentary manner – made discussing them much easier and less ambiguous. We happened to use a variant of Evo (cf. Tom Gilb) for this.
Our takes on our own – and other folks’ – needs were mostly educated guesswork. Conscious of this, yet not fazed by it, we tried to deliver quickly on a solution to each of these guesses – so that the person or group involved could try it on for size and determine how close to the mark our guesswork had been.
“You can’t really know what you need until you get it. Only then will you know whether you need it or not.”
~ Marshall Rosenberg
Over time, we invented various means to explain our approach, and to solicit, record and act on folks’s needs, and built these means into the way our work worked. “Stakeholders and their Needs” is one example of this kind of thing. The evolving record of who were our stakeholders, and their (ever-changing) needs formed one element of a broader “project control dashboard” (a.k.a. context radiator) – which also served to record and, more importantly, share and make visible other aspects of the work:
- Project Name
- Project Charter
- Statement of Purpose
- Case For Action
- Stakeholders and their Needs
- User Stories or Use Cases (derived from and traceable to Stakeholders needs)
- Quality Objectives (also derived from and traceable to Stakeholders needs)
- RIsk Parade and Top Risks
- Critical Success Factors (key quantified aspects of the Purpose)
- Outline Feature Schedule (including milestones or integration dates)
- Glossary of project-specific terms
- Project address book
- Miscellanea (e.g. quality, test and change plans – depending on folks’ needs)
Aside: This general form served the fairly standard needs of a wide range of projects. Each particular element only appeared, and was elaborated, to the extent that some folks had expressed a need for the information. Further (one-off) coordination, etc. needs were met on an as-needed basis.
For some of our staff, and customers too, the whole idea of a company going out of its way to seek out and listen to their personal needs, and moreover act on them, in an organised and intentional way, was bizarre in the extreme. In a refreshing way. (We selected our customers and suppliers – and staff too – with much care).
For staff in particular, I can remember many intense conversations on the sofas or over a pint, exploring the implications of what I now know as the Antimatter Principle.
That this all began nearly twenty years ago causes me some chagrin. Not least because of how it’s taken me so long to come to appreciate the role of the Antimatter Principle in our success at Familiar – and other occasions since.
Having experienced it, I have little doubt that the Antimatter Principle was at the root of the joyous experiences I have both witnessed and participated in over the years since I first began to “Attend to folks’ needs”.
|Caution! Attempting to treat people as if they matter, without winning the understanding and active support of your higher-ups and your peers, may cause alienation, organisational cognitive dissonance, damage to your credibility, and to your career.|
|Caution! Attempting to treat people as if they matter, without first winning their trust and understanding, may cause suspicion, resentment, gossip, and unforeseen consequences.|
|Caution! Attempting to replicate this story in your own organisation may require experimentation, adjustments for your own context, and sensitivity to the needs of the people involved. Your results may vary from those reported here.|