hackIT Code Week


“If you cannot fly, then run.  If you cannot run, then walk.  If you cannot walk, then crawl.  But whatever you do, keep moving forward”  -Martin Luther King

Well, the day is finally here! hackIT code week is happening!

The plan: Create a timebox for development team members to generate ideas based on things they seek to explore, form teams around them and build their ideas.

The Outcome: Demo day of built product ideas at the end of the week to peers and other organizational staff. Votes are cast and the first hackIT winner is declared.

The general rules:

  1. Place any ideas that you want to solicit team members for on the Shipit board.
  2. You have until to 2/25/2016 to declare your hackIT project idea and your team
  3. You can be a single person team but not a part of multiple teams
  4. Your code must be FUNCTIONAL for a demo during lightning talk.
  5. Keep it small and manageable to build in a week!
  6. Ideas related to the business are encouraged, but not specifically required.

We seeded the idea about 30 days prior and asked folks to begin thinking about ideas and soliciting for team members to join them, combine ideas and generally find out what creative “itch” they felt they needed to scratch. In retrospect, this was perhaps a bit too long but I did so as not to distract them from their current product commitments as much. Plus, coming up with an idea sounds easy, but can really be very hard when the end goal is to commit to that original idea. So I think it worked out well.

We had several ideas emerge including several hardware/software products, mobile apps, a scheduler system for operational support and a driving game that allows control of a website from a mobile device as a steering wheel.

So, why did I do this?

Simple; I strongly believe in a few principles as a part of how I am wired to work and think:

  1. I believe in the power of putting togethe r creative people to do amazing things and I have complete faith that this happens when you follow this principle
  2. I believe software development is a creative art and as so those who do it are creative people and need space to be creative.
  3. I love my teams. I love the fact that they are composed of diverse individuals who can come together and share a common set of values yet still hold onto the diversity that makes them individually amazing people.
  4. I believe that if you truly want to be innovative, you have to make space to do so. Trying to force innovation in the midst of the daily “getting sh*t done” is like just digging and believing that eventually you will strike gold. Building the right culture of trust and responsibility, leveraging the creative minds you hire and creating opportunities to let them explore, connect and cross-pollinate. This is where innovation truly happens. Expecting that people will merely be innovative without the time to do so,  a culture of experimentation and a lack of fear in failure is not reasonable. Creating these opportunities is where you find the best potential for innovation.

So, what came out of hackIT?

I expect you want to tell you about all the amazing innovative products we designed as a part of our BETA test for an innovation  event. Well, guess what? I can’t.  We had some amazing product ideas and technical approaches come out of it, but in my eyes that was not the largest value of our first attempt. What happened is we continued to commit to our cultural values and I observed that we were being true to what we said we believe. We had fun, we learned and we continued to connect in doing the thing we do.

How so? Let me give you some of my observations …

Team members just formed functioned as long standing teams.

Because we have been serious and deliberate about defining the way we work and have created a culture that supports the core values for our group and the way we work, we share a common language of working. Teams formed their own ideas and then formed around the idea based on the desire to make it happen. That intrinsic motivation on each team member’s part to see the thing they chose to build coupled with team approach to development led me to observe team members working together and supporting one another that may have never worked together before.

We helped share some of the ideas of how we work with other areas of the organization.

At least one team was composed of team members that were composed of members from an area of the organization that does not have the cultural definition nor work like we do in product development. Feedback from this group was that it forced them to think in different ways. They admitted that they are usually a group that plans a lot before taking action and were unable to do so in this case. They said they learned a lot from the value of small horizon experimentation and build approaches. Plus we continued to build relationships with others and expose them to things we believe.

We had unintended effects.

Groups outside of product development began to become excited about hackIT. Our human resources group showed up to see the event as well as people from other areas of the business. They all wanted to see what we were trying to do. The idea that I was so personally passionate about started to organically grow and ask people what they could do to sponsor innovative space for their own groups.

Following our demo day, I returned to my office a little spent from all of the event (and collecting my thoughts before going for a beer with the teams to celebrate) when several people came to visit me. A few came by inspired by the creativity shown from the event and wanted to express their admiration for a particular product idea but one stuck with me as an unexpected side effect…

I had a person from one of our shared service areas come and relay this to me …

“I just wanted to come by and tell you; product development is not typically ‘my thing’ but I really enjoyed today. It made me proud to be a part of a company that has that kind of people working here”. I told him that this was one of the best compliments we had received and I would pass this along to all of the teams.

The hackIT Retrospective

The next week, I held my bi-weekly staff meeting. Typically this meeting is owned by the product development teams with me as the director just providing some housekeeping items to kick it off and wrap it up. It’s a space for them to reflect on what they are doing and learn from one another. They had the space to design it that way and it works well.

However, some of the development leaders said we should reflect on the hackIT event for continuous improvement and growth. I agreed with them (and was very proud that we think that way). Plus it allowed me to dust off some of the dust from my skills as an agile coach and facilitate.

We reflected on the event. It was a success overall to the group and they saw the value and hoped we make it a regularly reflection of our culture. I committed to them to ensure that I championed this event to my partners in leadership (who were impressed by the event as well). Here were the things we centered on for improvement:

Start Doing

  1. Preparing technical needs (server VM provisions/configurations) earlier. We had some unique needs that caused difficult for operational team members to be a part of the team for dealing with configuration needs.
  2. Being more widely inclusive. I took the blame for this as I have spent a significant amount of time and energy on cultural building and team building and because I knew we had really moved forward here, I was uncertain if the organization as a whole was ready to be able to participate in this type of event. In retrospect, it was probably fear and uncertainty that drove this as I wanted to show the value and so I tried to keep it like a small experiment. But as I found out, once the genie is out of the bottle and coupled with not managing the message to the outside, it can cause more problems than necessary due to lack of understanding.
  3. Re-thinking team size guidelines. We also had allowed teams to be of any size (including a single person). This resulted in at least one team forming into the event as they had not joined another team and needed help when everyone was focused. Having a team of one sounds good in theory but in practice it goes against our more communal cultural core values so we may have to change this approach.
  4. Changing the voting process. We had kept voting simple for this attempt by creating paper votes with team names and a box to mark ‘X’ by the selected team product. The problem that happened was that two teams decided to build a product that was pretty coupled in how it was thought of (resulting in a tie for the teams as people voted for both consistently). A suggestion was to use “chip voting” to allow people to vote for multiple products.
  5. Earlier clarity of ideas prior to kickoff. What we noticed as a lot of teams kept ideas “close to the vest” as opposed of getting them to an idea board (maybe to be strategic). Getting those ideas out there earlier would allow people to create more diverse teams and allow people to know if they wanted to try and create their own team or join another.
  6. Display our countdown clock in a central location. We had a countdown clock on the home page for the event of the server hosting the products. It was never looked at as folks were too busy. Was it even needed since we defined the timeframe? Food for thought.
  7. More planning. This actually arose from an admin we pulled in late to coordinate a lot of the activities (mostly based on an unknown budget). We actually started the work about 6 months before the event but the swag and food was all very last minute. Fair assessment. We can do better.

Stop Doing

  1. Eliminate the need for use of VPN. Based on the enterprise network configuration, utilization of wireless requires the use of a VPN client. This caused some issues in demos as they tend to timeout, etc. Not sure we can eliminate it but perhaps we can be better prepared to deal with those issues.
  2. The Drama! This stemmed around my approach to “keep it small” and lack of wider communication until the event was at hand. I’ll handle this much better next time.
  3. Less Snacks (I ate too much)! We provided breakfast for the organization day one, lunch for teams day 2 and then lunch on demo day for the organization. In the afternoon, I pushed a cart of snacks and treats around the floor across the entire organization to make connections, allow people to take a break and share a conversation and give them a nice treat. Apparently some folks felt the temptation by my cart of treats was more than they could stand. Overall it was a good thing but leads me to consider how to make it more balanced and healthy. I’ll think this through to create a more balanced mix over the week.
  4. Plan the schedule and work the plan. We were in the midst of wrapping up some hiring paperwork and so on the day of the event, my kickoff instructions may have not been as clear as I wanted so I had to do a follow-up. I had the scheduled outlined in the initial presentation I did with the teams. Next time, I will rely on visual aids if I have them.
  5. Stop spending so much money (this was directed towards me). For the most part, I funded this event from my own pocket (and I will not share the amount). I never actively solicited for reimbursement from anyone as I felt it was a personal passion and I wanted to do it (thank you to those that contributed though as every bit helped). I made sure everyone in the organization had a t-shirt for the event, bought snacks for the week, provided organization wide breakfast and lunch and team lunch and some other items. I told my teams that I saw this as an experiment and wanted to demonstrate how to support it and as it was a passion for me, I funded and did not regret spending a single penny and would do so again if necessary as I believed in it even more after it was done. But I did agree to be better to solicit for funding next time.
  6. Taking about every detail or trying to make things perfect. Some of the more junior members of the teams struggled with the idea of not going into deeper discussion or trying to perfect the products. This was impractical given the timeframe and created stress for them. Fortunately our more senior developers were there to guide them as to making decisions as to what could and could not be done within the timeframe. This is a skill that gets learned as we do this more. What can I actually build in this timeframe? Product ideas developed are potentials for future products but should be seen as R&D, not as production ready releases.


This experiment with hackIT turned out to be a great success and something I think I can see us further developing into our culture supporting core value beliefs we have in continuous learning and growth and the power in experimentation without the fear of failure. As for me, it was a personal joy to see what an amazing group I have to lead everyday have the way we believe and the talents they have be shared to the wider organization.

I leave with this …

“When it comes to innovation, an ounce of execution is worth more than a ton of theory”                -Phil McKinney, former CTO of HP Personal Systems Group 


One thought on “hackIT Code Week

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s