You Had Me At Hello

I admitted to my cousin Laura the other day that I was watching the movie Jerry Maguire and loved it. Sure, I’m a sucker for a romantic comedy with a happy ending. This movie has even more appeal to me. The premise of the movie is a great leadership lesson captured by Jerry’s manifesto in the very beginning. In particular, “The answer is fewer clients.” More focus on personal relationships.

I’m not a sports agent, and this still applies to me. I think of each of my direct reports as clients. I work to get to know them and help them succeed. You may not have direct reports, and you still may have people that you feel responsible to help develop. They are your clients. And I believe in limiting the number of clients I have to allow myself to focus on them. I don’t believe you can have the same depth of relationship with twenty direct reports as you can with five.

In the movie, Jerry gets his wish as his world comes crashing down upon distributing his manifesto to everyone in his firm. He is fired, loses all but one of his clients. He is forced to survive by focusing his entire attention on just one client, American football player Rod Tidwell. I would argue this movie is both a romance AND bromance; following the evolution of the relationship between Jerry and Dorothy and also Jerry and his client, Rod.

Jerry is forced to evolve and get to know Rod and his family in a way he lost as a high-volume agent in a large agency. Jerry gets to know Rod’s wife and kids. They play together. They weather ups and down. And when Rod is injured on the field, it is Jerry that comforts Rod’s wife. Imagine having a relationship with someone you work with that would result in YOU being called on for comfort in a life or death situation.

Maybe that makes you uncomfortable. Because you see work and personal lives as separate. You feel like you’re prying when you ask about personal details, or you are shy to divulge them yourself. I certainly have not alway been comfortable sharing my love of the romantic comedy with the world. It can result in feeling vulnerable and exposed.

I’ve come to realize that trying to hold on to work separate from personal is a losing battle. We spend lots of time with people we work with. When we try and hold back pieces of ourselves we can be perceived as less than the human beings we are. When we avoid showing empathy, or compassion, or vulnerability. We can be difficult to relate to in situations where relating is our job, and our results rely on working together.

In the movie, the context is clearly the sports agent and his relationships. We all rely on others in our work, especially as leaders.

"The cause is caring about each other. The secret to this job is personal relationships.”

You had me at "hello”.

Respond, Don't React

You are more effective as a leader when you see the world around you for all the variation, and choose how to respond. Our world is a constant roller coaster ride. We have ups and downs that can feel like we’re being whipped around. It’s natural to move through the world simply reacting to stimulation. Reacting to other people. Reacting to unexpected situations. Reacting to new opportunities. Not truly taking the moment to think about what you will do next. Leaders don’t simply react. Take a moment and respond. 

It isn’t easy to insert that pause between stimulus and response. It takes practice to develop such a habit. For me, I’ve spend most of my adult life simply reacting. I honk my horn at the car ahead of me that takes too long at the stoplight. I send a fiery e-mail to chastise a coworker. I scold my child for disobeying. I am better when I see the stimulus, consider my feelings and choose to respond (or not respond). I have much more success.

I was reading a book called “10% Happier” by Dan Harris at the recommendation of my good friend Ryan. He set my expectations well that it was an interesting story of this news anchor who melted down on-air and went on a journey to explore meditation to understand how to deal with what he calls “the voice in his head.” Ryan also nailed that by about two-thirds through the book you feel like you have the basic story, and finishing it was much harder than starting it.

I relate to the words Harris uses to describe himself. He talked about being driven, at times obsessive about planning, and direct to a point of being jarring to others. He discusses his practice of meditation and mindfulness as his way to develop the habit to avoid mindless reaction. I appreciated the way he described his own skepticism about the process. I share much of that skepticism. 

One of the messages that “10% Happier” articulates is meditation can be training to control your attention, and provide tools to avoid reflexive reactions. I walked away with the understanding of the difference between reacting (an unconscious reflex) and responding. Dan Harris walks through his own personal story of managing to tone down his reflexive reactions and be more mindful.

Harris comes across as self aggrandizing in way that might be off-putting for some folks. The whole title is “10% Happier: How I Tamed the Voice In My Head, Reduced Stress Without Losing My Edge, And Found Self-Help That Actually Works - A True Story.” It feels like a warning to anyone that picks up the book that he’s a little narcissistic. 

In my own life, I find that when I can effectively be present in the moment and respond rather than react I am much happier. I am allowing myself to be happy. There are similar lessons in Chade-Meng Tan’s book on Google’s mindfulness program “Search Inside Yourself”.

I am side-stepping some of my first reactions that don’t support my desired end-goal. Harris calls out advice he got from an instructor to ask of any response “Is it useful?” Let your response go if it isn’t useful. You will be a better leader. You will be happier. And everyone else around you will appreciate your apparent calm. 

Actions Speak Louder Than Words

Leaders spend a lot of time communicating. In fact, it was a hard lesson for me to realize that communicating was one of my major job responsibilities as a leader of a large organization. It’s important for any leader to realize that communication is many things, including your actions. In many cases your actions can render your words meaningless. As a leader, it’s that much more important to be sure your actions represent the words you say to reinforce your message.

This lesson couldn’t have been made any more clear to me than during the current teacher strike in my kids’ school district. The teachers in our school say they don’t feel respected by the board of education. The board of education has said they respect and appreciate the teachers. The negotiations have been slow and tense with both sides accusing the other of mistreatment. The negotiating tactics have left the parties feeling disrespected. The words say the exact opposite.

As a leader, your actions are always under scrutiny. Your team is looking to see if your words are backed up by your actions. There are plenty of times when you may not realize the message your actions are sending. For example, when you say that you don’t expect your staff to respond to e-mails over the weekend and you still e-mail your staff on Saturday. If you aren’t very explicit that you don’t expect them to read or respond, it is likely the reader will assume some kind of urgency to work on it over the weekend.

We can be more effective by being extra aware that others may misinterpret our actions. Your team will ascribe a motivation for your actions that suits them. They may be totally wrong. We all naturally go through an exercise the looks like “If I did that I’d have to feel like this…” Once you’re aware you can take action.

Plan to communicate around your actions. Be explicit and share your motivation so people don’t have to interpret it for themselves. Practice looking at your actions from another person’s point of view, and explain a bit more around your actions and your intentions.

Change your behavior in a way that supports your message more directly. In our example above on e-mail, perhaps include in the message “I don’t want to forget this for Monday, so I’m sending the e-mail on Saturday. Please know I don’t intend you to have to work on it over the weekend.” Or perhaps you schedule your e-mail to send on Monday morning even though you wrote it Saturday night.

Actions speak louder than words. And your actions as a leader are always on display and open for judgement.

Live a Life True to Yourself

You may immediately think of this as just another inspiring statement you see on social media - “be true to yourself!” There’s depth beyond the clever Facebook postings you see every day. I was reading an article on Slow Hustle, a web-site on slowing down and enjoying life, called “The Top 5 Regrets of the Dying”. It sounds dark, and there’s real wisdom in the words. 

The top 5 regrets come from the experience of a nurse who provided care for people in their last 12 weeks of life. The number one regret is “I wish I’d had the courage to live a life true to myself, not the life others expected of me.” It seems straightforward. I really I think we can all relate to this concept. We don’t live in a bubble; we shape our decisions by the way we think other will perceive us. 

It isn’t reasonable to think we won’t adjust our lives based on what others think. Many people don’t push the bounds enough. Or challenge the assumptions they make. I recall a provocative question that has stuck with me: “what have you done today that scares you?” I would say often we don’t live the life true to ourselves because we’re afraid of the consequences. And that keeps us safe. It also keeps us from pushing boundaries that should be pushed.

Number two of the regrets is “I wish I hadn’t worked so hard.” I find this regret hard to relate to personally. I understand not letting work run your life. Perhaps this is where many people struggle. I am one that values hard work. If I’m working, I want to work hard. If I’m playing, I want to play hard. It reminds me of the Jim Harbaugh quote “Attacking this day with Enthusiasm Unknown to Mankind.” I prefer to interpret this regret as wishing I had chosen work less often. I very much agree we should all know where to draw the line. And we all need to prioritize our self and family.

Another of the top five regrets is not staying in touch with friends. I can totally relate. My friend Alex recently pointed out that although I’ve written many blog posts, I’ve never once mentioned him. And I want to publicly appreciate him for reaching out to me. I’ve done a better job in the last few years of being aware of my friendships and working to stay in touch. I find that staying in touch is hard for me, and I am always glad to hear from a friend. So thanks, Alex, for e-mailing.

The last regret of the top five simply states “I wish that I had let myself be happier.” Here’s the big reveal of the top five regrets. Folks on their deathbed recognize what so many of us have missed. Over the last three years I’ve worked much harder at allowing myself to be happy.

We have the power to allow ourselves to be happy. It may seem easier when Michigan football is winning. Regardless of outside circumstances, we are in control of our own happiness. So take control. Live a life true to yourself. Be happy.

Listen Fiercely

Listening is a lost art in modern life. So many things contend for your attention. Consider your day today. How often have you been distracted and not totally listening? Leaders connect with others. Notice when you’re in a conversation. Work to listen fiercely to the person speaking and you’ll connect on an entirely new level.

It is understandable that you have many priorities pulling at you. Maybe you’re getting ready for your day, checking your e-mail, trying to meet a looming deadline. In these circumstances, it’s tempting to allow a conversation to proceed even though we are preoccupied. Especially if we’re on the phone and pulled to multitask. Even when we’re standing in front of someone, we feel justified in checking our phone because we feel we can do both.

I have made the mistake in the past of assuming listening is a passive activity. I have assumed that listening is something that I can do while doing other more active things. What I have realized is that even in the best of circumstances, I give the impression that I don’t care about the conversation. At worst, I miss key points in the conversation. I always miss developing real empathy for the other person in the conversation. 

I continue to have experiences that reinforce the value in focusing on the conversation. When I’m driving, I’m not giving the conversation 100%. I have found I am much more effective when I decide to pull over. When I’m in front of my computer, I must resist my tendency to scan my e-mail. These distractions will pull you away from fiercely listening.

I make it a practice to set aside other distractions when I’m listening. When I’m standing and the other person is sitting, I will sit. If I have something in my hands (phone, papers, whatever) I will put it down. I will make eye contact. I will acknowledge the speaker, affirm the points made and often allow moments of silence to see what develops. When I’m on the phone, I often take handwritten notes of the words spoken. It helps me resist the temptation to do something else.

Not every person immediately appreciates this fierce listening. When I’m in a conversation with someone who is distracted, this level of intense focus is uncomfortable. Often when I’m in a conversation with someone where they clearly are preoccupied; I will offer to come back another time. Sometimes this offer is just the jolt my companion needs. Together we can decide if now is the time to give the conversation entire focus.

I find that I often receive focused attention back in response. Sometimes the other person simply accepts my invitation to be left alone. Many times my conversation partner simply doesn’t realize they are dividing their attention. This is a kind way to highlight that the conversation may not be as effective if your partner isn’t focused on you. 

Leaders make connections with others. It is possible to get through your day without actively listening. You’ll pass the time. You may avoid leaving a bad impression. You will not make deep connections with people. You will miss adding value through these connections.  

Smile with Your Entire Face

Leaders spend lots of time communicating and building relationships with people. It’s evident that people like spending time in the company of others that help them feel good. There’s no better way than smiling. A genuine full-face smile. If you haven’t realized it yet, just turning up the ends of your mouth isn’t really a smile. And other people notice.

It took me a long time before I realized the difference between a forced smile and a real smile. I often am preoccupied with what I’m doing at work. And early in my career you would be hard-pressed to see me smile at work. I was working, and smiles were a distraction. I eventually realized the impression folks had of me and I didn’t like it. I started smiling more. Only over the last ten years have I realized that I was forcing my mouth to smile. The rest of me was still just thinking about the next thing I was going to do. It wasn’t a real, full-face smile.

Consider the last time something made you genuinely happy that you smiled. Maybe your kids, or a joke that struck you funny. Or maybe you found $20 in some old jeans. That smile changed how your entire face looked. Your eyebrows went up. Your eyes looked different. Your ears moved. Your whole face smiled. 

Now think about the last time you ran into someone at work, a colleague, and you greeted that person. Maybe you didn’t frown. Hopefully you are at least making eye-contact and saying hello by now. Did your entire face light up and smile? Why not?

It may seem silly to think about practicing the act of smiling. Your job as a leader relies on other more than ever. Consider the story of Steve Jobs practicing his intense stare. He would look in the mirror and practice it. I’m not saying that’s a leadership tactic I endorse. He knew his effective stare would be needed when he was going to invoke the reality distortion field on others. He spent time on it. 

I’ve noticed that I can’t rely on my natural expression to convey my actual feelings about someone. My natural facial expression is somewhere between mad and in-pain. My daughter will ask me “why are you making that face?” When I force a smile, my natural tendency is to smile with my mouth. My forehead still says “I’m anxious.” And so I try and be aware when I’m smiling to relax my face, raise my eyebrows. I challenge myself to be genuinely happy in that moment.

I find myself practicing with flight attendants. I fly a few times a month. Flight attendants are people who have to put up with a lot of not-happy people. They are here to help. So I smile at every one of them. As I board, as they walk by, when they offer me a soda. I don’t find an airplane a particularly happy place. It’s a good place to try and channel happy when the nice woman in front of me decides to fully recline her seat into my lap.

Why not look in the mirror and practice your smile? Why not at least pay attention to how your face feels when you’re happy and smiling in a genuine way. What muscles are relaxed? Can you mimic that feeling? Can you do that on command with practice? And if you can, and share that feeling of a “happy, smiling self” to your staff every day. Wow. 

Decision Making and the Impact on Your Organization

How decisions are made impacts the organization. Set aside whether an organization makes good decisions. Where decisions are made inside the organization affects the organization itself. As a leader, it’s your job to make sure decisions are being made at the right level to develop the organization you want.

Let’s think about an organization where decisions are made at the top. Strong individual leaders who drive decisions that could be made lower down. The leaders at the top feel it necessary to make these decisions themselves. They rob their middle-level leaders of the opportunity to learn how to make these decisions. And this organization is handicapped from growing beyond the capacity of the top-level leader. This leader trains the organization to bubble decisions up and s/he becomes a bottleneck.

Let’s think about a different organization where decisions are made at the very bottom. Individual performers are left to make decisions that have impact beyond their sphere of responsibility. This organization becomes quickly fractured; with decisions that don’t fit together. Lots of local optimizations that come with lots of enterprise redundancy. This organization also has trouble scaling up and growing large. This organization is a patchwork quilt without vision into the larger picture.

It is the leader’s responsibility to consider where decisions are made. And to choose to build the organization we know to support our long-term goals. I heard recently a Manager Tools podcast that briefly referenced the difference between a manager and an executive. An executive is responsible for immediate results and long-term strategy. Where a manager is more focused only on the immediate results. As you develop executive skills, think about the impact of where decisions are made on your organization.

An organization that develops strong middle managers as it grows can scale beyond some of the limits of individuals. A leader that invests in developing decision making skills down the organization will enable that organization to scale. This investment is creating long-term capacity.

I also see this as where “no-manager” organizations struggle.  Not everyone wants to spend time on decision making and communication as required by middle management. It’s not reasonable to expect everyone to be held responsible for managing the organization (as in the holocracy concept). Some folks are good at this (and like it). Many don’t.

Thinking about decision making inside the organization is a balancing act. Small startups simply don’t require too much of this consideration. There aren’t many people to manage. However every startup I know has a crazy growth goal.

As a company grows, this balancing act becomes more and more important. An organization that explodes with growth without middle managers will struggle to scale effectively. Take a moment to consider where your organization is on the size spectrum. Ask yourself where you can influence what level decisions are made in your organization. 

Decisions and Consequences

I spent a week camping in Yellowstone this summer with my family. One of the most sobering events of the summer for me was the news that a hiker was killed by a grizzly bear. Just two-weeks after I hiked the same trail with my son.

We were tent-camping in Yellowstone for the week as a family. It was going to be the biggest camping trip ever for us. Both the longest trip (six nights) and the most remote (no electricity, no showers, surrounded by nature). We talked about the risks and we did our best to take precautions. I had bear spray with me at all times. We took care with our food, storing it in bear proof boxes. We did our best to follow the guidelines shared by the National Park Service and other experienced campers.

On our last full day in camp, we got up early and my son and I were joined by friend and his son and we hiked Elephant Back Trail. It was a moderate hike up a small mountain with a wonderful view. We stayed together, and we carried bear spray. We didn’t see any wildlife on that hike (although we saw bison, elk, moose, deer and bear during our trip). We enjoyed our backcountry experience very much.

Almost two weeks later to the day on that same trail, Lance Crosby was killed and eaten by a mother grizzly bear. Yellowstone is a very big park. There are hundreds of trails. And bear attacks are rare (especially when you consider how many visitors come to the park every year). The idea that someone was doing exactly the same hike that we did and was killed is very sobering.

From the reports, Mr. Crosby was a seasoned hiker. He worked in the park for many seasons. It’s very sad that both Mr. Crosby and the mother grizzly ended up losing their life as a result of this encounter. I suspect he understood the decision he was making by hiking alone. And I suspect he understood what could happen if he encountered a bear without any defenses.

This situation brings into stark relief for me that every day we make decisions that have consequences. We plan for the expected outcome. We must also be willing to accept the unexpected outcomes.  We make choices in what we do. And we make choices in what we don’t do. Decisions we make - to either do or don’t do - have consequences for each of us.

I’m happy to have hiked Elephant Back Trail. I had a unforgettable experience with my son, Mike and Ethan. And we all enjoyed an unparalleled view of Lake Yellowstone. 

Good Software Hygiene

I spent two weeks on the road with my family mostly camping. We camped eight nights in national parks - six of those in Yellowstone. It was an incredible experience. I made a small observation to share that I found parallels our work in software development as I emerge back into the civilized world. It’s important to practice what one of my former bosses called “good hygiene” for software development. What’s tricky is that good hygiene isn’t a constant - it depends on how dirty the working conditions. It’s important to invest more time when you’re getting more dirty. Even in code.

Sometimes good hygiene means spending more time if you’re working in rough conditions. I found that while I was camping, I washed my hands the same amount of time with soap and water. And yet the work I was doing - building a fire, setting up camp, generally getting dirty - meant my hands were always dirty. I had dirt under my fingernails constantly. It didn’t matter that I was still washing my hands at the same rate, with the same effort.

I spent two days in hotels on the way back from Yellowstone. During those two days, I continued to wash my hands at the same rate and my hands starting looking cleaner and cleaner. I wasn’t setting up and breaking down camp. I wasn’t working in the fire. My nails starting looking clean again. I didn’t look like I was camping any more.

In software development, I think of bug fixes and refactoring as elements of good hygiene. You can’t simply decide that you’re going to invest a set amount all the time. It depends on the quality of the code you’re working in whether you’re spending enough time on good hygiene practices. If you spend the same amount of time fixing bugs and refactoring on a brand new subsystem as you do on a legacy piece of code, you’re going to end up with the legacy code still looking ugly.  

Give Grace More Than You Ask For Grace

Grace has a lot of different definitions. Over the last five years I’ve come to use grace as a noun in a particular way that Webster defines as “goodwill” or a “favor”. I have found that it is incredibly powerful to give grace to others. Good leaders give grace to others much more than they expect grace from others.

In a simple way, this happens every day. I can get frustrated when folks don’t do what they’ve committed to do. Deliver a report. Update me on status. Attend a meeting (on time or at all). These things are not big things - not make or break things in the grand scheme of things. My natural behavior lends me to quickly becoming frustrated at these little things. And I have to remind myself to give the other person grace.

I find sometimes it is easier to suggest to others that they give grace. I often can be quick to judge, and I need to slow down. I can think of myself as a close friend and suggest to that friend that perhaps I need to give grace in this situation. Rather than jump to judgment or become upset.

I remind myself that I know next to nothing about what that person is dealing with and why they are late, absent or unable to update me on status. There are things in this world out of our control. There are priorities like family that are much more important. I remind myself that whatever reason I can give that person grace and let go of whatever transgression I’ve built up in my head. It’s a wonderful give to give others grace.

There are times when I need grace. There are times when a flights is delayed and I’m unable to make a meeting. When my family needs me and I’m there instead of at work. When my phone dies and I simply cannot update someone on the status or attend a meeting even by phone. And these are times when I need grace from others. I need the grace to not have my transgression held over me. 

It is in these ties of needing grace that I welcome the balance that I have given so many others grace. When I am in a hard situation, unable to meet the expectations of my colleague I can say to myself “I need grace.” And I know I have given grace to the world in a way that complements my own need for grace.

It’s important for me to give grace as often as I can, and to ask for grace as rarely as possible. It feels like a karmic balance that I can exist in the world giving more grace than I ask for from others. And I feel like that can put more positive energy in the world. We will always need grace from others (often when we least expect it) and giving grace freely can help lend balance to the flow. 

Say Yes More Often

A leader says yes a lot. It’s a positive affirmation. When someone makes a request of you, the best possible answer they can hear is “yes!” It’s so powerful and affirming. “Will you help me?” “Yes!” Imagine that you can provide that affirmation.

My kids joke that I’m mostly a “no dad” and only sometimes do I become “yes dad” (on special occasions like vacations or no-mom-no-rules-weekend). And it’s true, often times my first impulse is to say no. I’m not sure why. It’s a reflex to resist outside forces. Not everyone is like that, I know there are people who say “yes” more than I do. And I work on trying to say yes more often. 

It reminds me of a rule of improv that a colleague Hervé Granjean shared. Always respond with “yes and” to keep the improv moving. There’s an interesting twist on improvisational business where you need to keep the work moving.

My first instinct is often to be concerned by the commitment or change to whatever previous trajectory. I worry that my “yes” will commit me beyond my limits. I have spent time training myself to first think “How can I say yes?”  Very often you can say “yes” in a variety of ways that affirm your willingness to help without being overcommitted.

I recall specifically an experience where I got an e-mail from a colleague who said “do you have a resource that can do this particular technology that I can borrow for six months.” My initial thought was “no, my resources are all fully committed.” Instead, I found myself asking “What would I do if I were in this situation?” I replied with a paragraph of detailing a service provider we use when we’re in a crunch for talent and we need someone quickly. I gave my colleague the person I deal with at the service provider and offered to introduce him if he’d like. He was so grateful. No one else had bothered to reply. I gave him an option when before he had none.

I’m still a “no dad” most of the time. Although I do find myself finding ways to say “yes” more often. When my kids want an additional hour of TV time I replied yesterday “Yes, after you walk the dog and do the laundry.” It was met with muted enthusiasm.

Try finding a way to say “yes” today maybe once when your initial reaction is to say “no” and see what it does for you. For me it has unlocked better relationships, and more power to help others achieve their goals and my own. 

Leadership Lessons While Camping

I had a fantastic week with my family camping in southwest Michigan and I was surprised how much working together on the campsite has lessons throughout not just for better family dynamics, but also for leadership.

We have a big water container - it’s easy to carry water from a common pump and bring it back to camp. It’s designed to sit on the picnic table and pour water out. But it’s a jug of water and the walls of the jug aren’t rigid; so it slowly rolls off the table and falls to the ground. For three days we used the water jug and it fell a half dozen times. 

I knew it was possible to hang the jug and it would be stable and easy to use. I didn’t take the time to hang it. I also found myself trying to encourage my son to do various camp chores like preparing meals, building the fire, cleaning the dishes. 

So, I asked my son to find a way to hang the jug of water. I gave him rope and said “let me know if you need help - with the knots or anything - but I believe you can figure out how to hang it so that it doesn’t fall and we can use it to get water."

He started right away. Looking for how to hang it. He used a stick that was his “staff” for walking. He made a stand against a tree. He asked for help with the knots. We hung up the jug. In fact, my wife also helped by suggesting some ways to hang the jug. In the end, the jug of water was hung and it was much easier to use. My son didn’t do it the way I would have, and that’s ok. We worked together on the bits that he needed help on. I let him take charge of solving the problem.

I wasn’t always successful. We also learned to sail a sailboat. I wasn’t as successful as I tried to delegate during our first few attempts at sailing. I asked my son to take charge of mooring (one of our new skills that we hadn’t quite mastered). I needed to steer the boat accurately and slowly to the buoy while he latched us on. I came in to fast twice, and on the third try I impatiently ran up to the bow to take over and try and “help” my son latch to the buoy.

We both ended up in the water as I “helped” him. I ended up having to latch us onto the buoy while swimming. No patience to allow him to try enough times to get it right, so we both ended up wet.

Delegation is important for a leader. It can be hard to let go. Allow for failure. Have patience. Collaborate don’t control. And don’t end up all wet. 

Velocity Abuse

I see folks using metrics to manage software development teams in a less than positive way. My friend Ed Hughes shared this article on why Velocity is Killing Agility and I tend to agree with the abuse of velocity in software teams these days.

I have advocated collecting velocity in past teams in order to capture the inherent capacity of the team. It’s a measure of a team; not a goal. It can’t be used to measure productivity. Don’t get me started on trying to measure productivity in software teams. If I have to have another conversation with an uninformed business leader on why we can’t simply measure something simple like lines of code by FTE to measure productivity I may never come back to software development.

Metrics can provide great insights into the effectivity of your development team. I love the advent of some newer metrics like cycle time that shows something that really matters - measurement of work in progress. Metrics can be used to inform team where they can improve. It can uncover issues that the team can then tackle.

Although many, many business books will extol the virtue of reducing inventory and work in progress on a manufacturing floor we have a hard time seeing it as a valuable metric in software development when we don’t have the complementary manufacturing measures like “widgets per hour."

I love using velocity as a metric for a team. I do find it useful for the right purpose. I use velocity to plan iterations and help a team become more predictable. And every business person I know loves predictability. If velocity is used to measure team productivity (or heaven forbid, developer productivity) it’s going to be gamed and become useless. If velocity is used to create incentives for people (or punish people), you should find someplace else to work.

In the end, I see the usefulness of metrics as part-and-parcel to the reason for the metrics to exist. A team (and by "team", I include executive leadership) needs trust. Where there is trust, the team can use metrics to improve. If the team doesn’t trust one another and metrics are used to “get more” or “find out who isn’t pulling their weight.” Work on establish trust within your team as any part of of using metrics to measure that team. One way to do that is to engage the team in the discussion around what you're measuring and why.

I don’t see folks ask the question “why are we measuring this?” I like metrics that help us understand if the team is producing software effectively. I also like to look at metrics to be sure the team is producing the right software. So many times, folks over-focus on producing software effectively and they don’t care if it’s right. The team can optimize to produce a lot of garbage software.

If you want a business metric to tie to a software development team - I still love the idea of using customer-based metrics like net promoter score (NPS) to really measure customer happiness. I see NPS as a way to truly get at the thing the business cares about most - a forward looking revenue metric (something that predicts sales and renewals). I also love to look at utilization, although there are more nuances to that metric by product. In the end - find a way to tie a product team to NPS as a business metric to be sure they’re producing value.

So what metrics can a healthy team use to measure and improve their effectiveness?

To measure that your team is functioning effectively: I like velocity for planning. I also like cycle time to measure the work in progress. I think a team needs to know how many escaped defects they allow out of an iteration. I think there are creative measures like number of source code check-ins that I don’t see anyone use. We had lots of success using an internal measure we called “release GPA” that measured the communication during release and the success of the release process. These are a sample of what I’ve seen as successful metrics to measure the health of a team producing software.

Honesty in Software Development

In my experience one of the hardest things to get from a technical team is honesty. I don’t mean people are being purposefully deceitful. It’s not a question of ethics. I mean people have a hard time facing the truth themselves. It’s an often repeated axiom that programmers are overly optimistic. I’ve come to think of it as learning to be honest in the assessment of the situation.

Honesty is facing up to where you are on a task. Often times in a stand-up, I’m thinking about a task that I’m working on in terms of how many hours I have left. In a highly functioning team we may not need to think in terms of hours. But an individual who is in control of the work they’re doing is thinking about the number of hours left on a task and how they can complete it. When we start a story, the hours are the entire estimate for the story. After working on it for a day, an honest reporting of how many hours I completed and how many hours I have left is how I improve my estimate and track my actual hours.

Honesty in the stand-up helps continue to improve our estimates as we do work. In the stand-up, I’m thinking “I spent 4 hours on it yesterday and I have about 8 hours left to work it to completion.” If the task was a 4 hour estimate originally I now have much more information about the task that I need to share; and that has impact on the progress of our iteration. Although it’s less common, the opposite situation is just as important (when we spend 4 hours and complete a task that we estimated at 12 hours). At the macro-level our highly functioning team can report out “I finished yesterday” or “I’m going to finish today” if that’s a reliable statement. If not we need to dig deeper to improve our predictive ability.

Why is it easy to avoid honesty in the stand-up?

It’s very easy to avoid honesty in the stand-up. We’ll talk about a few reasons why; I’m sure they’re not exhaustive. I see these reasons very often with less experience people or teams.

We forget some of the details behind implementation and we aren’t secure to admit our oversight. It’s hard to admit we’re wrong. Especially if we’re trying to prove how good we are - new team mates, new boss, new project. We want to prove we’re right. And if we miss something in the implementation of a story we would much rather cover over it and smooth it out without having to say in front of everyone “I forgot that this API was used over here so I have to make sure it works in both places."

We get surprised at the difficulty that a previous decision has made this current task. It’s hard to admit that we took a short-cut before that makes this harder. This comes from incurring technical debt - something to talk about managing at another time. We will make choices to incur technical debt for all kinds of reasons. Many of them are good reasons. And when we come to a point where that debt makes our next story harder (before we’ve paid it off), it’s hard to be honest that we took a short-cut before. So now we’re trying to refactor a short-cut and implement a story; and it’s embarrassing to have to admit that the short-cut before is putting our current story in jeopardy.

We want to control the story by continuing to own it even if it’s bigger than we thought. We love owning things; we love the sense of completion. It’s why we became programmers in the first place for many of us. When a story gets out of hand and the estimate gets bigger, asking for help means giving away some of the control in how this story is implemented. This sense of ownership can be moderated if you have fostered a sense of ego-less programming (also common code ownership). But it’s natural that someone one your team is going to have a favorite way to implement something and desire control to see it through. We don’t want to see our story split and given to someone else

We fear missing our commitment. As much as we aren’t great at being honest about the situation, in the end it comes from a good place. We don’t want to disappoint. We don’t want to miss our commitment. Either explicit or implied, there are expectations we don’t want to miss. So we’re apt to hide from deviations in the hope that we can overcome them before they end up with big consequences.

How to encourage honesty

It is easier to tackle specific root causes If you identify some of the above as reasons why it’s hard to get honesty from your team. As a leader, you can direct positive reinforcement to downplay the fear. There are some overall tactics you can use with your team to drive increased honesty in your team stand up.

Encourage continuity between stand-up updates

One of the very best things about stand-up meeting is the cadence and frequency. They’re meant to be daily and short. And therefore there isn’t time to forget what happened yesterday. We use it as a feedback cycle to help one another get things done. Often it’s mistaken for a reporting meeting; status on the story. And while you can often get status on a story from the meeting you can get status on a story many different ways. It’s intended to surface roadblocks and ask for help; and offer to help one another. One of the best ways to identify when help is needed is to pay attention to what folks are saying from one meeting to the next (“you planned to get this done yesterday, how much is left?”). They can use your perspective to see what they may not -that they’re struggling with something they didn’t expect to struggle with.

When things go long, ask “How can I help?"

So what can you do if someone is struggling. Or if you see them struggle and they don’t realize. Ask “how can I help?” If you see yourself struggle, ask for help. Or just say “this is taking longer than I expected.” The honest of the situation in the stand-up will result in a supportive team taking action to help you out.

Pay attention to when folks are working longer hours to complete the work they expected

When folks are working more than you expect from them, or more than they usually do it’s another sign that things are going sideways. You can ask “are you able to get out of here at the normal time today?” Or “are the hours your working sustainable?” Remember one of the keys to agile development is sustainability of the work. It’s continuous, repeatable and sustainable. 

Context switch stories more frequently.

Context switching isn’t for everyone. The act of shifting story ownership mid-stream has some overhead. The benefits are many for a team that can commit to doing it. It creates a hard-wired culture of code ownership. Everyone works on every story throughout the iteration. Setting the expectation that if you start a story you won’t finish it removes some of the hidden reasons to avoid honesty.

Hold everyone accountable

Pay attention in your stand-up. Ask yourself if you are being honest with your own progress on stories. Engage your colleagues; ask them if they have a hard time owning up to the status of their stories if you see the telltale signs. Ask for help. Ask to help. 

If it feels like you’re ending your iterations with a big push to finish and accept stories; start paying attention to your stand-ups early. A two week iteration isn’t long enough to not be making good progress in the second or third daily stand-up. And if the problems only show up late in the iteration you probably need to ask whether you’re getting full honesty in the stand-up throughout the iteration. 

The Myth of Natural Leadership

You can find tons of articles about “natural leadership.” The Huffington Post has “7 Habits of Natural Leaders".  I can’t even bring myself to link to the Forbes article because it has some malarky about “how deeply to people value your thinking?" Inc magazine will even tell you the “3 Signs You’re Meant to be a Leader.” Natural leadership is a myth.

I recently listened to a podcast interview with Barbara Corcoran on the Dose of Leadership. I find Richard's interviews worthwhile. I might disagree with some of the observations that surface. I think it’s worth a listen to get exposure to other successful leaders. What jumps out at me is how successful leaders often don’t have great guidance for folks who want to be successful leaders.

When Richard interviews Barbara she concludes that hers was just natural leadership that she developed over lots of time. That her mom was a natural leader, and that she developed in her the same natural leadership. As the interview continues, there are clearly some good points to be shared. And the idea that leadership is simply a natural thing for some folks does a disservice to the multitudes of people that want to improve. Barbara hits on some of these behaviors even though she doesn’t highlight them as learnable behaviors.

There are behaviors you can learn. Nobody is born with these behaviors. They learn them. There’s nothing inherent about any of it. And you can learn new habits, become more effective and be a better leader.

Certainly some of leadership is being a role model. And yet many successful leaders model behavior that they don’t tolerate in others. So being a role model is something that happens - people watch what you do. Modeling behavior that you want to see in your team, that’s something that everyone can do. Treat others like you want to be treated (and how you want your team to treat your customers).

Certainly some of leadership is perseverance. Continuing to persist through adversity is an important aspect of leadership. Some of that is being the role model you want others to embody. Determination also requires communication in order that folks don’t see blind determination. There’s a time to cut-bait and pivot, and leadership means teaching people when to push through and when to pivot.

This isn't an exhaustive list of leadership behaviors. These are just some that came up in Richard's interview with Barbara. 

It’s a mistake to assume that some people are not natural born leaders. There are behaviors you can learn to help improve your effectiveness, and what others would describe as leadership. You may not be good at them. You may not like them. And you may not know how to do them when you start. You can try, and practice, and learn from your mistakes. And lead. 

Say Thank You

Say thank you. As much as you can. Stretch to find things about which to say thank you. Those things are there. I guarantee it. I certainly know I am guilty of moving through my hours and days and not reflecting enough on what others have done for me. And certainly not thanking them enough. It is easy to think of the day as going by, as people doing what they do, and not fully being thankful of the little things others do for you.

My mom always made sure I said please and thank you. I thought it was old fashioned even thirty years ago. Maybe that's what every twelve-year old thinks about what their parents tell them. It certainly is what my own twelve year old son must think when I tell him to say please and thank you. And it's incredibly important guidance. 

Look back at your calendar for last week. Did you ask someone for time to talk about something important to you? Did you schedule a meeting and invite someone who was important to the outcome of the meeting? Did you meet someone for lunch and catch up? Anyone who is taking the time to spend with you deserves even a little thank you.

Look back at your e-mail for last week. Those e-mails you got that helped you. Those e-mails you sent asking for help. Someone offering to help you or suggesting an article to read. Did you acknowledge them? Did you thank them? It may not seem like a big deal, it may not be that big a deal. And it is worth showing your appreciation that they thought about you.

Sure there are big things that jump out at you. Someone gives you a gift. An unexpected benefit to you or someone you care about. From my experience, even in these cases I forget to express my gratitude. I fall prey to the busy schedule and it escapes me to say the simple thank you.

I love getting written thank you notes. I know this seems very old fashioned, and the idea of holding a handwritten note in my hand is wonderful. There is nothing wrong with a thank you e-mail; if you want to stand out from 99% of everyone else write a thank you note by hand. I am stunned by the number of times people feel they must thank me for sending them a thank you note. Trust me, you stand out.

A leader appreciates other people as much as possible, and expresses that appreciation as often as possible. Consider how you feel when someone appreciates you. When they say "thank you" out loud. When they write you an e-mail. Or write you a handwritten note.

You have the power to share that feeling. Share that feeling with anyone who has helped you, and I guarantee it will come back to you in some sort of positive way. You will feel great, others will feel great. Just by saying thank you.

Three Big Mistakes to Avoid in Your First Splunk Install

You have decided you need to install Splunk to get your logs together. Or maybe someone else decided it for you and you are on the hook to make it happen. Avoid pushing through your Splunk install and ending up with it not being used. Or worse configuring it so it is not useful. You and your organization will have wasted a lot of time and money. You and your career will have missed an opportunity to shine. And you need to eventually get it done right.

Take a moment and examine some common pitfalls. Avoid these three big mistakes with your initial adoption of Splunk to improve the overall outcome, and demonstrate more value with Splunk.

1. Don’t Ignore Indexes

Indexes help you partition the logs you are indexing so that when you do searches, you can quickly tell Splunk what log sets you are interested in. Spunk has a few already built in - for the internal Splunk logs for example. And by default, Splunk uses the default index. The "default" index is convenient when you are searching because the user doesn't have to specify an index. The ease of this use might make you might think “I should just put everything in the default index to make it easy when I search.” Do not.

When you are starting to pull in data from a single application, put them in a new index. Perhaps think about the user of the logs – is it a new set of users? A new index will require the user specify the index later when doing the search. And Splunk will search only that index (instead of everything). Splunk uses indexes to optimize for performance, so searches and dashboards stay responsive by searching only your data. The bottom line is using indexes will be faster as your data grows.

With your data partitioned to indexes, you can manipulate the data in that index outside of all the other data. Let’s say you really mess something up and you need to blow away all the data - if it’s in an index, you can do it easily.

Indexes are a great way to organize the log sets that work together. Indexes along with source types allow Splunk to quickly use the sources you want and ignore the rest. If your Splunk install becomes even slightly complicated (multiple use-cases, multiple apps, etc) then you’ll be glad you put your logs into their own index.

2. Don’t Assume Splunk Knows How to Read Your Logs

Spunk knows many standard logs, and maybe the ones you are using are one of those standards. If so, that is great.  However, it is likely though if you stray from the basic standard *nix or applications, you need to think about how Splunk is going to read your logs. Splunk does a great job when logs follow some basic rules - one event per line, date time stamp at the beginning and fields following the “fieldname=value” format. If you’re dealing with logs that begin to stray from some of these basic assumptions, you should beware. 

If your application has a log that starts with a thread-id and continues on multiple lines like this: 

123543 – 03-22-2014 03:22:01.05 Loading Plug-ins
1. Logger
2. SMTP
3. HTTP

Splunk needs to know these lines are all one event and the event date-time isn’t the first field. That means making sure you have your logs mapped to properly defined source types. Splunk uses source types to translate the log you are providing into useful events to be searched. Most importantly, Splunk needs to know two things: how to split events in the log, and what date time to assign to each event. With these two things, your events in Splunk become incredibly useful. Get these wrong, and you might find one event is divided into many with date time stamps that make no sense.

Invest the time to configure Splunk to split events properly - if they are not one event per line and use the most meaningful date-time stamp for those events. See this article on Splunk and the importance of source types.

3. Don’t Just Go It Alone

Maybe this is your project, and you need to drive it to conclusions. Probably you are the one person who is going to make sure this Splunk install gets done and gets done right. The thing to remember about Splunk is that the power of the solution comes when lots of people are using it. So do not just go it alone, recruit some colleagues to be early adopters of Splunk.

The different between a lone-nut and a leader is that a leader has followers. You don’t need to end up being a lone-nut Splunk evangelist in your organization. You will not get the fame and glory of solving the big problems if you’re the only one who knows that Splunk exists. Early on in your Splunk implementation, include some of your best folks who you think will be helped by the new Splunk install and push them to use the solution. Having a few followings increases your chances 2-3x just you alone.

In my experience, Splunk can help automate some of the most cumbersome log analysis to be quick and easy. If people still come to you, however, you’re still the single-point-of-failure. And the value of Splunk is still limited by your use of the solution. When I initially engaged some of the early adopters of Splunk in my organization, I found new ways to use Splunk. We went from basic troubleshooting to advanced performance monitoring because that was what my development team needed Splunk to analyze.

When you are ready to roll it out, make a splash. Get you and your entourage in front of folks to show off what Splunk can do. Sharing the power of the solution with what you have done and what is possible will inspire the n natural curiosity across your team and your company. Get out there with the message and be sure to recruit other power users to give you more ability to deliver results.

Think Like a User

It seems both simple and hard. Think like a user. When you’re building something. Anything. It’s easy - sometimes necessary - to think like a builder. Like an engineer. So often we think about how we’re going to build something and we get lost. Lost in the technology. The feasibility. Answering the question "will it work?” Figuring out the minimal viable thing we can deliver.

It is important to take moments and step back; to approach the problem as though you just delivered it to yourself. Do you love it? Is it what you expect? As someone without any of the baggage you have as the builder? It is key to think like a user throughout the creation process.

Let’s take for example an electronic medical record (EMR). There are so many awesome things that an EMR could be and do. Document a medical history. Substantiate a service for an insurance company. Help propose treatment plans. Flag patient risks. It’s easy to get lost in the details of how we build all those things. It is easy to get preoccupied by what technologies we use. And how we implement the solution. And lose focus on the user.

When I started Virtual Clinician my idea was a simple one: provide an EMR that was easy. Not just easy to start using, but trivial to start using. I wanted someone to be able to use their browser to say “sign me up” and the system would create an instance for them immediately that could be used. The world was full of EMR systems that needed consultants to be hired. Software to be installed and configured. Hardware and software to be bought. I wanted a doctor who had no more experience than experience with online shopping to be able to sign up for a high-quality EMR. 

I had to build it. And I got lost in the technology. And the feasibility. And I forced myself to think like a user. And be sure that we created something that was so easy to sign-up it was entirely automated. I found that asking the question “is that necessary?” and “would the user think that was necessary?” as powerful tools for eliminating steps that were artificial to the essence of what I was doing.

I find that often I have to remind myself to slow down. And give myself time to think like a user. And open my mind. And I see the things I am missing through the eyes of the user. 

Demo What You've Done

Demo’s are incredibly powerful tools in any software development shop. And they’re a key tool for you as a technical leader. Demoing what you’ve done can provide a ton of value to your team, and help you lead more effectively. Here’s why.

I like to think of demos as what Joel S. means in #12 of his “Joel Test” for good software development practices. Hallway testing is demoing what you’ve done for the average person, and see how it goes over. Is it intuitive? Is it usable? Continuously demoing what you’ve done puts it under the routine sunshine of other people’s opinion. Many folks are afraid to hear that feedback. If you’re writing software for someone other than yourself, you may as well know sooner rather than later what they think. Demo it.

Doing a demo of what you’ve been working on holds you accountable to deliver something. Back to the idea that “doing beats talking” the way you get your work in front of folks is show them. It demystifies everything and shows that something has been done. It may pierce the veil of “too hard for this team” or just provide a starting point of real tangible work from ideas and white board. If you’re trying to get a point across of something you want folks to do, don’t just continue to use words. Demo it.

Doing demos in the daily standup is something that I’ve gotten away from in recent years. I’ve focused the morning stand-up intent on communication to one another. And I think there are still good reasons to work in a demo of what you’ve done as a team on a regular basis. Maybe it’s not daily. Maybe weekly. Or maybe a couple times a week. Demoing what the team has done can create the pride of completion of the work in an iteration, and it’s great to show off the progress of what’s happening within the iteration to gain better cross-team pollination on what’s happening. If you’re not switching story ownership mid-stream to cross pollinate this is a great way to share what’s being done while it’s being done. Demo it.

One of your jobs as a technical leader is communication. You need to continue to be good at communication in order to lead. It’s a fundamental skill. It’s one of Steve McConnell’s seven unbreakable rules of software leadership to become a student of communication. When your leadership is around software, being practiced at demoing software is important. It’s a part of your communication. If you’re communicating about software, then use the software. Demo it.

When the iteration is complete, the entire team is successful. You completed what you committed to completing. The team is probably going to do a retrospective to look back and see what worked and what didn’t. Don’t lose sight of the celebration of the successful iteration. Celebrate that the team worked together and fulfilled the commitment. One of the best ways to celebrate and revel in your success? Yep, demo it.

Demos are powerful things for lots of reasons. They’re a staple for software development. Development you’ve done, your team has done or you want to inspire your team to do. Look for every opportunity to demo your software to all sorts of audiences and become practiced in the art of the demo.

Small Steps (the Art of Kaizen)

I often find that the best technical leaders can manage the combination of thinking big and acting small. We need the big thinking part of us to set a grand vision and often to inspire folks to support the journey. I find that ineffective leaders only have a big picture view, they only ask for the big accomplishment. The most effective technical leaders have mastered the art of kaizen, or small steps to continuous improvement. These small steps are not only approachable, they also help solidify permanent change.

Small steps routinely executed have been called out over and over as a way to make big change. There’s a book by Robert Maurer called One Small Step Can Change Your Life that outlines the kaizen way.

As a technical leader, you not only need to make progress - you also need to inspire others to make progress. Ideally towards a big goal that folks may not see as achievable. Breaking own a problem into small parts that can be started and finished, built, demonstrated, tested is the way to make real progress. Often these small steps feel like partial progress. Measuring against the big goal, they are partial progress. And the more tangible they are the more tangible the actual progress you’re making is to the actual big goal.

I’ve been party to projects where the team is working week in and week out on stories. Stories that are completed, but not tested. Burn down charts that shoe progress and percentages of total project completion without interim builds that can be exposed to the user. Or even effectively integration tested. And those project invariably use the cloak of bad reasoning to hide the lack of true progress. Have you ever heard “it’s more efficient to complete all the stories and test at the end” or “if we make all the changes in one big set we don’t have to compromise the architecture by interim builds”?

Jim Collins has a different take on it with his tactic called the “20 mile march” in Great by Choice. Collins talks about building a habit that can be sustained over long periods of time. In technical leadership, this “20 mile march” is measured in continuous contribution to the project every day.

The most effective projects I’ve participated in hold true to small stories completed, built and demonstrated. Your job as a technical leader is to model this behavior, to encourage it, to provide feedback when it’s going well (and when it’s not). We all need to be checking in code daily that builds and runs tests. If we’re checking work in daily there is no way we can’t be forced into working in small pieces. And the requirement stands that the build cannot break. So we’re making small progress towards the big goal, and we can not only see it we can use the software in the new state every day.

Take a look at your team and the frequency of commits you have in your source code repository. If you’re like most average teams, you’re not getting daily commits from your developers. Are you getting the frequency of builds and integrations that you need to be assured that even your short, two-week iteration is on track? If you’re not, encourage your team to commit more frequently. Maybe make it game and report out who is winning. Take the artifacts and automatically deploy your nightly build so it can be exercised every day.

Small steps, ever visible, are real progress to the big goal.