Montague.tv

One of the keys to successfully leading teams of people is to run effective meetings.  On the surface, this seems pretty straight-forward.  Ensuring you have an agenda, take good meeting notes, and sending action items out afterword aren’t rocket science.   Relatively trivial, even though consistency is key and rarely is delivered.  However, when you are dealing with those recurring tactical meetings, especially ones that occur multiple times per week, the old model falls down.

To begin with, there really isn’t a simple strategy to produce detailed agendas any longer.   Many topics, the critical ones that need to be discussed ASAP, sometimes come up just hours before the meeting.  Furthermore, the priority of the litany of things that are on the list changes at a rapid pace.  Sending anything in or prepping for those discussions can be fruitless at best, and counter-productive at worst.

Enter the “Weekly Tactical” meeting format:
Some of the concepts in this format were adapted from the book, “Death by Meeting” by Patrick Lencioni, but others were evolved on the spot as the need arose.

The basic premise of the Weekly Tactical meeting is to get a group of leaders together to make decisions.  We don’t want to go to meetings to “talk” about decisions, we want to MAKE them.  (After all, that’s one of our core job functions)  So many organizations are plagued by the notion that meetings are simply to “discuss”, not to “do”.  This simple shift alone will increase the effectiveness of most meetings.  The word Tactical, for our team, implies that the scope of topics should cover 1 week from the date of the meeting.  We have 2 Tactical meetings per week that are 1 hour each.

Detailed Overview:
The following photos show the simplicity of the process.  I have a large whiteboard in my office that is refreshed each time we have this meeting.  It has the template written on it and is ready when the team comes in.  The image at the right shows what the layout looks like.  I tend to facilitate the sessions, but now anyone can do it as the process is simple and well understood.

Next let’s break down each section with details.

Lightning Round:

Decencies
We have recently added a kick-off titled “Decencies”.  This is probably the one I’m most excited about, and most proud of.  After re-reading Tom Peters book, “The Little Big Things” last week, I was reminded of the need to refocus our efforts on our people.  I’m leading a group of manages and architects and we tend to get mired in the day to day.  The complexity and pressure for those leaders is immense and it’s easy to get stuck focusing on “work stuff” and neglecting the “people stuff”.  Tom reminded me a second time “it’s all about the people”.  Hence, the “Decencies” kickoff was born.

Essentially we will create actions to recognize the wonderful and talented staff we have and the things they do every day to make all of us successful.  We will also think about ways to remember the Power of Pleasant, how we can connect emotionally with our customers, and hopefully keep some “damned perspective” when the tension escalates.

Topics
We then go to each person and ask for their topics.  If you have an issue or topic that you need help delivering, or you need a team decision, then it’s a good topic for our meeting.  They each have 1 minute (yes, 1 minute) to get through their entire list, along with associated explanations if needed.  We then move to the next person, in order, until we have a list of topics.  We then get started at the top of the list.

Note: we used to prioritize the list, but as of late, we have blown through very large lists so rapidly that we haven’t needed to prioritize.  If we start leaving important stuff undone, we will go back to prioritizing.

Actions and Decisions:

We then take each topic one at a time and attempt to give each topic its due attention.  We are all aware of the need to get to an Action or Decision so we tend not to lollygag.  We will discuss for a while and someone will say, “Do you need us to help choose for you?” or “Is there a next action for this that we can assign to one of us?”  More often than not, the topic simply needed a quick decision and some collaborators to ensure there wasn’t something being missed.  Other times, the issue is a bit more complex and the initiator needed help deciding on the next steps to take.

As we move through the list, the grid in the image to the right begins to unfold.  We assign tasks with associated details, 1 per line until we’re done.  Normally a “decision” is indicated with a task to communicate the decision so we ensure we are communicating those decisions effectively.

Parking Lot:

As a group, we occaisionally bump into a topic that has no simple solution or the right parties aren’t present to discuss.  They also span many teams and possibly a large time horizon.  These issues we deem “strategic” and get placed in the parking lot with associated detail.  We have a few venues that these strategic topics can end up in so we attempt to classify them on the spot

Note: this classification exercise is new.  I will update you on how its going.

The three Strategic Meetings are a “TRI-Weekly” meeting that we prepare for in advance.  It includes both leadership teams in my organization (Development Managers and Enterprise Architecture) as well as any special guests needed to (once again) make decisions on the topic at hand in the meeting.  The second is a “Development Manager” Strategic meeting and the third is ”Architecture” strategic meeting….all similar formats.  I will try and describe these formats in a subsequent post.

Well, there you have it.  This evolved format has helped our team and organization communicate better, make timely decisions, and get aftet the topics we know are critical for success.  With the addition of our Decencies section, it will also help us double down our efforts to remain focused on whats important, our people and their well-being!

I’m a firm believer in “surveying the landscape”. I think the time you invest understanding your clients and customers needs, the better off you are. It’s one of those things that’s just reasonable. Don’t jump to conclusions. Don’t pedal solutions before you know the problem you are trying to solve. Which is why what I’m about to say feels blasphemous…

Sometimes it’s just not that hard to understand the real, honest to goodness business issues that are right in front of your face. Furthermore, left unchecked, some could mean curtains for your customers. In that moment, make the tough decision.

For instance, it really doesn’t take much to diagnose a gaping gunshot wound. There is no need to take someones temperature and have someone step on the scales when there is an obvious diagnosis and prescribed course of action. I would classify these types of issues as Organizational Emergencies. These issues need immediate attention! They need decisive action and the trade off between a “timeliness bias” and “consensus building bias” is wildly weighted toward timeliness. If your business problem is of this variety, don’t be afraid to make the tough decision.

In the agile community, we lean toward a complete consensus building model. In my mind, this is a very, very good approach. However, this makes Organization Emergencies more precarious. Often times the process of complete consensus building is near impossible to achieve, and left with the choice of making a tough call or throwing up our hands, we choose the path of least resistance. The typical choice leaders make between errors of commission and errors of omission is to choose omission, every single time (and twice on Monday). After all, we don’t really track this type of error. This makes the process even more difficult to manage and time begins to slip through our fingers.

I truly believe the majority of the decisions organizations need to make have a clear “consensus building” bias. This is why I feel the agile community has it right. But, when you recognize those rare occasions where delay might have dire consequences, find the fortitude to make a decision and trust your instincts.

I have been thinking a lot lately about how I might go about working with teams to ensure they understand the main message behind agile engineering practices. In many ways, the knee jerk reaction of many managers, including me, is to edict the use of common practices and skills. In my past, I have heard many many reasons for why people don’t want to unit test, setup build automation, peer review code, and refactor. What I haven’t heard is a GOOD reason. This has made it even tougher to refrain from handing down a set of criteria to the teams on “how to code”. After all, for me these practices “just makes sense”.

“What” vs “How”
A lot has been said about internal versus external system quality and I think this concept has helped me teach the difference between “what” systems teams deliver, and “how” those systems are built.  When starting a conversation with teams about learning the well tested agile engineering practices, I typically hear a common refrain.

“We are senior developers.  We don’t need to improve quality. We’re doing great…just ask the business!”

In one way, they are RIGHT. The business loves what they are seeing. But quality to a user of a system is only skin deep. They see half the equation (arguably the most critical) but half none the less. They see the working system. They see the new feature they requested and by gosh it works exactly as expected!  The system is performing as expected.  There may be a few lingering issues, but 95% of the system is awesome.  It supports the business just fine.  Mostly, we just need more features, faster!

Lurking Under the Surface
So what don’t customers see?

• They don’t see the manual jobs we kick off behind the scenes every morning to ensure the data “looks right”.
• They don’t see the delays to building products because only one person knows each individual part of the system, and if they are busy (or even worse on vacation), then nothing in that specific module can be delivered.
• They don’t see the painstaking manual testing efforts that go on before we push to UAT.
• They don’t see the manual roll out, roll back, roll out dance we do simply “moving” code to UAT and PROD.
• They don’t see massive nested If-Statements that look like Japanese word art.
• They don’t see the 12 year old version of J++ that their core processing engine is built with, and that if Christy loses the J++ disk she has in her desk drawer, we’re screwed.
• They don’t see how difficult it is to add simple logic to the system each time they ask for something new.
• They don’t see how often even simple changes strike fear into the hearts of anyone relatively new to the team.
• They don’t see the 18 month ramp up time it takes skilled developers to “learn the system”.
• They don’t realize that “regression testing” really means “test whatever we can for the 2 weeks we have left”.  (hint: ~10% of features)
• Etc, etc, on and on, ad infinitum -1.

For the above reasons, we need to be better.  As technologists, we need to be stewards of our systems.  And in many ways, that means protecting both “external” and “internal” quality.

Stewards? What does that mean?
It means if there are time bombs in our code, we have to make those time bombs REAL to the business and advise them how to prioritize up what is critical and to prioritize away what is not. In technical debt terms, pay down your high interest technical debt quickly by prioritizing it as high up in the backlog as possible. Business people will never do this on their own. We have to help them toward this decision.

It also relates to “how” we build systems.  As professionals, we need test automation, build automation, refactoring, pairing, peer reviews, patterns, etc.  This is where my brain and my emotions clash.  On one hand I want to pass down upon high an EDICT, “Thou shalt unit test!”  I would say this is my emotional, impatient side.  Intellectually I understand that I need to lead these teams toward these principles.  More “supposing” and less “proposing”, as they say.  The minute I create the rule, the simple and powerful act of automated unit tests lose their power.  People begin to test in haste.  They write tests that assert nothing so test coverage reports show arbitrarily high numbers.  They write tasks for testing and never get them written.  They come up with every reason in the book why testing isn’t that valuable for them, in their system. And when rules are imposed, any shortcomings, difficulties, roadblocks, or otherwise ill will surrounding the approach are attributed to external sources…namely, me. After all, this is Jason’s RULE. He owns it, not us.

Grass Roots
So, I am back to the grass roots. I want to rebrand engineering principles (and the stewardship it implies) as a virtue, not a rule.  I am back to the task of building a ground swell in our culture.  I am back to focusing my efforts around a few key (and critical) early adopters who have seen the value of software craftsmanship.  With these progressive folks, I hope to create a magnetic pull.  A “why aren’t we doing that” effect that emanates.

With the rest, I have but one request:

“If you don’t think that these principles and techniques are valuable, so be it.  In the absence of using these techniques, please show me how you can assure consistent, sustainable, internal and external quality of the systems in which you have been granted stewardship.”

I am being sincere when I say I am open to being wrong about this.  If those principles I have come to lean on are of low value for these teams (and in their context), I am anxious for a better answer.  More to come!

I recently re-read The 5 Dysfunctions of a Team. I am through it for the 2nd time and find that I have gleaned so much more this time around.

The Role of a Leader: (A look back at 5 Team Dysfunctions)

1. Absence of Trust – Avoid Invulnerability
2. Fear of Conflict – Avoid Artificial Harmony
3. Lack of Commitment – Force Clarity & Closure
4. Avoidance of Accountability – Confront Low Standards
5. Inattention to Results – Focus on Collective Outcomes

In my first foray into this book, I found many insights useful, but not particularly familiar. I read the book quite a few years ago and really didn’t have the background to understand the content that the book addressed. I just hadn’t faced those types of team building dilemmas (or maybe I just hadn’t thought about it that way). Even in an Agile coaching capacity, I find many small teams quickly gel and find a rhythm, building trust, managing conflict with help, and holding one another accountable. I think software teams are, in the end, really good at this given some subtle guidance.

Fast forward to 2010
I’m currently part of a management team that displays many of the detrimental failure modes that the book describes. Sadly, I’ve come to realize over the years that this is more the rule than the exception. The team members are all, individually, extremely talented.  They are also great people.  I mean that sincerely.  This fact makes me both hopeful and fearful at the same time.

It’s great news because it’s obvious that my current challenge is unambiguous and squarely in front of me:  work on building a dynamic and healthy TEAM.  It’s also scary because I now know what I need to do: work on building a dynamic and healthy TEAM!

This supremely simple concept, the one that eludes 95% of leadership teams in all types of organizations, is one of the most difficult experiences teams can go through. Knowingly embarking on that journey is a sure-fire way to bring emotional exhaustion and short-term discomfort to your collective lives.  But alas, like many things in life, I know it’s critical and completely necessary. There is no exception.

Mentally I know that this hard work and emotional discomfort will be the only way to long-term fulfillment and happiness in a collaborative endeavor like building great software for customers.

Outlook
I’m growing more encouraged day by day.

“Drive”, by Daniel Pink answers plainly the omnipresent question “What will make me happy and engaged in my life and  career?”. What I have felt so strongly throughout my career is confronted head on in this book and the answers you uncover will likely surprise you.

Like many, I typically would fall back to standard, cliche’ answers:

• “I want to be promoted. If I just moved up, I would be happy.”
• “I want to manage people. The more in my organization, the happier I will be.”
• “I don’t have enough money. I really just need more money to be happy.”

 
All of these things have come pretty quickly in my career, and I can tell you without doubt, they do not ensure sustainable engagement, motivation, or happiness. The things that have motivated me seem to be the residue of having a persuasive personality and organizing my work (come hell or high water) to give myself the three things Dan Pink describes as critical. 

1. Autonomy – being self directed and interested
2. Mastery – being great at what I do
3. Purpose – what I do “means” something and makes a difference

 
Not only does the book describe those motivators, it also explains the incredible disconnect employers of “thought workers” have had (and still have) related to what motivates their teams and workforce. I happen to work with teams that create art for living (software systems). These people spin value out of whole cloth. They essentially take concepts and thoughts and turn them into tangible goods for others to hold, interact with, and use. I cannot think of a better definition of a “thought worker”, can you?

Yet, nearly every employer of software developers I encounter has had it wrong in some form or another. To begin the journey of trying to satisfy the needs of those team members, you first must understand what motivates them. The book has moved me a bit closer to that understanding. This video, brilliantly produced by RSA Animate, gives you some of the shocking truth behind what motivates us.

Do your teams use the term “done”.  Does it mean something?  Does capital “D” (Done) mean more than small “d” (done)?  Or do you use the dreaded (done-done-done) to indicate “done”?

Here at GHQ, we have actually uncovered 3 states of “done-ness” on our Agile projects:  Rare, Medium, and Well-Done. I’ve noticed that without exception, every team I have helped adopt new Scrum principles uses the dreaded “done-done-done” moniker, or some such,  to describe a state that essentially means “there’s nothing left to do so we can ship it!”.

In my first coaching endeavor, I thought, “what a unique way for the team to express itself!  That’s so quaint.”  Now, when I hear teams say, “Are you done-done-done?”, a shiver goes up my leg.  This is not the kind of leg shiver Barack Obama gives Chris Matthews.  It’s the bad kind of shiver.

Now with more experience, this phrase (and other like it – see meat analogy above) mostly make me feel like I haven’t done-done-done my job.  At the very least it makes me think that somewhere along the line, I have neglected to describe why DONE needs to stand for something, and why “done-done-done” screams “we still don’t know what DONE means!”

The reason, I believe, this word should mean more is the message it conveys to our customers and our partners.  Applying the reasoning of a lawyer, it doesn’t pass the “reasonable person” test.  If I say the term, “it’s done” to a reasonable person, do they think:

• It’s DONE….

or, do they think

• It still needs to be checked in, unit tested, QA tested, promoted to UAT, UAT tested, validated, blah, blah, blah, etc, etc, etc

As Agile has gained momentum and customers have made their way into our stand-ups, design sessions, and overall daily lives, we as software development organizations need to be cognoscente of the messages we send.  Scrum has done a pretty good job of making us realize that demo’s mean something to our business partners.  So if you show the “happy path” of a feature, they don’t SEE the happy path.  They see their system…and it’s working!  Yahtzee!  Ship it!

The first time you pull back the curtain and show them why you can’t just ship it (the broken links, the hacked supporting pages, the hardcoded breadcrumb, the broken buttons, or the fact that it doesn’t work anywhere but Sam’s developer machine) the sadness and disappointment sets in, and the terrorists have won.  You may not know it now, but Trust (capital “T”) is starting to erode.

“But, don’t they know that it’s just a demo?”

No.  They don’t.  Just like they don’t understand that done (small “d”) doesn’t mean DONE (all caps) either….because no reasonable person does! 

Some small advice that turns out to make a BIG difference in the long run. 

1. Treat the language you use with your partners carefully 
2. Apply the “reasonable person” test.  Would a reasonable person understand your intent?
3. Make the word “done” mean something in your organization before one of your teams creates multiples meanings for it.  Once “done-done-done” emerges (or Rare, Medium, and Well-Done in my case), it’s much harder to regain lost Trust (and the appropriate meaning of our words)
4. Lastly, teach your teams the power of Trust

Recently I ran across a manuscript that my father was writing some 25 years ago. The topic: how to engage and cultivate greatness in a battered, and oft embittered workforce. My father focused his career managing companies, mostly in the manufacturing sector, so you can imagine the context of the following line:

“If we are to cultivate greatness in our organizations and in ourselves, we must learn to tolerate and acknowledge failure, and have a fervent disdain for apathy.”

Can you imagine what that statement might have meant to a union worker at that time who was all but *commanded* not to care?

Union Labor vs. Knowledge Workers

I can just imagine the union dominated workplaces, the heavy handed bosses who sat up in the plant office looking down at the hired help, and the scores of unmotivated and distrustful factory workers staring back up at them. As I read through the pages, bound together into distinct chapters by binder clips and rubber bands, that one line stood out. It still does. “Failure”, the subject of a few of my recent posts, is something I seem to be exploring these last few months. Mostly because I see it for what it is, for what it truly stands for, and how wrong our command-and-control heritage had it. I also think of how good, comparatively, we have it. Many of my staff have Masters Degrees. Some have had PhD’s. Most are still searching for an organization that will allow them autonomy over their work and a healthy place to practice their craft. I can’t say the same of the factory worker of the 70′s and 80′s. How good I (we) must have it, right?

My father passed away in the early nineties before he could publish his book. He had gotten through six chapters and what notes and collected data that accompanied these six chapters has long since vanished. At the time, I was an awfully young man caught up in endeavors that feel a thousand miles away from this.

Failure is an Option. Stopping is Not.

Fast forward to 2010. I am in the middle of a career spent coaching others, cultivating relationships and friendships, striving for purpose and mastery in the field I have chosen. I now have an opportunity to lead others. To teach. And I hope, in some small way, to inspire. Every day I think about how truly difficult it is for me to discuss these heavy topics in a meaningful way. Every day I feel like I can’t quite pull our teams out of the rut they find themselves in, inching toward some level of congruity and understanding. Everyday it feels like someone in the management hierarchy is willfully subverting *every* effort toward a more sane and rewarding workplace. I know this is not true. But it does FEEL true sometimes…even through the exciting highs and feeling of accomplishment our field provides.

Caring Enough to Do It Again

After finding his book and imagining the “all but impossible” tasks my father must have gone through, I now have a slightly different perspective. Failure is an option and one that must be tolerated and even expected. The hard work, the true heavy lifting, comes in the form of caring enough to do it again. To learn what just happened, revise your strategy, and do it again. The moment you let apathy creep into your day, even *after* a monumental failure, you’ve lost.

Now, everyday (win, lose or draw), I vow to do it again tomorrow and try something new. I do it again – because I care enough about the outcome, the people, and myself – to do it again.

In a recent session with my Ironman coach, we got on the topic of how she and her husband were building their business, how coaching is a very individualized endeavor and how it doesn’t necessarily “scale”. I didn’t have much insight at the time related to her comment, but it made sense. She and her husband, both professional triathletes and coaches, only have so much time in the day after all.

This discussion got me thinking about the coaching I do in organizations. What makes me successful in my interactions with clients? Why do I prefer the coaching model over consulting (Big-6 style)?

I went home that night and had some further discussion with a friend of mine (Chris) who owns an organization that does business coaching. He had something interesting to say about the subject that proved to be very insightful. I felt like I “knew” the answer, but he made it clear to me after I bent his ear for a good hour. In fact, I say it all the time but it didn’t dawn on me until he reminded me of it. What was that wonderful insight Chris was coaching me to “discover”?

Well, most business owners (in his world), and software executives and managers in mine, need to find that emotional tie to an issue and work out the solutions on their own. If they don’t, and you GIVE them the direction they are seeking (even if you may be right) then you have failed to truly coach. Why? Because you have just put yourself in the distinct position of “owning” the outcome of your direction. If the direction works (and the first few attempts probably won’t) then you were wrong! They knew you were too good to be true!

Another likely scenario is that your direction will take some effort. Maybe it will even take multiple difficult steps. If your clients aren’t emotionally engaged in this decision, they will most likely abandon your suggestions, stop moving forward, and again you’ve lost.

Lastly, and probably worse for clients is you’re direction worked! Eureka! …What’s the problem then? Well, you have just created a dependent, complete with all the “frozen and can’t make a decision” trappings you can expect when the next issue comes along.

So what’s a better approach. As Chris puts it, “act like a coach and not like a consultant”. Get to the heart of the emotion with your clients. If the answer is obvious (to you), don’t jump directly to it without first helping lead the others toward the answer and let them discover it on their own. Their hard work and persistence will pay off and you won’t rob them of the engagement they so desperately need to make the difficult, and sometimes emotional journey to solving their own problems and thinking on their own.

Coaches do things this way because they know you have to perform when they aren’t around to help. Consultants on the other hand will happily answer all of your questions and bill you hourly when you come back to sit at their feet.