Hack Days

Last week we had our third internal hack day at STC Europe and I am still buzzing from the excitement. For those of you that are not familiar with the concept, hack day “is an event where developers, designers and people with ideas gather to build ‘cool stuff‘”.

I have been organising them at STC Europe since I first joined (after some gentle prodding by Ian Hegerty) and I have found them to be extremely fun and valuable.

Therefore, in this post, I want to share with you some of the learnings & benefits of organising Hack Days and to gently prod you in return to start your own hack days within your organisation or team.

Are you going as fast as you can?

What surprises anyone participating for the first time in a hack day, or attending the demo session, is how much can be created by very small teams – from idea to implementation in 48 hours – while so many traditional software project don’t produce anything over much longer time periods with much more managerial care and oversight. For me, having worked for bigger companies in the last 5 years or so, it is a good reminder of how lethal start ups can be: when you have a highly motivated team that fully buys into an idea,  combined with a strict deadline that forces a team to focus on the essence of the product, not much is impossible.

Although by its very nature, a 48h sprint will be faster than a normal development cycle, and hackers will take many shortcuts, hack days can illustrate shortcomings in your normal systems and processes. For example, are your release management systems causing too much overhead? Are you giving developers enough ownership of feature development to be fully engaged? Is planning becoming a drag instead of a tool? It can also be a call to arms for your leadership team: how can we bring the same energy, agility and excitement to our day-to-day work? Even if you are no longer a start up.

Your team may be better than you know

Remember that quiet guy in the corner that never seemed that interested. He will blow you away with something truly cool. This is not a Hollywood movie. Believe me: Hack Days will allow team members to demonstrate talents, skill sets and great ideas that they themselves may not even known they had. This opens up many new opportunities and improvements for how you structure the team, products or features you go after as a company but also makes for much happier team members.

Joint experiences & adventures make for stronger teams

Surviving release cycles together may create team bonds over time, but hack days will do that for you in much shorter time and will do so cross-team, maybe even cross-office. Hack day is basically one big rush: come up with a cool idea (buzz), find like-minded people (buzz), implement it together – quickly (buzz), demo it for your peers & management team (buzz). All lubricated by pizza, beer and doughnuts. In 48 hours. It’s like a road trip but geekier. You will create bonds, you will make friendships and you will gain respect for your peers.

Great invention ROI

I love this recent tweet from Kent Beck: “once i thought all my ideas were gold, then i realized most of them were crap, then i learned i had to try them to find which were which”. You can try to research if new products and features will work via a variety of means but nothing will demonstrate if an idea will work or not faster than a working prototype. And you will get many of them via hack days, far outweighing the cost of the 2 developer days.

And don’t forget about the ideas. Nothing like a nice mix of backgrounds and experiences to come up with new cool ideas… Much better than a blue sky thinking offsite with similar people just waiting for the open bar in the evening.

It’s fun

Finally, it’s fun. You are likely in the technology business because you love to create. Hack Day is it – close to its purest.

What are you waiting for?

How many things out there are fun, create better teams and have great ROI?

Go for it!

Standards

An idea of one of my favourite authors, David Allen, that really resonates with me is that you often only become aware of your standards or principles when they are violated.

His example is that of dirty mugs around the house. Some people cannot stand to have even one dirty mug lying around while others would not even notice it until they no longer have a clean mug to drink out off. Where it becomes interesting of course is when these two types of people start living together…

Recently, I have become more and more aware of how standards also strongly impact the performance and cohesiveness of a team. Personally, I take a a lot of pride in building great teams and frankly I think I often succeed but there were also the occasional teams that – although not necessarily under-performing – never really felt like they clicked.

Analysing this a bit closer, when I felt that a team really clicked, it was often due to the fact that we were aligned on these standards or the team had higher standards than I had. For example, as a PM, I feel strongly about shipping often and early, be always ready well in time for deadlines if time allows, bring a sense of urgency to project execution, avoid victim mentality, ship things that make an impact for the user (please fill out other clichees). In parallel, when a team did not click, it was often due to the fact that these standards were not shared. Team members may have felt more comfortable with shipping at the last minute or not care so much about making an impact to the user rather than doing something that is interesting or fun.

Now an interesting question is: should you demand your team to live up to your standards?

You could argue that as long as they provide acceptable performance to the business there is no need to force your team to adopt your standards.

I myself had a case where IMHO my manager has impossibly high standards and I certainly felt uncomfortable being dragged there as I could not see the point of them.

On the flip side, I have had managers that have changed my standards and they have proven me a great service. As we all know, a small change in standards (be it extra effort, or networking) can be the difference between good work & great work, and between decent ROI and splendid ROI. And I am forever grateful to them for pushing me there (although, at first, often begrudgingly so).

I guess the key is just to be more very self-aware and analytical of your standards: are these standards clearly linked to success and will I do my team a service by pushing them there or are they just personal preference? Or, alternatively, do I want to be part of a team that do not share my standards?

Beginner’s Mind

After having been in the Web Search game for a while now, I start to notice more and more signs of professional deformation.

Major world events happen and my first reaction is to check the search results page for fresh content or the presence (or not) of certain features. You think about likely trending queries, or how it will affect referrals.

Glancing over the ethical questions the above raises, as a program/product manager, you also always tend to get to a point of expertise (or familiarity with the domain) when you notice that you don’t look at the product any more as a normal user would, let alone a beginning user.

It may be unavoidable but it is not inescapable and I have found that simple awareness of the problem matters a lot.

In that context, I have always loved the Zen or martial arts concept of Shoshin or the Beginner’s Mind which conceptualizes the problem and solution so much more elegantly.

It refers to having an attitude of openness, eagerness, and lack of preconceptions when studying a subject, even when studying at an advanced level, just as a beginner in that subject would.

Or you may know this famous line:

In the beginner’s mind there are many possibilities, in the expert’s mind there are few.

That said, maybe it is not so bad to not be a true beginner any more as the following quote from the Dalai Lama probably resonates as strongly with me as the concept of Shoshin:

Learn the rules so you know how to break them properly

In any case, I think I will take some time off from my normal routine for a day or two of just pure creative indulgence and see if after all these years, I can still clear my pre-conceptions about Web Search and come up with some interesting ideas without regurgitating the old.

Wish me luck.

Experiences with Scrum – Part 1: Sprint Demo

Over the past couple of years, I have used Scrum as the main project management methodology on my projects. I adapt the exact methodology from project to project or team to team and usually it is a pretty light weight, unsophisticated and / or bastardized variant.

That said, I often get asked about my experience with Scrum so I thought I’d do a little series. First up, my favourite: the sprint demo.

Why is it my favourite? Several reasons but in short, it allows you to build a better product by building a better team (which I guess is true of the entire Scrum process).

Most importantly, I am a strong believer that when you use a software product you can feel how well the team understood the problem space, cared about quality, etc. As the sprint demo shows an early, iterative version of the product, it allows you to catch these kind of problems early that would otherwise maybe go undetected until the final milestones of the product lifecycle.

It is also a great tool to help the team develop “outcome-based thinking” which is especially critical with a young, inexperienced team:

1. You imagine / set an outcome at sprint planning
2. Work for generally a very short period on what you think will be the most effective / efficient action steps to reach that outcome
3. Demo whatever you have actually accomplished at the end of the sprint (proof is in the pudding)
4. Repeat

Slowly but surely, you will see the team getting better at setting outcomes, better at reaching them and better at selling them in the demo. You often see 3 different stages:

• PHASE 1: Several team members don’t have a demo prepared. This is especially true for new graduates. Without getting too psycho-babbly on you, the underlying reasons are typically the following:
  • They did not get anything done as they do not yet know how to do “knowledge work” efficiently and effectively and end up frittering away much of their time. This “pathology” can often be resolved through the Scrum process itself and some on-the-job mentoring.
  • They want to produce great work and they just do not feel that any of the work is good enough or worthy enough to demo (“I have got a PhD for **** sake and this demo is just a webpage with an algorithm I learned in Statistics 101″). In short, they need to learn some “humility” and to acknowledge and celebrate their small wins.
• PHASE 2: Individual team members start to enjoy demo-ing and looking forward to it. The whole event becomes a celebration and you feel momentum building. Outcomes and demo’s become crisper and gradually more and more ambitious.
• PHASE 3: The team starts to collaborate to build cooler demo’s. Team members starts to leverage each others skills to get to bigger and better outcomes. That is when you know you are on a roll.

It is a great thrill to see a team getting better and better after each iteration, and a product slowly emerging from what was first just an idea in someone’s mind.

So, in short: demo EARLY and demo OFTEN and by doing that build a BETTER team!

Are you writing a fear or greed presentation?

As a PM, a large amount of my time is taken up by reading & writing powerpoint decks. Yay me!

What I have noticed though is that most of them are seemingly written with the following underlying intents in mind (consciously recognized or not):

1. Show what a great job you are doing
2. Show how smart you are
3. Cover your ***

They typically do not tend to affect any change or motivate me to take any action. I hardly ever go: “He is so smart, I just must follow the recommendations in his deck!”

I have found that when you do you want to affect change, something else needs to be added to the mix. I think one of my old bosses put it quite well, he said: “Ask yourself one key question when creating a deck. Are you writing a Fear or Greed presentation?”

Fear is painting the audience a picture of all the bad things that are going to happen if they don’t follow the recommendations in your deck: market share will decline, good employees will leave or they will look foolish to their bosses.

Greed is based on the opposite: follow my instructions and you will get a “atta boy” from your boss, the respect of your peers, more sales, etc

It is the classic pain / pleasure principle. People want to move away from pain (fear) or work towards pleasure (greed). Pain (fear) is maybe unsurprisingly the biggest motivator…

Flavour of the month: Company Culture

What I always find amusing is when a company gets successful, a bunch of books get published about the company’s culture and how to implement it at your company.

Far from it that I doubt the importance of a company’s culture but let’s be fair, most of these companies did not become successful due to their culture. They became successful as they happened to stumble upon a really succesful product.

One analogy that always comes to mind is that of team culture in football which is typically attributed to the coach. A coach departs due to disappointing results and a new one gets hired. Some better results follow and out come the “team culture” rationalization. “Well the last coach was such a disciplinarian. You need room for trust and freedom for a team to be successful.” Some months down the line and results are no longer so good and the reverse happens. “Well, he was too friendly with the star players. You need a strong hand & discipline to perform.”

By all means, think about your company culture, but don’t go for flavour of the month.

Value of Authenticity in Presentations

In recent days, we have had some visits to our office of the Bing leadership team. And this means, presentations, lots of them.

Yes, on occassion, long sessions can be extremely draining, but in general I quite enjoy it. I believe there is a certain art to giving presentations (which I would love to master). Hence, I am always keen to see how other people handle it: how they structure their presentations, what they choose to highlight, how they engage with the audience, and finally, and most importantly, the reaction of the audience.

In a way, a presentation is like a live music performance, isn’t it? Will the audience go home going feeling like they experienced something or would they have rather listened to the CD at home (or flipped through a deck in 5 minutes)?

Yes, there are tips & tricks and a certain craft to doing a presentation (just like with music) but what is more important I think is to have presenter and a presentation that is completely authentic. Are you being true to what you believe or are you gunning for what you think your boss wants to hear? Are you trying to manipulate your audience or are you trying to share something you truly believe in?

I think the value of that authenticity cannot be overestimated. Best intuitive barometer for me is my energy level. A good gig or an authentic presenter make them shoot through the roof, which lots of impressive slides regurgitating a 2nd hand message never can.

Brainstorming trick: write your announcement email at project definition stage

As a program manager, I have the pleasure of writing announcement emails to the organization when features go live and I recently had the chance to do this when Autosuggest went live in France (of which I am very proud).

One of the things I have used over the last couple of years is to write, or at least imagine, the announcement email when I start a project. What do you want to be true about the project when it is done? What would amazing success look like? What would you want your boss to say, the press, your peers, the users?

It is a great exercise to use when brainstorming ideas, features, goals for your roadmap.

I actually used this again today in two highly productive sessions. I am sure some people found / will find it hokey but give it a go. It works.

Let your team play

Continuing on the theme of my earlier post of “cranking widgets”, is micromanagement and the fear to avoid mistakes at all costs creating a reactive, dumb-downed team?

Phil Jackson, coach of the LA Lakers, is notorious for not calling time outs when his team is in trouble. He feels it is more important for the team to develop calm under pressure and learn to work through adversity together as a team, rather than give them an easy “out” by calling a time out.

I feel this has a lot of merit for a software team as well. Don’t interfere every time anything goes wrong. Don’t manage every play / task. Let the team play, learn and work together.

The team will never be as good as it can be if you want to control every play and every situation.

Widget cranking

For those who know me a bit, know that I am a fan of the Getting Things Done methodology. One of the key analogies that its creator, David Allen, uses to explain (part of) the methodology is that of “cranking widgets”.

It basically makes the point that, typically earlier on in your career, you probably had clear tasks to do when coming to work that was just like “cranking widgets” and how easy and fun it was. In fact, you might leave with more energy at the end of the day then at the start as you felt so amazingly productive.

However, as you climb up the corporate ladder, all your projects and responsibilities tend to become more amorphous blobs of stuff which can make your work quite overwhelming and unfulfilling.

Therefore, he recommends you turn that “stuff” back into “widgets” by making decisions about the next action you are going to take on any of your projects and make it so clear, distinct and immediately actionable that it is like “cranking a widget”.

I fully buy into this and I have been using this for a while as a means to personal productivity. However, be careful how you apply this when it comes to delegation, or as a style of program management.

Too often I have seen a program manager personally break down a project in small widgets and just ask every team member to execute their widget, checking up continually on every widget’s progress and see that as their job.

I have to admit, many people like this style as it is clear what they need to do and when they are done and they don’t need to think of anything else (i.e. the widget cranking job as to my earlier point). And, of course, I am not immune to its appeal either … as it easy. However, I always knew in the back of my mind that I could be offering more to the project if there was room for it and expected to provide it.

The reason you break down your work into widgets is so you can free up your mind for more creative & courageous work.

Especially in the software field, it is so critical that your whole team is thinking along in every step of the process and all work together to make the goal happen. They may see opportunities for quicker delivery by using a different approach or by cooperation with other teams. Or, realize that cranking your widget on schedule may be less important than taking some more time to help another team as this is your chance to build up a stronger relationship for when you need them later on in the project.

By all means, provide the widgets (or better have the team collectively define the widgets) but don’t lose your team’s collective intelligence in the process.