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. 

Give Feedback

As a technical leader, one of your responsibilities is to help others get better. Being great at some technology just isn’t enough when you’re leading. Being a part of a great organization is where it’s at; and that means helping the people around us be great. 

People don’t start out great; they get great over time through experience. One of my favorite quotes (attributed to all sorts of different people) is “Good judgement comes from experience, and experience comes from bad judgement.” You probably realize this in your own evolution as a technical leader. You’ve gotten better because you’ve made choices that later you would realize you could have done something differently and gotten a better outcome. A strong performer is out there always looking for feedback and ways to improve.

I’m a big fan of Manager Tools and the actionable advice they provide for managers. As a technical leader, regardless of whether you directly manage someone or not, I believe they have a model that will work for you. In particular, I have found that what they call the “Peer Feedback” model is something that would work in any situation. You can read more about it on their website, and the particulars aren’t hard to master.

Here’s a brief summary of the Peer Feedback model. It’s a two-part statement that follows the format “When you…” some behavior “this is what happens…” some consequence. The behavior is observable, it’s not subjective. It’s the words you say, how you say them, your physical gestures, your work product. A simple example would be “When you say to Bob that his technical design is stupid, here’s what happens - Bob is less likely to suggest an idea next time and I think you can’t work well with your team members."

Your job as a technical leader includes giving feedback. Sure, you can model good behavior. And if you don’t actually provide feedback to your team, it will be not as effective for them to know what they’re doing that they should keep doing. Or what they’re doing that they should rethink and adjust. It can be communication based like the above example, or it can be helping share the impact of a design choice. There are all kinds of ways to use the feedback model to help people on your team know the impact of their behavior.

Here’s a shocker for many folks: not only do the most effective technical leaders give lots of feedback to the individuals on their team, it’s also mostly positive. What? I can hear you saying “I can see so many things that can be done better!” Sure, and you’re also probably not working in a technical team that’s a sinking ship. If you are, it’s not feedback that’s going to get you out of that situation. If your team is largely successful at planning and finishing sprints, completing stories, making releases; there are tons of positive feedback opportunities. 

Often times it is much easier for us to see the problems than the positives. We’re used to looking for defects, looking for gaps in logic. Some of the most powerful feedback you can give folks is something you want them to keep doing. When you give lots of positive feedback, it builds up your relationship. And it helps folks see you as fair and balanced. For a good period of time (weeks to months), try giving only positive feedback and see what happens.

So what do you do now?

• Start giving positive feedback once a day
• Experiment with giving more than one piece of feedback a day once you consistently do one
• After 6-8 weeks start giving feedback on things someone should change
• Do a self-assessment after 3-months and ask yourself how you’re doing.
  • Are you doing it?
  • Are you keeping balance (more positive than negative)?
  • How are your relationships with the people you’re working with? 
  • Are you getting better results?

Find the Most Important Problem (and Contribute)

I see technical leaders that diminish their impact by contributing to a lessor part of the problem or discussion. The most impactful technical leaders I see tackle the most important part of the problem. They contribute to the most important part of the discussion or problem being solved. Focus is important as a leader because you can’t do everything all the time. And focusing on the most important part of problems distinguishes you as a technical leader.

How do you know where to focus? Take stock of who is in the meeting and what is the goal of the meeting. If you’re one of the more senior folks in the meeting, folks are looking to you to help prioritize what’s important. Ask yourself what’s on the critical path to the goal. If you focus on apparently trivial details, that’s a sign that the most important stuff is already taken care of. For example, have you ever been in a meeting when someone senior focused on some apparently bureaucratic detail? Did that make you think more or less of that person as a leader?

If you’re in a group of your peers, consider where you can make the most impact on the goal of the meeting. If the goal of the meeting isn’t clear, one of the best moves to make is to ask “Let’s be clear about what the goal of this meeting is…” - trust me that’s a move that everyone will appreciate because they’re asking the same question you are asking.

When you’re about to contribute, ask yourself “if I don’t contribute here, will the goal still be achieved?” I recognize this may be difficult because you feel compelled to contribute to prove it was worth you attending this meeting. And there’s truth to the fact that you should be contributing. You should be contributing something impactful; if the goal can be achieved without you there maybe you should decline next time. Keep pressing yourself to find the most impactful thing you can contribute.

Another reflective question “Is my contribution directly related to the core of the problem being worked?” I often see technical leaders contributing in a way that distracts from the goal rather than building on it. It’s slightly different than the first question in that some technical leaders don’t realize they are distracting from the problem by contributing an idea that is top of mind for them. For example, a technical leader that says “this would be a great problem for Python” because they see adoption of the new language as important. Be as “in the problem” as possible and leave your baggage at the door.

Conversely, don’t contribute something that is not the most important part of the problem being worked. I see technical leaders diminish their impact by contribute lesser insights. Operate at the top of your ability, and folks will see the impact of your contribution. Operate any lower and that’s what folks will associate with you. When you contribute something like “you didn’t follow the process” to a hairy technical problem, folks will assume you don’t have any insight to contribute to the technical problem at-hand. Even acknowledging that the hairy part of the problem has no easy answers, and working to wrestle with it has more weight than falling back on something not core to the problem.

Probe to get clarity on where the real complexity lies. Ask the question, “what’s at the heart of this problem?” or “what should we be worried about that we’re missing here?” Be aware that if this is all you do, it will come across as entirely without content. These questions can be very helpful early in the discussion to nail down the consensus of the group on what is the real nut of the problem. Follow-up on these questions with statements to help nail it down, or ideas to propel the discussion forward.

Let’s take a particular example - a meeting and your contribution to that meeting. Let’s say it’s a technical review of a story being implemented. One of the engineers you work with is presenting the technical design for the group to review and provide feedback. Your role is to help make the design as good as it can be to fulfill the requirement. Examples you might focus on are that the design will be difficult to maintain over the long-term, that the performance characteristics won’t allow it to scale, that the administrative overhead of managing it in production will be larger than normal. Examples you might not want to focus on are why the language chosen isn’t as good as your favorite language, why the person didn’t follow the right process leading up to the design review or that the format presented is non-standard.

When you operate at the top of your ability, and that’s how your team will treat you. If you operate in the middle even when you have the ability to solve hard problems, folks will associate you with contributing less and having less ability.  Solve the hardest problems you can solve, and leave the easy stuff for others. Or better, delegate the easy stuff to others. But that’s a different topic...

Ask the Next Question

One of the most powerful lessons I’ve learned is to ask the next question. So often early in my career I’ve thought to myself, “here’s the answer” only have someone more senior or experienced than me burst my bubble with the next logical question. To which I had no answer. Silence. Awkward.

It can seem like the answer was hard enough to get that you should be “done” at that point. When the person asking realizes you don't know the answer to the next question, to them you've not done a complete job. You're not done. When you can plan for it before someone calls you on it, you can stay ahead.

The most effective way to get good at this is to simply ask yourself "what will they ask next?" You won't get it right the first time, or maybe the first bunch of times. And if you try and keep track of what you thought someone was going to ask you can course correct. It will be heavily dependent on the person (what do they care about, what is their natural disposition) so this is a person-by-person exercise. 

“How much money do you need to raise to start your company?” Someone will inevitably ask “What will you do with that that money once you raise it?” “How long will it take for you to spend it?” “When will you start seeing the benefit?"

"How many people do you need to hire?" You should expect to also answer “How long will it take you to get those three people on board and productive?” “Do you already have people on deck?” “What’s the impact of not hiring them?"

"How long will it take to complete this product?" You should anticipate “Who is ready to use the product once it’s finished?” "What if you only had half that time?" “How are you going to deploy it?” “Who is giving you feedback along the way?"

Each question illuminates that difference between the short term goal and the long term objective. What are you trying to accomplish? Or maybe what should you be trying to accomplish? Are you asking the next question of yourself so that you can stay one step ahead?

Often there are more than one “next questions” from various vantage points. Sales. Operations. Development. Consider the different points of view that might be important in the next question.

Always there are different styles of people who will ask questions depending on their natural style. An action oriented person may ask active questions like "What will you do next?" A people oriented person may ask something different like "What will the team feel about this decision?" Knowing the audience will help you know the next question that is likely to come (and will help you see the world from their point of view).

So start asking yourself "what's the next question?" Target your boss, you likely have many interactions with him/her that you can test your hypothesis on what will be the next question. Adjust and continue. 

Creating a Culture of Innovation, Part 4: Follow-up

One event doesn't make a culture. It requires discipline and follow-up. Most importantly it requires extending the behaviors beyond one person's leadership. One of my favorite videos describes the importance of the first follower in under three minutes (with a crazy dancing guy). So what can you do to keep things moving?

Sponsor ideas that have impact beyond an event like a Hack-a-thon. Provide resources, times and exposure. These ideas can create a bridge between discrete events and can give the most active of your innovators outlets to spend their time and drive change on something they're passionate about. We had projects like a mapping app that helped folks navigate from one employee's desk to another that eventually became a part of our firm's internal toolkit. For some folks, the recognition of having their pet project used across the entire company was huge recognition and meant they were more likely to continue to participate in the culture of innovation.

Take feedback from retrospectives on the events you hold. Get your active participants together and figure out what worked and what didn't for the events you run. Adjust and run them again. Folks who feel passionately about something (either change or keep) are your leaders, they will want to be more involved in the event next time. They will become the leaders of the next event and they will be even more invested in making it a success.

Delegate the sponsorship of events and activities to other people. It's hard to let go. The most tangible evidence that you're not just a lone-nut pushing for innovation is when many others are actively involved. I knew that our culture had taken firm hold on the organization when we held our third Hack-a-thon and I was not involved in any part of the planning or execution. 

Expand the network of folks leading change. Delegation expands the number of folks who are leading change. Push to decentralize the leadership around innovative behaviors. An expanded group of people who feel ownership on the activities associated with innovation is the culture of innovation. It doesn't rely on a single person, a single event, or a top-down initiative.

Continue to hire to the culture you want, not the culture you have. This result is way easier said than done. Especially early on in a bigger change. Not everyone can see the culture you're forming if it's dramatically different from where you've been. You need people that will make the culture what you want it to become. You need people who will lead these events. People who will continue to follow-up and ensure it doesn't end in the "flavor of the month" pile of new initiatives that get stale. These people are your culture of innovation.

Creating a Culture of Innovation, Part 3: Take Action!

How do you create a culture of innovation? Well, from my experience you're really not creating a culture. It's a mistake to think you can create a culture from one moment to the next. When I say "take action" I mean let's talk about what specific steps you can take as a leader that will help create space for innovation, encourage innovation, recognize those who are innovating and help make it fun.

Making space for innovation is important if your culture is like many where people are continually feeling the pressure to deliver on their daily work. Often this feeling is one that your team will allow to be a reason they don't follow an idea that feels like a distraction. The often mentioned Google 20% time example runs into roadblocks fast when folks simply can't imagine having a day a week to spend on something outside their iteration and basic development responsibility. We used events like a Hack-a-thon to create a day dedicated to allow folks to create teams (often outside their existing product teams) and pursue an idea outside their normal work. These type of events create space for innovation.

Encouraging innovation can come through events like challenges in addition to those mentioned above like a Hack-a-thon. Challenges are more specific problems to be solved, often over a longer period of time and leaving creativity in how to solve the problem. We used challenges to outline problems like "how would you predict XYZ given these preexisting data" and leave folks to use languages and technologies to solve however they want (as a team or individually). Our first challenge was a success on many levels - not only did many people participate and expose the group to many different new technologies. Also, an unexpected team (the QA automation team) actually solved the challenge best and gained recognition for their technical capability.

Exposure and recognition helps everyone who participates gain benefit and share the work they've done. At the end of our Hack-a-thon, we have everyone present and working prototypes are the main focus. At the end of our challenges, each team shows what they tried and what the result. As a bonus here, we include others outside our department to judge and recognize participants so they not only feel their peers see their work but other executive leaders as well.

Making it fun helps sustain the energy and keep things going. We created a video parody of a popular song, and spliced videos together from all the participants. When we showed the video at the final presentation, it roused all sorts of team spirit. We included events that weren't always work related to lighten up the mood. We have introduced a paper airplane contest as an annual affair and changed the rules to keep it interesting (fly the farthest, longest hang-time, etc).

We held a foosball tournament to mix-up the people to allow them to get to know one-another. It doesn't always have to be work, weaving in some fun can help keep it light. I've had folks say "I learned more about what other people do during the foosball tournament than in my first six months of working here."

Follow-through is important to help continue to encourage innovation. We assigned executive sponsors to the projects that folks wanted to pursue beyond an event like a Hack-a-thon to help make sure it continued to get support. We have had projects started in an event that have gone on to become tools we use internally (Office Navigator to get from one point to another in the office, for example). These projects require someone to continue to support the development effort, run interference to get resources or time, and just help folks see that the senior leadership still wants to see it continued. We assigned out many different folks to be executive sponsors, and it helped use pursue over a dozen projects after they got started.

There's a "what I learned holding a Hack-a-thon" post as a stand-alone because there are many things I've learned in the experience of getting our team together and make these events successful. We've come to a point where people love Hack-a-thon and we run them regularly with our development teams. We've held them annually and it's been referred to as the highlight of the year by many on my team.

Taking action as a leader to help create space for innovation. You are also responsible for encouraging and rewarding the behaviors to kick-start the culture. Your follow-through will help folks realize you mean it, and you want to sustain the energy. Your folks will fill in the space if you give them the nudge and keep supporting them.