When you are in the business of building software; information, knowledge and wisdom that you carry in your own your head is not the only measure of how successful you are.
With software development it is in fact, the knowledge and wisdom that you have 'access to' that matters much more than how much of it you carry with you in your own head.
Malcolm Gladwell In his book, 'The Tipping Point', explains this concept when he talks about 'Transactive Memory'. He explains:
| This is what University of Virginia psychologist Daniel Wegner calls "transactive memory." When we talk about memory, we aren't just talking about ideas and impressions and facts stored inside our heads. An awful lot of what we remember is actually stored outside our brains. Most of us deliberately don't memorize most of the phone numbers we need. But we do memorize where to find them — in a phone book, or in our personal Rolodex. Or we memorize the number 411, so we can call directory assistance. Nor do most of us know, say, the capital of Paraguay or some other obscure country. Why bother? It's an awful lot easier to buy an atlas and store that kind of information there. Perhaps most important, though, we store information with other people. |
The idea of 'Transactive Memory' is relevant pretty much in all spheres of personal life and work life; including your online time. When it comes to the world of software development, even though a huge number of us may not be open to the idea of contributing on the internet; we use 'Transactive Memory' all the time; while we are looking for information; and particularly when we are going to make decisions based on that information. Ever read a blog to find out what someone thought about a tool or application you were planning on buying? Ever went through Amazon user-reviews before buying that book?
Using transactive memory is exactly what you were indulging in when you were doing all of these or multiple other activities that you do online when you look for information and in particular when you use that information for making purchase decisions; online. You were depending on individuals who you did not even know personally and you were trusting them to provide you with accurate information.
When you are buying a thirty dollar book at Amazon it's easy. However, when a part of your job includes picking tools and technologies for your organizations and most projects that are implemented in your organization, developing strong 'Transactive Memory' using sources of information you can trust becomes much more important.
As someone who is involved with making technology decisions for multiple development projects for years; I've had my share of successes and failures at picking products and frameworks to be used in projects. I've also learnt some lessons along the way quite a few of which are about building a better 'Transactive Memory'. This post is about one of those lessons.
At Multiplitaxion Inc, for example, during my early years, a client approached us with the need of having a customized user portal done. Someone high up in the pecking order at the client organization had a friend, who turned out to be the SharePoint expert.
This gentleman with his expertise in SharePoint was expected to lead the project; if it materialized. When the client approached us, the decision to use SharePoint was something they has 'defaulted to'. This decision of course, was based on 'expert advice' and they believed, in all sincerity, that it was a correct decision taken under the guidance of a true expert.
For days we struggled back and forth; trying to do a 'proof of concept' with SharePoint; the SharePoint expert helping us out every time we were up against a road-block. This guy, was amazing with band-aids, workaround, tips and tricks up. He always seemed to have some cards up his sleeves; especially every time we were going to hit a wall.
This was the early SharePoint version where if you were going to do custom development, you were pretty much stuck with writing .NET-Custom-Controls and all SharePoint did was act as a liability slowing you down in development instead of being this amazing portal framework that the Microsoft marketing folks were busy portraying it to be.
This gentleman, however, wasn't discouraged. To be fair to him; he was good; in fact he was great. He could do things with SharePoint lists that none of us thought made any sense to even attempt and he would get away with it; producing a new magic trick every time a road-block was showed up.
After a few weeks of prototyping, band-aiding and this expert of ours pulling magic tricks out of the his expert head, we decided to quit.
'Freakonomics' by Steven D. Levitt and Stephen J. Dubner co-incidentally of-course, describes what had gone wrong with us trying to implement SharePoint in that project. We, the allied relationship of the client and us, had relied on an expert, when the best interest of the expert was not aligned with our best interest. Both the client and development team wanted a simple maintainable ASP.NET web application; this expert on the other hand needed consultancy and dependence on him.
In their book Freakonomics; Steven And Stephen provide excellent explanations on what is wrong with working under the assumption that an expert will always provide you the accurate information and work for your best interest if you pay them. In the book, Steven And Stephen describe an experiment conducted to find out if experts always work for the best interest of their clients:
| Experts are human, and humans respond to incentives. How any given expert treats you, therefore, will depend on how that expert’s incentives are set up. Sometimes his incentives may work in your favor. For instance: a study of California auto mechanics found they often passed up a small repair bill by letting failing cars pass emissions inspections—the reason being that lenient mechanics are rewarded with repeat business. But in a different case, an expert’s incentives may work against you. In a medical study, it turned out that obstetricians in areas with declining birth rates are much more likely to perform cesarean-section deliveries than obstetricians in growing areas—suggesting that, when business is tough, doctors try to ring up more expensive procedures. It is one thing to muse about experts’ abusing their position and another to prove it. The best way to do so would be to measure how an expert treats you versus how he performs the same service for himself. Unfortunately a surgeon doesn’t operate on himself. Nor is his medical file a matter of public record; neither is an auto mechanic’s repair log for his own car. Real-estate sales, however, are a matter of public record. And real-estate agents often do sell their own homes. A recent set of data covering the sale of nearly 100,000 houses in suburban Chicago shows that more than 3,000 of those houses were owned by the agents themselves. |
The experiment involved measuring data and coming to a conclusion which describes why relying on experts may not always be the best way to gather information. Steven And Stephen explain:
| There’s one way to find out: measure the difference between the sales data for houses that belong to real-estate agents themselves and the houses they sold on behalf of clients. Using the data from the sales of those 100,000 Chicago homes, and controlling for any number of variables—location, age and quality of the |
In the world of software development, especially when you are responsible for picking tools, technologies, directions, trends to follow etc. for your organization and even for your own career, knowing three simple facts is important.
- You'll never be able to know or find out everything and keep it in your own head. You will have to use Transactive Memory and depend on 'experts' rather frequently.
- When you are building POCs, every tool out there meets your requirements; especially when you have an 'expert' who is convinced it does.
- When your best interest doesn't align with the best interest of the experts you are relying on; experts will cheat; most of the times they will do so unknowingly and subconsciously.
If there is one thing I've learnt, in my career as a software development it is this; don't depend individuals who are 'just' experts. If you must depend on someone for the choice of the tool, platform, technology, framework or information in general, depend on individuals who besides being decently good at what they do; are also individuals who can otherwise be defined as Mavens.
Malcolm Gladwell describes these individuals in his book, The Tipping point when talking about Mavens, Connectors And Salesmen. He explains:
| The word Maven comes from the Yiddish, and it means one who accumulates knowledge. In recent years, economists have spent a great deal of time studying Mavens, for the obvious reason that if marketplaces depend on information, the people with the most information must be the most important. |
Malcolm in 'The Tipping Point', while talking about one of the Mavens, further describes how these individuals, end up helping others by simply being themselves and indulging in their own nature of gathering, processing and sharing information:
| At one point Alpert launched into a complicated story of how to make the best use of coupons in renting videos at Blockbuster. Then he stopped himself, as if he realized what he was saying, and burst out laughing. "Look, you can save a whole dollar! In a year's time I could probably save enough for a whole bottle of wine." Alpert is almost pathologically helpful. He can't help himself. "A Maven is someone who wants to solve other people's problems, generally by solving his own," Alpert said, which is true, although what I suspect is that the opposite is also true, that a Maven is someone who solves his own problems - his own emotional needs - by solving other people's problems. Alpert is not, it should be said, an obnoxious know-it-all. It's easy to see how he could be, of course. Even Alpert is aware of that. "I was standing next to a kid in the supermarket who had to show his I.D. to buy cigarettes," Alpert told me. "I was very tempted to tell him I was diagnosed with lung cancer. In a way, that desire to be of service and influence — whatever it is — can be taken too far. You can become nosy. I try to be a very passive Maven... You have to remember that it's their decision. It's their life." What saves him is that you never get the sense that he's showing off. There's something automatic, reflexive, about his level of involvement in the marketplace. It's not an act. |
Anyone who has seen Life-Hacker, Scott Hanselman's Tool List, Scott Guthrie's direct and straight forward elaborate posts on technology Microsoft is working on or seen Rory criticize Microsoft when they make lousy mistakes, while retaining his full time job at Microsoft, knows what Maven-ship is; of course there are countless other examples of true and genuine maven-ship out there.
If you look hard enough for Mavens who are genuinely trying to help by collecting, processing and then distributing accurate, honest and true information; you will find them. Another way to spot them, is that unlike experts, who primarily work on information and see all information that benefits them as 'good', Mavens have an ability to form strong personal opinions about information they gather.
Pick a few Mavens; follow them through their blogs or website for a few months; see if your opinions align. Scrutinize their posts. Are they are making the right judgment calls that work for you most of the time? If your answer is yes for a particular Maven, you can use his knowledge or effort and make it a part of your own 'Transactive Memory'.
Months ago, for example, when I was asked to go looking for a static analysis tool to suggest at work, the nDepend official website was not the source of information I wanted to base my judgment on; I had tried the product and was happy but with; but when a third person who I know to be an honest maven talks about it and helps me get started on it, that is often the personal tipping point for me; something that results in a buy.
Coderush is another example where multiple Mavens have got me introduced to the product without any hidden interest or incentive; ultimately resulting in me recommending the buy and a license getting purchased.
The list is endless but what is common in the list is that I would say I've never been disappointed with any of my purchase, downloads, recommendation-to-my-organization or recommendations-to-a-client; when the information used for the recommendation, purchase or download was from a genuine Maven I already trust. That, for me at-least, speaks highly of the power of 'Transactive Memory' used correctly. On the other hand, any software purchase or download that I've done based on an 'expert opinion' has turned out to be a lousy decision more than once.
You can take an expert opinion; but the opinion would be correct only as long as the interests of the expert who is giving you the opinion align with your interests. When given the choice between the Maven and an expert; especially when you are picking sources for your 'Transitive Memory'; irrespective of how talented or awesome the experts you have access to are; don't depend on them.
Look for the quality of maven-ship in people instead. Depend on people who demonstrate that quality and then form your own pragmatic opinions based on theirs. I wish you good luck.
Comments are closed.