Over the past day, a LOT of attention has been focused on Facebook's IPO filing and it's actually pretty interesting to see the numbers behind FB's business. One of the areas that caught my attention though is the cultural focus on continuous, iterative improvements. In Mark Zuckerberg's words, it's "The Hacker Way"
This post on Startup Lessons Learned has a nice summary and way to think about this.
Whether or not you call this a way that hackers think about their work, for me, it comes down to a commitment to iterating and improving at every step. Facebook's a great example of that especially since they are clearly pushing the envelope of Social but bring their users along for the ride and improving based on their inputs. I've lost track of how many big changes we've seen to the timeline and other features, but in the end, what I see when I login there today is FAR better than what I saw in 2008.
So by total coincidence, before the IPO announcement yesterday I had talked to some folks at work about accomplishing big things over time using fast steps. On one occasion it was in regards to an organizational announcement which was solidifying the work that a small team was doing around trying out new "innovations" even if it required a lot of manual work to start with. The idea was that it's better to test it out and see what you can make of it, but not get too bogged down by the need to make it everlasting. If it works, great, we can figure out a way to make it last. If it doesn't work, not a huge deal since we tried it out and quickly determined there may be better ways of spending effort. Effectively, this is The Hacker Way even if it wasn't in the context of hacking code.
To be honest, this org announcement sort of surprised me, since this ethic isn't all that common where I work. In fact, it goes counter to the way that most things get done around here.
And that was the second time this idea came up in conversation. In doing some planning, I felt that the group was trying to do too much and it may make sense for them to decide, example by example, whether something should be in scope or not. My take was that it didn't make sense to put something on a release roadmap if you had very little confidence in getting it done and especially if it would require such a long timeframe to plan & execute it. I wasn't suggesting to think smaller or to drop the idea, but to think more tactical and not get stuck in the idea that everything that could possibly be aligned to their goals should definitely be in scope. If it's such a great idea, we can probably find someone else to take it on while we focus on the goals at hand.
The response I got was interesting since it was a bit of the Hacker Way of thinking since they were suggesting that if they can get it done, they should give it a try. I still don't agree since "it" was just one of 20 other things they wanted to get done at the same time. Lending even more reasons for me to believe that "it" wouldn't get done and it would be better to find another team to give it a shot.
About an hour after this, Twitter blew up with news about FB's filing and I got to thinking about these two conversations. My takeaway is that the iterative, continuous improvement way of working is definitely a winner, but you have to keep that in the context of not trying to get too many disparate things done at the same time. Trying to get too much done will likely cause you to lose focus and incorrectly think that all the mad-crazy work you're doing is actually getting you to your goal.
No comments:
Post a Comment