Monday, February 17, 2020

The Automated Testing Trap

A brief sidebar at the latest local Tester meetup (#GRTesters) caused a certain amount of thinking and remembering. This is the result.

Before venturing back into contract work, I was working for a large company where bosses had very definite ideas about "testing" and "automation" and "code." Some of them were quite reasonable. Some of them resulted in me, and others, pushing back really, really hard on their assertions.

I got responses like "Have you read the book {big boss} talked about? If you have, you would understand his message." Yeah, except I knew the authors of that book. We had presented at the same conferences and had taken each other's workshops. I also knew the people their work was build upon, whom they cited. So, I'm sorry. I still have no comprehension what this means.

I got pretty well ignored after that. Then I read the "new" job descriptions for people doing what I did. Oh my.

I pushed back really hard on those - You SAY you want certain skills, and somehow you ignore the skills needed to make use of the skills you say are required. I think there is a disconnect.

The Problem of Automation

To begin, I am a fan of using automation for testing. I want to use the best possible tools to make sure the best possible outcome. I want to use tools that help me do good work.

I see more and more positions for "Automation Testers" that focus on the primary development language, characteristics of the stack, tool set, Git repository and on and on. Many of these read like the job descriptions I was speaking out about a few years ago. I have kind of been pushing hard against these types of characterizations for some time. (I think that is why some folks consider me to be "anti-automation.")

Please, don't misunderstand me. Those things can be important, in some contexts for some organizations.

To paraphrase the Wendy's commercial from 1984, "Where's the testing?"

By placing the emphasis of the job descriptions, notices and search terms into the easy to understand structure used for developers, there is a disconnect. By focusing on development skills at the cost of all other skills, for example, actual skill and experience in testing, you are limiting the role you seek to fill.

More importantly, you put the product and your organization, at risk - if not potentially in mortal danger.

On Situational Awareness

After a bit of consideration, I had a thought.I realize it does not fit ALL tech type managers. Still, many I have met clearly have a mindset something like THIS when it comes to testing. It is reflected throughout development teams.

I don't place the blame for this on the "code camps" many developers are coming from. I do not place this on the colleges and universities where many more have come from and continue to come from.

Instead, I think it is a failure on many levels to understand what Software Development as a whole is. I think it is a complete failure in "situational awareness." People are not aware what the full picture is. They are focused on their little corner of it, if that.

The failure, as Sherlock Holmes would put it, is "You see, but you do not observe."

Part of this is failing to recognize there are many forms and types of "Automation." Something like a typical CI environment, running low level tests that are effectively base-line tests for core functionality, is one aspect. Building meaningful regression tests to exercise software function to cover known behaviors is another. Adding to and removing from both of these sets of test suites takes time and careful consideration.

Discounting the need for experience in testing over experience writing code is a disaster waiting to happen.

On Testing

Good Testing is not a box to be checked.
Good Testing takes careful, considered work.
Good Testing is crucial to understanding how your software product behaves before your customer gets their hands on it.

The issue I see in many, many organizations is most "leaders" of the software organization have no idea what Good Testing is, nor what is involved in achieving that. I wrote a series of blog posts on this some time ago.

Start here: You Call THAT Testing?
Then go here: The Failure of Testers
Then go here: The Failure of Management
And then go here: Testers Rising to the Challenge

Finally, there is this: Why Don't Managers Understand What Good Testing Is?

I have spent the last many, many years trying to help people understand that thinking, good, testing is impossible to be removed from good software development. Apparently it is easier to talk accept the glossy paper snake-oil people sell while sipping craft beer and artisanal cocktails.

"Automation" will not help your company, team or project. Automation driven by informed planning, driven by people trained in testing can likely help a great deal.

Sunday, February 16, 2020

Encouraging, Motivating & Cajoling: Getting people to do the job...

The local testing meet up (#GRTesters) I'm part of had an interesting discussion this past Thursday (13 Feb, 2020). We do round table discussions a fair amount of the time, which allows a reasonably free exchange of ideas - sometimes helped by locally made wine and beer, and sometimes a nice Toscana not made locally. This is based on my notes from the conversation.

The official topic of conversation was the title of this post. It came about from a conversation a few months ago around a rather vague, but troubling prospect.

How do you get people to do a job they were "voluntold" to do which they really don't want to doat all? People walk into a meeting with an uncertain subject, and find out for the next 6 months, or more, they will be "helping out" on a "special project" that is "really important" to the company. It will take a lot of work, probably some extra hours, to get this stuff done.

Oh, by the way, you also need to get your other work done on time, too. OK?

Perfect organizations don't have this issue. It seems most of us don't work in perfect organizations. Threats and intimidation tend to be counter productive. When people are put into a position they don't really want to have, how can we get good work done and keep some form of harmony in the working group? Is that possible?

THAT was the idea behind the discussion.

I was a tad concerned. There were folks from what are considered "high performing" local companies. I had visions of people looking at me as if I had three heads and had pasta stuck in my beard. (We were in a corner of a local Sicilian restaurant.)

Instead, people jumped in. Here is a summary of the discussion, because I found the results to be really interesting and potentially important.

To Start, "Short Term"

A couple of people jumped in with "Maybe not for 6 months, but shorter term things, a week or two, I've seen this work..." ideas.

One idea, was something like the company bringing in lunch three days a week for the duration of the effort - a week or two they had seen. One idea, which I've used in the past, was to relax "dress code" and other typical office goofyness. Jeans whenever, t-shirts instead of "collared shirts", snacks in the project room - ALL THE TIME.

For many companies, these are nothing new and a fair number do this all the time, anyway. For other companies, these little things can help ease the burden a bit.

For a longer effort, one participant (who works for an "all remote" company) said he had seen money help as a short term thing. Something like, the project finishes, quality is OK (by some definition of OK) and the people doing the work, giving up time away from friends and family to make this project happen and get their usual work done as well - THEY get a "piece of the action." They share in the bonus or incentive pay which managers or directors might normally expect.

This sent us down a tangent around "leadership" and what do "leaders" actually do. The energy seemed to be around the idea that if people have got pretty much any sense of professional reliability, they'll jump in and do the best work they can, without any special effort from bosses. Therefore, instead of the boss getting money, why not the people who actually made it happen?

Longer Term, ergo, Harder

One idea or term that kept getting bandied about, was "team." We took a bit of time to distinguish between "people who report to the same boss" and "people working together on a common effort."

If a group is really working as a team, at least part of this might be addressed. People pulled from their "real jobs" might get the support of others they normally work with to cover at least part of their non-project work.

The group working on the "special project" needs to actually work as a team, toward a common purpose. If there is a small group "telling people what to do" without explaining the purpose, or allowing the individuals to learn and understand the purpose behind the work. it is unlikely there will be a meaningful level of success.

The challenge is to encourage, coach and teach people through the learning process and keep them engaged and actively participating. Keeping people engaged takes a couple other things not noted yet...

Making it work

In the end, there are some things everyone agreed on. Among them, for this to work, people need to (at least act like) professional, adult workers doing their best possible work for their employer, while they work for them.

Teams need to be teams and actually work together - as a team - supporting each other, holding each other up with support and holding each other accountable to contribute to the best of their abilities to team success.

Without these things, not much else matters. The cool gimmicks and "motivational techniques" won't get you where you need to be. People need to do it.

That includes managers, product owners, product managers, scrum masters, project managers, and on and on, supporting the team in tangible ways, then getting out of their way to allow them to do their best work.

Finally -

Thanks to those who actively participated in the conversation Sarah, Jace, Keith & Greg. They jumped right in and had no qualms explaining their views.

Saturday, February 15, 2020

But What Does a QA, Tester Guy Know About...

... Product?
... BA work?
... Development?

My, what an interesting few days. I was asked those questions Thursday afternoon and Friday morning. It was an interesting set of discussions. My answer was similar for each of them.

Starting with the easier one to explain first.


There's a secret that people with a specific agenda don't want others to know, I think.

The better someone doing testing or general quality work understands what developers do, the language they work in and the database that holds the data, the better questions they can ask around the software and the better testing they can do.

It seems obvious to me, but I think it isn't so obvious. Let me see if I can explain what I mean.

If a tester has a basic understanding of, say, SQL, and can read and write basic queries, then she can build more targeted test structures and more vigorously explore the application's behavior.

If a tester can at least read through and understand what is happening in the code, she can use her "tester mindset" and check her understanding against the requirements - either in a traditional "Requirements Document" or in notes on the User Story/Story Card.

She can look for discrepancies between her understanding of the requirements, specifications, whatever, and what she sees in the code. This can lead to conversation with the people writing the code and the BA and Product Owner/Product Manager to clarify and make sure everyone has a shared vision of the project.

This is similar to how a good tester can understand what a BA does.

Business Analysis

Testers look at the requirements produced by Business Analysts. Ideally, they participate in discussions where the requirements are discovered and defined. For many organizations this is not the case. (I suspect it goes a long way toward explaining the disbelief around a tester/Qa person understanding what a BA does.)

I remember past projects and companies and clients and places where things did not work well.  Each time I asked about reviewing the requirements or specifications or user stories, then discussing them with the people who created them, I was often looked at with confusion. Like, "Why would you want to do that? Everything is written down here." This was often followed by "No testers have gone back to this stuff before. Why do you want to?"

I learned to control myself.  My automatic reaction typically was to smile to myself and think "And that explains the state of testing for these projects." 

What I actually said was "It is good to know what the documented requirements are.  It is also good to know what existing tests have been set up or run already.  It is essential to know what problem the project is intended to address.  It is crucial to know what people are doing now and what they need the software to do for them."

When looking at how to test something, or how to approach a piece of software, I've learned that the most effective way for me was to gain just that level of understanding. If I can understand the problem the BA was describing better, I can do a better job of testing to make sure the customer needs, problems and desires are being addressed.

I sometimes get told that a BA will explain everything in the documentation and I should simply leave them alone. Except, everyone translates information that fits their view. Everyone filters out unimportant bits - which sometimes is really important.

For that reason, I find conversation is the most powerful tool a tester has to build good, meaningful tests. They need to go beyond the handful of words written down and make sure they have the same perspective the BA was trying to represent.


The purpose of every software organization is to deliver a viable, working product to customers. Every development model, quality program, testing model, and approach, waterfall, Agile, SCRUM, Kanban, or XP aims to deliver the best product possible. 

These goals often fail, in my experience, with what I think of as the Edsel.

Anyone drive an Edsel lately? Wait. What? You haven't? I bet your neighbors have one though, right? Well, maybe not.

The Edsel was an amazing piece of engineering, design and marketing. It had absolutely bleeding edge features for the time it was designed and produced. The goal was a "perfect product." 

When working with software projects, I have a really fundamental opposition to trying to advance by "hitting home-runs." Most baseball players strike out, most of the time. 

Incremental improvement, based on firm understanding of the needs and problems we are trying to address seem a more solid solution to developing ideas into software.

If we don't understand the needs and problems our customers have can we really make a product people want to use, let alone pay for?

I get the idea of "revolutionary." I get the value of being the "first to market." I also get that ideas are never perfect, and building on good ideas can lead to better ones. Take a minute and gather some data, then load it into VisiCalc  and see the odds of the breakthrough leading to corporate success.

Good ideas grow on each other. If you set a fixed direction and channel every available resource into that, will you be able to respond to changes in the market, or world? Will you be able to respond to problems found in creating the breakthrough?

I find it helps to have a general idea with a broad, fuzzy view of what the final product will look like. The work to build that view needs to be sharper and more clear as it is being worked on. The tasks for next week need to be well understood. At least, they need to be understood enough to make progress toward the final end goal.

What Does a Tester Know?

As a "quality guy" I have seen enough examples of well meaning, well intended direction carved in stone that results in chaos, if not disaster. The key to success, as I see it, is to remember that ideas are transitory. They shape and shift and change over time.

By keeping the conversation around the purpose of the product alive, and keeping every person involved "in the loop" as equals and as contributors to success, amazing things are possible.

The higher and more formidable the barriers the less likely conversation and communication will happen.

Wednesday, January 1, 2020

An Unexpected Party, Journey and Post

Up until yesterday, I had no intention of writing this blog post. I told many people I had no intention of doing so. Still, here I am.

In 2009 I was in the process of winding down the small business I had started teaching drumming and music in general, mostly aimed at drummers in pipe bands but also other forms of drumming. In early 2010 I shuttered the blog I had on drumming, and in fact had not posted anything in since July of the year before.

The "downturn" in the economy in 2008 had played havoc among small pipe bands, from whence most of the students attending workshops or taking lessons came from.

This left me with a pile of time on my hands, and I found myself diving headlong into software and testing conferences. I had a new gig in 2008 and was helping folks find learning opportunities around software. One thing led to another and I ended up taking my boss's place at a conference in Toronto where I met loads of people whose work I had read and been influenced by.

Fiona Charles, Michael Bolton and many more people I learned from and mentioned over the years in this blog, I met for the first time at that first conference. I determined to attend and participate in more. I determined that I had a message to give and I could share what I had learned, even though I was not a famous guru.

An immediate outcome was creating this blog.

In my very first post, Good Morning Tester Land,  on May 1, 2010, I wrote this:

What are rhythms? They are patterns - ideas and concepts that can be found in the expression of music. Like any form of pattern, they can be found in other places as well. Typing on a keyboard gives a specific rhythm that can be identified. Seams in the pavement while driving to work gives an audible rhythm that sometimes mixes with the windshield wipers...

My intent, therefore, is to use this space to talk about testing and other topics related to software, and the patterns and rhythms I see and hear and participate in around me.

I have tried to do that. I still talk with people about patterns and rhythms. Over the last 10 years I have spoken at many conferences, made many friends and learned far more than I knew existed to be learned.

I have made many friends and found deep wells of wisdom I cam call on when needed. I try and share what I have learned openhandedly.

At the same time I offended people. I never intended to cause hurt and I know I did. For all those things I apologize and renew my annual intent to be a better person t-an I was the year, and now the decade, before.

While I have done a fair amount of speaking, I intend to reduce that significantly going forward. I have some writing I want to do and I am looking at other means of sharing ideas and lessons.

I want to find a way to work with individuals and small groups to help them discover how they can improve themselves. This might be in testing, things "agile," or even getting their own message out.

These are things I have wrestled with and made a point to remember my early struggles, I still remember how hard it was to learn some things and I try to draw on those memories when helping others.

I get called an expert a fair amount these days. Frankly, I get called that more than I feel comfortable with. I explain I simply have experiences and perspectives that I can draw on to help people.

Am I the same person I was 10 years ago? No. Far from it. I have learned a great deal. I have tried to teach and share what I have learned.

I try every day to be better than I was.

Thank you to everyone who participated in my journey of learning.

Sunday, September 29, 2019

Developers and Testers Are Made, Not Born

I read fairly regularly, and hear more often, that "developers don't make good testers."

Of course, I also see, and hear, just a little more hushed so as not to offend delicate sensibilities I think, that "testers don't make good developers."

To both of these assertions I'd like to offer the same (heavily edited) response:


People learn skills. Very few are born innately knowing how to write code (in any language). Very few are innately knowing how to test software and report the results in a meaningful way.

These "testers" who go on about developers not making good testers have no idea what they are blathering about. Likewise, "developers" who like to talk down to testers, or talk poorly about testers when there aren't any around, are likely insecure ninnies.

Being a good developer means you also test. These days, being a good tester means you can at LEAST read through and understand code.

The hardest part of both jobs is to admit you don't know something. The second hardest part is to communicate clearly and openly.

All of you, get over yourselves and learn how to work together.

Carry on.

Tuesday, August 13, 2019

Agile Change is Hard

Loads of people are engaged in some form of "Transformation." I sometimes think people latch on to that word because, well, it sounds more impressive and has less baggage than the word they really mean - Change.

For example - Agile "Transformation."

I've worked with teams that have done that T thing. I've worked with teams where it has gone really, really well. I've tried to work with teams where resistance was the underlying theme from managers all down to the most recent hire.

In my experience (this could just be me, after all there are loads of "coaches" and "experts" out there who can and will tell you differently) "Transformation" sounds better and because of that they can charge more money.

"Agile" has become a catch-all word to describe work done in small increments toward a specific purpose. Sometimes, I find that the "small increments" part is optional for many organizations.

They'll take the ritual labels, slap them on meetings or stuff they are already doing and POOF! They are now Agile! And they'll do pizza and t-shirts and motivational posters to emphasize the point.

Except, this isn't a change, or a "transformation" in any way. It is codswollop.

They'll hold meetings and send out lengthy diatribes in the form of emails from the "facilitators"  or "change agents" on things like "safe spaces" and "fail fast" and other catchy phrases. And then turn around and insist delivery metrics be met, at the least. More likely they'll raise the minimum standards fairly dramatically because "Agile" (and Scrum in particular) will "make" teams deliver product faster. So they should be checking stuff in faster and getting work and projects done faster. Somewhere in there, they'll likely be some level of criticism, delivered harshly (because they are being "open and honest") on how people did "everything wrong" and how their manager would have done it. And then they'll follow the same production implementation process they have since COBOL was the hot new language.

This isn't change either. It is more codswollop.

The hard part about any kind of change, Agile or otherwise, is not the external mechanics. It is not "doing daily standups" and it is not "increment planning" or "retrospectives" or any of the other labelled activities and rituals that many not-quite-agile organizations embrace, by relabeling activities they already do.

The hard part is sitting down and doing the really challenging work of looking at the organization, as a whole, and asking hard questions around why do you want to change?

Of course, the hard part about THAT, is each person needs to take a long, hard, honest look at themselves, their beliefs, work habits, intentions, goals, dreamsn and desires. Then looking at how that fits in with their team and the broader organization.

For those who have never stared into the abyss of themselves, this can be a terrifying prospect.

That may be why so many organizations settle for codswollop. It is easier to swallow than the actual medicine to make change happen.

Wednesday, July 10, 2019

Agile Testing Days USA, Thoughts on the 2019 event

Many conferences around software have a feeling, a vibe if you will. This can shift from year to year, but rarely in a huge dramatic way. Partly, this is the result of the energy from the organizers, partly the work of the people reviewing speaking proposals, and partly the feeling of people returning from prior years.

This was my first ATD USA event, as I had a conflict with last year's. I came in with a mix of eager anticipation and recognition that things would be different from what I had experienced at the several Agile Testing Days in Potsdam, Germany before. I was hoping to have some of the same energy and spirit of "fun" as the event in Germany, recognizing that it would, by the very nature of partnering organizations and attendees and speakers who had not been to an ATD event, different.

I think Ray Arell (@elmoray) has been credited as describing Agile Testing Days as a Festival disguised as a conference. He's not far off. Loads of social events, including a themed costume party, given the venue and city (Chicago) a "Roaring 20's" party seemed appropriate.

What is most important for me, personally, at a conference, is the conversation and interactions with other people. At one point in my conference life, "hallway conversations" were short, while grabbing a coffee or snack and heading off to the next session - because I was going to get my (well, the company's) money worth from being there. I'd like to think I know better now.

The result was I went to the keynote sessions (except one, given after I had to leave) and one or two track sessions. I spent a great deal of time the first day in the "Mentoring Corner" - This was intended to be for new speakers or people who WOULD be speakers. I actually was there charging devices and using the table to spread stuff out - and made a point of being as helpful as I could.

I am glad I did.

I spent a great deal of time talking with people who had similar issues they wanted to talk with and bounce ideas around with someone (my words, not theirs.) I got to see presentations grow from "this is kind of what I want to say and the arc I think I want to cover" to "This is what I am going with - thanks for your help!"

To be clear, I'm not really an expert in a lot of things, I am very good at asking questions when I don't understand something. I sometimes also make leaps from what people say, connecting ideas they are having a hard time identifying - for example, how ideas tie in with broader topics in the wide world and can be shaped by the energy in the room, or in the broader place.

Such things happened here in abundance.

The Start

Heading down to ATD USA, I was disappointed that two people would be presenting at times when I could not possibly catch their presentations - One (Jenny Bramble, @JennyDoesThings) because I was presenting at the same time and other (Bonnie Aumann, @bonniea) was scheduled to speak after I had to leave to catch my train back home. So, rather than well on things I could not change, I "hoped for the best" and spent a pleasant time milling about the day I arrived chatting with old friends and getting registered and hanging out, in between connecting to meetings with the Day-Job.

Heading to the Speakers Dinner that evening, I see Jenny has been delayed in arriving because of odd flight issues. So, sitting at a table, having found a fairly safe spot in the corner with folks I mostly had not yet met (protip - don't sit with yer pals at an event like this, find folks you don't know yet) when - HOLY COW!!!!!! Here's Bonnie looking for a spot!


One thing led to another and POOF! I had, what was for me an enlightening and very enjoyable conversation with someone who has put stuff out in public that I admire greatly and have learned from. We talked on a variety of topics, all of which dimmed when Bonnie expressed concern over the presentation to give (the one after I left...)

"Welp, I'll be sitting in the Mentoring Corner for speakers (and others) the next day, after I give my talk. Come on by and let's see if we can sort through it and help get it sorted." (I think that was something along the lines of what I said.. or at least a very polite folksy version of it...)

Later in the evening as I'm about to pack it in, I realize Bonnie knows Ray Arell and instead of packing it in, I find myself having "well, just one more" with them. (OK, I'm in full blown gob-smacked hero worship mode at this point...)

Having "just one more" with the two of them, and a changing cast of characters at the "Networking Night" - IN WALKS JENNY BRAMBLE!!!!!!! WHEEEEEEEEEEEEEE!

What ensues is a discussion around nearly any topic imaginable. Really. I eventually toddle off to bed a happy conference attendee, with the feeble excuse of needing to go over my talk one more time.

Day 1

Lean coffee was an interesting exchange of ideas, questions and "Oh, yeah, I had not thought about that" moments. The opening keynote was given, then I gave my talk. Then I scurried over to the Mentoring Corner.

At some point I ate lunch, went to a couple more keynotes, then went to the "Costume Party."

What struck me was not the details around these things but the ideas floating around in presentations, conversations and questions.

Ideas. ideals and bringing together people with different skill-sets and backgrounds and experience and life experience and outlook and pretty much anything you can imagine. The common word was "diversity" - and as much as that might be a problem for some folks, the looks I got when saying something like "part of the issue is there are a bunch of folks who look a lot like me, who figure they are the only ones with good ideas."

I learned a long time ago in pipe bands that the presence or absence of "dangly-doon-bits" (as one Glaswegian put it) had nothing to do with a persons ability to play pipes or drums. Nor does skin color, ethnic identity - having hung out with folks from the City of Tokyo Pipe Band and the Royal Sultanate of Oman Pipes and Drums in Glasgow, and having had some really fun times with members of the Church Street Pipe Band in Toronto.

The simple fact is, there were some very fine players in those bands. Sure, less experienced and much to learn, but when I think back to some of the bands I used to play in? whoa. Get real.

My overall lesson from the week

The message I was hearing much of the week can be summed up thus:

Anyone and everyone can contribute to goo work. Anyone and everyone capable of thinking can contribute. Anyone who thinks differently than ME can definitely contribute. You probably don't want an entire team of people thinking like me (no matter how they look or pray or vote) because it would just be weird.

Of course, declaring a bunch of people a "team" doesn't actually make them a team. Declaring a bunch of people a "team" who have only ONE THING IN COMMON, their employer, is not likely going to lead to a successful, diverse team.

That takes trust. That takes building rapport among people who are effectively strangers and have nothing really in common with each other, except possibly species. Trust comes with time, after people have found a way to relate to one another. The folks at ATD generally approach this as "of COURSE!" and yet, for many, like many first time attendees, the "how" is really hard to get our heads around.

Until you have DONE it, it is either very Unicorn-In-The-Sky, or it is pixie dust or glitter or some hand-wavy thing where in a process diagram there should be a cloud with "POOF! A Miracle Happens Here!" (For the record, I find most "team building guides" to have the same fundamental problem, people forget about human nature...)

My favorite part of this year's conference. 

Remember way up toward the top when I mentioned Bonnie Aumann? Bonnie DID come by the mentoring corner and we talked about the message within the talk. We talked about some really key ideas. Bonnie presented a compelling graphic, which I saw get drawn in the Tuesday night conversation at the "Networking Night" with Ray Arell and Jenny Bramble.

I'm not a famous name in software. I know that. I am honored that you read my meandering thoughts in my blog from time to time. I'm thrilled when people find some value in a tweet I might send. What I am trying to do now, particularly at conferences and meetups I can attend, is to help people tell their story.

That is one thing I tell people who say "I want to speak. Where do I start?" I always ask them about their story.

Because when speaking, we take on to persona of the parent or grandparent telling a story to children. We take on the role of what is called a seanchaidhe or seanchaĆ­ in traditional Irish culture (in Scots Gaelic tradition it is seanchaidh). We take on the mission of extending memory and inspiring our listeners to be better. We take on the challenge of calling people to be bigger and better than they are now.

Bonnie talked with me about the challenge of persuading everyone and how it had become clear that was never going to happen. So, logically, start with people who were closer to you, but not in full alignment.

Over the course of a day, more or less, I saw Bonnie's collection of excellent ideas grow into a cohesive, powerful "call to action" and model for how people can build rapport, trust and a team.

My end note.

I have met loads of people with loads of things to say. I have met people with huge egos who have little to say. I have met very wise, intelligent people with much to say, if people are willing to listen.

The people I mentioned in this post, Ray, Jenny and particularly Bonnie, are all in the latter category. I learned much from them in the few days at ATD USA. I suggest anyone wishing to learn, find them and learn. They are masters in their own right.

As for me?

The Road goes ever on and on
Out from the door where it began.
Now far ahead the Road has gone,
Let others follow it who can!
Let them a journey new begin,
But I at last with weary feet
Will turn towards the lighted inn,
My evening rest and sleep to meet.
Bilbo Baggins