9/1/07 Architecture Notes from Prior Months
I jot architects/architecting/architecture-related notes (those that don't relate to client work) in this "journal."
Journal notes from past months in 2007 are at: August, July, June, May, April, March, February, January. And from 2006: December, November, October, September, August, July, June, May, April, March, February.
9/1/07 Traffic Calming
A letter from the city about traffic calming in our neighborhood made a lesson stand out in bold relief. Now, our neighborhood is one of those middle of the road neighborhoods where we have the full spectrum of children from college students to babies, making for varying degrees of recklessness both behind and in front of the wheel. So, apparently there is enough concern about speed along the three primary access roads that the city is paying attention. They have sent out a survey, leading up to community meetings and action to institute "traffic calming" (a politically euphemistic term if ever there was one). I thought "this is genius, they want us to tell them to put in speed bumps or more stop signs," and then I thought "this is genius, get the community to solve the problem: raise awareness, and get the community to articulate and agree on the problem and be motivated to propose and come to consensus on the solution."
In software development, we raise issues to management attention, get chartered to solve the problem "our way" and roll our solution out. We don't take community action. We don't see the state of architectural decay in aging systems as a community challenge. We don't see the need for integration, or consistency, or service leverage, as a community challenge. We think organizations move decisions up and down in an efficient, mechanistic way, even if every day we are disabused of such notions.
I'm not talking about town hall meetings and press cheer leaders; not necessarily. I am talking about seeing course-resets in system development, including shoring up brittle architectures and incrementally nudging them into the next age of technological evolution, as change that impacts multiple people often in various groups—communities. Communities with identity, "folk-lore" about their history, evolution, leaders, place in the market, and so forth. We're always told that change requires "change management" and that inherently jars with my sensibilities. In every sense, I rebel against being "managed" through change. Led, inspired, empowered, all these things—yes! But "managed"—no!
Oliver Degnan made the point that we need to give our team(s) what they need: the context, ideas, encouragement, stories from our experience, whatever they need, and let them come to their own conclusions about the problem and the solution. We might have "envisaged" the solution in the first 30 minutes. But we don't have Derren Brown's powers, and can't pipe our thoughts into the heads of our team, unchallenged. Nor do we want to; imposing the solution we see, doesn't integrate the good ideas and experiences that come from opening up to the possibility of a better, team solution. A better solution, deeper understanding of the context and the problem, and a shared stake in the solution.
We can't do all this thinking, research, incubating, and so forth in "group think" mode. Architecture by committee is slow. Deathly slow. I so like The Wheel on the School. The team was chartered: wonder about storks. The team went off, and in their individual styles, wondered. They created a shared vision. Then they each went off in different directions, like the spokes of a wheel, but with a common vision unifying their search for a solution. The whole village got pulled into the creation of the solution, at different points. The team told vivid vision stories to motivate and inspire various people along the way. More and more people got drawn into creating the solution; taking risks, doing what it takes. The core team, working like cogs, pulled in teams of teams. Sometimes all working together, sometimes as smaller teams. Fluid, dynamic, ever-changing teams. Through action, they made the vision real. People changed; changed their self-concept, changed the communities concept of them. In changing how they viewed themselves, in changing how they viewed others, they built the team. A man with no legs, an old man, an old woman, a teacher, the children, the preschoolers, the men of the village, the women, the tin man from the next village, all were transformed by working towards the vision. Of course, these are metaphors for all the different forms we take; whether we are stunted by chronic resistance to ideas not our own, by small-mindedness of any kind, if we are highly tuned up in some areas, but deficient in others, in all sorts of ways, a team needs diversity and a team is transformative; or it can be. They changed what they could accomplish. We can too.
I would be interested to hear from others who have read The Wheel on the School. Did it resonate with you?
So, did you wonder about HelpMatch and Katrina yet?
9/4/07 Links: Loose Coupling
Inversion of Control and Dependency Injection
That's not a speck on your screen; that's Ryan fishing solo out on Lake Monroe. Makes me understand dependency in a whole new way!
Cohesion defined, Wikipedia
Single Responsibility principle, Robert Martin
Single Responsibility principle, Wikipedia
Links: Contracts and Protocol
Bringing Speech Acts into UMM, Maria Bergholtz, Prasad Jayaweera, and Paul Johannesson, 2002
Consumer-driven Contracts, Ian Robinson
How to Design a Good API and Why it Matters, presentation by Josh Bloch (of Google) on InfoQ, 2006
Links: Interfaces and Roles
Matt posited that there is conservation of complexity—you can push it around, but you can't do away with it. DI may be somewhat counter-intuitive; at least it can raise the instinctive "dependency is dependency, and any dependency is bad." But, can we get away from dependency, or just make it less profligate? Dependencies, generally speaking, raise the cost of change. We strive to lower the cost of change, often applying one or other strategy to consolidate or isolate the impact of change.
9/6/07 Agile not Fragile
9/7/07 Blog post: Agile Architecting
I pulled together some of my scribbling on agile and architecting to get a blog post out. I really need to get more into the habit of pulling pieces out of my journal to post to my blog. My journal is all very well for some people (namely, uh, me!), but my blog has all the "features" (thanks to WordPress)—like LIFU (last in first up :) post organization. Looking at the sadly meager set of sites that link to my blog, I see that "Bohemian Girl" "hangs out on" my blog. Well, to have at least one person willing to name my blog as a hangout is tremendous. There's something nice and optimistic about that "at least"...
Now, if that weren't enough to make me just intolerably big-headed, Jason H. wrote of the Resources for Architects site:
"Your material is amazing!"
My feathers are all plumped up.
And, and, and Arnon Rotem-Gal-Oz commented on my blog post on agile architecting. He reminded me of one of his posts that I had seen but forgot to mention, and another of his posts that I hadn't seen. Here they are for reference:
9/8/07 Recognition: Pay your way with Kudos
I am reminded that 4 words with "your" and "amazing" among them are very powerful! We don't have to pull the salary strings and have formal authority if we know how to see value and appreciate contribution—and say so! People work for recognition. Yes, yes, the pay check is not incidental. But empowerment and recognition feed self-esteem and motivation. This is not to say we should be superficial and hand out cheap praise. It does mean that when we feel a sense of appreciation and respect for a piece of work, we should go ahead and say so.
It does not diminish the giver of praise to value other people's work! On the contrary; it takes a solid sense of oneself, of one's own worth, to heartily give appreciative feedback to another. That communicates something about the person giving the feedback—they know they are not lessened by acknowledging another's contribution. If I say "I've learned so much from Charlie Alfred," does that undermine how much I know? I'd have to have a pretty shoddy sense of myself if I was worried about people translating that into "she doesn't know very much" or "if she's still learning after all these years she can't be very smart"... What, you were thinking that? Oh no!
9/8/07 Networks of Influence and Dominance Hierarchies
That leads me to a different vein of wondering... I've seen researchers (e.g., Helen Fisher's First Sex) saying women have a predilection for social networking and web (system) thinking and men for dominance hierarchies and linear, step (algorithmic) thinking... but looking back over my life, I started out my career highly tuned on the algorithmic thinking side, and progressed to seeing and placing more value in systemic thinking and collaborative, networked rather than hierarchical modes of work. I'd hate to add age cleavages to the gender divide. My wondering is more along the lines of whether this is why the transition from engineer to architect, and architect to chief architect, is hard: it entails some degree of transformation of work style and mode of thinking, and it meets with unfriendly resistance in part due to style differences. I mean, architects have to:
favor interactive-collaborative leadership styles
be comfortable sharing information
see redistribution of power as victory, not surrender
readily accept ambiguity
honor intuition as well as pure rationality
be inherently flexible
If this list of attributes sounds spot-on to you, this may surprise you—it is Rosener's list of qualities of women leaders as cited by Tom Peters in Leadership: inspire, liberate, achieve (2005)!
Ok, now hear what Tom Peters has to say about men (also in Leadership: inspire, liberate, achieve, p.101):
Guys like rules
They like commanding and controlling
They like "knowing their places"
They like hierarchical structures and the certainties associated therewith
Isn't this better if we say "some guys"? Or is it that some of the people that gravitate into management positions in organizations characterized by strong dominance hierarchies have these attributes? Certainly in the software community we brook no pedestals! And the software community is predominantly (65% or more, right?) made up of men.
So let's take away the men versus women brackets, and simply say some people have the predilections in the first list, and some in the second. It makes it pretty clear there'd be a good set of arrows being directed from the tower of the second proclivity towards the flatlanders in the first.
Now, if your organizational landscape is cleft this way, the higher you go on the architect career ladder, the more likely it is that you have to work effectively with both worlds—the world of consensus and collaborative leadership styles, and the world of hierarchy; the world of engineers and the world of managers. This is not to say every management hierarchy is a dominance hierarchy; but it is often enough that it is something to think about.
It is worth noting too, that in the management space there is increasing recognition of the value in the collaborative leadership style, and soft skills, like storytelling—or "business narratives." Many men held to be exemplary leaders in modern business have this leadership style. Still, what Tom Peters is saying is that there is something to be learned from those pink types. As far as I'm concerned, if there's anything to learn from me, it's because I have a bigger challenge retrofitting myself with soft skills, so I have to pay particular attention!
See also Built to Last: Successful Habits of Visionary Companies, by Collins and Porras (of Good to Great fame). Aside: I need to add these to our Recommended Books lists, but I'm not sure whether to put them under Leadership or Strategy, or do I need to create a new section on Organizational Architecture and put them there?
9/10/07 Software Architecture Workshop in DC
I have been so busy I haven't done anything to let people know about the upcoming Software Architecture Workshop near Washington, DC, in early October, and the enrollment numbers are suffering as a result. So, if you know anyone who could be interested, this would be a great time to say something really nice about the class to them!
9/11/07 Carrots Anyone?
Given my recent scribbles on "recognition: pay your way with kudos," I noticed The Carrot Principle: How the Best Managers Use Recognition to Engage Their Employees, Retain Talent, and Drive Performance by Adrian Gostick and Chester Elton (2007). Not that I'm recommending it—I didn't buy it myself. But I did glance through it. Can anyone explain to me the tax implications of paying for a maid-service to clean a high-contribution employee's house for a month???
So, what better ideas are there? Here's an idea that pays you back. Ask engineers what they are doing that they feel especially proud of. Make these contributions visible in a way that makes it clear you appreciate and value them—collect best practices and put them to the community as part of a bootstrapping program that raises the bar for everyone.
By getting more tuned to what individuals are proud of, we get better insight into what they are passionate about. But more, that is where they are generally most informed, most deserving of recognition. The onus on you to find what to recognize is diminished considerably!
Oh, are you groaning "Ruth, give me a break, this stuff is for managers. Look, it's even in the title of that Carrot Principle book"? Well, ok, ... but you also tell me you want to learn how to influence without authority... You may not have positional power in the classic carrots and stick sense. But you are held in high regard, and you do have positional power from the point of view that recognition from you carries more weight because you are seen as a leader in your community. (Or you will be, once I'm done messing with you. :)
The more you give away in terms of genuine recognition and kudos, the more you will have people wanting to work with you because you build them up. Yes, managers need to pay attention to developing the people on their teams. But my point is that when you give kudos to others, you open up a space to influence, persuade, and demonstrate leadership. Being humble is not the same thing as having a credibility deficit! I realize that when we work in a world that is predominantly controlled by dominance hierarchies, we have to play out some of the associated behaviors. But two things are true: i. much of the corporate world is shifting away from strong dominance hierarchies towards more collaborative-network-styled organizations; and ii. you gain credibility through your successes, and you will accomplish bigger things if you are effective working with and through others.
9/11/07 Room to Read
Well, well, apparently my efforts to market Leaving Microsoft have been awesomely successful:
"Chosen by Amazon as one of the "Top Ten Business Narratives of 2006" and since translated into 15 languages, Leaving Microsoft to Change the World has motivated thousands of people across the globe to become part of the Room to Read movement. In the one-year since the original hard copy was released, we have tripled our number of fund-raising chapters, and increased our annual fund-raising by over 60%! Thanks to this remarkable generosity, Room to Read will establish its 5000th library by the end of 2007."
Before I consider this chapter of my job closed on a successful note, hear ye this
"But we're not stopping there - the paperback version of John's inspiring memoir is in stores now - so an even greater audience will be introduced to the book Publisher's Weekly describes as "an infectiously inspiring read."
We kindly request your help in sharing the Room to Read story. Please tell your friends, family, and co-workers that the soft cover is in bookstores now! We hope to get tens of thousands of people to read it and to then support our work in bringing the lifelong gift of education to kids across the developing world.
The book should be "front of store" in most Barnes & Noble and Borders outlets. B&N.com has special "bulk pricing" for orders of 50 or more, and is even giving 5% of revenue from sales of the book to Room to Read! (www.bn.com/roomtoread). And, as usual, Giveline (www.giveline.org/roomtoread) continues its incredible support of Room to Read by donating a percentage of sales."
Room To Read newsgram, 9/11/07
Ok, so I can't really claim any part of this amazing momentum, but... if you didn't read the book, why not? Don't I have any influence? Sigh... It is an inspiring account of leadership and pursuit of a vision, complete with detractors and ... messy trunks.
9/12/07 More Carrots?
No thanks? But wait, here's a good one. It comes from James Madison (and no doubt others before him): Have someone else present the architecture (even if you view it as your work). But be sure you've done your part of this, freely giving the person insight into the thinking that drove the decisions he/she'll be presenting. To present the architecture and field questions, they will need to be sure they understand it. Of course, someone who would use this speaking opportunity to rip into what they don't like about the architecture, has to be guarded against. Find advocates. But don't forget to look among detractors—context (competitive landscape, architecture/technology roadmaps, etc.), a sense of urgency, a sense that they can play a role in swinging the course of the project and organizational history, may bring them around.
At any rate, presenting the architecture and leading discussions around it is an opportunity to play a visible role, which is a kind of reward; it communicates valued contribution. Yes, it means sharing credit. But if you want others to share the burden of creating a great architecture and making it successful, then there is credit to go around anyway. If you want it all, work in isolation to create a great architecture—but expect to have to work in isolation to get the great system built with that architecture too!
For those who share visibility and credit like this, it is an obvious thing to do. For those who don't, it feels like it will threaten perceptions about who's in control, who made the real contribution, and so forth. But leaders set the tone—you can choose to set a collaborative tone, or not.
9/13/07 Who Needs Carrots Anyway?
I have had the pleasure of working with several very strong architects and chief architects who have "defected" to the management track. Now they find they can be more effective architects (yes!), and drive cross-business unit solutions more successfully. Given the lines of communication and the lines of power, architecture in their various organizations (government and business) is relegated to a "sideline cheering activity without authority."
And I've worked with an architecture program manager who wants to move back into a chief architect role. I warned him that he will truly suffer the loss of power, the power to affect change across businesses, but he wants to be more concerned with the development of technical systems and less concerned with people development.
Of course, we see engineers migrating to the technical management track, and managers deciding enough already and moving back to developer roles. So why worry? We expect these career transitions. But when architects have to move to a management career track to be more effective architects, that is to better influence what gets built, this is a symptom of an architectural fiefdom in the management domain. Good managers are, and see themselves as, organizational architects. Still, we have to remember Conway's Law: if the architecture of the organization and the architecture of the system are at odds, the architecture of the organization wins. While the management stack controls what happens in system development, the organizational architects determine the system architecture. This scuttles software/system architects into the aforesaid cheerleading (going forward) and reactive, crisis-fighting paradigms (retroactive).
You know the iron triangle of project management, of course. Who owns decisions about the tradeoffs that must be made, because we inherently get to set only two of these dimensions and take the third as constraint?
The iron triangle is one of the key interfaces between the organizational architects (management) and the product/application architects. If it is not architected across, the organizational architecture wins. Full stop. No need to worry about carrots any more, except that they'll make you a better cheer leader.
Why, you cry in disgust, am I telling you? You know this! At least you feel it. But since I don't generally get to talk to your managers, while you do, you have to develop awareness of the touchpoints between organizational architecture and product/application/solution architecture.
Um, just so you're aware—my journal is not the right forum for managers (except for the exceptionally smart, investigative, open ones who are reading this ;)—here I talk to myself (primarily) and to (a few) architects. If managers or developers stumble here, they may take offense at my bias to promoting the interests of architects. I do it because organizational forces are so pervasively set against architects, putting the role at a veritable cross-fire from turf-protecting clansmen, that I have become the self-appointed champion of architects. Grin. You don't take my effusive rhetoric seriously do you? I tend to forget, once in a while, someone new to my style might be wandering through this...
9/13/07 Lessons in Dynamic, Collaborative Teaming
Have you read The Goal? It was required reading back when I was doing an MBA almost two (gasp) decades ago. It is still a pivotal book in the Lean movement. I’ve been telling architects that The Wheel on the School (a children’s story) is the hidden jewel of that genre—namely novelization of business fundamentals. I believe it could be a pivotal book in the networked, collaborative dynamic teaming movement. Is there such a movement? In software development, we see it instantiated in Agile development. But we see this in other areas too—for example, books, articles and blogs about leaders in prominence today, fête collaborative leadership styles.
The Wheel is about vision and teaming, and how core team members, with a shared vision and powerful vision stories, become the hubs around which flexible, fluid teams of teams form—like cogs, working together. Clearly Goldratt wrote with the purpose of promulgating and elucidating lean/flexible factory concepts and practices, while DeJong was ostensibly writing a children’s story. But this is the magic—it leaves it up to us to make sense of the lessons, and there are many! Did DeJong intend this? Frankly, I don’t care if it is pure serendipity. We are better served asking ourselves "what did I learn?" than asking "what, if anything, was I supposed to learn?" The second is passive-aggressive and defuses our attention, excusing disengagement.
So, what did I learn, that excites me so? Let's begin at the beginning:
Ch 1: Do you know about storks?
Lina, the only girl in a school of six children, on her own initiative, writes an essay titled "Do you know about storks?" Her essay plants the seeds of a vision. This is from the end of the chapter:
Eelka raised his hand. "But I'm afraid I can't think much about storks when I don't know much about storks. I'd be through in a minute."
Everybody laughed, but the teachers eyes were pleased. "True, true," he said. "That's right, Eelka. We can't think much when we don't know much. But we can wonder! From now until tomorrow morning when you come to school again, will you do that? Will you wonder why and wonder why? Will you wonder why storks don't come to Shora to build their nests on the roofs, the way they do in the villages around? For sometimes when we wonder, we can make things begin to happen.
If you do that—then school is out right now!"
So the team is chartered to wonder why, and given resources (time) to do so! And so, powered by wondering, the wheel within the wheel of the book starts to turn, and things start to happen.
But there's more. The teachers eyes were pleased. The teacher was not phased by the pragmatic engineering response — I don't know much; I'd be done (unsuccessful, but done) in a minute. No, he saw it as an opportunity to clarify what he wanted—to wonder. Not to think about what we do know. But to wonder about what we don't know.
There's an opportunity we are just starting to glimpse, and we don't know yet what the opportunity or the solution is. So we need to wonder. To put aside our preconceptions and what we know and just wonder. Wonder why.
Isn't that great? Isn't that just the essence of getting started with a new development initiative? We tend to get all focused on what we know; try to find the safe ground. We need to be given encouragement and resources to wonder. Not for too long. Just until the next day.
And a benevolent manager and coach (the teacher). How nice!
So, your assignment is to read chapter 1 and 2, and tell me what you learned! If you don't, why I'll, I'll (to quote an architect we worked with) "just have to hit you with my ... feather!"
This last is an allusion to the "architect with a baseball bat" pattern in our Architecture Teams piece.
Here's a neat story about what happens when you wonder, well, if you're Jobs and Co., that is.
9/13/07 Innovator's Solution
I'm wrestling with Innovator's Solution. I suppose it's good... But three books out of one graph seems a little over-strained... Even if it is a graph that I find "challenging." Ok, so performance is really feature set (functionality and quality attributes), or quality, or even performance... I can grok that. I had to do some work there, that Christensen could have saved me... but that's ok. I don't mind exercising the brain cells. But... why are the sustaining lines always drawn at the same angle, like technology learning rates are the same (and always linear?) for the original innovation as they are for disruptive innovations? And what is the interpretation if the lines cross? And what about the fact that price-performance shifts along the technology learning/improvement curve, so the customer utilization curve is tied (dependent; shifts in relation to) to the technology learning curve. And, and, and... I suppose I have to go back to the Innovator's Dilemma and see if this is explained there...
9/14/07 Problem Solving
What is the largest number of pieces you can cut a pie into, using 4 straight cuts?
If your doctor gives you 5 pills and tells you to take them 1 every half hour, how long will it be until you've taken them all?
How do you solve these problems? They become trivial as soon as you draw a model. Visualization. The "obvious" answer that comes to mind, dissolves as soon as you express it visually.
Speaking of visualization, have you used Quintura to search? Pretty cool!
9/14/07 Carrots or... Snake-oil
Daniel reminded me that we don't like insincere and manipulative behavior in ourselves or others. Engineers are a diverse bunch, but if there is one thing that is common, it is a nose for cheap manipulative tricks, and an aversion for the slimy perpetrators. Insincere, happy-happy, glibly-profuse-with-praise types have engineers' antibodies lining up in isolate-and-disgorge-the-foreign-invader mode. The level-setting forces in communities are quite powerful. Among kids, we call it "peer-pressure" but the desire to fit in, and the converse, the community pressure on those who stand out, is subtle but omnipresent. Those who exchange technical focus and associated credence, for resource focus and associated power, moving to the management ladder, can stand out as leaders. But in the technical community "consensus" (an instantiation of the equity principle, or, "no-one should have more decision power than me") is the order of the day. That's a generalization. Forceful statements always are. (Yes, I intend the irony.) Yet, when an architect leads, emerges as a leader despite these leveling counter-forces, they are great. They accomplish amazing things—with and through other people. It is not easy for them. The structures, the reward streams, the budgets, everything, everything, is set up to make the technically-based person retrench into the technical individual contributor space.
So, we have to ask ourselves, are we trying to manipulate when we set a strong example of collaborative behavior for our architecture team members, and development team members to follow? Are we trying to manipulate if we make our teams a great place to spend the biggest single chunk of each waking (work)day?
Teams are about shared responsibility. So what about shared credit?
Genuine appreciation and shared credit are not glib, manipulative tricks to subdue engineers into passive acquiescence! The giver of genuine recognition gives something of themselves. This is not snake-oil. And it's not a Derren Brown stunt!
Perhaps we need to re-evaluate the biases that living/surviving/thriving in a cut-to-the-chase engineering culture reinforces. When pizza arrives unexpectedly for the team, does the team feel threatened by undercurrents of manipulation. Or champagne at the product release? When credit, or a celebration, or whatever shape the kudos take, are felt to be deserved, they don't send the signals that insincere gestures send.
So, be sincere. But be open to finding the good in what other people are doing, so you can acknowledge that contribution to yourself, and acknowledge it to that person, and where relevant/possible, to the community.
For me, the big hurdle is not fear that I'll be perceived to be smarmy. (Oh gosh—I'm not, am I???) Instead, I have to battle my tendency to say "let them manage their own internal state; I manage mine." I'm able to self-motivate prodigious productivity (and compliment myself on it, as you see) without explicit external reinforcement. And it erodes my productivity if I have to spend time understanding and finding value in another person. But collaboration, teamwork, is about relationships. I'm not talking roses and rings. There are other kinds of relationships! Leadership, especially collaborative leadership, means relationships, and just like rings don't guarantee maintenance of relationships, being a nominal leader doesn't guarantee sustaining relationships.
Enthusiasm, energy, passion, all these things can exist in individuals without any community reinforcement. But leaders are in a position to foster them, and the leader's position is strengthened when the leader recognizes that commitment of passion is optional. Work is not. But passion makes the difference between just a job and pursuit of excellence.
If you want to influence my priority stack, and you see me, see what I stand for, appreciate that, why, you get bumped up. Because I get to choose much of what I take on. I am the most powerful influence on how my time gets spent each day, and your sincere appreciation influences me. So, if you say something nice but obviously cheap, something that didn't cost you anything, well you might get 5 minutes for your trouble. But if you say something that reflects you invested, you understand and value what I'm trying to do (or you don't understand but genuinely hope that I might have something important you're just missing), well you could get cycles I didn't think I had; told clients I don't have. So, then, did you manipulate me if you took advantage of that? That depends. It depends on your orientation. It depends on what you are trying to gain, and how you go about it. And it depends on me. It depends on stories I tell myself about what you are doing.
Watch for the stories that circulate around you. Are people projecting you as a leader, or simply a technical expert? A go-to person for a tough problem? A go-to person to lead the technical community to excellence? The second takes much more than the first. Not snake-oil. No insincere flattery. But inspiration and motivation. And so you get back to how do you motivate without the (direct) prospect of putting more carrots in the payroll? One way is to include people in driving to excellence, and include them in the visibility, the recognition, the rewards of achieving excellence. Excellence is best known after the fact, so you have to find the signals of excellence along the way, and reward for them as you go. Reward with recognition.
We can choose to think of this (with a shudder) as carrots or kudos, or simple relationship management, or just the stuff of collaborative teaming.
The essential point remains. Genuine, deserved, recognition is motivating. Leaders can harness this insight to make the work more fun and more fulfilling, to make the team a great place to shed months and even years in. Great because it feels good to get excellent work done, to be a meaningful and recognized part of something big.
Ok, that's more than enough of that... but I do have to tell one little story. When I was a teenager my mother went on a strict and strange diet. Carrots. I kid you not! She ate carrots. Whenever she wanted to eat something, she ate a carrot. She turned orange! So, carrots are essential; help you see in the dark. But too many carrots and you turn orange. Literally!
Let's end this on a note that may be more satisfying. Last year I mentioned that Brad Culter prefers the image of technology statesman. Statesman—that has the air of ethics and greatness that we want associated with the architect role!
I thought this has to be a topic leadership bloggers go after, and yes, here's the best of my time-boxed scan:
Mike Griffiths, Developing Authentic Leadership, Leading Answers blog on Agile project management, 9/5/2007 Mike's latest post on a visual project dashboard (that's what I call it) is good too. Can you see doing this with architecture qualities?
And the title of this book sounds pertinent to many of us: The Contrarian's Guide to Leadership, by Stephen Sample. It's on the US Coast Guard's Leadership books list.
9/15/07 Detractors are a Drag
Mike Griffiths visualization of the net negative contribution of project resistors is exquisite in its communicative power. I've been on projects where the detractor caused more damage than shown in Mike's illustrative instance, but of course we know each project is going to have its own graph. This relates to an application of the Pareto principle that Howard Gardner refers to in Changing Minds—the bottom 20% of the workforce causes 80% of the trouble (p. 8). We could accept this as "life" and get rid of the trouble-makers, or at least sideline them where they can do no/less harm. Or we could take it as a challenge to draw people along, of change minds, align the team and imbue them with infectious enthusiasm.
9/15/07 Changing Minds
I'm only a few chapters into Changing Minds; I'm enjoying it. Gardner indicates that our natural tendency is to treat everything and everyone as equal (the Equity Principle) and introduces the Pareto Principle as an example of something that takes a change of mind(set). Given my post yesterday, this is interesting:
"Evolutionary psychologists go so far as to claim that this "equity principle" is part of the mental architecture of our species." (p.10)
I've pointed out that in the Visual Architecting Process we've sifted for techniques that help Pareto the work, so this struck me:
'It is important to be judicious about where one places one's efforts, and to be alert to "tipping points" that abruptly bring a goal within (or beyond) reach. Conversely, one should avoid the natural temptation to inject equal amounts of energy into every part of a task, problem, project, or hobby;...' (p.8)
As for Gardner's main thrust: changing minds takes some part reason and rational argument, and some part representation in different forms. Then there's research, and resonance (yes, pathos, including stories, matters), and resources and rewards (oh boy, carrots!), and real world events. And mind changing attempts encounter resistance.
I like reading Gardner because he is smart and he assumes his reader is smart and he doesn't fool around equivocating on whether leaders should be smart. He comes right out with it—and more—he is clear that the leader needs to have different kinds of intelligence:
(s)he needs to be gifted linguistically (be good a storyteller),
have interpersonal intelligence (the carrots and kudos thing: understand and motivate people, listen to them, respond to their needs and aspirations),
have existential intelligence: be comfortable posing and pondering the fundamental questions—Who are we? Why are we here? What is it all about? In the larger context of our lives this has to do with "spiritual" investigation and growth, finding meaning in our lives, but in the workplace is important too, and has to do with finding meaning in work. It has to do with "that vision thing."
There's more (p.108)... including logical-mathematical intelligence... Gardner points out, though we may not like this, experience proves that a leader in politics or entertainment may get along without logical-mathematical intelligence, though there charismatic intelligence is important.
My enthusiasm for enthusiasm is quite drained... Some music, I think... I pick Dave Matthews: Proudest Monkey... Hmm...
[9/16/07] back to Gardner's intelligences of leaders:
We may not want to call some of these attributes "intelligence," though Daniel Goleman brought to the business masses the notion of emotional intelligence and social intelligence. (This notion doesn't seem, for example, to have reached Nassim Taleb, at least not the Taleb of Fooled by Randomness vintage.)
I (somewhat) like the notion that there are different kinds of "intelligence," as it allows us to explain the success of different personality and cognitive styles in different areas. I think it is worth calling out in its own category the "big picture" thinkers, people who are good at discovering and exploring the connections, relationships and interactions among things—the "web thinkers," or "system thinkers," if you like. This is an ability that is especially important for system architects, naturally.
While I generally like Gardner's treatise (as far as I've read), I don't always agree with everything he writes (as a flatlander, institutional authority doesn't cower my intelligence into subservient acquiescence). For example, in my experience I don't see people who are peaked on logical-mathematical intelligence (e.g. statisticians) being necessarily more adept at seeing down-the-road, thinking in terms of future scenarios and rolling that back as implications for decisions taken today. Given different scenarios, the statistician can create a descriptive model (albeit with simplifying assumptions), and sometimes even a predictive model (again, assuming away much of the real world complexity). That's not the same thing as being good at finding the scenarios that matter. Even though Taleb gives short-shrift to those with non-traditional intelligence (for most, our traditional concept of intelligence would reduce to logical-mathematical intelligence and linguistic intelligence), he does recognize that those with traditional intelligence can be—and often are—misled by randomness. As I see it, Fooled by Randomness, Stumbling on Happiness, The Art of the Long View, even The Great Deluge (which is a look back at what happens when a leader isn't a forward thinker), and on and on, draw out the important role to be played by the people who are "forward" thinkers. This is an ability that is especially important for leaders, for leadership is about how we move into the future.
One thing that occurs to me... I'm an integrative thinker (for example, the more I read, the more I write—on related and entirely different topics). My mental models are constantly shifting as I encounter new ideas and material. Sometimes it's a subtle shift, and sometimes it is big leap to a new position. Adding "existential intelligence" to my concept set is integrative and incremental, for example. And there are people who are much like me in this respect—the people who much like me, I guess. So I'm intrigued to read more and discover why Gardner is adamant that people change their minds less, become more resistant to mind change, as the years pass. Is flexibility another one of those attributes that differs across the various casts of the human brain?
[9/20/07: I told Sara she'd better hurry up and be more flexible, for time is running out on her window of mind-changing flexibility. She tried pesto-chicken pizza. She likes pesto. She likes chicken. She'd always had plain cheese pizza, and was deeply entrenched in her position on pizza. She was very proud of herself for trying something new. Hmmm... back to the drawing board Dr. Gardner? There is a discipline within the sociology of organizations that sees companies as made up of competency bundles tuned around the company's primary functions and markets. The Darwinian adaptation to historical markets, renders the company inert and sluggish in taking advantage of market shifts, especially shifts that require new competency bundles. Oh yes, this is why eagles don't swim. And it's the innovator's dilemma.]
9/16/07 Pareto the Work: Doing What Matters
Doing What Matters is a book I haven't bought yet, but I did toy with it and will get around to it I think. It is about a manufacturing company (Gilette), but as Kristen Sanders is gently leading me to recognize (again; for this was my role on the Flexible Factory Project, given my background in both software development and operations research), there are lessons from manufacturing, especially lean, that are relevant to software system development. Some translation required of course. But "Do What Matters" sounds like a good catchy name for a key guiding principle of Visual Architecting!
I did get through the first chapter or two squatting in the aisle at Barnes and Nibble. The "quick screen" is certainly one to add to the Pareto toolkit.
9/16/07 Basics in Architecture
No, this is not a reference back to Sara's Architecture Basics/architecture definition in the first post of September! Take a look at this set from Birkhauser. What would the main titles in a "Basics of Architecture" series in software architecture be?
9/17/07 What Can Go Wrong, Will Go Wrong, so let's at least smile about it!
The BodenUSA site (Boden is a British clothing company that is making successful incursions into US online retaildom) hiccupped and spit this out:
"B is for Bit of a boo boo
It could well be for one of the following reasons;
There is a programming error on one of our pages (sorry, we’ll fix it).
Our server got up on the wrong side of its bed and is having one of those days.
We forgot to align the warp drive, and now she cannae take it, Captain!
You might try one of the following options;
Return to our Homepage, or one of the appropriate links on this page.
Press the Back Button, and try another link.
Use either of the Search functions at the top of the page.
Phone our call centre on 1-866-206-9508.
Reverse the polarity of your dilithium crystals, or alternative etheric rectifier for Warp Field energies, and try again.
We apologise for any inconvenience or confusion. An email has automatically been sent to us so we can investigate the problem."
source: www.bodenusa.com, 9/17/07
This made my day! Way to go Brits! A dollop of humor when you hit a rough spot goes a long way to saving grace.
OK, so I tried a different tack, and this time I got:
"ADODB.Field error '800a0bcd'
Either BOF or EOF is True, or the current record has been deleted. Requested operation requires a current record.
/col.asp, line 1793"
source: www.bodenusa.com, 9/17/07
So, I see inconsistent error handling, and two developers, on these two separate (but attempting to access the same data item) parts of the system. If you were the architect, what would you do?
Delight is architecturally significant. So is error handling strategy. Our systems all get into scrapes now and then. Bleeding error status in a user visible way is so... ER. A humor band-aid with some "how to treat this at home" instructions is... well, delightful.
It's not ok to deflect this with "that's all very well for a British site selling to moms"... or "that'll get old real quick" ... or whatever ... The point isn't that we should all copy the content of this example.
The point is that humor, energy, and enthusiasm are the fuel of goodwill.
Goodwill and delight. Properties to strive for. In our teams and in our products.
Rah, rah, rhetoric. Be great. All that.
Well, I've got to go get a drink from the enthusiasm fountain myself. Anyone know where it is?
9/18/07 Architecture and the Quest for Agile
I adapted a journal entry from last month into a blog post titled Architecture and the Agile Quest.
9/18/07 How EBay Addresses Operational Manageability at Scale
I found this interesting: Ebay's Dan Pritchett on video at InfoQ addressing operational manageability.
And this (guess PayPal isn't Dan's baby...): Reflections on the Fragile Internet Ecosystem, Christopher Hoff, 9/2/07. Hoff has a great security-focused blog.
I guess, power will be the hallmark of on-line stardom. You've made it when... you can't get enough power!
9/18/07 Tech-stars Are Talking
Todd Hoff has collected together state-of-play links to architectures of high-profile systems. These from his Flickr collection:
Building Scalable Websites (book) by Cal Henderson, leveraging lessons learned building Flickr
Slides from Cal Henderson's talks
Federation at Flickr: A tour of the Flickr architecture, blog post notes from talk
We're all going to benefit from this wave of tech stars talking about their architectures. I'm so excited to have these conversations in the open space. If Grady Booch doesn't hurry up, it's all going to be a done-deal—top architects from all manner of companies are talking, publishing, and blogging. Companies have woken up to the social networking revolution, and are sending their architects out as emissaries of goodwill and branding as leaders in high tech stardom. Still, all this goes not much further than skin-deep; often focuses on infrastructure architecture with allusions to the impact on software architecture, but no real drawing back the covers.
So I believe that HelpMatch is a critical project, not just because it will help people who need help but because it is an open and fully observable effort. Which reminds me—once this gains any kind of momentum, I want to keep snapshots of the architecture state, so that we have a historical trace of the strategy and architecture decision set. If we can create a great system that democratizes help, that extends the help continuum from charitable institutions all the way to one-on-one help, the architecture work that led to it will be very useful to novice architects seeking to learn how to create great architectures, or seasoned architects seeking to validate and improve what they do.
9/18/07 Better Carrots
I probably dealt with the whole carrots thing better and more succinctly in this "collaborative partnerships" post last year!
9/18/07 Brain Candy
TV is not my brain candy of choice, but I'm not a strict puritanical sort; today I bought a little brain candy, but mine was in the form of a book called Thinkertoys. I scanned it and one line caught my eye—I'm paraphrasing (don't have the book with me): We're all moving into the future at 60 minutes an hour. It sounds fast, when you put it like that! ☺ It went on to make the point that we need to think about future scenarios, but this was the twist—we need to think about multiple future scenarios. The author (names just have no stickiness on me) talks about growing strawberries. We wouldn't just grow one plant if we wanted a strawberry. We'd grow several, to allow for contingencies. Another snippet (again paraphrased)—write down what you think because nobody else has written a Cliff Notes study guide on your thoughts. I thought that was a great one given my kick on documenting your architecture thinking as you go.
Anyone read Risk Intelligence: Learning how to manage what we don't know? I just came across it. If you read it, do you recommend it; does it speak to architects?
Looking at Reich's review of Cracking Creativity on Amazon to see if it was worth toying with, I was struck by this:
"For example, pg.42 there is an experiment where students were separated into two groups. The groups were asked to read a passage of the Kansas-Nebraska Act. One group was asked to simply learn the passage and the other group were asked to read from "multiple perspectives," example: an author's perspective, another person perspective, also including their own perspective. Which group learned more information? Of course, the group that used multiple perspectives outperformed the other group. Furthermore Michael elaborates on this process and places many ideas on the table. He called this subchapter "Da Vinci's Multiple Perspectives," further along the chapter he elaborates "Take on a Different Role," then "Imagine You Are the Problem" and many more areas further along that blend to create a vast pool of creative thinking."
Perspectives. Ok, the theme of taking on the customer's perspective is also strong in Hidden in Plain Sight—did I mention I've been reading that? Oh well, not enough time for everything! And in The Wheel on the School, Lina learns she needs to think like a stork, to know what a stork would want.
In our workshops, when we're doing Stakeholder Profiles, we role-play the various stakeholders (when they're not available in-person) and in the debrief following this exercise, people often make the point that "being" the stakeholder, seeing from their perspective, really reshapes their own sense of value and priorities, helps see new opportunities, because the reference point shifts.
I'm reading Outside Innovation. Yes, ... 3 or 4 books at once... I'm certainly acquisitive in the idea space. But, I also have to spend a fair amount of time in holding patterns. Literally in transit, but also waiting for ballet auditions, rehearsals, lessons, the endless juggle of life on and off the road. And I just like to investigate, explore, discover; it fuels the creative process to collaborate, albeit asynchronously, with another thinker.
I read most of Gardner's Changing Minds; jump-skipped through some of the most barfy stuff (ok, so the first thing that got me was Gardner saying that Cisco CEO Chambers was full of hyperbole on the internet changing people's lives), but still, I enjoyed much of it.
No silver bullets on persuasion though. Drat!
Gardner had an opportunity he didn't fully capitalize on. He introduces mind changing as changing the intellect, not just changing one's own or another's orientation to something. But he doesn't drive out these distinctions as well as he might have. Much of the stuff I've seen on persuasion can be mapped onto Aristotle's ethos, logos and pathos, leaving the feeling that there's not much new going on in the persuasion space. I think Gardner does make a contribution to actionable mechanisms of persuasion: for example, there's presenting new mental models, new representations, to change perception or understanding and allow a shift in orientation or stance or position.
But because Gardner doesn't draw out the differences between mind changing as changing mental capacity or intellect and mind changing as persuasion and influence, he leaves questions on the table. Like, does he say children change their minds more easily than adults because children learn more easily, change mental models, even go through significant changes in brain structure, not just knowledge foment? Or does he mean children are more flexible, more readily persuaded? Or both?
As usual, Dana is still the best source of actionable advice! He's been telling architects "value before resistance"—establish clear and compelling value before resistance has a chance to root itself. We have long been telling the story of Jaime Lerner in creating the down-town pedestrian mall in Curitiba, Brazil. It is a classic in the value before resistance paradigm! Of course, when I tell the story, I sometimes get pushback from those burned by the "ship-the-prototype" mentality in software. But, sigh, the lesson is still the lesson! Find the value. And find a way to quickly demonstrate that you can make real on it. Cereal boxes and duck tape can do it.
We watched Apollo 13 with Ryan. If you're still resisting The Wheel, do at least watch Apollo 13 again. Lots there to draw on. Even duck tape!
9/24/07 Life as a Journey
I looked in on Booch's blog and bounced from there to Randy Pausch's lecture, the first in Carnegie Mellon's Journey series. Randy, creator of Alice, takes as his theme his childhood dreams and his reflections on achieving them, or not, and what that taught him. This is poignant, given that Randy is living with a cancer death sentence, given just 2-5 more "healthy" months. This setting is sad, but it reminds us to do what is important. To have dreams and follow them. To realize them. Randy shares a number of important lessons.
Booch highlights interesting tidbits from time to time. It would be interesting if he would reflect more on them. He quotes Randy Pausch:
"We found that when we targeted Alice as a storytelling vehicle, girls were three times as likely to be engaged and motivated to write computer software, as opposed to just moving 3-D characters around."
What have you done to support and encourage women to enter and stay in software engineering?
9/25/07 Gold Carrots
Saranavan made my day—this by email:
"I am writing to say how much I like what you are doing in bredemeyer.com and traceinthesand.com. Keep going, it is inspiring and very useful!"
In Outside Innovation, Patricia Seybold writes:
"We humans are ego-driven, craving approval and accolades."
We humans? She doesn't know our dog! Anyway, Seybold is arguing for bringing this into our business models, letting customers create content, for example, in exchange for the reward of feedback. And I'm arguing for bringing it into our team model. It takes extra energy, and I'm the first to admit that energy can be hard to find when you work with some really limp fish! Some days I find it so tempting to apply the Pareto Principle and eliminate those energy-dragging bottom 10%. But that's on a bad day. On a good day I tell myself I have to set context, provide the inspiring target, have the team set shared expectations for what it means for each of us to be in a high-performing team, and work forward with the energy that creates for all of us. I have to recognize that some people set their state more by external context than I do. I like to get approval, and hey, I expect that, if ever I were to receive them, accolades would be great. But intrinsically, Ludwig van Beethoven's words align better with my ethos:
"I have never thought of writing for reputation and honor. What I have in my heart must come out; that is the reason why I compose."
I suspect this latter is more accurate for many in the blogosphere than Seybold's tagline statement. All the same, positive feedback is a nice treat, and definitely to be encouraged!
That said, I do like Outside Innovation. That and Hidden in Plain Sight. Of course, both are preaching from the same choir book that I've been using; or something like that. We each make complementary points, and taken together there is, I believe, real substance for building winning value.
Just like you don't agree with everything I write, I don't agree with everything I read. Mostly it's because I'm just too stupid and narrow-minded and set in my ways. Oh, now I have you agreeing with me, do I? Aw shucks. In one book I scanned a while back there was but one line that stood out; I'm paraphrasing—a book (or website?) is worthwhile if it leaves you changed. I guess Gardner's Changing Minds left me changed. But Hidden in Plain Sight is my passion du jour. Joachimsthaler even writes like me! Some might say racy (that would be me), and some might say flowery (that would be you). But he rates passion, desire, dreams, fears, all equal citizens in the demand ecosystem that we need to pay attention to when we're looking for opportunities to create customer advantage (or in my lingo, delight).
Now... it's time for closing chapters of Tom Sawyer.
9/26/07 Chartered to Wonder
I've heard it said that Google gives developers Fridays to wonder. I wanted to find out more, so I Googled "Fridays at Google." I didn't find anything interesting on the first page of results, so I Yahoo'd "Fridays at Google". Grin. And came up with this piece of Google's history (from 2002, when Google had 300 employees!): "How Google searches itself." More interesting still: Google on Innovation (August 2007). Marissa Mayer has made a history of innovation at Google.
I like Mayer's point number 3: "You're brilliant; we're hiring!" When I read Scott Berkun's observations in his description of sneaking in on a Google site tour, I'm thinking—bosh Scott, they've designed for the kind of people they want to attract and hire. They've designed to be seen as top-dog in the innovation game, so they attract the people who want to live with that identity and who are smart enough to qualify for the tech elite equivalent of top team in the NFL. It isn't necessarily true that they think the building and interior decorating will generate innovation, but it will attract the people who will innovate. It says, let's wonder. Let's be unencumbered. And it says we're it; we're the design elite. If you set the whole system up for innovation, from physical environment to expectations that everyone spends 20% of their time on their own projects to who gets interviewed and who gets hired, to who gets promoted to Vice President of Search Products and User Experience at Google, then you get innovation. You get innovation that defies all of Clayton Christensen's models!
Which is not to say that Google doesn't miss opportunities!
I mentioned we watched Apollo 13 (again; it has been a while). What struck me about Apollo 13 and about what is happening in the blogosphere and around the I-way is that engineers, yes even software engineers, are the modern-day heroes, the stars of our culture. We are on an innovation kick, a product as object of desire kick. I saw iChairs on the cover of a teen-catalog! Yes, iChairs! The iPod revolution integrated into teen furniture, if you please! And the stars of high-tech are getting to come out of the corporate closet and reveal themselves as the stars they are. Of course, they are stars standing on the shoulders of giants, and they should be giving full credit to their backdrop of engineers and managers who really make things happen. But the architects or chief designers deserve what moments they get in the spotlight because great products are built by great teams and great teams have great leaders. This may not always feel true, within the broil of the team (or even the unteam), but greatness is an honor bestowed by success.
Chris Bangle, former chief designer at BMW, reportedly said "Engineers make the world happen. The role of the designer is to give them focus." I liked this interview with Adrian van Hooydonk, BMW's chief designer. I bounced around a bit and landed on these quotes from Chris Bangle:
'"In the future, everyone will be a designer." Sites like Kinkos would become mini-factories of rapid prototyping, where people could go in, design the latest cell phone - and then "print it out." That's the future!'
That's the future—"where design will become as important as literacy." How do we prepare our children for that? Our school systems are seriously deficient in key areas: visualization, teamwork and collaboration, innovation and inventiveness. We place such a high premium on verbal expression (oral or written) and don't teach children that visualization is key to problem solving. We place a high premium on math and science, without demonstrating how and why it is important. We take a strength work-out approach to math—acting like we have a brain-muscle that must get exercised with repetition, rather than presenting problems that are challenging and so fun to solve. We have computers to do repetition. Our children need to be good at solving new kinds of problems. Montessori Schools do better than many schools, I'm sure. And we have the special privilege of a head teacher who has taught in the age 9-12 classroom for more than 20 years. So, for example, he has created a vast reservoir of "head problems" and each school day the kids start out with a sheet of "head problems" to solve. He lectures the kids like they're at college, and they absorb like sponges a vast array of knowledge that this remarkable gentleman has built up over a lifetime of investigation and learning. The children have to do research to cover the curriculum and then some. They don't have text books. They use reference books, online resources, interview experts, and so forth to build knowledge about a subject and then they (the children) share what they learned with the class; they teach their peers the state curriculum plus plus—because a child's inquisitiveness goes well beyond the bounds of the state curriculum! It's a great approach, but I can't help feeling like we could do even better preparing our children for a future where innovation is the life-stream of economic advantage and job satisfaction.
How we develop software also has to change. That's why I like the interview with Adrian van Hooydonk. We need to think in terms of multi-functional teams who are innovation and design centers. Instead, we have UI folk who drive "user experience," we have business analysts who drive "requirements capture" (like they're running around and we just have to coral them), and we have software architects who wear beepers and are the second line of defense when the ops people can't put out on-the-line fires. Like these are all separable concerns. Different beasts. For beasts we make them.
We need to look in the mirror and see ourselves as the people who are fundamentally reshaping the landscape of people's lives. This is not hyperbole Mr. Gardner. The internet has changed the world, and will continue to. And software has changed the world even more diffusely, and will continue to. It has changed how people are. How they see themselves, what they are capable of. Those of us with a modicum of artistic ability can revel in new outlets for our self-expression. Our avenues of exploration and investigation have broadened and deepened. People are connected in ever new ways.
In all this momentum we need to continue to find new opportunities, new ways to create value and delight, to ignite the passion that fuels customer-to-customer selling. Do we throw up our hands and let small new ventures spark product revolutions, or do we seek to innovate even within industry incumbents? Innovation can come from any where. Google understands this. Software developers, architects, customers, suppliers, and ... start-ups. The architect doesn't just focus the engineers. The architect focuses the design team. The hard stuff is not just about how we scale. It is about creating the value that will demand that we scale! The hard stuff is not just about innovation at any cost, it is about controlling complexity, risk, and cost, not just from the point of view of user experience but also the developers who must create and evolve the thing, and the ops teams who run it.
Yeah, scaling is a big deal, and getting bigger. It's the hot stuff tech stars talk about. But what got them into the situation where scaling is make-or-break (or, make-and-break-and-fix)? Yes, value. Value that heaps and heaps of people seek. The start-up core team understood that, took the spark of an idea and made it real. Marissa Mayer understands that. I believe the architect should lead the design team on the path to value, but at a minimum the architect needs to be sure someone is leading. Architects are in a unique position, watching trends, understanding capabilities, and knowing the downstream impact of early decisions. They bring opportunity to the table, and they bring insight into what it will take to the table. Value is born of good ideas that fit the demand ecosystem, and value has to be built. Not just once. Shareholders demand growth. Growth by innovation, by value generation, is arguably better than growth by conglomeration. Carlos Slim Helu notwithstanding.
9/27/07 Architect Jobs
A recruiter told me his client doesn't want to pay relocation expenses so is restricting their candidate search to the Bay Area. I was about to respond as follows:
Not pay for relocation… Interesting… You’re talking senior architect here; that’s equivalent to a talented senior manager on people/strategy skills but with deep technical skills as well. Yeah, there’s talent in the Bay Area—and lots of companies trying to get it. I know companies _in the Bay Area_ who have been looking for architect talent for months, and they haven’t been casting a small net either. But I know some of the people they’re hiring, and they are superb architects. Architects create capability. In the innovation game, that’s premium. But I lived in the Bay Area (Stanford grad, worked at HP Labs) and I know it’s a big puddle when it comes to high tech talent. Still, when I was there and architects hopped from one lily pad to another, they expected a signing bonus when there was no relo. I know the dotcom reset changed that for a while, but didn't expect it still to be that way.
Well, either you’ll find someone quickly (depends much on your clients identity in the tech marketplace) or they’ll come around to noticing that the rest of the world has found that architects are not so easy to grow internally, and not easy to reap off someone else’s architect tree.
But I thought better of the impulse, and scrapped the email. It's not really my place...
The market for architects is burgeoning. The fulfillment pipe is set at a trickle. With some exceptions, we haven't been doing enough internally to help technical people make the large-step transitions from developer to architect and again from architect to senior/chief architect. But this latter is a self-serving observation, so I have no credibility making it. Except that everyone who knows me, knows that I immerse myself in helping architects, mostly for no tangible gain to me.
9/27/07 Does the Tail wag the Dog?
The business world is full of functional islands and documents as the batons that get passed, and we're learning (and relearning) the hard way this is broken. Business unit islands, marketing islands, producing market requirements documents with neat hand-offs to the development team in IT or R&D. It's archaic. Fiefdoms in the modern age. Some places I've worked, these islands are on different floors, or in different buildings. No connection; no connectedness.
Agile is an approach to righting things, but comes at it from the tail end. This doesn't make sense either. We need tighter integration in the front end, to spin off the agile sprints on a sounder footing. We need better ways to do what matters, to create value and competitive distinction.
Referencing journal entries: I figure at some point, someone, somewhere, is going to find something I've written worth linking to. I know, it's a long shot. But hey, it's a world full of different people, and if I write long enough, someone is going to stumbleUpon this Trace in the Sand and be delighted enough to want to tell someone else about it. So, here's how: To link to a particular entry, I bookmark and link to section titles from the sidebar, so you can copy the shortcut (from the sidebar).