Category Archives: GenExecutive

Don’t Be A Jerk

Posted on by
7

I’ve been threatening for years to put together a presentation titled “Everything I needed to know about Leadership I learned while running a guild in World of Warcraft.” I still might someday, but I’m annoyed with myself for continually talking about it and not doing it, and one of the points I want to make is top of mind today so I’m just going to write it down in a post and consider it pre-work for my epic future Agile Alliance presentation.

I started playing World of Warcraft shortly after it was released in 2004. I had a small group of friends who had been playing City of Heroes together and we all decided to try it at the same time. When enough of us had gotten the game and decided to stick around to do so, we started a small guild (a guild, for those of you are unfamiliar, is a means to communicate and share resources in the game with a specific group of people). Eventually we met another guild that was populated by people who we thought were neat, and we decided to merge the two guilds together.

For some reason I agreed to lead this new guild.

I won’t go into a lot of detail as to why a guild needs leadership, because it’s not really relevant to this post, but the very short version is that there is a lot of content in the game that requires large groups to complete, and part of running a guild is to help schedule teams to take on that content and establish agreements around how any rewards won from beating it would be distributed among the group. Guild leaders also establish the culture of the guild (ours was considered a “casual” guild, with mostly older players who had responsibilities that prevented them from devoting excessive amount of time to the game) and will also set up rules around acceptable behavior by guild members.

When we formed our guild, we had one rule: Don’t be a Jerk.*

For a while, that worked just fine. Everyone understood what being a jerk meant, and we were all pretty good about not being one.

But then the guild grew. We kept adding people who we didn’t know as well as the original members. As our numbers expanded, the line on what everyone accepted as “jerkish” behavior began to get fuzzy. Common sense, it turns out, is not so common. Especially when you’re dealing with a diverse group of individuals who are paying for the privilege of playing a game. People with different backgrounds, who come from different regions of the world, and have a variety of socioeconomic situations, genders, ages, and sexual orientations (not to mention skill levels). Heck, one of our prominent members was a retired grandmother who used to send me cookies every Christmas.

Mardi, if you’re still out there my address hasn’t changed.

Eventually something happened that I, and the folks who helped me run the guild, couldn’t ignore. I don’t remember what it was, specifically. All I remember is that our response to the thing that happened was to create a new rule, so now we had two of them. It wasn’t too long before another incident got our attention, so we created a third rule. Then a fourth. A fifth. You get the point.

When I finally stopped playing the game in early 2009, I believe our rule book was three pages long.

We would make broad announcements about how we have “noticed certain behaviors” and how those behaviors “violate the spirit of our core value of not being a Jerk.” If the person in question continued doing the “thing” we had created the rule for, we could point at the (newly expanded) rules list and accuse them of violating it, thereby justifying our decision to remove the person from the guild.

You know what we never did in any of these situations (before it was too late)?

Talk to the person in question.

Instead of having an open, honest discussion about whatever the infraction was that caused us concern we avoided confrontation entirely and hid behind bureaucracy.

Our reward? More headaches. The bureaucracy that was protecting us from being the “bad guys” continued to grow and become more complex, and eventually got to the point where we spent more time managing rules and people than, you know, playing the damn game.

Eventually it got to be too much for me and I quit playing. All the enjoyment had been sucked out of the game for me, and I walked away. I still have friends who I met playing WoW, and some of them are still playing and in the guild I helped create, but I canceled my account almost 14 years ago and haven’t looked back.

So what does any of this have to do with Leadership in the professional world?

The first, and most important, lesson I took from this was that creating rules to deal with people problems is a no-win scenario. I’m not saying you shouldn’t have rules, codes of conduct, etc…but if you’ve got someone on your team who isn’t working well with others in some capacity, creating some kind of rule, procedure, or process to deal with that person is not being a Leader. It’s managing (and managing poorly, at that).

The other big lesson I learned is that by creating a rule that applies to all members of a team when only one person is responsible for doing the “thing” that caused the rule to be made, you create a situation where the unintended consequence of your action is to cause people who have nothing at all to do with the situation to suddenly worry that THEY were the reason the rule was created. For example, say you have a person in your organization who has some kind of issue with body odor that is disturbing others and instead of having a conversation with that person you send out an all-users e-mail reminding the entire company that “we all have to work together in small spaces” and to “please be mindful of how our personal hygiene might impact those around us.” The person who inspired the e-mail might not think it is about them, or they might realize it is and get horribly embarrassed and/or resentful. Even worse, people who had nothing to do with the original announcement may start wondering if they are the reason the email was sent in the first place.

This lesson shows up in the Agile Manifesto, of course. “Customer Collaboration over contract negotiation” is one of the four values found in the manifesto. Talking with people and working out situations directly is much more effective than hiding behind contracts (and what is a list of rules in an organization but a contract that one agrees to abide by to continue working there?), and how can we argue with the fact that most effective means of communicating information being face-to-face communication?

If I knew then what I know now, I’d have spent a lot more time talking to people and a lot less time managing a list of complex rules. The short term discomfort of having a difficult conversation pales in comparison to the drudgery and annoyance of dealing with the red tape of a ridiculously long rule book.

*In the interest of full disclosure, the word wasn’t jerk. I think you get the drift, though.

Team Building Activity – Look into the future!

Posted on by
Reply

This past Wednesday I had the opportunity to facilitate a workshop with all the senior leaders in our organization to start working on our Annual Objective for 2024. As part of that workshop, I put together a team building activity to bookend the workshop. I got a lot of positive feedback from the attendees, so I thought I’d share what we did here, along with my lessons learned, so that others could use it if they were interested.

Activity: Looking into the future
Time Required: 10-15 minutes
Materials Needed: A decent sized ball. I used this kick ball.

  • Get your participants to stand in a circle, ideally arms-length apart.
  • Stand in the center of the circle and introduce the activity while holding the ball. Here’s a paraphrase of what I said to my team – “Today, we’re going to predict the future. Now, as many of you know, I’m an actor. The last show I was in was about a medium who used a crystal ball to speak with dead Hollywood celebrities. I learned something very valuable when I was doing that show – Genuine crystal balls are heavy, fragile, and expensive. The crystal ball we were using was the most expensive part of the show. Even more expensive than my salary! Because I want to be responsible with our members money, and because I don’t feel like cleaning up a bunch of broken glass, I’m going to ask you all to use your imagination and pretend that this fine kick ball is, in fact, a very fancy crystal ball and that when you are holding it you can see into the future.”
  • Introduce the rules of the game. These are the rules that I shared with the group on Wednesday (you can partially see them on the slides behind me in the picture above).
    • Only the person holding the ball can speak.
    • Players who are not holding the ball may communicate with eye contact, gestures, etc…but no words.
    • Prediction must be accompanied by the current count of predictions
    • If a prediction is a repeat of a previous prediction the team must start over
    • Predictions may, however, BUILD on previous predictions. Example – “1! There will be a rain of trout that hits New York City!” “2! The ambassador from Chile will suffer a serious injury after being hit on the head by a falling trout.“
    • If the ball hits the ground for any reason the predictions must start over.
    • If a new round of predictions begin, predictions from a previous round may be repeated
    • You cannot throw the ball back to the person who threw it to you.
  • Explain that the goal is to see how many predictions the team can hit in the time allotted. You should challenge the team with two goals – One of them that you think should be achievable, and one that should be hard. In our case, we used 25 and 50. Put some kind of bet in place to make it interesting. I initially had the idea to be the “bad guy” and assert that the team would never hit the goal and my partner (Adam Ulery from Compass Productivity) would be the “good guy” and bet that they would. I volunteered to agree to conduct the rest of the meeting using my puppet, Mr. Judgey, if I lost. We were discussing our bet with the CEO before our workshop, and he got into the game in a big way. He offered that if the team hit 25 predictions we’d donate $2500 to the local chapter of Celebrate Birthdays (the charity the team was sponsoring for the day), and that if we got to 50 we’d donate $5000. I threw in me using the puppet for the rest of the meeting as a bonus to tier on the 50 predictions.
  • Toss the ball to one of the participants and get the game started!
  • Play referee and make sure they follow the rules.
  • If you can, record the session.

The point: I based this activity on an exercise we have used as an ensemble warm up in a few of the productions I’ve done in the past. In that activity, the goal was to keep the ball in the air and count out every time you hit it, and the point was to get everyone in the ensemble thinking and working together as a unit before the show begins. It’s also a lot of fun. In this case, I wanted to add on to that by getting them thinking about the future as our workshop was around building an Objective for 2024 that would focus on the Most Important Thing our credit union would accomplish next year.

Retrospective:

  • What went well: The team hit the stretch goal, with a list of 50 predictions that ranged from serious, silly, far-fetched, and realistic and pretty much everything in between. We had some laughs, shook off the after-lunch drop in energy, and got into the right mindset to do some forward-thinking. We raised $5000 for charity and I got to freak everyone out with my eerily accurate Muppet. We gave a spontaneous lesson-in-the-moment about stretch goals in relation to the 25 and 50 targets, getting the team to agree that if we had started with 50 as the goal, or even 75, that they would have been less motivated to try and hit it.
  • What didn’t go well: I didn’t anticipate how quickly the team would devise a strategy to get to the goal without dropping the ball. In the theater world, the ball is constantly moving. In this scenario, the team member got to hold it while they were making their prediction. They quickly realized they could just hand the ball to the person next to them and let it go around the circle. There was also no motivation to make a prediction quickly, so team members holding the ball could pause to think about an answer.
  • What I’d do differently: Add the following rules to the list above –
    • You cannot pass the ball to the person immediately to your left or right.
    • You cannot move from your spot.
    • If you hold the ball for more than 5 seconds the count resets.

Conclusion

After we finished the workshop I closed our time together with the following (again paraphrased, because I don’t work from cue cards my friends):

I spent a good deal of time working in and around Renaissance Festivals when I was younger. Yeah, probably not much of a surprise given the fact that I’m wearing a kilt. When I was doing so, I got to know quite a few fortune tellers – Tarot card readers, psychics. You name it. I’m sorry if I’m ruining the illusion for you, but none of these people possessed any kind of supernatural powers. What they had, was the ability to look at the world as it is, look at trends, ask probing questions of their patrons, and make a relatively accurate prediction about what their future looked like. We did that together today. We may be right, we may be wrong, but we used our collective knowledge together to gaze into the future and make some predictions. I’m excited to see how they turn out.

Bonus: Adam recorded the session for me, and I’m going to keep track of their 50 predictions for 2024 to see how many come true!

Update: I can’t believe I left out one of the most impactful parts of this! As I was finishing my summary, I asked everyone to pass the kick ball around the room one last time and sign it as we moved on to our next activity. This, I told them, was our contract that we were committing to building a future together as one big team. I gave the ball to our CEO as a memento of the event and a reminder for everyone of what we did together.

Where I want to be and who I want to be

Posted on by
Reply

This post was “written” almost a year ago. I was experimenting with using dictation tools to write a post on my morning walk, and the end result was pretty scattered and required a lot of editing. I got about half way done, had to move on to other things, and promptly forgot about it. This morning I stumbled across that draft in progress and decided to finish it up. Honestly, it was rough. I had to remember what was on my mind a year ago, and I went off on some completely unrelated side rant that was about a thousand words long and needed to be edited out. I think the end result here is worth posting, though, so here it is.

The company I work for recently went through a major reorganization. A new department was created for our business unit and our team was moved into a new vertical under a different executive. A VP position was created to head up the new department, and another senior leader was given that position to help align all of our Agile/Lean/Project/Strategic activities.

It’s a lot of change. I was, admittedly, quite shaken when it happened. I’ve had my cheese moved more than once at my current job, but this one felt overwhelming at first. I don’t feel that way any more, and in fact I’m really excited about all the changes, but that initial jolt was pretty big.

One of the reasons it was such a shock to my system is because I was moved into what we are calling the “process” vertical in our organization. As someone who believes in and supports Agile, being in a group that seems to be on the “processes and tools” side of the “Individuals and Interactions” equation wasn’t a look I was happy with. I’m still not entirely keen on the optics around it, if I’m being honest, but I do believe that in our current structure we landed in the right place.

In any case, I was meeting with my new boss on Monday (the above mentioned Vice President of our newly formed department), and we were having one of many “getting to know you” style conversations we’ve had since the change. While we’ve worked together for many years at this point and have a perfectly amiable working relationship, we don’t really know each other all that well so we’re spending some time working on that. In our conversation on Monday, he asked me where I wanted to be in five to ten years.

Now I need to go ahead and state for the record that he knows about my cancer and said right up front that he realized his prepared topic for the day probably wasn’t something that was top of mind for me at the moment. I concurred and stated that “alive” was really my top-of-mind goal, but since I intended to achieve that one it was totally cool to talk about what else I’d like to be doing and we did so. In the time that has passed I’ve thought about it some more, and that was the path I took to starting this post.

When I reflect on my early days in software development, I see a perfect example of how my mind works. My first job was with a company that sold ColdFusion based auction software. The original person who wrote the code did so in a way that was most efficient at the time he wrote it. The internet was slow, and any extra white space in the background of a page could cause longer load times, so he removed any characters that were “extraneous” from his code.

The result, while readable to a visitor of the site, was a solid mass of text that was nearly impossible to decipher on the back end.

As my responsibilities there grew I eventually got access to that code base and was charged with helping to fix/improve the software. Every time I had to access a page, I would poke around in it and make it better. I would add comments where none existed. I would explicitly name variables from x or y. I would tab-delimit nested code. I would update deprecated functions or replace code blocks that were inefficient. What I was doing was removing technical debt, but I had no concept of what that was at the time. I just wanted to understand how the code worked, and I wanted to help make it better.

Which is a perfect example of how I look at the world. I want to understand how it works, and I want to make it better. So when I think about where I want to be in five or ten years, my answer is really just as simple as that – I want to have made the world a little bit better. To do so I need to keep learning. To do so I need to look for ways I can improve the code of the world around me, whether that is in my personal life or professional one. I want to take my experience, my influence, and my knowledge and apply it in little ways to make incremental improvements for as many people as I can.

But, ultimately? I still want to be here.

Ambush

Posted on by
Reply

One of the first things I had drilled into me when I first started dipping my toes into the madcap world of organizational change was that you never, ever, “ambush” someone in a meeting with questions they are not prepared to answer. This was particularly important in cases when you had concerns or questions about something another person in the meeting was attempting to accomplish. These types of discussions, I was told, should ideally happen before the meeting so that when you go in front of the rest of the group you were presenting a “unified front.”

In other words, you and the other person hash your issues out in a meeting-before-the-meeting, come to an understanding, and then go and present your decision to the group as the “right” decision.

This scenario is one of the many reasons why I have a long-standing reputation as a person who hates meetings. It represents a fine example of collaboration theater, and it is just as wasteful as the meeting-after-the-meeting where decisions that were supposedly made tend to get undercut.

I have been trying to get my head around why this happens for years, and I have landed on what I think are a few main reasons, but they all tend to circle back to two root causes – Lack of psychological safety, and lack of trust.

Psychological safety gets tossed around a lot these days, and I feel like the importance of the notion has been dampened as a result. It seems like there is a common misconception that when someone says uses the phrase “psychological safety” they are implicitly implying that there should be no conflict. I interpret psychological safety to mean essentially the exact opposite. For me, psychological safety represents situations in which healthy conflict can occur. Ones in which people felt free to express their opinions, ask questions, challenge assumptions, and otherwise contribute without fear of being negatively impacted by doing so. Negative impacts can range from being characterized as a troublemaker, being complained about to a supervisor, being passed over for promotions, being bullied, or even losing a job (to list just a few things).

Trust can also be interpreted in a variety of ways in this context. Trust that the other people in the room have common goals for one, but it also includes trust in the competence of people outside of your immediate sphere of influence. Trust that those you are working with are operating with the best of intentions and at the best of their abilities is another.

Neither of these concepts is new, which is one of the reasons why I find myself surprised that both things are still a factor in many modern professional settings. Perhaps surprised is not really the proper word. Creating trust in the workplace is hard. Creating cultures where team members feel genuine psychological safety is hard. These things require dedication, diligence, and a significant amount of time. Time that can also be spent trying to “get things done.”

Completing tasks is easy. Much easier than changing the way we work, and treat, each other in the workplace.

Some thoughts on “Comprehensive Documentation”

Posted on by
Reply

There is no value in documentation.

Why Would You Say Something So Controversial Yet So Brave? is a quote from The Eric Andre Show rendered in an image macro and used as a reaction image on Tumblr humorously in response to relatively banal statements.

I am sure that if you know me personally, or if you are at least tangentially aware of what I do and how I view the world, you are rolling your eyes right now and writing off my statement as being naive. My ask is that you go along with my thought process for a minute to understand what I am really saying.

One of the four values in the Agile Manifesto is “Working Software over Comprehensive Documentation.” Many people inherently interpret this as meaning that those of us who resonate with the manifesto believe that we should never document. This is patently untrue. In fact, if you look at the statement under the four values it explicitly says that “while there is value in the items on the right, we value the items on the left more.” Agile enthusiasts do not advocate for the abolition of documentation.

What we want is documentation that is valuable, and for documentation to be valuable it must be useful. The people it was written for must be able to find it. They must be able to understand it.  The documents must be relevant to the current environment.

Having a document repository that nobody uses is wasteful. Putting effort into populating such a repository is wasteful. Using physical and/or virtual space to store documentation that is never referenced is wasteful.

One of the reasons why I am so critical of “traditional” project management practices is because of the amount of documentation that is considered a requirement for projects to be completed, and the main reason I feel that way is because I see most of them being designed as cover for the Project Manager. Often, I see situations in which a Project Manager has all the responsibility for ensuring project success but none of the authority to make it happen, so they make sure that they document everything that they do to be able to say they have done their job when a project fails or is delayed. I cannot tell you the number of times I have seen this happen personally. I have, in fact, watched a Project Manager bring up said documentation and force people to look at it to prove exactly this.[i]

I do not claim to have the right answer for what is the proper amount of documentation in any given situation. Like most things in the Agile world, it really depends. As a developer, I was a huge fan of self-documenting code (using variables with long, descriptive names to describe what the code was supposed to do), so I did not spend a lot of time adding comments to my code. I also contend that if your organization does not have individuals dedicated to the creation and curation of knowledge most of your documentation efforts are going to end up being wasted (largely because doing so is a full-time job). If your end users search for a document on your intranet and cannot find it, it might as well not exist.

Even more controversial is the notion that your systems/processes/products should be designed in a way that does not require documentation in the first place. Documenting complexity does not generate value for your users but eliminating that complexity does.

Creating documentation is a process, and like any process you should constantly evaluate it to determine whether it is generating value. If it is? Think of ways to make it more valuable! Maybe teach others how to do what you are doing or find ways to make your documentation more accessible to your end users.[ii] But if, as if often the case, your documents are essentially locked in a disused lavatory behind a sign that says “Beware the Leopard” your time could be better invested.

[i] In the specific example I am thinking of, the PM in question asserted that it was not their fault if the people in the meeting were unaware of a situation because the PM had followed the communication plan. My contention is that if you followed the communication plan and your message still did not get across the fault is in your communication plan, not the people.

[ii] If, for example, a user says they searched for your document on your company intranet and could not find it ask them to show you what they did and give that feedback to the people who manage the intranet.