A Trace in the Sand
Online Architecture Journal by Ruth Malan
I also write at:
Trace in the
I joke about the volume of notes that amass here. Now it appears that my flood sketch last month was most unfortunately prescient! We spent the best part of a week on an idyllic nearly-deserted island off the Isle of Skye (Scotland). There we enjoyed mostly sunny days, though a drought threatens newly planted trees and is causing springs to dry up, while in England there was flooding; likewise back home in the mid-West. Even in Bloomington, IN, there were cars dramatically stranded in streets.
"What is more important today than ever before is the ability to synthesize the facts and give them context and perspective…What we want from people who stand before us and give a talk is to give us that which data and information alone cannot: meaning."
Garr Reynolds, Presentation Zen, 2008
6/16/08 Visual Thinking
Daniel Stroe pointed me to VizThink, which led me to a "The Back of a Napkin" podcast with Dan Roam (March 8, 2008)—jump to segment 3. I liked the point that by using pictures, we can reserve our words for conveying the insight, the "so what," behind the picture. I've been urging architects to use hand-drawn pictures/models/visualizations more (and scan them, or use a digital camera, for record keeping). This is both low overhead in terms of generation and upkeep, and conveys an informality that allows more openness to change and interaction over the ideas.
Of course, in our world we're often looking for more than polish in our visuals—we're looking for round-trip engineering, for traceability tracking, and ease of maintenance. But we should be looking for vehicles that help us gain insight into tradeoffs and their ramifications, to think through system decisions, get input and improve them, and explain, clarify, and transfer not just understanding but buy-in. If we say those are our paramount goals, then the space opens up and informally drawn models percolate up in importance.
Well, I already jokingly suggested IBM-Rational, Microsoft, Sparx, and whatever new venture wants to overthrow the incumbents, should look at model recognition (like voice and writing recognition), but I realize it's likely some are already on that path and it will be strewn with all the technology invention-adoption hurdles typical of industry reshaping innovation (what Bucky Fuller vividly called the new technology gestation rate).
6/19/08: It struck me that while we talk about "back of the envelope" calculations (because there's address and other stuff on the front), what is the back of a napkin???? Is this a striking and funny faux pas, or is this something the author recognized and played with???
6/16/08 Conceptual Distance
Charlie Alfred has finished his promised blog post on conceptual distance. It is so good to have Charlie back blogging again. The post is directly helpful, and set me thinking around the edges. But... more when I've caught up on all the loose ends that gather when away from connectivity and the office for a while.
6/16/08 Architect Humor
While I was working on London's Canary Warf a few weeks ago, Vincenzo pointed us to these classics of architect humor on YouTube:
Some people just know how to have fun! And the Brits have a great, off-beat sense of humor. One of the architects in Norfolk said "it's like wetting yourself when you have dark pants on; it feels good and nobody notices." How would he know that? But I'm sure it is appropriate to much of what architects do; certainly much of what I do! Anyway, it really appealed to Ryan's ribald sense of humor!
Well, I have to get my jet-lagged kids to bed; we got in after 4am yesterday, grateful to be only about 9 hours late. Our luggage arrived this afternoon, after Dana had to leave for Pittsburgh. And so it goes.
6/17/08 Shatner On Failure
Thanks to Grady Booch's heads-up, I watched William Shatner's talk on IBM TV and there is much there for architects! Software failure stories are just the beginning! Funny stuff: "changing customer demands—the idiots; poor management oversight—the idiots"... So are these pebbles others overlook, or are these the nuggets you'd pick up and take home too:
I was impressed by Shatner's story telling. No slides. No "objectives" or "this is what you'll learn" roadmap. Not on a slide or in so many words. But a clear theme—failure, and what you learn from it. Of course, it is hard to talk about personal failures. Especially hard for an icon. So there were points where Shatner's humanity leaked through: jibes at a producer, a little defensiveness with a quick antidote of self-directed humor (I thought that was my trademark). That humanity made the story, for me at any rate, all the more authentic and compelling. I hope you enjoy it too, for it is a powerful example of leadership by storytelling—sharing lessons and insights in a way that inspires a change in perception and action.
Following up, Grady quotes Walker Royce (September/October 2005 issue of IEEE Software, titled "Successful Software Management Style: Steering and Balance."):
"a software manager's day-to-day decisions (like those of a movie producer) are dominated by value judgments, cost trade-offs, human factors, macro-economic tends, technology trends, market strengths, and timing."
Sounds like an architect's day-to-day decisions to me... I wonder, is the architect more like a movie director or is the project manager more like a director? If the manager is the director, is the manager effectively the architect (a la Conway's Law)? The powerful effect decisions, and power is typically vested in the management tree, relegating the architect to cheerleading on the one hand, and the energy-sappingly endless necessity of relying on persuasion and influence to get anything done. Yes, the shovel and the rear end of the elephant. But it doesn't have to be that way, and Shatner is pointing to the key—organization. That is, what organizational partnerships are part of the structural fabric of IT or product development, and how we allocate decision responsibility. If we want to talk about the architectural competence of organizations (the topic of a workshop Dana is participating in at SEI this week), then we have to look at how power is distributed, who has (actual) authority over what decisions.
One approach to complexity is to "divide and conquer." Organizationally, this allows us to leverage specialization, but too often this results in island fiefdoms. The cognitive distance between specialties is further driven out and entrenched by political power mongering, especially when managers position themselves as gatekeepers to relationships and information flow among the fiefdoms. Architecture is the discipline that makes tradeoffs across the parts in the best interests of the overall system. Architecture allows us to create a system that is more than an assemblage of parts with emergent properties and integration by happy accident. It is the discipline that must make calls that compromise the individual interests of the fiefdoms for the good of the kingdom. Or whatever overarching organization is analogical to fiefdom. Anyway, architecture is the role that compensates for however the organization is carved up. It is the role that needs to have perspective or visibility and authority to make tradeoffs and decisions across the vested interests of the different organizational elements and the pieces of the system they own. It breaks down when the decision model is broken, so we really look at the architecture decision model that is in place, when we informally assess organizational architecture competence.
Dana Bredemeyer puts it like this: the architect must have access, authority, competence, and passion. Access to the sources that will inform decisions, authority to make decisions, competence to make good decisions, and passion or motivation to do what it takes. Motivation because it is their job; passion to go beyond "just a job."
6/17/08 More Golden Carrots
Well, well, catching up on Bredemeyer mailing list signups, I see that on May 26th Pete E. said:
Wow, I never knew that one word, "fantastic," could be so powerful! And twice in one month! I guess once I get the next executive report for Cutter completed (due August 18), I'll have something I want to push out to the mailing list. I'm always so careful about what we broadcast that way, that we're seriously overdue on sending out an update!
6/18/08 Doing the Right Things Right
Alan Inglis has a great post on the role of (enterprise) architecture in doing the right things right. Of course, if you've been following along, you know this is a theme I've been pursuing too; here's a sprinkling of entries along those lines:
Obviously everything I've written about the architect's role in requirements, is about doing the right things, and I'm glad to see others (Alan Inglis and Brian Sondergaard among them), making this case too! Dana got a wonderful email from Marco Salden debriefing his experiences with the front end of VAP and confirming the importance of these pieces, despite the push-back that one gets stepping into what is too often perceived as someone else's turf. Marco is urging us to do more in the area of domain/requirements modeling, and I agree with him (and Einstein) that discovery and structuring the problem definition is as important an architectural problem as structuring the solution.
Marco is another of those great Dutch architects. Dana and I both worked with a good number of great architects in the UK these past few weeks. There's a lot of good stuff happening across the pond from us. And on the other side of the globe. But at home, I'm gratified to see that even in tough businesses like retail, where the pressure to be lean is intense, architecture is really taking root.
6/18/08 Architecture Scout
While I was out-of-range the past few weeks, Daniel Stroe pointed to a number of other gems that I'm only just catching up on. These include:
I'm so grateful for my scout; thanks Daniel. (Usually I keep up with email correspondence while traveling, but in the Scottish Highlands and the Cotswold we were gloriously unconnected!)
6/19/08 Visual Thinking Revisited
Dana is just back from the SEI workshop focused on developing an assessment of organizational competence in architecture. As we are want to do, he used a flip chart rather than slides for his presentation. Because he was the only one to use the flip chart, the key models we talk to stayed up for most of the workshop. This had the neat effect that the models were on view for all to refer back to, becoming beacons and touch-points for work that was done. We rely so much on electronic media, we forget the value of paper. I feel bad about that use of trees, like I have to do penance (a la Yvon Chouinard and Patagonia), but we also have to balance this with human effectiveness, and there is a strong value to being able to tape up the key models and keep them in full sight. No doubt you remember I harp on about The Wheel, especially chapter 3. One of the nuggets there: the vision picture is placed where the team can see it all the time.
And the other side of this coin, is the value of organizing models. I always feel much more confident facilitating a session with architects if I am prepared with some organizing models to focus discussion and elicitation. Either that, or I want to be background (not facilitating/foreground) while I discover the organizing model that elevates data to information to wisdom/insight/inspiration and action. Sometimes I can create the organizing model on the fly while facilitating, but it is a processing overload on complex channels of thought and visualization and I'm not good enough at that to be confident I can always pull it off. For many purposes, I have my toolkit of usual suspects—competitive landscapes foremost among them, just because groups are, by and large, so shaky without any shared ground under their feet. And all the strategy, scope, architecture, role, and so forth models that are our hallmark contributions in this architecture space. But fortunately my clients also ask me to grow with them, and that means new territory to facilitate. New models that need to be developed.
6/19/08 More SEI Workshop Stories
Dana came back with a neat story. The group was walking to a micro-brewery for dinner. One of the hosts led them on an expedition through the urban jungle, on a windy route that went through shady neighborhoods and, looking for another short-cut, they took an old, over-grown stairway that wound down, down and then back up, up... back to a point on the route they'd already traversed! Dana's actually one of those guys who breaks the "men don't ask directions" stereotype, but he has the usual tech-toys so he could just ask TomTom, and they made it to the church-converted-to-brew-pub. Fun, and in a group, no real danger to persons. But isn't that just so poignantly like the norm in software development? Someone has a destination and vague sense of direction in mind, and the group willingly puts themselves in his hands and takes a winding route, getting into the general spirit of the adventure, looking for short-cuts that lead through areas of uncharted risk, back tracking, ...
Sharing memorable snippets, Dana also reported that when someone said an architecture effort can be divorced from reality, Paul Clements quipped "reality doesn't pay alimony." Funny and insightful. Paul has strong and likeable qualities.
Dana enjoyed working with the set of SEI (Clements, Bass, Kazman, Klein and Klein among them) and industry/government architect practitioners, all of whom are very smart and have been paying serious attention to software architecture over the past decade or two, yet have distinctive and complementary insights to bring to bear. And it is rewarding to be recognized by your "competitors" in the architecture arena.
6/20/08 A Physicists Insights Into Human Nature
Surely You're Joking Mr. Feynman went with me on my travels last month because I wanted to find a passage about context that I use in workshops. It came back still crackling new. Actually, that's not so bad; you see, when Dana was listening to the audiobook (during workouts and flights) some years ago, he'd recount the stories to me; and he's retold many of them again since. Dana is a great storyteller! Then, I listened to (most of—my trip wasn't quite long enough) the original myself. Why do I say all this? Because when I was putting the book away, it fell open on the safecracking section and I started to read. And despite my many encounters with the stories therein, I was again absorbed by it, and struck by Feynman's canny understanding of humanity and especially how we solve problems. Since my current kick is that actually solving hard problems has much to do with our approach to defining, and our definition of, the problem, it set my sensors a-twitching.
Yes, I too collect and retell stories. I try to demonstrate the tools of leadership. And that I succeed at all, says volumes about the effectiveness of the tools because I am at a strong disadvantage when it comes to stepping in as a leader in a workshop setting. Mostly, I'm an unknown. Even if the participants are familiar with the Bredemeyer site, they don't know how much of it is my work. Then I have a quiet South African female voice. Not exactly the (stereotypical) voice of authority. So I have to build from a starting point of incredulity rather than a platform of credibility. To have highly talented, competent architects like Brian leave the workshop full of energy and wishing all educational experiences could be so rich, is highly rewarding to someone like me, who is, in some senses, poorly equipped by nature to deliver such an experience. But that is the point: we all have our weaknesses and our strengths, and following VAP allows us to flourish as leaders and allows our teams to flourish as contributors to something that is bigger than what they could do on their own.
The snippet at right is from The Art of Richard P. Feynman: Images by a Curious Character (p. 21, 1995). Actually, Feynman does a good job of teaching through stories how to go about solving problems!
Feynman recognizes that one way to help people learn, is to create a crucible for outcomes, and that approach is especially fitting in an area that is not formulaic. And isn't that what we want to do, leading system development: create a crucible for outcomes?
Notice, I'm leery of saying desired outcomes, because that is itself an area where the astute learner is open. Architects come in to workshops expecting something, and based on that expectation state their desired outcomes. At the end, many have said, "That wasn't what I was expecting. It was much better." Challenge to those who have a strong sense of their abilities, invigorates and stimulates growth; to the weak, it is a threat.
Alas, we don't own the book of Feynman's art.
6/20/08 How to Disagree
I read Paul Graham's essay titled How to Disagree. He also has an essay on procrastination. Ok, Johnnie Chung Lee's blog is called procrastineering (you no doubt know Johnnie is the prolific inventor of such innovations as the wiimote interactive whiteboard and steadycam). In Johnnie's self-professed case, procrastination, succumbing to distraction, is profoundly productive. So, where does this instance stand on Paul's disagreement hierarchy? Of course, I'm just being defensive because I had to be procrastinating and surfing to stumble on Paul's essays. Defensive. How does that relate to the disagreement model? And questioning?
In short, I'm asking: Does that mean two axes are valuable: emotional stance, and content?
Is that disagreement, qualified agreement, or collaborative engagement?
Playfulness aside, I'm happy that someone of Paul's stature in the industry is working in positive ways to encourage more civil behavior on the I-way.
6/20/08 Happy Summer Solstice!
6/20/08 Randy Pausch's Message
It's not the things we did, that we regret on our deathbed. It's the things we didn't do.
Find your passion. You will not find it in things. Your passion must come from the inside... It will be grounded in people, and what they think of you.
There are two thrusts: minimizing regret by doing the big things we dream of, and doing what we do, well. So well, we surpass others, earn the respect of people we respect, people in our field, and people we love.
Randy Pausch has done something amazing—he has made our mortality, and the meaning of our lives, discussable, because he sets a great example of facing life full-on, no whining, but with humor and a keen sense cleaving the pith from the distractions of life. The importance of getting clear with ourselves what our personal mission, or passion, is. Now, if I was facing death and had not written a novel, I would regret that. Given that this (my journal, the Bredemeyer site, and helping architects) means I'm not doing that (writing a novel), it had better be worthwhile! Earn the respect of people I respect.
Oh my goodness! Put like that... that dandy exit shot comes to mind...
Just kidding. The mission I've set myself is to make a difference in the system development world, the architecture world, because that is where my combination of creative draw, analytical bent and software development background come together, and because I am so, so excited about this field and about innovation and technology, even with all the caveats. But it does make me realize that since this journal site is the place where I am exploratory and experimental and reveal some part of my creativity and intellectual journey, it is where I most value positive reaction, for I most care about impacting creative, investigative, smart, multi-dimensional people. People who get that the photo in my footer this month is poetically rich with visual metaphor; people who get that reflection is a design mechanism, but there is more to system development that is exciting. Creating value is at the heart.
6/21/08 Predicting the Future
We went kayaking on Lake Monroe today, and it is high—like kayaking the Everglades, at least to begin with. Those trees are more than paddle deep in water!
Along the lines of "this road ends in water," this one really does. Usually. But now it does so much earlier.
Ok, so just what about this likely future was hard to predict? You see the road signs. You look at the evidence around you. You make a judgment call. And drive in anyway?
Unfortunately I only had Sara's camera with us, but the photo is still eloquent. I can see myself using this one on a project at some point. Alas.
Applied right, this Alan Kay quote is powerful:
"Don't worry about what anybody else is going to do. The best way to predict the future is to invent it." - Alan Kay
But not thinking things through some, can get us to that "what was I thinking" point where a "fail fast, fail often" principle is not much of an excuse!
Ah, the power of projection, and of common sense.
6/21/08 Is or Is Not; Scope and Beyond
Charlie Alfred has another great blog post titled Is, or is not architecture. I like the "4 b's" of architecture:
"being, behaving, balancing, and becoming"
Challenging and thought provoking. Thanks Charlie!
Now... it's late... Tonight we saw Prince Caspian (disappointing for us, as we loved the book but perhaps we'll grow to appreciate the movie in its own right). And last night we kept the kids up until midnight watching the moon come up over the lake.
6/28/08: And it wasn't even man's first foot-steps on the moon! We also believe very much in that
"Fuel your kids' dreams, too. Once in a while, that might even mean letting them stay up past their bedtimes." Randy Pausch, The Last Lecture, 2008
In part, we think that means fuel your own and your kids' imagination, and sense of awe, by seeking those moments that set you outside yourself, breathless with wonder. So, once in a while that does mean staying up past bedtime. Sharing the extraordinary events of a lifetime, but also looking for the extraordinary in an ordinary experience.
6/23/08 Leading By Example
Just in today, another Resources for Architects mailing list signup featuring that "fantastic" carrot:
"Your resources are fantastic. I look forward to seeing more."
Thanks for the encouragement Peenak.
... There's no way that referring to these pieces of feedback from our signups is influencing anyone is there?
There's not a lot of cross-over from the Bredemeyer site to this one (80% of visitors come here directly, not via a link or a search, indicating considerable loyalty but not much advocacy for this site on the I-way). Still, the Resources for Software Architects (Bredemeyer) site is one site that does refer here—no surprises there.
6/23/08 Business Architecture
There is anenterprise architecture discussion group on Google Groups.
6/23/08 SOA Impact
Craig Jordan has influenced and stretched my thinking in the past, and recently he very kindly shared his notes on the interactions/impact of SOA on the Software Architecture/VAP course material. Thank you Craig! I've been going through your notes, and the input is very timely. No one has done that before, and it is very stimulating to have that level of engagement, input and, at times, challenge. I love challenge, especially when it comes with sincere goodwill and good suggestions.
Whenever I go into the SOA space, I'm reminded that much that is valuable to say there has to do with lessons that are just as pertinent to the product family/product line case, or what was known as "reuse." Some architects, like Rob Seliger, objected to this even in its heyday, preferring to call it use rather than reuse, and this is what we see with services—we use services in different contexts. Anyway, this drives many of the considerations that we need to take into account as we design an SOA and it's services.
6/24/08 Visual Architecting
In workshops I often quip that a picture is worth 1000 words, but only 1000, and we need to use words to fill in the thinking that went into creating the picture or model. It is worth emphasizing that in documentation, both are very important. Some people are more skewed towards visual processing, some to more verbal processing, so a balance takes into account the diversity of our audience. But regardless, heavy reliance on one or the other (all visual models and no explanations, insights, experiences, rationale, caveats, assumptions, etc., that are conveyed in words; or all words and no models that integrate and relate information so well) misses conveying key, complementary, information. Besides, a document with all, and only, the right words tends to be bland. It is important to create compelling documents, for no matter how much content the document contains, it is worthless if it is not read with engagement.
But visuals aren't just for presentation and documentation. They are for getting essential work done. Graphic templates and models are great to facilitate group work, creating a shared thoughtspace that stimulates collaboration and creativity, for example helping to surface diverse, sometimes conflicting, assumptions that would otherwise become roadblocks at some point if they weren't raised and dealt with. Using graphic templates (models and conceptual frameworks translated using some visual metaphor into a structured brainstorming/elicitation aid) and system modeling (informal like rich pictures, or more or less formal use of UML, for example), transforms a "meeting" into a collaborative team working session. Meetings that are just talk are too often undirected and so end up predictably not reaching a satisfying destination. You should still do the usual meeting effectiveness stuff around explicit desired outcomes and tracking/tabling issues, risks, and ideas, of course. But the focus is on getting work done in a format that fosters creative engagement, and a side-benefit is creating work in a directly communicable form (using a digital camera and your project wiki) that is interesting and evocative. And then, you have to add the words that create a record of the thinking, discussions and experiences and explanations that happened dynamically in the meeting; the words that allow the visuals to stand alone, without you being alongside to explain and defend them, share insights, and so forth.
In short, models are better than code at creating understanding of the system in big picture terms, or to reveal the design of a mechanism especially when multiple components collaborate to implement the mechanism, and so forth. But just like code, models don't stand alone without accompanying words to make the intent clear, to make the assumptions and context clear, to defend the chosen path and explain why alternatives were eliminated.
6/24/08 Navigating The Information Explosion
I was asked how I stay current on trends. That was transparent flattery, of course, but a kind gesture nonetheless. Still there's so much to keep up on, just having a good "sniffer" for relevant and interesting trends is a developed art! And it is worth thinking more self-consciously about how to develop it.
"What information consumes is rather obvious: it consumes the attention of its recipients. Hence a wealth of information creates a poverty of attention, and a need to allocate that attention efficiently among the overabundance of information sources that might consume it."
Herbert Simon, Computers, Communications and the Public Interest, pages 40-41, Martin Greenberger, ed., The Johns Hopkins Press, 1971
So, it set me thinking—even long after I responded. My initial thoughts were along the lines of who I trust to broaden my awareness, and certainly my (with an emphasis on the possessive in that pronoun) scouts were first to come to mind. I'm in the very fortunate position of having a number of people who have taken upon themselves a good part of the care and feeding of my mind; Dana foremost among them. I guess I'm a maven (in the Gladwell/Tipping Point sense) who collects mavens!
Which reminds me—the architects I was working with this past week joked that for them it's not the tipping point, but rather the kicking point that launches adoption. But they were only half joking, because they combine a serious emphasis on "socializing the architecture" (through a slate of techniques from active participation in the creation and assessment of the architecture, walking the talk, mentoring and training where needed) with that "kick."
In part, I have a very broad base of interest. I scan broadly for material that stretches my thinking and understanding of architectural effectiveness. For example, I don't filter by formal publication standing, whether industry-facing or academia-facing. This is because I recognize that the people who may know the most about something I'm likely to be interested in (e.g., principles and mechanisms from a high-availability architectural style) are too busy to be publishing in formally recognized arenas. For the most part. So, aside from the great architects I'm so fortunate to get to work with, there's blogs, news and community sites, and subscriptions to the likes of Harvard Business Review, Technology Review and Wired. These point both to experience and to interesting events and trends that could, or are, reshaping the competitive landscape. But there's way more than even an active scanner can get to, so I develop a set of blogs I visit on an irregular basis (my bandwidth is not consistent) because I trust the author will be interesting. Which reminds me I haven't updated my blogroll on my TraceInTheSand blog since I set up the blog, and it is not reflective of the blogs I follow. At any rate, I scan broadly and read acquisitively, meaning I engage with and integrate what I learn.
I am an inquisitive and (generally inwardly) contrarian person who questions and engages with everything that interests me. So, I get interested in business intelligence because I think it would be too bad if business intelligence was relegated to compensating for data silos; in the same way that it is too bad if "integration" (the other focus of this compensation) simply means stitching together workflow elements rather than supporting flexible (re)design of business processes. Ok, so business users have been creating integrated views using spreadsheets to support business analysis and decision making for more than 20 years, and there's opportunity to be more effective. But it would be unfortunate if BI was defined by the latest buzzword painted on the tool de jour, like a tool to manage balanced scorecards. Yes, scorecards should be watching the interim indicators that shed light on the path to the ultimate objectives, dynamically integrating data to keep these indicators up-to-date on a dashboard. However, in good part, I think BI means "how do we make sure we are doing the right things?" at least as much, if not more than it means "how do we make sure we're doing them right?". So I'm interested in system health (business system and information system) and I'm interested in business events and patterns, and in the bigger questions that help me think about what events and patterns would help signal right things to do or when changes in course are indicated. So I'm interested in EDA as a technical way to do that, but I'm always first interested in right system, before I'm interested in built right. In short, what will BI be when it fulfils the promise in the title? What does it mean to go from information to intelligence, and how do we get there? What is our vision? And what are our first steps?
This engagement is in good part what makes me shy away from the Kindle—I view all the notes and questions I write in my books as "intellectual property" and I don't want to keep that in a format that only Amazon owns access to. If my perception is wrong, do enlighten me, because the paper-free book has appeal in an age of being careful about killing trees.
On the subject of books, I spend a lot of time in bookstores, because I like to follow my interest through sections of material and if I find I've squatted and read 15% of the book in the bookstore and there's still more I want to read, or I feel an urge to deface the book with my highlights, thoughts, questions, extensions, images and mini-models, then I buy the book and pursue it until my interest in it wanes. I get through all of a good number of books, but I don't feel bad if I get part way through and find my insight acquisition rate has tapped out and my interest is lost—then I scan ahead in case the author just hit a dull spot, and if I find nothing there for me, I drop it. With The Tipping Point, for example, there were times when I thought Gladwell was simply being self-serving and I'd jump ahead. So it must be with this journal. If you read every word, these words, you have to question your ability to Pareto. Just kidding. Those were the most important words, but how would you know unless you'd read all of them? Grin.
For my flight home from Houston on Friday (just a 3 hourish hop), I picked The Last Lecture and The Translator. Both are emotionally challenging! As I read about Randy Pausch looking around the doctor's room and noting there's no Kleenex, I was realizing I had none! In Indy, for the first time, someone came up to talk to me about the book I was reading while waiting for my luggage to show up. Randy Pausch has reached a demographically diverse set of people because he shares his lessons in a delightfully candid, but not self-pitying, way. And his lessons are relevant! I mean, here is the ultimate software geek, leading a world full of people through the most challenging questions we can face—what is the meaning of this day, if it does not add up to a meaningful life? The meaning is in the lessons we learn and the lessons we share, the value we get and the value we give.
Now, I realize that a recommendation from me is not going to add to sales of this book. According to the Amazon stats, The Wheel on the School has been looked at 40 times in the last 6 months based on my persistent insistence that it is the best book on the creation and role of vision I've seen (and I've read more than most professed experts on the subject), and only 1 of those turned into a purchase. The Leader's Guide to Storytelling got 35 peeks and 1 purchase. Either Amazon is not the place people buy their books, or they're not taking my recommendation as seriously as I think they should! Ok, so clearly it's not the former. I'm not trying to sell books (I would be much more effective if I was), but it is a barometer of influence. Ok, let's reframe: that I got 40 adults to look at a kid's book is astounding! That they didn't follow through is perplexing. Clearly, whatever else I am, I'm not an intellectual snob—I'm willing to learn from, and promote learning from, children's books! Well, actually, maybe I am a kind of snob. I think openness to surprise and delight is an important quality... It is quite interesting to see that of the 1,100 unique visitors to this site each month, at least a couple come because they used a search phrase associated with Bud Not Buddy. Which increases the stats on people who immediately leave. I reference Bud Not Buddy because it has one of the most fun illustrations of the use of principles around; I also point architects to Yvon Choinard's Education of a Reluctant Businessman, because it demonstrates leadership through principles so well. And, returning to children's (award winning) literature, in Walk Two Moons there's an absolutely classic piece on agendas:
"When I told them about the message, Everyone has his own agenda, Gram thumped on the dashboard and said, 'Isn't that the truth! Lordy! Isn't that what it is all about?'
I said, 'How do you mean?'
'Everybody is just walking along concerned with his own problems, his own life, his own little worries. And, we're all expecting other people to tune into our own agenda. "Look at my worry. Worry with me. Step into my life. Care about my problems. Care about me."' Gram sighed.
Gramps was scratching his head. 'You turning into a philosopher or something?'
'Mind your own agenda,' she said."
from Walk Two Moons by Sharon Creech
None of these reveal trends, but do demonstrate how keeping a broad radar puts some pretty cool tools on our architectural leadership tool-belt. And Randy Pausch's book does that, and more. Despite its small package and quick read, it packs a surprising wallop in terms of lessons from a strongly acquisitive learner who has played a leading role in shaping dreams and dreamers, and who will continue to do so thanks to his book and his legacy in applied computer science, virtual reality and animation.
6/30/08: I was having lunch out today and overheard the guy at the next table tell his colleague that he has decided he must make more time to read, so he'll watch less TV and clean his toilet less often!! I kid you not. And his colleague didn't even chuckle!
As for me, I was thinking about axing the piece above (too many "I"s in it), and then I decided it probably has a lot of value, for it says how to avoid being like me! Whatever you do, don't break down and read the children's books I point out! (Nor for that matter, the books "for managers" like Guide to Storytelling or Reluctant Businessman.) Then again... I feel like I've looked to the bottom of Pandora's box and found the word "hope," so forgive my persistence in coaxing and cajoling, nay browbeating, you to let a little of the delightful yet canny clarity of books written for tomorrow's leaders help you lead today. I know, I know, if I hadn't read these with my kids, I'd think "if I'm going to push aside my collection of software, strategy and leadership books to read a novel for a change, I'll read one written for an adult, thank you." But at one workshop one of the architects noticed a note below one of my slides quoting Bud's Rules and Things; it's a fun illustration of using principles to crystallize experiential lessons to address key goals. He brought it to the attention of the class, telling them he'd listened to Bud Not Buddy on his commute to/from work and highly recommended it. So another of the architects (with kids all grown up and past the Bud-reading age) went right out and bought the audiobook to listen to on his drive back to Canada! I highlighted that these were men, because there are people out there who would discount my advice as a mom thing; I don't mean you of course.
But, in truth, I read highly selectively; for joy in learning is a paramount driver. You, in reading this, I have to wonder about, for clearly I am not nearly so selective in writing as I am in reading!
Well, it's the end of June and no-one asked to see more of my archman sketches (of course, I added some anyway). Sigh. I guess I'm the only one who's taken with my box-and-line-drawing character (you know, archman—a derivative of conceptual architecture; it's not "a stick-figure-because-I-can't-draw-people" thing!). Oh well... Action Guides. I think I'd better focus on Action Guides. People ask for those. But just think, when archman is famous, it won't be because you encouraged the development of this fledgling character. What an opportunity missed! Grin.
[7/5/08: A Wheel story—at a Software Architecture Workshop last year, I didn't want to read chapter 3 because we already spend more time on Initiate and Gain Commitment than the average architect is comfortable with. So I asked someone to volunteer to read it during a break and report back what he learned (as is common, I was the only woman in the room). As I expected, the architect who volunteered right off was the architect most "there" in terms of being the lead architect for a product family at a Fortune 10 company—he was already leading in a role where the scope of influence is broad enough to mean if you want to get anything strategic done, you have to be seriously good at leading through inspiration, influence and action. A good ploy, because then I had the most respected architect in the room recommending chapter 3 for me!]