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.

What I Learned About Holding a Hack-a-thon

As a part of creating a culture of innovation, we decided to hold a Hack-a-thon within our organization. Hack-a-thons have become really popular as a way to bring like-minded folks together; one of the biggest is from my alma matter. Our definition of Hack-a-thon was a time-box opportunity to create a team of folks and pursue a pet project of your choosing culminating in a short presentation of what you did to everyone focused on working software. It's different from a challenge or long-running competition.

Goal

Decide on the goal ahead of time. Do you want participation? Do you want innovation in a particular area? Our first Hack-a-thon, we wanted to encourage a culture of innovation so simply participation on any level was success for our group. We let people choose projects and technologies liberally (not related to any project we had going on). Subsequent events we held had more constraints (innovating with a particular technology, for example) to help foster usage of that technology.

Before the Event

Publicize the event for the staff to know what's coming. Use posters, emails, flyers on desks. Get the word out that it's happening and create buzz. Maybe even do some goofy stuff like music videos or something to get people talking. Hold events like mixers to get people to meet and talk about ideas leading up to the event itself. Register teams prior to the event (who's on the team and what's the team name) somewhere public like on a wiki page. Get them to volunteer what they're working on (some will use it to recruit, some will refuse and keep it secret, it's all good fodder for the event).

During the Event

Start late in the day (we did Thursday around 4pm) with a kick-off event. Bring food and drinks. Get everyone together and officially "start" the Hack-a-thon. Allow the teams to go all night in the space if they want. Encourage teams to claim working spaces and make it theirs for the duration. Take pictures. Feed people regularly. Stock lots of drinks (alcoholic and caffeinated). Have leadership round the teams to ask questions, offer advice, lend support. I've seen some folks create a formal group of consultants to round and act as advisors. End the next day (we did Friday with presentations). The roaming advisors and leaders also helped people think about practicing their presentation at least once.

Presentations

Set expectations of what people should present. We wanted actual working software and prioritized the demo as the show-and-tell. We were clear that everyone got 5 minutes and had a formal time keeper. We worked to get the audio-visual set up and working well so transition time was minimal. Remote participation is possible but hard; work on getting the video conference and screen sharing nailed if you have remote teams.

Have judges, maybe 3-4 people, who can see the presentations and ask questions. In the end we had the judges confer and agree on awards (see below). The judges can be a great way to create exposure outside your group (we included executives like the general counsel to create excitement that it wasn't just a department event).

Give multiple awards focusing on a number of things you want to recognize. For example, most creative use of a new technology. Best design. Best new solution to an old problem. We would attach famous people (Edison, Branson, Jobs) to help give the award more flair (the "Steve Jobs award for Best Design"). Having multiple ways to recognize teams gives you the ability recognize more people.

Logistics Considerations

• Make sure you have space to spread out
• Make sure you have adequate bandwidth and Wifi for the people who will participate (and all their devices)
• Have a space big enough for the presentations, here you can create a party atmosphere by encouraging folks to sit on the floor and crowd in (folks will be crispy anyway if they stayed up all night)
• Get some key folks to act as ring-leaders to help model the behavior you want during the event (we had a guy bring in an air mattress to set the tone that he was sleeping at the office that night)
• Run a retrospective on the event to learn what worked for you and what didn't; then do it all over again.

Creating a Culture of Innovation, Part 2: What Does It Look Like?

It's not always easy to think about what we mean when we talk about a culture. A culture is composed of many different things, and a company culture is difficult to describe. The traditional definition of culture outside the setting of a company refers to the arts and humanities of a society. The best way I've come to describe a company culture is through its values, and most specifically through the behaviors the people do regularly that embody those values.

Innovation itself isn't a behavior, which makes it more difficult to just assume everyone knows what I mean when I say a culture of innovation. Innovation is a little bit like "executive presence" - where people say they know it when they see it, but they can't actually give meaningful feedback to help you get there. Maddening! As someone who wants to encourage the creation of this culture I can't leave it to chance that we won't give very specific examples and feedback on the behaviors that I think embody a culture of innovation.

I believe innovation can be captured by some of the following behaviors: experimenting, trying, failing, proposing an idea, operating outside the normal channels. Experiments are something that I believe innovative organizations do all the time. Experiments require a hypothesis to test and a lab to test them in; this can be all sorts of settings. Process change, technology, seating configuration, anything. It doesn't have to be formal, I do think that having a hypothesis helps distinguish experiments from simply messing around.

Trying (and sometimes failing) is a really important aspect of innovation. You want people to try things all the time; and if they fail you want there to be a positive reinforcement. The trying is important and you want people to keep trying, so there cannot be any negative flavor attached to the outcome. Detach from the results of these experiments and realize that any outcome is knowledge and celebrate.

Operating outside the normal channels is also an important aspect of innovation. Ideas for improving a process can come from anywhere. Ideas for new products don't have to come from the "new product group" - they can come from anywhere. In a technical organization, there must be the ability for a technical team to surface new capabilities from new technology that can turn out completely unexpected products. An innovative team can say "let's do this new thing" even if nobody thought it was possible even six months ago.

The big benefit includes a more engaged and happy team, more productivity from your team, better ideas, more ideas and better results. Your team will work on these things with the passion of commitment energy; not just the energy of compliance for doing what they're told if they have a say and contribution to what's being done. And that's a culture of innovation.

Next up: Creating a Culture of innovation, Part 3: Take Action!

Doing Beats Everything

Leading the Way by Doing

The power of doing something is enormous in the efforts of changing a culture or elevating performance. I’ve often seen a team fall into a rhythm and routine of delivering what they’ve always delivered including maintaining limitations that have always been limitations. I’ve changed entire cultures of teams by simply being able to “do” rather than simply “encourage” change.

Nobody like to hear the words “how hard can that be” from someone who really doesn’t know how hard things are to implement. I’m very conscious of the impact that a flippant comment can have on a team; you can lose them if they think you’re belittling the hard work they do. But there has to be a way to challenge a team to do more, better work. The ability to demonstrate that a barrier can be overcome with your own hard work is so very powerful. Doing beats everything.

Being a Technical Leader Brings a Unique Ability

I’ve worked in organizations where leaders are technical, and in organizations where leaders are not technical. The supreme benefit of being a technical lead is being able to “do” when facing resistance to change. This works as a technical leader if you’re part of a team or if you lead the team. If you can deliver results, demonstrate that the “impossible” is indeed possible you disrupt the status quo in a very positive way.

I experienced this myself when I joined a team that was struggling to make a system perform for a large customer - the largest customer they had ever experienced. The team believed a screen couldn’t be made to load in as short a time as we needed given the volume of data that was to be processed. This conclusion was true if we stuck to the model of development that required we manipulate the data through the heavy-handed SQL queries originally developed. I knew it could be much faster if we changed our model to retrieve the data in very fast queries, and manipulate the data in memory in a typical MVC model. In the end, I was able to demonstrate significant performance improvement by actually doing this change rather than simply trying to convince my team to try it. And doing trumped every objection.

Another experience I had in changing the overall productivity of a team was hiring a significantly better technical individual contributor on a team of individuals that weren’t performing at the level we needed. In our first session pointing stories in our iteration planning, this new engineer gave a much lower estimate (3 points) than everyone else on the team (20 points). He didn’t understand, and said he didn’t understand, why this story was so big. It should be simple, he said. He effectively said “how hard can that be” with one huge caveat - he could back it up with “give me the story.” And he completed the story in the time he expected, and demonstrated it could be done 10x as fast. It put people on notice that the bar was raised and they needed to push themselves to be better. It changed the tenor of the team and the performance we got was higher than it ever would have been without that technical leader.

You’re Setting an Example, Not Taking Away Responsibility

It’s not always your role as a technical leader to jump in and “do” something. You need folks to be capable and free to experience and do their own thing. This tactic should be used sparingly. If folks don’t feel trusted or empowered to try and experiment, it won’t matter if you can do it better (you’ll be doing it alone). But you can effectively us it to elevate your team and teach them something new, the best folks will be receptive to learning. The best folks will want to take the new thing and build on it. The best folks will see the restraint you ripped off and pursue it with enthusiasm like you gave them a new toy.

I believe this works in a number of situations, from production development to proofs of concept. I find it works best when you can pair with someone and work together; so you’re not seen as working behind the scenes. In some cases working independently can come across as “unveiling" something you expect will revolutionize their world. Instead taking the initiative while still engaging others can help keep folks walking alongside you as you demonstrate a new way. It’s better if you have the position to require folks to stick with you (if they recognize your role power), you can work through relationship power as well (ask them to help you as a favor) or information power (offer to teach a new tactic or technology). 

Doing is Engaging, and Engaging is Always Good for a Leader

You need to lead by example sometimes and step in and “do” in the face of resistance or the feeling something is impossible. Either you’re going to learn a new reality (that maybe it is that hard), or you’re going to teach a valuable lesson (that it isn’t that hard). And so long as you approach it without ego, and with a willingness to both learn and teach, the end result will be positive for the team.

Creating a Culture of Innovation, Part 1: Do you have it?

Culture of Innovation

I believe that innovating is a key part of your culture for any growing, thriving organization. Innovation itself is important. I’ve been a part of organizations that say they innovate only to have systemic processes that put “innovation” in a part of the organization responsible to “innovate.” Making innovation a part of the culture means everyone is responsible for innovation. Mass innovation. Everyone innovates. I believe this culture of innovation is required to have a world-class development team.

There are tons of organizations that do not have innovation at the center of what they do. They’ve still been successful. Many are larger, more traditional organizations. Some organizations don’t have this issue; they’ve grown up with innovation and freedom as a part of the culture. Examples that get mentioned commonly in the press are Google, Facebook, smaller start-ups, companies where innovation was required to survive/grow/dominate. Many of us find ourselves in organizations not on the cover of magazines about how innovative they are; these tactics are for us.

I spearheaded the transition of a fairly large team (75 people or so across many teams) to take on a culture of innovation between 2012 and 2014. The firm I worked for was highly successful, growing at a rapid clip and taking on new technology and new products very quickly. The process required new product ideas to come through a central part of the organization and the rest of the organization helped develop, sell and deliver those new products. We had an untapped potential of very smart development and delivery folks who didn’t feel they were a part of the innovation process. I had a problem because the individuals on my development team didn’t embody a culture of innovation.

What we could be?

We needed to push beyond the label “innovation” and look at the behaviors that yield the feeling of innovation. Translating that feeling into specific behaviors makes the next steps actionable. So I took a look at the actions I saw that I liked, or didn’t like - and worked to figure out how to create incentives for the innovative behaviors.

Do you have it?

Here are some of the telltale traits I’ve come to believe reflect that we missed the culture of innovation. Our teams didn’t spend time on ideas that generated within the team. Our teams didn’t tackle things that were outside of what they had done before. Our people were stressed about delivering on existing commitments. We rarely changed course from one iteration to the next based on new information we learned. The team wasn’t celebrating the impact on the users of what they were delivering. Our people were focused on titles, position, winning and losing.

Not all of these traits are just about innovation, but I believe without this foundation were unable to innovate fully. We weren’t going to have each individual on all teams be willing to propose an idea, share new learning, inform the creation of a better product and suggest disruptive new technologies that would change our capability as a product development team.

Spoiler Alert: We Succeeded

We succeeded in creating a culture of innovation across many teams, in many office locations, in many different product areas. I’m going to dedicate a series of posts on some of the key learning and activities we employed to make the change effective.

Book Review: The Hard Things About Hard Things

I recommend The Hard Things About Hard Things by Ben Horowitz. It's a book that chronicles experiences and lessons he’s had through the founding and running of an Internet company over many years. It’s written in an easy to read format, in plain terms that I can relate to. Not to mention it quotes rap lyrics which sings to me in particular.

The book is organized but not so processed that the lessons are too abstract. It provides insight into specific difficult times - raising money, laying people off, pivoting a business. It’s up front with the idea that there isn’t necessarily a theme except that these are hard things that any CEO may encounter, most specifically someone leading a start-up.

The examples in the book come from Ben’s specific experience in starting a company during the dot-com days. I also started a small tech company during that time, and I found the stories very relatable. Even if my experience was smaller his experiences mirrored my own. In particular, in the section "when things fall apart." There are hard things you can’t be prepared for, but you must deal with regardless. There are decisions and options you never knew were coming. I found the lessons relatable even for an executive in a leadership role in a larger company, particularly "how lead even when you don't know where you're going."

The book walks through the history of being a CEO through tough times. In particular the stories of how to continue to survive are very real. The chapter on taking care of "the people, the products and the profits" outlines examples. Pushing yourself to see all the options, even those you don’t want to pursue, is at the heard of being a scrappy start-up. And as a leader, you have to make tough choices. He talks about changing the focus of his business, letting people go, hiring the right people and firing the wrong ones.

He also brought some insight into situations such as when to bring on people who have “big-company” experience. His description of what the difference in small-company and big-company leaders helped me understand my own transition from small start-up experience to my recent work experience with a larger company. How you work and prioritize your time is very different, and as someone responsible for taking a company from small to big I can imagine it’s hard to know when you need folks with each kind of experience.

Ben has turned his experience and observation of how tough it is to be an entrepreneur into a style of venture capitalism. VC with sympathy for the entrepreneur. The books describes how he and his partner, Marc Andreessen, manage their relationships with start-up founders. They recognize that although they have the capital, the founder is very much on the hook for results to everyone involved.

There are great key lessons that I took away from this book. On how to execute layoffs. On exploring all your options. On leadership and supporting your staff. On seeing things through and sticking with it. On how hard it is to lead, especially at the top. And the importance of advisors. 

In the end, I like that the book talks as much about running a business as it does how to make money. And it avoids the trap of just talking about "how to make an exit" that you might expect from a VC.

The Benefit of the Doubt

I. What is the Prime Directive?

You may be thinking of Star Trek’s Prime Directive to not interfere with alien civilizations. Which is not what this is about. Although you probably shouldn’t interfere with alien civilizations, either. Instead, this is about creating a positive culture. In this context, the prime directive is about giving people the benefit of the doubt. They guys at Manager Tools refer to it as “assume positive intent” and cover it well in a podcast on their site.

In James Shore's book on The Art of Agile Development he discusses the use of something he calls "the prime directive" that he recommends to read at the beginning of any retrospective. The prime directive goes something like this - "Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand." The most effective teams I've lead have believed the prime directive. They acted in the spirit that this was true. They gave one another the benefit of the doubt.

Nobody knows the depths of you. You're complicated. Everyone is. There are an infinite number of possible reasons why someone acted a certain way. Our natural tendency is to attribute the reason we would have acted that way. "I wouldn't arrive late unless I was didn't respect that person" when it could be "I arrived late because my daughter is very sick." Giving the person the benefit of the doubt is the way to always take the high road. And it doesn't cost anything. Don't you want to be treated that way? 

So let's say it before we start our retrospectives.

II. How do you do it?

The retrospective meeting is one of the most important ceremonies in agile development. It creates a system of continuous improvement. It provides much needed feedback into the system that you rely on to deliver working software. At the beginning of each retrospective, have one person (generally not the same person) read the prime directive out loud. That person then asks each and every person in the retrospective to agree out loud by saying "I agree". It's that simple.

It may seem crazy. Read the prime directive out loud? Require people to agree out loud. Yes, it's that important. It's worth every moment of having to have a conversation with a bunch of adults who might find it a little childish. Because really, it forces the issue that you mean it. It creates a ground rule for the meeting, and the ground rule will spill over into the other day-to-day interactions of the team.

How do you introduce it? Start with yourself. Tell your team you believe it's important. That you want to act this way, that you believe everyone does. That you want to be a part of the team that gives one another the benefit of the doubt. And that you'd like to read it and ask everyone to agree as a ground rule for retrospectives. You might have team members that thinks it's silly. Or unnecessary. In reality you won't have people say that don't agree. Anyone that has trouble saying "I agree" to the prime directive has larger issues that must be addressed individually. And the time it takes for your team to each say "I agree" is incredibly short.

III. Why do it in the retrospective?

A retrospective is a safe place. Ideally an entire scrum team is a safe place. The retrospective is where a dysfunctional team can really get out the knives.  We need a retrospective to provide feedback to the system. And we need folks on the team to feel like they can say "we need to do more of this" or "less of that" without either stabbing someone in the back or feeling stabbed. 

You're looking for the entire group to brainstorm on ideas to change. And you're looking for each member of the team to own one or two things that can be tried. It won't work if some of those people on the team feel undermined. Or not trusted. It will devolve. It sets the standard for how change ideas will be surfaced and vocalized. Your team will think harder before they say something the implies negativity to someone else. There will be more "we statements" like "we need to user accept more stories earlier on in the iteration."

When you set the standard that you're willing to say out loud that everyone gets the benefit of the doubt, you're making it that important. What else is so important that you make a point of saying before every meeting? Ground rules. And ground rules create the ability for no one person to have to be the enforcer. It sets the a standard that anyone can refer to; the ground rules become the enforcer.

IV. What happens?

You will subtly see changes in the language of your team. Your team will say "we". Your retrospectives will be more constructive. When someone does wander into a finger pointing moment, you can simply say "remember the prime directive." Anyone can say it. It becomes a core value of your team. It fits with kindness and the golden rule - treat other people how you want to be treated. It’s a ground rule.

Your team will start to ask how they can help one another. They may ask "do you need something to be sure you can do that?" It will help focus the stand-up meetings; where you're surfacing roadblocks. When someone acts out of the prime directive, it means that I'm the hook for helping get that person better information or improving their skills. Because we’re in it together. And we're going to get the best we can get from that person within those constraints.

The Importance of the Retrospective

There are a couple specific activities that define the scrum process, the specific implementation of the more general category of “agile” software development. One of these ceremonies - the retrospective - stands out to me as critical. Conducting regular retrospectives is so important, it alone deserves recognition as a core value for any organization.

A retrospective is any opportunity to look back and ask yourself “what could I have done differently to get better results?” It’s not a time for finding fault. It’s not specifically a software development thing. It’s a core function of a highly functioning team, whether it’s a team of one or ten. People run retrospectives differently, and the core benefit is the same. Inject feedback into the system. Encourage continuous improvement. Anyone who isn’t looking to continuously improve is going to lose in the long run.

When can you apply a retrospective?

I like to challenge myself to apply the concept of the retrospective in many different situations. The traditional scrum application of the retrospective has the team coming together at the end of an iteration and doing a simple “start/stop/continue” exercise. One instance of the scrum process has the team use sticky notes to put up as many ideas under start/stop, do a sorting exercise into themes then voting to choose what to focus on in the upcoming iteration. Jim Shore does a great job at talking about how the retrospective can be applied in the agile software development process.

Another, very different example, comes from my friends at Manager Tools called the “hot wash”. The hot wash refers to the quick and simple mechanism of taking time to look at what works and doesn’t work. The MT folks apply it to a regular standing meeting. Say your staff meeting with your technical leaders. Take 10 minutes at the end and ask “what’s working, what’s not working” as a way to get quick feedback to incorporate into the next few months of your meeting series. This is a good example of how not every retrospective is tailored to self-organizing teams. It’s you getting feedback from your team that you choose how to apply.

I would argue that we all should be doing individual retrospectives for our own progression to our goals. We should set time aside to ask “are we making the progress we expect?” and setting up some feedback loops around what’s working and what isn’t working. We should be doing this more than the traditional “new year resolution” annual exercise. At least every quarter your goals probably change, and you should be asking if you achieved what you expected. How often do you sit down and think about what you should start, stop or continue in support of your goals?

How do you run a retrospective?

Whether it’s just you or a small team of folks, there’s no reason to overly formalize the retrospective. You need to capture the output. You need to create an opportunity to get free input. There’s two types of input - brainstorming to get ideas on the table, and refinement to evaluate what ideas are worth focusing on. Finally, take a moment to capture an action or two as a constructive change. All of this can be accomplished in 10 minutes at the end of a standing meeting. Or in 30 minutes to an hour for a more serious regular process. 

What next?

Run your own retrospective on your goals. Make it an introspective exercise. Or, pick a standing meeting and reserve time at the end of the next one for a hot wash. Attend your development team’s next retrospective and observe if you’re hitting the right mark of continuous improvement for a self organized software development organization.

If you’re always improving you’re on the road to winning.