A Trace in the Sand
by Ruth Malan
What's a Trace?
For those new to my Trace, be warned, this is "different"... It is a dynamic trace of (part of) my exploration of topics and content I relate to architects architecting architecture of various systems including software-intensive, socio-technical, systems of systems, and enterprises. I share the thoughts that these encounters touch off in me, as well as the places I go (references and links), in the hope that you will find my investigation and insights useful, even though they are jotted in the style of a journal which is suffused with my distinctive personality. That is, after all, what you get when working with a person, so why not when reading their journal? It makes things "interesting."
Please join us in exploring the monk and the mountain problem and discovering what it has to teach architects! Ok, I fully realize that it kind of puts people on the spot to answer a "puzzle" out loud in public, but the neat thing about the monk and the mountain problem is that those who answer true and those who answer false all add tremendous value to the discussion. And this (like the others, hopefully) teaches (or re-emphasizes with new nuance or reinterprets in the context of architect mastery) some very vital lessons.
3/3/13: Anyone else with courage and generosity here? Hm? Hm? Just Peter Bakker? If you have any ideas or are just not seeing it, jump in and say so. Your reaction is important to making this work. Ok, folk. This is "the ask." Collegial style. ;-) The main thing is, the more takes at this the better, so look at the problem statement and tell us what you think. Look at the answers so far, and see if that changes how you think about it. Etc. Just join in. That is an important part of this. Risk. We have to take some. In this case, take safety in knowing that whichever way you go, you are teaching us something valuable. Seriously.
3/4/13: And to move this forward, if you have seen this before, tell us what you thought when you first saw the problem, and what convinced you.
3/5/13: A big thanks to Gene Hughson and Stuart Boardman. Peter and I were feeling pretty alone out on that limb. This is getting interesting, isn't it?
It'd be super to have some new faces to the party too. We don't want to keep all this fun to ourselves, you know.
Celebrating Joy and the Creative Impulse
After: It definitely had its moments. But, to me anyway, moved too ponderously between them. The story is one of change too sweeping to stick especially with an out of touch, inward-looking (symbolized as incestuous) leadership (vacuum)... So it is a story of a turning-point moment in history that then came unraveled in moral striving compromised in the messiness of humanity -- even as aspiration shapes intention, the messy conflicting pulls of the human condition undermine and subvert. Still, though the changes Akhnaten introduced didn't stick, it laid the seeds of monotheism. As for the production, there was lots of potential, realized fully in moments, and in good degree throughout. But generally the supporting cast didn't seem comfortable in the "bodies" of those they portrayed, though some exceptions stood out. I did really like the countertenor paired with the mezzo of Akhnaten and Nefertitis.
The point isn't the specific politics (at least, that's not why I'm quoting it here), but rather the broader point about leadership and teaming:
And then there's Click... the book. (Here's a summary -- caveat: I haven't read the book.)
Dana Bredemeyer and I did a quick brainstorm on authors that were foundational in the systems area. I'm (in the process of) adding an influential book or two from that author, to give a sense of the work.
Paradigm Shifts and Social Evolution:
As it happens, in our case, the foundational classics are in our attic library (way up in the clouds).
Anyway, please do send me your list (or delta off the list above) of what you think are the foundational classics. :-) Thanks!!
Oh, yes, Dana was rushing off just then, so I still have lots of other ground to cover. We just started with systems science. For example, I'd want to add David Bohm, Arthur Koestler, Herbert Simon, Chris Argyris, Gregory Bateson, Margaret Mead, etc.,
3/15/13: This, via Daniel Stroe, is a neat piece on the (yes!!) mother of Chaos Theory:
A few years ago we watched Jim March's Lessons in Leadership from Don Quixote, and I was so excited by it that I have shown or recommended it in various leadership workshops.
Tonight we at last got around to watching this (can't explain why not sooner, really), and it is thought provoking: Stanford Professor Emeritus James March's "Heroes and History: Lessons for Leadership from Tolstoy's War and Peace".
Image source: James March's "Heroes and History: Lessons for Leadership from Tolstoy's War and Peace"
This second of Jim's movies on leadership has somewhat the same style of debunking the myth of heroic overblown leaders. The flaw that I see may be because I don't believe in inhumanly great leaders or single simple arcs to historical narrative, but I have to remember that I am a child of a moment in history (when we have learned much, including from Jim March) as well as flawed human being well set up to feel empathy and compassion for the flaws and foibles, the striving and the foils of multiple interacting threads of events and relationships... At any rate, I think it is a movie well worth working out to, so your time investment does double duty. ;-)
If you're left wondering, go back to our paper on Fractal and Emergent for an approach that doesn't dismiss intentionality but recognizes and embraces emergence. I think James March would learn a lot from Malan and Bredemeyer. don't you? Oh come now, that's a playful wink.
Jim March does a nice job of making beauty focal. I loved the line about the beauty of mind.
I've long been an advocate of hiking meetings and when the weather is good, a cross-country ramble or run is our preferred workout. We also watch movies and video tutorials and lectures, etc. while we work out during the winter.
What's that about capabilities and social networks? Well, did you watch the video?
I often credit Maria Popova for a reference, so hopefully you are following her. She brings all manner of "interestingness" to view -- helping "people to see" and serving Serendipity to us. She characterizes herself as a curator, and I think she is, importantly, a celebrator, for it is in joyfully pointing out that she helps us to see and become interested in a work on innovation/science/technology, or art/beauty/love or human interaction/dynamics and so forth. She defines herself as an authority by noticing and declaring the beauty and greatness -- the unique and outstanding contribution -- in the work she is celebrating and drawing attention to.
This past week she has several times reiterated pointers to a set of works on love. I especially liked this line:
Not architecturally significant? Being as fully human as we can possibly be, is architecturally significant! If you won't take it from me, go back and listen to Jim March. ;-)
And this, right on time:
Being kind in how we see other people is expansive. It creates possibilities by magnifying rather than contracting -- creating increasing marginal returns to complexity in a world where that usually goes the other way! That is a strong assertion, and by all means ask me to explain how I see it to be so.
3/5/13: Sara plugged her iPhone into my charger and it beeped on with this background: "Don't go to bed angry. Stay up and plot your revenge." You could see that as sinister and dark, or a sparkly bright sense of humor, well-tuned to the paradoxes that anthropomorphise Life as witty Jester. So much is in the stance of the beholder. I think it takes a lot of trust and courage to be who we are (exemplified by Amanda Palmer), expecting others to be as positive about us as we are about them. And it takes a lot of heart to behold our own self with a tender sort of humor.
Why do we stuff others into the confining Procrustean frames of our own small conceptions of them? If instead of seeing a person foremost as flawed, we acknowledge they are juggling all manner of forces and floods of feeling and the tears of the human predicament, of mortality, the seasons of life, the flows and confluences of relationships, so we are freed to feel empathy and compassion but more, we see them for the great they are and are capable of. Then the version of them that we hold in us magnifies them, and that is empowering and enabling to us and to them.
If I write about relationships, even love, in an architecture trace (for crying out loud Ruth, what are you dragging us into??), we could view that as "there she goes again, dealing with mush and not the hard technical stuff we really care about." Really care about? Really? Why? Because it is a job, just a job, or because it enables something great for people you work with and among -- people you care about? People you want to help thrive? What we care about draws us towards a greater possibility, a possibility we want to shape and reach for, work for, help each other attain.
Leadership is about seeing a need, something that is wrong in the world that we feel passionate about changing. Because we care. Not about our own reputation or creating a landmark in history, but because there is a difference that needs to be made in the world. An artist creates meaning and helps to shape thinking, and so can forment change. But a leader cares enough to see clearly and articulate what needs to change, and sets about seeing what is possible, and helping others to see and shape that possibility, and make it so. Yes, yes, incrementally and adaptively, reshaping the possible as more is learned.
On Technical Debt is shaping up to be quite interesting. They went to the source for the kickoff:
Putting my understanding of Ward's point into my own terms, I'd say that technical debt comes from trading technical learning* and code design improvement for market learning (getting features into user hands to improve them) and product design improvement, in order to gain shorter time to value, and time to market advantages (such as network effects and switching costs) over slower competitors. Other market timing factors may play a role, such as significant trade shows or meeting holiday market windows. For a start-up or small company, creating cash flow can be make or break, but even in well-resourced companies management and investor patience may run short, or their risk sensors may be triggered.
We can generalize that to trading structural integrity for product design improvement and time to market gains, but we have to realize two things:
So what we have called "technical debt" is weighting product learning and market timing over, or at the expense of, structural design learning and improvement of structural integrity. We focus on adaptability factors like understandability, modifiability, etc., but these impact other dimensions of structural integrity (kludginess erodes cognitive traction which erodes not just development speed but also reliability and other factors) and downstream market timing (due to decreased adaptability). [Again, technical debt discussions tend to focus on properties of the code as opposed to properties of the system in use and operation -- that is, development-facing properties with consequences for development/evolution costs. But these impact user or operator facing properties (otherwise known as runtime qualities); kludginess bleeds through in various faults and vexations.]
While conceptually we might distinguish between "messes" resulting from intentionally choosing market/user-facing design learning over code learning and improvement, versus the messes that are unintentional (we don't know what we don't know, etc.), this is a hard line to draw. If the code is sloppy because we chose to focus on the market, or if the code is sloppy because we're just in the messy part of the technical learning curve (new technologies, inexperienced team, new domain, whatever), or we adopted a strong YAGNI/just do it ethic with pressure cooker commit deadlines, or the code grew beyond cognitive bounds, yadda, the sloppiness becomes a burden we have to invest time in to rectify. Which is why, I think, in general parlance, the term technical debt has taken on the broader form of kludgy code and "entropy." It is a borrowing of resources that should be spent on code integrity now (to achieve an "industrial-strength" sufficiently well-engineered system), and spending those resources instead on (in the best case) product learning and elaboration but at least revenue flows. But the borrowed resources (time) have to be paid back later with interest -- at a compounding rate -- on restoring the system to a state of sufficient code integrity. In Fractal and Emergent I argued that we seize opportunity earlier at the cost of opportunities later. We want to do some of that, but not to the point that it is debilitating and ultimately undoes any and all gains we made from being quicker to begin with.
Our conversations around technical debt tend to focus on interest, but we need to notice when seizing opportunities now, comes at the cost of entanglement and inertia that mires and impedes opportunity taking later. We don't want "interest" on technical debt to mount to the point of stressing the system, including the development team. Opportunity cost is wickedly hard to even notice (when it's still an opportunity; we notice when we've lost ground in the market). The trick is to balance market, operational and technical design learning, so that we're improving fit to need (even as the market/ecosystem evolves, reshaping needs) and internal design integrity and sustainability (adaptability and responsiveness to evolution in the larger (eco)system context).
One might say "to its bootstraps."
We also need to ask if there is a better way to proceed, so our debt levels are reduced with a more effective learning process and creating more balance between investing in market learning and structural integrity.
Michael Feathers is a go to authority on the topic of legacy and refactoring, but I'll presume to paraphrase at least an introduction to his point, as it threads into and informs my thinking here, and extend it. By nature, the state of the code erodes over time -- the growth process of software itself leads to much moreness and the wash of time to obsoleting assumptions, muchness obfuscates and expediency suboptimizes and software just ages into decrepitude which we call technical debt (or entropy). In this view, wear and tear is normal -- that is, it is to be expected, for software development is an organic process, and organic things grow bigger over time, then age and die off, and are (or would be, if we did organic right) replaced with new.
Over time, we accommodate the architecture to additional, new, emerging, changing, revised, etc., requirements. As we add new features, where do we add them? Well, it depends. On? Are the alternatives evident and easy to decide among? [It is interesting to consider how similar the results of the hip surgery study in Dan Ariely's "Are we in control of our decisions?" TED talk would be to a study of design decisions like whether to add a method to an existing class, to add a new class, to refactor in the light of the new functionality demands, etc.] This is not just a question of whether explicit architectural design is a do once upfront sort of activity. Even if we have (a) talented architect(s) (paying attention to the system design) and ongoing attention is paid to architectural evolution and discipline, dependencies and entanglement is a tough problem. When design decisions have become entangled with too many other design decisions (explicitly made paying attention to desired system properties or implicitly made during implementation), it becomes hard to rip them out (altogether to simplify by getting rid of obsolete functions, or to replace them with a more effective design given emerging requirements and evolving code and production and use contexts). So the complexity deriving from code mass and interactions -- more and more of them, under changing conditions at that -- mounts. And as it does so, our design control becomes more and more lax because it becomes too costly to revert entangled decisions, and entropy mounts. Some entanglement breeds more entanglement. Inertial webs of dependencies become more entrenched. Even cohesion -- leading to collocation -- may become an unfit codependency if underlying assumptions are no longer valid.
There is no clear boundary line between the messes we create because we are hurrying along and "buying time" from the future because we don't refactor (enough) and rip out and replace and such as we go, and the wear and tear that, no matter how diligent we try to be, will inevitably take place as the unforeseen and unforeseeable unfolds on us. So to say technical debt is only the kind of debt we incur in the more narrow case that Ward was naming with the term, is perhaps too artificial and hence the de facto industry understanding (generalized entropy not only due to deferred design attention but also due to unavoidable growth giving way to mass that challenges cognitive tractability, and coupling in the context of assumptions that turn out to be maladaptive, etc.) is more reasonable. "Technical debt" then becomes any backlog of technical (re)design and (re-)engineering work (where I'm using backlog in its general sense) that has accrued in the process of evolving the system to meet moving market needs and contexts. Unless dealt with in smaller "payments" along the way, this work mounts to the point where huge spikes in cost have to be absorbed to replace or radically refactor and re-engineer the system to get it back into a state where we can consider it an "industrial quality" system rather than a software jalopy fit more for hill-billy back roads than professional practice where many, many lives and livelihoods depend upon it.
Ok. So if it is natural that the code will grow and that growth, adaptation, evolution and change simply will wear at the code integrity over time, what do we do?
And from the ever awesome moi (hey, I have to do that because unless someone with significant authority and credibility says "Ruth sheds a lot of light on this topic, so go read these other posts" no one will bother, right? Right. And notice any other persons pointing to what Ruth Malan says on technical debt? No. Exactly. So):
Oh goodness. Just kidding. Sheesh. Don't be so serious! This is just a trace, not a formal treatment. We're here to have fun, aren't we? As a little light-hearted treatment goes, there's:
A system may have organic or biological qualities, but a system is still a product of mind -- for complex systems, many minds. As complexity compounds, we need more effective ways to gain and maintain cognitive tractability and discipline in terms of system thinking and evolution. So, let's ask that again: what do we do? Well, to give you our answer there, means describing the Visual Architecting Process from early concept through evolution to renewal and regeneration and evolution and...
3/12/13: Even when we do more systematically and continuously refactor (using the term loosely to mean various scales and scopes of (re)factoring and repartitioning or (re)modularizing, removing, etc.) the code, changes in the technology substrate and the environment and new competitive bases in the market and and and more may mean sooner or later we still have to swallow the big cost of a major redesign-rebuild. One approach is what Martin Fowler called stranglerApplication -- the replacement is built incrementally, leveraging the system it is incrementally replacing over time. If the big rebuild path is taken, I caution teams not to simply modernize what they have, but to build the system that will compete with what unfettered new entrants will bring to market to trounce them if they don't do it first.
[I know, I have insufficient shame putting my handwriting on display like that... But, sigh, it's that or not at all. All evidence to the contrary, I'm really busy.]
* By technical learning in that case, I mean learning how to to better design-build this new thing we're inno-creating. It is also true that very often in software when we build new systems we munge learning new languages and a slew of infrastructural/substrate technologies into the mix. This is perfectly understandable -- not only do we want the sexy new stuff on our resumés... no, no, no... I mean, not only do we want the fun and reward of working with the latest advances... no, no, no... I mean, because every advance in language and the whole technology base (how we handle core problems like persistence but also, increasingly, heterogenous sources and messy data, distribution but also taking advantage of multicores, etc., etc.,) gives us a raised platform of capabilities from which to craft our capabilities for a capability hungry, ever more sophisticated world. That will have that hunger served, if not by us then by those who will seize the moment instead. And so it goes. So, while my emphasis when I say "technical learning" is on the design learning relating to how best to design the "guts" of the machine (as opposed to the design learning for the "skin" or use context interaction and function side of things), there is generally at least some of the other kind of technical learning that has to do with figuring out how best to exploit a new technology base and toolset in that mix. And this is a good thing. Seriously. Resumés and joy on the job are important. Not reinventing capabilities from the ground up and leveraging others investment of resources and market learning is important in a world that keeps upping the competitive ante. And so it goes. Compounding complexity and novelty. It's the modern world. The world of Dreamliners, even if they have serious kinks to work out. And all that.
Very cute. :-)
Oh yeah, driving into a gorgeous red sunrise this morning, every branch an twig of the marvellous hardwoods trees, not yet showing their spring blush, were etched against the red dawn. Ok, that doesn't bring my picture above to mind? I'm stung. Well, it did for me, and reminded me that I've been wanting to add a third organic metaphor to the branching and organ one above. I know, when I'm sketching to think my sketches are iffy and I don't take the trouble to redraw them because, well you experience this too, life. SHORT. So much to think!!! SO little time. Moving on. ;-) Anyway, (Im nasty mean wasting your time like this, but hey, price to pay for insight), it was an image of pods, a la Dave Gray. Just wanted to bring the image of larger grained elements that form "pods" or "social groups" to get some larger outcome done. These may be more tighly co-ordinated, as in mechanisms, or more loosely choreographed networks. I need to get back into reading Design in Nature. The emphasis there is on flows and tree-like structures, and I need to read more but in what I read I thought networks was missing... that is relationships that are multidimensional... scratching thoughts out quickly here... on the run...Time. SHORT.
But here's another quick thought. When I say technical debt accrues because we are trying to figure out how to get things to work (at all), I'm by no means slighting our ability! It is just a different mindset to get something to work than to get it done "right" and then righter. By which I mean, widening our lens from the narrow focus of getting a piece of the system thought into functioning code, to more of the system, to the system -- as it evolves. And yes, there's also just kludging it out to get a better sense from the user of what the system should do, but also how to do it, with the intent of coming back and rethinking it... but then... schedule schedule... more interesting things to do... more voluble demand for more pieces... we don't go back and improve the design... and.. technical debt.
10/3/15: What I tried to do (above), is clarify what the tradeoff space is, so that reasoned arguments for discipline can more compellingly be made.
Great additions to the conversation:
Twitter is providing a topical example of my point with regards to market learning. Clearly they have a number of challenges convincing analysts (influencing valuations) that they can grow -- that is, shaping a convincing narrative around innovation and revenue growth. Rumors about moving to more than 140 character tweets, along with the Mentions experiment, make it clear that Twitter has ideas, but no firm idea what will actually gain traction and promise and then turn into future revenue streams.
I think one of the areas we stumble on here, is trying to stay loyal to Ward's definition. While it is wonderful in spirit to honor Ward's contribution, I think it disserves him and our field to lock down a term that wants to leave its parents and have a life of its own. Or something... Language is alive and evolves. Sometimes errantly. The term gained currency because it was expressive of something we evidently needed a handle for.
But aside from that, I think we need only the slightest tweak to make it work (as in, include its dominant colloquial use). In shaping how we think about technical debt, Ward was concerned not to advocate profligate debt, and he -- and/or we -- collapsed disciplined debt onto debt. But the notion of debt is independent of how the debt is taken on and paid back. We can wantonly take on (technical) debt, miring ourselves in pernicious couplings that impact our ability to earn revenue (by preventing us from adapting to market shifts and opportunities) and pay back debt (it's just too much mess and deferred design decision making). Or we can take on debt with discipline -- taking only only as much as we need to take an opportunity we would not otherwise have, if we did not "borrow [code design and refactoring] time" so to speak, from the future. Then a kludgy ball of mud is profligate technical debt. Not to be recommended. Better to write the best code we can given what we know, recognizing that we learn as we go, but we're going to feed that learning back in after a bit, so we can get a chunk of value to market sooner -- the stuff of disciplined debt; cue "what Ward said."
Status: listening to Sedna by Efterklang.
These are some profound words:
They relate well to the message in James (Jim) March's "Heroes and History: Lessons for Leadership from Tolstoy's War and Peace".
3/6/13: As far as Jim's message goes, I think he kind of over-corrects... The leader narrative is only one thread; most of us see many threads, many players and events and flows, all woven together to make the great, multidimensional history. If we consider all the simultaneous "truths" and "meanings" inherent in one moment for one person, and mix these up with those of other people, then swirl them across time, we have an enormous mess of ways to see things. The leader narratives of Martin Luther King generally leave out his philandering, for example. We might view narratives that leave out the flaws of leaders as inflating the idea of perfect leader heroes. Or we may view that as thinking of the audience as being rather simple-minded and unsophisticated, which may lead to us treating audiences that way, until we have created audiences who see leaders in simplistic terms, expecting too much. Hence demanding too much. Setting us all up. So, part of what Jim is doing is debunking the myth of the superhero leader. In the process, as I said, I think he overcorrects. Good leaders can play a shaping role, and do so in very subtle ways, more like creating places for energy to flow, than commanding where it should be invested. And so forth. And, as we point out in Fractal and Emergent, leadership happens at different scopes of impact, or fractally (where the fractals do not necessarily map to the formal organization power tree, though some may).
There are multiple interacting threads of "reality," and I'm so very excited at using Richard Feynman's explanation of wavelengths as an analogy for perception of reality -- and how much more complex when it is a social construction, like the interpretation of the course of events interwoven with motivations and (re)actions and and and muchness! First, what we perceive unaided is only a limited set of possible perceptions of the system. (And tends to be focused on just pieces of the proverbial elephant, for more complex, or diffuse systems.) Different views we use to visualize systems enable us to access different "wave spectra" as it were. (It's an analogy; lean into it, and use it with generous imaginative interpretation. Later, once we have sucked the good stuff out of it, we can look for where the analogy falls short and that will help us understand still more. ;-) And these views interact; that is, we have to understand and design holding those interactions across views in mind, too.
Sara was complaining that she didn't like the lasagne. I passed her the salt. She said "Mom, salt brings out the taste!" If you don't like something, why would you want it to taste more like itself. Hello?! She's right. Never thought of it like that!
Where I'd be without a sense of humor, I don't know. :-) Just kidding. She's a really sweet kid, with a great sense of humor.
So much depends on how we orient to a person, doesn't it? If we are willing to see a person in a negative light, they will present us with plenty of fodder to support, justify, goad, and encrust our negative views of them.
Doug Neill's Sketchnotes of Maria Popova's conversation with designer Debbie Millman is awesome -- he has captured wonderful essence vividly, highlighting gems from the conversation. These two image snips are pieces of the larger conversation tapestry by Doug Neill.
The curious octopus? What an image! So, curiously Serendipity serves more octopus today:
As curiosity goes, I'm curious and excited about Stuart Boardman's book. I believe this introduction will have you joining me in that state. :-)
This is interesting:
I doodled this while Dana Bredemeyer was talking about what architects do:
My drawing makes it look like architecting is ... working with silly putty... ;-) Well, it works for me. When that is the just enough design or creativity release medium for the moment. When I say that sort of thing, I am doing the equivalent of Amanda Palmer's crowdsurfing -- I'm trusting that you hold me in that kind of suspension of disbelief that allows me to make fun of myself while also making a serious point.
3/6/13: Clarification: "with the whole in mind" doesn't mean holding the whole thing in mind, but taking outcomes for the whole into account, rather than focusing (only) on the outcomes for a part. Sure, we are bounded, limited, partially seeing creatures, and, what is more, social realities are mutually constructed over time, so no one person can have a sense of, nor (fully) control, the whole when it comes to complex systems, let alone enterprises. But if the architect doesn't have system outcomes in mind, who does?* Do we just give up and insist that intentionality is a lost cause and no-one can influence the trajectory towards desired system outcomes, leaving all system outcomes to be simply those that happen to emerge from self-interested actions in the "parts"? Complex systems are complexes of many interactions under uncertainty (shift happens). We work to resolve ambiguity, resolve uncertainty and bound the impact of surprises, and and and, shape, adapt and adjust (sense and respond), and and and, to get more what we want. The fractal and emergent approach embraces emergence, but also considers what big things the organization wants to accomplish through the application of intention (and emergence), design and active enrollment and alignment of many participants to help achieve that intent.
* It is always hard to explain/advocate an entire mindset in the space of a single sentence! This isn't just about the way we set up organizations, dividing up responsibilities so we can cope with making bigger things real in the world. This is also about human attention -- what we are paying attention to, shapes what we perceive and pay attention to. So if we are responsible for part X, we tend (by virtue of our charter, the people we interact with, what our manager expects from us, what we feel responsible to our team for, etc., and our cognitive tendencies and capacity) to focus there and don't see how part (component, service, feature, ...) X may be impacting parts Y and Z and/or the overall system. The architect has a pretty unique responsibility set -- to design for the overall outcomes of the system and to do so in a way that doesn't wall off the future. That is, designing for sustainability, and, to the extent that this can be accomplished, with allowance for emergence and constant tending, to refresh and renew as needed, to see the system into its future more sustainably.
Of course, we don't design the entire enterprise the way we design a wristwatch. Although if we are designing an iWatch, we likely apply (some level of) design attention to the broader ecosystem -- or we would, if Steve Jobs was still the lead designer. No, Steve Jobs never had tight design control over the entire music ecosystem when the iPod/iTunes innovations swept a wave of change across the music industry, fundamentally reshaping that entire (set of) ecosystem(s). But he sure made a number of shaping plays that set those changes in motion. That is what I meant by design interventions in the ecosystem.
Etc. Shoot. This stuff warrants a book or five to get my understanding expressed... A Trace lets much of it out, but in a disorganized way that doesn't help build enough of a view of my understanding...
Aside from James March's movies, what resources (books, movies, etc.) do you find useful on leadership?
Later: This, recommended by the always awesome Peter Bakker, looks interesting:
My World Today
This is what we woke to:
Lovely, innit? My very Being sang so!
As singing goes...
"In a thousand years time this will still be controversial" #alwayslookonthebrightsideoflife
Where was I?
Yes, we saw the black knight. :-) Loved it! I'm not sure what I enjoyed more, the show, or the kids loving the show. Ok, I enjoyed the show more. But Sara and Ryan were reciting whole chunks of it and loving that it referenced not just the movie, but Brian and beloved skits and pop culture references, etc. And the drive home afterwards was hilarious!! We must be doing some things right. :-)
What... is she on about??? Spamalot!
Here's a lesson learned from car mechanics, plumbers, electricians, the whole roster of folk that one will encounter as things age: When something isn't working, tap it. If that didn't work, repeat, but harder. Ever so often, it fixes the thing like magic. Cos it was just a loose connection that needed a jiggle, or a block that needed to be cleared and a tap rejiggers stuffses (scientific catch-all term for gunk or air bubbles or, well, you know stuffses ;-) enough to free it/get it working again.
I like the tap it approach. Rather than tossing the whole thing, see if a tap in generally the right area will give the just-off configuration a teense of redirection to allow reconnection so that current can flow again.
Often this works in relationships too. Rather than giving up and shutting down, try a little tap, a nudge, ask, listen, extend grace, and allow that even a small shift may free things enough to let the good make its way again.
So often the way we think about things, the stories we tell ourselves about them, makes something possible or impossible. Of course we don't have infinite degrees of freedom, but "reality" is mutually constructed and negotiated, navigated, possibilities opened up or closed off by how we think and the actions our thinking-perceiving initiates and shapes. If something is stuck, does it need a nudge in our own thinking? If we just opened up a conversation space, could we just jiggle something loose that was stuck between our perception and that of anothers?
This is a good day to be grateful for all the acceptance and support women have achieved, allowing women to gain access to the dignity and representation of the vote, opportunity-creating education, and self-determination and fulfilment of careers, and -- as I like to see it anyway -- for men to play more full and satisfying roles in their families and to experience the full range of their emotions with less restriction in terms of social mores.
It is also a good day to raise awareness of the many ways women and girls are still -- in 2013! -- abused and unjustly treated. We hear about abuse in India, but in Indiana 1 in 5 women have been the victim of rape. Indiana! You know. In the USA.
It isn't only girls and women who are raped. It isn't only women and girls who are the victims of domestic abuse. It isn't only women who are discriminated against in the workplace. But women and girls are more vulnerable and this shows up in the numbers.
Thanks to Richard West for including me in his "yay women" response to Ruth John's "yay men." To the extent that it was even paid any attention, it was interesting how much today was about appreciating men -- rightly I think, because all the good we have to celebrate is because we get to work and play with men who pitch in, work so hard, give us so much of themselves. It's fun, it's rewarding, it's wonderful! Thank you.
Goodness me, these should not be lost under the silt:
Last night we watched The Perks of Being a Wallflower. Awesome movie! It is rated PG-13 and it was challenging material for our 13 year old -- who loved it too for the way it raises and deals with big issues, but she (and I) asked several times what the rating was... :-)
Friendship, the degrees and realms of love we get to experience, are so important. Our dreams are fragile. Our sense of self, no matter how resiliently resurgent after each of Life's wallops, is obliterated or radiated by those who make us nothing or reflect of our best selves.
3/12/13: Worked out to Wings of Desire last night and tonight. Another wonderful movie -- very poetic, so some memorable quotes. More action in one's own head than on the screen... that sort of a movie. . :-) I guess if I look I'll find the architectural significance but for now I'm just relishing Marion's lines from near the end... which include this:
Which I suppose is the kind of (architecturally significant) insight that makes a 2 hour long movie worth it right there! :-)
3/15/13: Ok. Architecturally significant. This. One of the wonderful things about Wings of Desire is that it takes such a tender-gentle view of the human predicament. Serendipitously... I like to call it Serendipity (happy accident, but with the spotlight our Bliss throws on it) though I also like the touch of Cabell's "long arm of coincidence." Whatever. Anyway, serendipitously, earlier this month I was tripping on along the lines of "So much is in the stance of the beholder." and "Why do we stuff others into the confining Procrustean frames of our own small conceptions of them?" and so forth. And along comes a movie that is very much in the vein of holding humanity in a positive light. Not overlooking the pain and the struggles, but doing so with compassion, empathy, even a recognition that in our desires and wrestling with being in this short life we are gloriously human. I just wanted to say all that as a segue into raising a point about managers. Grin. There is such a tendency in the tech-tweet-sphere to disparage and denigrate managers and I realize that there is a lot of pain that gives rise to this typecasting of managers. As architects we need to understand that managers work at a conflux of hard to resolve forces, and it is our job to help them understand what those forces are and what the options are for dealing with them. I know they may resist our input and that is hurtful, but to get around that we have to stay resourceful, maintain our equilibrium and positive stance, and find a way to be helpful, to flex and reposition and reframe, taking their point of view and feel their pains and pressures into account. I'm not saying let go of your principles (and don't let go of mine either; oh, I mean, I won't let go of mine either ;-). I am saying learn to work more effectively within them.
Remember, architects partner with managers -- too. :-)
Seriously great essay by Charlie Alfred on what architects really do:
3/13/13: Charlie is one of my heroes in this space -- he has given me new, or rejiggered my, mental models enough that I have huge respect for the man, but he's also wonderfully generous and insightful. He is one of those treasures of our field that deserves more recognition.
Sweet movie -- only got to watch it this past Christmas. My movie education has big holes in it that I'm working on filling with these wintery evening workouts. ;-) So hey, another light dusting of snow today. Very pretty!!! But... More slick muddy slush in the hills. Lake still too cold for kayaking. So.
Uh. I think this is barking up the wrong tree:
That sounds about right to you does it? Just kidding. Anyway, it sounds all wrong to me. My sense is that it isn't about women versus men. There is a spread of styles among women, and among men. Criticism is tricky business and if I was to come up with any glib heuristics it would be more about the kind of thing that feedback is being given on. Where it is a matter of advancing technique, men and women value being told very directly and without undertones (that carry evaluative judgment that erodes at and undermines sense of self) what we are doing wrong. Where it is a matter of aesthetic judgment or artistry or a balancing of many competing values and experiences and subjective criteria, then feedback must take that ambiguity into account. Moreover, feedback needs to be sensitive to context. Men and women in the very tentative early formative stages of nurturing a competency or an idea into existence need encouragement not a sand-blasting treatment that erodes and obliterates.
is ostensibly about Netflix choosing Python over Java more and more, but it is a really interesting case of BI (instrumenting/analytics/dashboarding/alerting) applied to operations. ;-)
I do realize that the Requisite Variety blog can, like my Trace, seem a bit "in the clouds" compared to the (often very tactical) daily slate of demands on the architect. Who has time to observe a fish for days? And days. Even if the "fish" in question is a complex system, of systems, an enterprise, or ecosystem. And how does one observe such a "fish" when it can't be seen all at once -- when there is no helicopter to take us up several hundred or thousand feet? When there is no macro-lens or tele/micro/peri-scope to bring it into view? The architect then becomes the "scope" rendering the invisible visible. Partly this is a matter of abstracting, because the details are just too much to hold in mind all together. Partly it is a matter of determining relevance, and filtering (a separation of concerns). A matter of representing, because we're dealing with intangible concepts like value and flows thereof. A matter of discerning, because the muchness otherwise obfuscates. And and and. ;-) [And and and? Oh, that's my lazy way of acknowledging there is more to go after there, but also waving a hand in recognition of at all the stuff you're thinking of, but I haven't thought of in this moment. Consider that an invitation to clue me in. ;-)]
As visualization goes, I do hope you read and followed the links on my What Architects Do trace last month. ;-) Yes, in one sentence, with some visualization help from the great Randall Munroe, I so did "architect as scope." ;-) With a little characteristically self (d)ef(f)acing humor thrown in at the end, so no dancing on the table would be seen as arrogance but more as playful enjoyment of our fallibility -- we of all people can't take ourselves too seriously because the job is too demanding to be perfect (or to strive for perfection) in every way that it demands of us!!
What do I mean? Well, if we, or even a team of architects, tried to visualize every aspect of an organization along every possible facet of the enterprise it would be impossible to do -- to do at all, and to do anything with!!! If we return to that What Architects Do trace, just parsing that sentence is big. Clicking on every link? Outrageously demanding -- who does that ruffian think she is anyway? ;-)
Which is why the Extraordinary Moment Principle of Dana's (borrowed with attribution from Buckminster Fuller) is so important. Say what? You know:
The "extraordinary moment" principle is a handy tool -- an Archimedes lever if you will. The architect, as leader, needs to lift her head from the tactical grind and consider what is make or break -- what is architecturally significant -- and how best to do that (and when). This relates to technical debt, and making that visible, including the impact now, soon, later. And relates to informing strategic direction and setting technical direction (in the case of technical architects), and making shaping forces and trends visible. And so forth. Much of this is about thinking outside the strict lines of daily demands, especially if management thinks of architects as simply talent to point at tricky issues and get things done. Architects should, for at least a good chunk of the time, be paying attention to a quite different slate of concerns from everyone else -- hence the need for the distinct role! These are strategic cross-cutting concerns and system outcomes (over the strategic horizon). But if the architect and the management team is committed to architecting, then the Extraordinary Moment Principle is that lever to move the world in the direction of attending to what is of strategic and architectural significance. And there will be times when the most important thing is studying the fish. ;-) Observing, instrumenting and "scoping out" the system, sensing what is relevant and investigating how to make that visible. This may have to do with the structure of the system. For example, making mechanisms visible, exploring, visualizing, etc., how they work, and how they don't, and what to do about it... And so it goes.
Anyway, I picked those stories (used in the first several Requisite Variety blog posts) to begin a keynote I designed for Dana a few years ago. [Did you recognize them Daniel? :-) ] Lots of stories strike me with lessons they hold for architects, but that set together really sets the scene for discussing the role of the architect and architect mastery. Don't you think? No? I'm stung. ;-)
I do hope more people will step out from the shadows and help make the blog work by telling others about it and/or by joining the discussion... though goodness knows I am shy too, and express myself where I am more comfortable -- here, for the most part. ;-)
The Visual Thinking and The Monk and the Mountain posts are still open for comment (as are all of the posts). My plan is to debrief the Visual Thinking post after The Monk and the Mountain post. (Yes, in a way they are sort of nested, Shahrazad style. ;-) (That debrief word again... sigh. But it is expeditious and you'll just have to interpret it in line with my personality/interaction style. I'm no military commander and this was no sortie.)
Image source: science teecher
Useful checklist (wink):
I don't like to read about writing. When you're out there being avant-garde without thinking about it, you don't want someone to make you become self-conscious about it. Oh rats. I just did. ;-)
Even so, I succumbed to a peek at what Stephen King has to say about adverbs. Now, when it comes to writing I feel I some degree of competence and my use of adverbs is a matter of personality (like "I really, really care what you think because I really. really like you" communicates that I'm both stereotypcially a Q<= and not) along with idiosyncratic color. So Mr. King can just put his notion of adverbs in a book if he likes, but I will use an adverb in my email signoff to signify that I am a hallelujah of a verb and I will use adverbs wheresoever it jolly well pleases me! ;-) There. You see. Even Stephen King is no match for me. ;-)
That said, this snip struck me:
Uh. I'm getting to the point... just multi-tasking here... It has to do with technical debt, broken windows and the impact on (yes, the title signifies) neighbors, too.
Oh, and remind me to write a post on documentation, because really the bread crumb trail we leave is much like this image.
Tonight I enjoyed reading these (by way of John Maeda):
And earlier today enjoyed looking through this (via Tom Graves):
And I must report that (the movie) Anna Karenina is really quite perfect to work out to. :-) I wonder if it will come to be better rated, over time? It is very theatrically staged. And I think that makes it work in its own way, but it also seems to try too hard -- hard enough to make me wonder if a movie of a Tolstoy novel should make Sontag's Essay on Camp come to mind... Ah but... those few stories that keep playing themselves out over and over; well, after all, it is now as it was then, at once wonderful and hard to be human.
3/18: Finished (worked out to/it's excusable, no?) the second half of Anna Karenina, and I have to say it is a wonderful movie! I was completely won over by the staging. Watching the first half, there were times when I felt like the staging obtruded -- it was so self-conscious that I was overly conscious of it being self-conscious. But by the second half it was adding so much I let myself go with it, and appreciate it. It makes the construction of "reality" more real, throws the "roles" and staging of society into greater relief, so that these constructs become visceral parts of the drama. Relevance to architects? This is an exquisite piece of work -- wrestles with issues that are as relevant to us today as then (though some laws and expectations have changed) and pushed to a pinnacle of art and craftsmanship. Again, relevance to architects? Integrity of the work. Conceptual integrity, structural integrity and, ultimately, design integrity. But integrity is a complex matter, and one person's sense of integrity may not be the same as anothers. Witness how the film did at the Oscars...
So, I'm wondering how you are finding the Requisite Variety blog style. Do you want to do more of the present a story--discuss--debrief thing? We could do one on assumptions. ;-)
Or should we switch gears?
Perhaps we should do a brainstorm on what is the variety that is helpful for an architect to have in his "clue bucket." Clue bucket? You know, which he can dip into when he needs to get one. That's putting it playfully, but the situations where "get a clue" comes up are usually somewhat stressful and our resources (including our sense of humor and ability to maintain equilibrium) need to be sufficiently ready to hand. Alternately put, we need to have a clue how to deal with system design and evolution in contexts of complexity and uncertainty, and be able to get a clue (or several) when surprises unleash that veritable Pandoras Box of ills -- that we might characterize as chaos, especially if we can't retain our resourcefulness and try out some clues. ;-) So, what clues are useful? We've been working on big clues like mindful observation and thinking, as well as assisting our thinking by externalizing it (visually). And so forth.
Uh, could you put that in English Ruth? The kind that real injuneers understand?
In the next Requisite Variety blog discussion, should we brainstorm what architects do, as a segue into surveying what is useful for architects to know/understand/be competent at?
That is, are you feeling like you need a roadmap of sorts, that helps understand what in the name of all that is pragmatic makes Ruth think that monks and dead fish and boys fixing radios signify in any way that is the least bit to useful to an architect in (huff!) the real world, solving urgent and intractable problems (puff)????
Hat tip: Tony DaSilva tweeted something with the phrase "declining marginal returns to complexity" in it and my magpie brain seized on that important nugget. Looking it up on Tony's blog -- interesting set of sources, when considered in the broader societal context in which the phrase originated. Well, I thought it was a neat concept to apply in the context of code growth and collapse. :-)
I'd want to redo my scratchings at some point, but it suffices to capture/retain the idea, I think/hope.
If this wasn't the most retweetable response in all of history, I'm a pilchard:
Goodness. Where's everyone's sense of humor? If you don't follow Charlie and moi, why not? I mean: here's the tweetversation with the video link. It's a must watch. Really.
;-) Oh, Just Kidding! Still, I do love that video and have been known to use it to discuss ethics when we do the persuade and influence module in the Role workshop. ;-)
Ok, ok. As laughing at ourselves goes, here's more. Totally awesomely ROFL!
One of Dana's favorite responses to my sort of randomness is "Do you want to go to Oregon or by bus."
But stereotypes are fun to play with, especially when it is in self-deprecating fun -- since we have to fight ugly destructive typecasts like architects in "common practice" "put themselves on pedestals." (I'll never forgive Scott Ambler that, will I? That's a mischievous wink! Sheesh. The things you're willing to believe about me!)
Background check: Goofily falling off the platform of a stereotype is the sort of conjunction of (figuratively) physical comedy with cognitive twists that I associate with the Marx Brothers. ;-) [Since I grew up in South Africa, I missed out on the Marx Brothers and it took having a son to get fully acquainted. Now I'm a "needle in the needlestack" and "I don't care what you have to say" kind of Q<= ;-). Call me on my cell phone and try to leave me a message, if you need evidence. ;-)]
[Oh right. Derren Brown is an awesome British illusionist. My sense of humor couldn't resist teasing on multiple threads including the notion that Charlie was asking me to teach you magic. And the stereotype that architects don't do anything useful. Uh. Sorry. Blame my misshapen sense of humor on extenuating circumstances. ;-).]
3/21/13: Fine. Just call me Pilchard. ;-) Was that way too obtuse? Stereotypes are, because there is just enough truth knocking about for people to convince themselves with the stories they tell themselves and others about them. Core to the architect role is understanding the system well enough to be able to shift it towards better -- which means understanding the encompassing system, to understand what interventions are needed to unblock the flow, as it were, so that gooder (I know), better, things happen. This is right hand - left hand work, to use Dana Bredemeyer's image. It is understanding that we need to work big picture, culture, strategy (including technical strategy and technical culture) right hand kinds of areas as well as pragmatic, tactical, make-a-difference now and soon left hand kinds of areas. But it is a constant weighing. And some may (be perceived to) spend too much time, get too caught up in, one or the other. Become too much an "architect astronaut" ... or become a developer with no bandwidth to "pull up" from the details and sense the system and its context, including the forces that are shaping and steering it into a future that may not be what is wanted.
So I was playing with the notion that bad impressions of what architects do can form a front that precedes us. By ostensibly agreeing that this communication and persuasion stuff is touchy-feely woowoo NLP magic stuff. I was asking us to confront these preconceptions in a light hearted way.
And I was playing with the notion that magic -- illusion -- does have something to offer. I obviously -- come now, even if you don't know me, you orient positively to your fellow human beings right? You have the highest expectations of my good sense and insight? Good. Glad we have that settled. ;-) Uh where were we? Oh yeah, I obviously don't think we should convince stakeholders by magic to want something they didn't. But just as one can learn about structures to figure out how to make them fall down (safely or not), we do so to make them stand up and withstand forces. Knowing how magic works is not altogether irrelevant. Indeed, cast it a little differently, and you're in the ballgame of "behavioral economics," and a little differently you're headed into "neuroscience of leadership" kinds of things. Right? Should we make this video a Requisite Variety post so we can discuss it????
3/22/13: Understanding attention flaws and weaknesses is what magic is all about. That is not irrelevant. Sure. Magic exploits them, while we need to understand and accommodate to and with them. Dan Ariely suggests "prosthetics for the mind" (playfully) but regardless, it is helpful to work with the brain in mind. After all, we're trying to illuminate our own thinking and move thinking/understanding/perspectives/etc. between minds. Hard stuff. All the help we can get. That sort of thing. All I was saying :-)
The other night I saw Shadowlands, about C.S. Lewis, for the first time. Running from mortality has the upside of giving me the opportunity to rationalize filling in my movie education an hour or so each wintry night. ;-) Well, it is lovely and heartbreaking and I can't recommend it highly enough for it is history, it a wonderful lens not just on a life but Life, and it is magic. This is such a poignant line:
which also gets rearranged as "The pain now is part of the happiness then."
I think that is such a wonderful way to look at life, but also at systems. The YAGNI mantra misses the weaving together of now and then. That is, they aren't separate, and what we with crude reasoning tools simply shrug off may not be so expeditious as we think.
Oh, come now. I wasn't born into this fresh today. I know we don't know what we don't know, and that the world keeps changing in unexpected ways. And not. There is often unexpected inertia, resistance that lasts and lasts and then suddenly seems to be overwhelmed and a wash of change rushes through entire ecosystems, reverberating with failing companies and the mass pain of job losses and more. And if we are the ones to boldly decide to take the future into our own hands by inventing it, Alan Kay style, the future can feel pretty indifferent to our desires to shape it in any particular way. So we should just give up, not try to do anything intentional and shaping, and just react to local perturbations?
Yeah. There's uncertainty. There's risk. There's making the wrong call.
Yesterday I realized there is another neat conjunction which I put like this:
As architects, we need to have a healthy and resilient self-esteem, but not the kind of arrogance that blinds us and makes us unwilling to find that we have been wrong. Because we will be wrong. Shift happens.
And we need to have the confidence that enables us to lead and act boldly (not rashly) despite knowing we will be, and maintaining openness to being, wrong.
That is a pretty strong demand. Sometimes, truly YAGNI. And sometimes we have to take some pain now, because it is part of the happiness then.
Leadership is not for the faint of heart or mind.
C.S. Lewis, who gave us so much, was given, much though he shielded himself from it, the pinnacle experience of life. You think I'm going to say Love. But I'm going to say Loss. Too. It is not an experience one wants, but it is the price.
Let's leave it at that.
(That's Sara's drawing of Alice at the Mad Hatter's tea party from a year ago. As her drawing improves, she is critical of the year ago versions but I love what she captures in them.)
Awareness of the importance of thinking in terms of ecosystems is bubbling. It was pointed out that it is hard to find my musings on ecosystems, scattered as they are across the months, so here's a collection:
In formal (as in published) work, there is the "Change: Not Whether But Whither" section of the 2010 Fractal and Emergent paper (later sections connect EA and product line architectures to that view of ecosystems and agility).
My orientation is:
Of course, I don't mean we design the (entire business) ecosystem. I wasn't born in this moment, though snow-magical as this morning is, I do feel like a skip-happy kid! (Smiles) We can, though, design interventions in the ecosystem, to shift value flows and support the value network. You know, like supporting the development community that will build apps on your platform with tooling and APIs, or creating relationships with content providers, that sort of thing. And more.
Traces on Ecosystems:
I'd also like to point to the following, since they slot in nicely:
Woke up in a magical place. Couldn't be Indiana. It's Spring, right?
Left for the middle school run in the dark, drove through a magical dawn, got home to this:
Lovely, isn't it?
Ok, so it's hard to make a case for the architectural significance of my view today:
Except. You know. Empathy isn't just about feeling another person's frustration and pain. It is about feeling their joy too.
Not working for you, huh?
I try. I do try. ;-)
Later: Oh my, look who's chillin' outside my window:
That's a great blue heron -- (even) big(ger) guy when he isn't all hunched up! I guess that long neck gets cold, so neat he can tuck it in under his wings like that. :-) Sorry. I should have run upstairs for the zoom lens. I went back to work, and when next I looked, it was just in time to see his breath-arresting majestic unfolding and flight.
Wiki is Old Enough to Vote!
In countless ways, we're indebted to @WardCunningham and the wiki. Gratitude! Some of the backstory, in his words in this wonderful 5 minute video. If you didn't watch it when I pointed to it before, why not? I mean, why not watch it today? You know, feel the punctuation of history through Ward's telling.
This is a useful add to thinking on criticism:
I would caution again though, that there are no easy pat universals like "don't criticize in private"... Imagine the harm that little message nugget could do!! I'll say this publically (smile): that title is striking and memorable -- hence dangerous. Public shaming whether in a team setting or the interweb is not a resort I'd want to encourage. Oh, Roger Schwarz was not going there. But in our technology culture we have proponents of "praise is manipulation, don't do it" and a ready reception for "use peer pressure" which can shade into "call the flakes out in the team setting" and "public shaming"... I think it would be more positively orienting if the title was "Team ownership for surmounting challenges." Or something to that effect. I know Roger's agenda was to say the team needs to get the smells out on the team table and have the team figure out how to deal with them, without avoiding confrontation just because confrontation is emotionally charged, hard stuff.
Personally, I much prefer to take the reframing approach -- like helping the team (learn how to) ask itself the questions that will expose what needs to be improved, and figure out how to do so. Taking criticism out of the equation and instead simply asking objective questions to surface risks and sticking points, takes a lot of the personal sting out and keeps emotional resources productively focused. But that is glib too. Sometimes it comes down to a behavior that needs to be confronted. So we need to view criticism as a tool in the toolbelt, to be used skillfully and judiciously. Teams are as different as the people on them. Some people are really good at giving negative (constructive) feedback, and partly it is just who they are, their personal qualities and the respect they draw at the same time as knowing their intent is solidly and respectfully oriented to helping good people get still better. And others not so skilled, or the relationship is just different. And some very talented people crumple under negative feedback, not because they are weak but because they are fully vested, and they stay in possession of their emotional resources better if they discover the flaw "themselves" and figure out what to do about it. Anyway, conflict resolution is a good skill to have, and all these areas of "soft skills" important to develop, yet often undervalued and treated as "extracurricular."
It is, I think, helpful to take away the counter point to the (common) advice to always criticize in private. The thrust of the message isn't to make criticism public, but to make it a team responsibility to deal with its issues, even though sometimes that will mean the team needs to be in the uncomfortable place of resolving conflictful tensions.
As for me, I have to learn how to call an end to a day! :-) I hate criticism -- I have very active inner critics and they're a handful as it is. Which is to say, most flaws people think they are being helpful to point out to me, I am well aware of, and accept, knowing I have counterbalancing strengths. For example, some kindly folk pulled together a meeting to tell me how to give negative feedback -- not taking into account that I have something different to offer with my distinctive style. Something that I think is as, or, coming from me, more valuable. It is very easy for me to find fault and be critical. I am a very analytical person. My inner critics get strenuously worked out every day sorting me out and they're frightfully good at being critical. ;-) But believe me, what they say is not easy to take. ;-) It takes real work to turn that into useful questions and reflections so that the person discovers for themselves where they were missing something. So, yeah, I was pretty downhearted at the felt need to "teach" me to criticize, which spoke of not noticing the effectiveness of my alternative approach -- not because it wasn't effective, but because it wasn't as blunt an instrument, hence not so obvious when applied. Yet it takes more work for me, but is worth while, because it helps people build themselves through discovering what they can do. (Oh, I do still inadvertently criticize, and rediscover through the shuttering of the person so mishandled, that criticism coming from me is generally speaking not a good thing. And sometimes I just fall out of my tree and react. I'm as human as they come. ;-) I just wanted to point out that in our technology culture we have this value set around criticism that obscures alternatives.
3/26/13: TIL fools can make blunt tools of anything, including school rules. It comes down to people, indeed.
Scoops from the Stream
There are still seats available in the our EA workshop with Dana Bredemeyer next month:
It is a pragmatic approach to EA, and Dana Bredemeyer is a wonderful teacher! He's also teaching the Software Architecture Workshop in The Netherlands in June. Tell people. (Smiles -- if I do an imperative, it is with a distinct wink.)
Heartfelt gratitude to Peter Bakker for tweeting, and Tom Graves for retweeting with an encouraging comment, a pointer to the criticism trace. The collegial camaraderie of that inclusion touches and warms me. Thank you so much for your generous kindness gentlemen!
It is a great big noisy world out there, and that a few good people are kind enough to give my work some exposure marks them the greater!
Today, I remembered with gratitude that I had met one of my self-set challenges in at last getting straight 5's from everyone in a workshop. Oh, I'm fully aware that it was the generosity of the gentlemen, but here's the thing -- inspiring people to that level of generosity is also an achievement; perhaps, after all, it is the greater achievement. ;-)
It's such a short life to be kind in, to touch others and make this rush of life through us ring with a moment of joy at being seen, appreciated, celebrated.
Aw, That's so Cute
As inspiring stories go, here's one I don't generally get to tell, but I'm making allowances. ;-) Ok, first some context. In upper elementary school the girls at Montessori wouldn't wear dresses. Partly, it was not being pretty little girls any more, but mostly it was just playground pragmatics of swings and monkey bars and boys that were getting older too. Smiles. Which I understood, but thought was sort of a pity. For my birthday, Sara had Dana take me out for a country drive. She called before we were due back, because she had a migraine starting. We hurried home, and poor kid greeted me in a dress and then pretty much collapsed in pain for the next few hours. But she had made biscotti, cleaned the kitchen to a shine, printed out a story (she never lets me read her writing while in progress), showered and done her hair and put on a pretty dress. With all that tension, she'd brought on a migraine. The kid was 11. Last Mother's Day, she greeted us at the front door in a stunning dress (she'd bought with Gerrit Muller's daughter when she was visiting us last January) and sent me to go in through my office. On the door was the start of a treasure hunt. It sent me all over the house, picking up gifts she'd made -- real treasures. Ending up with a trail of pages of the novel she's been writing, leading to her computer, where she'd made a funny archman animation, about me and coffee. One Valentine's Day, she gave me a box of paper hearts, one for each day of the year, with a little loving note written on every one. And then again, for Christmas, she gave me a box full of "Christmas spirit." The kid has a sense of humor too.
It is tempting in this world crowded with remarkable people, not to be stunned by those we see just shine! I can't express all the ways special people strike me with awe and wonder, but at least I got to express that one.
Do that thing you do, that no-one else does, that you so shine at! It is how you, and we, feel your life! It gives a unique sparkle and aesthetic to the pragmatic stuff you do, but also makes us lean in closer, attend, be more receptive to it
Philosophy, My Way
There are so many different ways to stumble and bumble around, making sense of life. Just thought I'd remind myself this is my orientation:
I hope I get to write the "female Don Quixote in the later 21st century" novel that broils in me. Damn this world needs it! ;-)
But, you know, time. I'm glad someone can explain it. :-)
Right. So I imagined that when I said "female Don Quixote," you immediately went "autobiographical, huh?" because you know, you've seen me tilt at windmills. But no. Don Quixote and Totoro figure large for me as emblematic of the imagination. So at the foot of my monitor, I have a little Totoro Sara made out of marzipan, my "earth's scream" pebble, a crinoid, a peace pin Sara made me, and um TMI, one of Ryan's baby teeth. Imagination, the present, the past, a vision, and standing in for fairies to realize dreams. You see, imagination is foremost among these, for it enables us to see, to explore and interpret, to make connections, to make the possible so.
And yes. That's architecturally significant. ;-) (What? Stories. Metaphors. The creative process. And minimalism. Ha. Gotcha. ;-) Humor too.;-) Oh yeah. And rationalization, connecting the dots, finding patterns, naming and classifying, meaning-making, fallibility, ... I could go on and on. ;-)
[Aka a serendipitous collection of the droppings nostalgia clings to. A debt of sorts? What you think? I'd really keep Ryan's baby tooth on purpose? 'fraid so. Imagination is a wicked tool. It constructs and destructs. ]
(So, yes, that's Totoro with me in the pic below. Dana brought him back from Korea for the kids several years ago, and I opportuned him the moment they lost interest. ;-) I don't do photos... but I made an exception -- my architecture-on-my-mind cartoon avatar might capture a goodly part of my identity, but a mischievous imagination (the Totoro) peeking over the lip of the frame, adds more dimension.)
3/29/13: Well, my, my. My site goes down and NOBODY* notices. Hmpf I tell you. Just hmpf. ;-) Uh oh. You don't think it was the photo, do you? Well, I hope you followed that earth's scream link and kept reading on that page. There's some good architect humor in there. ;-)
Oh yeah, whenever I see dreams and hopes I think of Sara's poem that she wrote in 2007, when she was 7:
Amazing what a 7 year old already knows, isn't it? The imagination is powerful. Insight -- and prescience; in the same timeframe - that is, in 2007, she also wrote:
Our imagination allows us to see around corners, it is our periscope, if you will, into the future possible. It allows us to "see" what isn't "real" -- make connections others haven't cast into the space of the "known." In enables us to be inventive. It romps in the playground of ideas.
And yes. It likes itself. It has a built-in reward system in the brain. And like anything else, we can overdo. But goodness me, we can overdo the mechanistically analytical too. Take ourselves down blind alleys.
Oops. To do list. Lots to do. Balance. See what is architecturally significant.
And do the other thing. No, no. I mean. To do list.
* Oh my, I was teasing myself because I fully didn't expect anyone to have noticed my site was down -- but some did. Wow. I am so very touched!! Thank you! :-) Well, it's like this see, every time a camera comes out, I mumble about breaking cameras and duck out of sight. So, you know, the first thought that popped into my mind when my site was down was "OMG I broke the internet!" jk. Low hanging humor fruit. The only kind I can reach. I know. I repeat myself. But only twice! Couldn't resist. There was still juice in it.. :-) UGH.
As pebbles and buttercups go, David Troupes is on a rock theme. Just thought you might like to add this one to your Sisyphus image collection. What? You know, the folder where you keep images that tell the story of the concerns and travails of architects architecting architecture with vivid visual eloquence. ;-) Of course, my Archman as Sisyphus sketch is fully representative of my life in the architect swimlane. ;-)
Not Your Mama's Pie
The message in the message -- awesome visualization! ;-)
I also write at:
- Bredemeyer Resources for Architects
Architects and Architecture
- Todd Hoff (highly recommended)
- Anna Liu
- JD Meier
Architect Professional Organizations
Agile and Lean
Agile and Testing
Other Software Thought Leaders
- CapGeminini's CTOblog
CTOs and CIOs
CEOs (Web 2.0)
- Don MacAskill (SmugMug)
- Wired's monkey_bites
Social Networking/Web 2.0+ Watch
- Dan Roam
- David Sibbet (The Grove)
Strategy, BI and Competitive Intelligence
- Freakonomics blog
Um... and these
- CNN Money Business of Green videos