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.