Shaping culture through inaction

I follow Dan Rockwell on twitter. His handle is @leadershipfreak and he tweets quite a bit of good leadership content. If you don't follow him, I recommend you give him a look.

Dan sent a tweet out about how reinforcing behaviors builds organizational culture.
I agree with the tweet. I retweeted it.

The only thing necessary for the triumph of evil is for good men to do nothing by BK, on Flickr
https://www.flickr.com/photos/pictoquotes/10476531225
It got me thinking. It is not only the things we reward that shape culture, but the things we allow. Perhaps the easiest way to shape a culture is to do nothing at all.

When a rockstar employee yells at, denigrates, or refuses to help teammates and you let it slide because the rockstar is valuable, you are shaping a culture. When a teammate tells a racist or sexist joke and you say nothing because nobody present is a member of the target group, you are shaping a culture. When an executive abuses power, when a coworker engages in gossip, when a team cuts corners to make deadlines and you decide it isn't your problem, you are shaping a culture.

What appears to be inaction is still an action.

The Love Contagion

We have an application internal to Groupon called the "Love Monster". It was written, in large part by Devin Breen. There are other contributors, but Devin is the one that made it happen. He didn't do it because it was on a roadmap or because it's part of our quarterly objectives. He did it because he and others wanted something like this to exist. So he willed it into existence.

The idea is simple - send people love. If somebody on your team goes above and beyond, send them some love. If somebody helps you through a tough time, send them some love. If somebody does something that exemplifies our company values, send them some love. When you send love, the recipient gets an email and the love note is recorded for all to see. Anyone can give love. Anyone can receive love.

This makes me happy. Not only do I enjoy getting a little love now and then, but I really enjoy giving love. I have a recurring reminder to reflect on the past couple of days and to give out some love.

The science on appreciation tells us that gratitude is not only lacking in most work environments, but even a little bit of appreciation can lead to a better work environment and higher performance. People start to feel better about themselves, perform better as a result, and are more likely to show appreciation to others, creating a virtuous cycle of performance and appreciation.


Let's Start an Epidemic by Doc Norton from Groupon Engineering on Vimeo.

Let's Start and Epidemic!

Let a family member, friend, or co-worker know how much you appreciate them. Tell us about the awesome way you show appreciation at work. Share a quote related to showing appreciation, leading with gratefulness, or brotherly love. If you use social media, tag it with #LoveContagion.


Inflexible agility

Back in May of 2014, I attended ALM Chicago. I had the privilege of closing out the conference with my "Let's Start an Epidemic" talk. The second speaker of the day was Venkatesh Rao. This was his third time speaking at the conference and I quickly came to understand why they kept inviting him back. His talk was daring, extemporaneous, and insightful. There were many pearls in his presentation, but one thing he said in particular struck me. And it's popped back into my head time and time again since that day:
Yet - this is what we do; the "agile community". We say people over process and talk about nothing but process. We debate the merits of XP, Scrum (ala .org or alliance), kanban, SAFe, and DAD. We debate the value of specific practices. Now and then, you'll even hear someone proclaim, "If you are not doing [insert random practice], then you are not agile."

I find it ironic that so many who claim to be agile are so inflexible in their views.

Let's talk about people more than process. Let's focus on individuals and interactions, working software, customer collaboration, and responding to change. Let's figure out how to best achieve these things in our own unique environments. Let's follow the same kind of thinking that lead to these practices so many now hold rigidly to as agile.

The world has changed. The tools have changed. The dynamics have changed. There is more to learn.

I fartlek in your testing strategy's general direction

I see an interesting parallel in the debate over practices in the running world and practices in the software development world. Indulge me for a moment while I attempt to share my thinking.

Mileage versus Code Coverage

In running, we often look at the miles you run in a given week as an indicator of your general ability to perform in a race. At first glance, one who runs 20 miles per week would not likely perform at the same level as one who runs 50 miles per week while 200 miles per week is probably going to hurt performance. But this actually depends on the type of race you're training for. If you're a sprinter, 20 miles per week may be optimal and 200 would be just silly. If you're an ultra-marathoner, 20 miles per week will not cut it and you may be topping out at 200 on some weeks. What is optimal for one is not reasonable for the other.

In software development, we often look at code coverage as an indicator of confidence that our code is adequately tested. At first glance, 20% coverage is not as good as 50% coverage while 200% coverage is probably too much (every line of code covered by at least 2 paths). But this actually depends on the type of system you are working on. A legacy code base where the majority of the code is never touched might be sufficiently covered at 20%, assuming it is the 20% that frequently changes. If it is a greenfield code base comprised of small well composed classes, you may exceed 200% between unit and integration tests. What is optimal for one is not reasonable for the other.

Types of Work

In running, we can engage in base work, strength work, and speed work.
In software development, we can engage in unit testing, integration testing, and acceptance testing.

I know these are simplifications. This is not a comprehensive overview of either endeavor. I don't need all you opinionated, highly-critical, and vocal runners that follow me lambasting me because I didn't mention fartlek, intervals, zones, or VO2max. Fortunately, most developers don't share those same characteristics.

Beginning runner programs often focus on base work. This is relatively long slow distance through which we can prepare safely for any general race. Beginning developer programs often focus on test first techniques. This is relatively isolated testing through which we can write reasonably simple applications. Neither of these approaches alone is enough to create excellent performers.

To be excellent performers, we need to understand the purpose and application of each practice. We need to know when to use each in order to solve a particular challenge.

Want to improve endurance? Base work.
Building a single class? Unit testing.
Want to improve power? Strength work.
Verifying contracts? Integration testing.
Want to improve speed? Speed work.
Verifying user interactions? Acceptance testing.

For each type of race, the distance run and combination of work needs to vary.
A sprinter needs lower miles with a focus on speed.
A marathoner needs higher miles with a focus on base.

For each type of application, the amount of coverage and combination of testing needs to vary.
A simple service needs fewer tests with a focus on units.
A class that consume that service needs more tests with a focus on integration.

Well-intended advice

When someone tells you that too much focus on base training can result in a slower race, they may be right. Or maybe they are a sprinter dispensing advice to a marathoner. In either case, nobody in their right mind would suggest you don't run base miles.

When someone tells you that too much focus on unit testing can lead to over-confidence and broken contracts, they may be right. Or maybe they are a full-stack developer dispensing advice to an algorithm developer. In either case, nobody in their right mind would suggest you don't unit test.

Mileage alone is not the measure of a good runner. It is the careful and deliberate combination of quantity and type of running that results in optimal performance.

Code coverage alone is not the measure of a good test strategy. It is the careful and deliberate combination of quantity and type of testing that results in optimal performance.

Choose, Observe, and Adapt

The best runners understand the tools available to them, choose an informed combination, observe their own results, and adapt.

The best developers understand the tools available to them, choose an informed combination, observe their own results, and adapt.

5 Tips for Building Trust

In 5 Tips for Building Trust | Globoforce Blog, Darcy Jacobsen suggests the following steps for building trust within your organization:
  1. Encourage multilateral communications and dialogue  among peers and between employees and leaders. Offer workers a shared sense of ownership in company goals and mission—encouraging employees’ sense of voice, position, significance and purpose.
  2. Establish strong company values that employees can understand and know how to practice—increasing their sense of belonging, purpose and security.
  3. Set challenging but achievable goals
—to increase employees’ sense of challenge, learning and autonomy.
  • Shift the focus from hierarchy to community
  • —connecting employees to one another in ways that empower them and increase their sense of belonging, connection and security.
  • Ensure that you are adequately recognizing and rewarding individual and team achievements as they relate to shared values and goals. Make sure those rewardsrespect individualism and include choice. This will increase employees’ sense of fairness, purpose, recognition, belonging, and choice.
  • These all seem self-evident to me.
    “A man who trusts nobody is apt to be the kind of man nobody trusts.” - Harold Macmillan
    As I look at the list, I agree with all of the statements. I don't think it's a comprehensive recipe, but it's solid advice. The sequencing of the list jumps out at me as a tad off. I'm not sure Darcy is suggesting things be done in this order, but enumeration implies some form of priority or sequence. Assuming there is a priority to this list, I'd put strong company values first, followed by shifting focus from hierarchy to community. These two are the foundation of the remaining three items.

    I encourage you to read Darcy's article. And please share your thoughts by commenting on this post.