Andrew Wilkinson

Random Ramblings on Programming

Archive for the ‘management’ Category

Steve Jobs and the Lean Startup

leave a comment »

Steve JobsOn my 25 minute train journey to work each morning I like to pass the time by reading. The two most recent books I’ve read are The Lean Startup: How Constant Innovation Creates Radically Successful Businesses by Eric Ries and Steve Jobs by Walter Isaacson (both links contain an affiliate id). Although one is a biography and the other is a book on project management they actually cover similar ground, and both are books that people working in technology should read.

Walter Isaacson’s book has been extensively reviewed and dissected so I’m not going to go into detail on it. The book is roughly divided into two halves. The first section is on the founding of Apple, Pixar and NeXT. This section serves an inspirational guide to setting up your own company. The joy of building a great product and defying the odds against a company succeeding comes across very strongly. The later section following Job’s return to Apple is a much more about the nuts and bolts of running a huge corporation. While it’s an interesting guide to how Apple got to where it is today, it lacks the excitement of the earlier chapters.

Eric Ries - The Lean Startup, London EditionThe Lean Startup could, rather unkindly, be described as a managerial technique book. It’s much more than that though as it’s more of a philosophy for how to run company or a project. The book is very readable and engaging with plenty of useful case studies to illustrate the point being made. The key message of the book is to get your product out to customers as soon as possible, to measure as much as you can and learn from what your customers are doing and saying. As you learn you need to make a decision on whether to persevere or to pivot, and change strategy.

There are many reasons why Steve Jobs was a great leader, a visionary and a terrible boss. One aspect was his unshakable belief that he knew what the customer wanted, even before they knew themselves. This is the antithesis of the Lean Startup methodology, which focuses on measurement and learning. Eric Ries stresses that a startup is not necessarily two guys working out of a garage. Huge multinational corporations can have speculative teams or projects inside them, that act much like start ups, so it wouldn’t be impossible for the Apple of today to act like a start up. Apple weren’t always huge though, and back in the 1970s they really were a start up.

One Apple trait the Lean Startup methodolgy doesn’t allow for is dramatic product launches. The Lean Startup is a way of working that relies on quick iteration and gradually building up your customer base. It’s hard to quickly iterate when building hardware, but early in Apple’s life they were struggling to find a market for their computers. The Apple I follow the trend of the time of build-it-yourself computers. Just a year later and Apple released the Apple ][ which came with a case and was much more suitable for the average consumer. This represents a pivot on the part of Apple. They could have continued to focus on hobbyists but instead they decided to change and aim for a bigger, but less technical, market.

Reading is a key part of becoming a better programmer. Whether it’s reading about the latest technology on a blog, the latest project management techniques or the history of computers reading will help you become better at your job. I’m not sure I recommend anyone tries to recreate Steve Job’s management style, but as a history of Apple Walter Isaacson’s book is inspirational and informative. The Lean Startup is considerably more practical, even if it won’t inspire you to set a company in the first place.


Photo of Steve Jobs by Ben Stanfield.
Photo of Eric Ries – The Lean Startup, London Edition by Betsy Weber.

Advertisements

Written by Andrew Wilkinson

March 20, 2012 at 1:50 pm

Hackathons, and why your company needs one

leave a comment »

CodeI could wax lyrical about how programming is an art form and requires a great deal of creativity. However, it’s easy to loose focus on this in the middle of creating project specs and servicing your technical debt. Like many companies we recently held a hackathon event where we split up into teams and worked on projects suggested by the team members.

Different teams took different approaches to the challenge, one team set about integrating an open source code review site in our development environment, others investigated how some commercial technologies could be useful to us. My team built a collaborative filtering system using MongoDB. I’ll post about that project in the future, but in this post I wanted to focus on what we learnt about running a company Hackathon event.

If you’re lucky you’ll work in a company that’s focused on technology and you’ll always be creating new and interesting things. In the majority of companies technology is a means to a end, rather than the goal. In that case it’s easy to become so engrossed in the day to day work that you forget to innovate or to experiment with new technologies. A hackathon is a great way to take a step back and try something new for a few days.

Running a hackathon event should be divided into three stages, preparation, the event and the post event. Before the event you need to take some time to collect ideas and do some preliminary research. The event itself should be a whirlwind of pumping out code and building something exciting. Afterwards you need to take some time to demonstrate what you’ve built, and share what you’ve learnt.

Typical IT departments will been given a set of requirements and will need work out how to achieve them. What a hackathon event should allow is for the department to produce their own set of requirements, free from any external influences. In your day to day work what projects you actually tackle will be decided by a range of factors, but a hackathon is designed to let programmers take something where they’ve thought “we could do something interesting with that data” or “that technology might help us make things better” and run with it. The first stage is to collect all these ideas from the department and then to divide the team up into groups to tackle the most popular projects, perhaps with a voting staging to whittle the ideas down. To keep things fun and quick small teams are key here, any more than five people and you’ll start to get bogged down in process and design by committee.

Once you’ve got the projects and teams sorted you can prepare for the event. People who are working on each project need to think about what they want to have built by the end of event and should be dreaming up ways to tackle the problem. Coding before is banned, but things will go much quicker if you’ve come up with a plan to attack the problem.

For the event you need to remove as many distractions as possible. Certainly you need tell others in the company that you will not be available for a few days. Whether other possibilities such as not reading your email are doable depends on how often you need to deal with crises. Hopefully with no-one fiddling with your servers fewer things will go wrong than on an average day. Moving location, either to meeting rooms or to an external space are both good ways of getting space to focus on the work.

Once the time has expired you need to wrap the event up, and the key thing is to demonstrate what you’ve built to the rest of team. Not everyone in IT is happy with standing and presenting, but a few minutes to people they know well should not be a problem. It’s tempting to invite people from outside the department to the presentations, and before my first hackathon I was very keen on bringing management, who often won’t understand what IT do, into the meeting. Hopefully what is built will show how innovative and full of ideas programmers can be. In reality though the best you can really hope for is a set of tech demos that require quite a lot of understanding about the limitations inherent in building things quickly, which those outside IT will struggle to understand.

The presentations should focus on two things, a demonstration of what you’ve built and a discussion on the technology used and decisions made. The aim should be to excite the team about what you’ve built and to impart some of what you’ve learnt. A good way to spark a discussion is to talk about what problems you encountered. How long the presentations should be depends a lot on the complexity of the problems being tackled, but ten to twenty minutes per project is a good length of time.

In the longer term after the event you’ll need to decide which of the projects to keep, which to improve on or rewrite and which to abandon completely. In a more structured and prepared presentation showing the projects to management maybe a good idea. The presentations immediately following the hackathon are likely to be a fairly ramshackle affair and won’t make the most ‘professional’ impression.

Traditional ‘training’ session don’t work to well in IT, it’s a easier to learn by doing. Most people are also quite sceptical of ‘build a raft’ style team building exercises, compared to those hackathons are the perfect mix of learning and fun. They’re also a great way to work on the problems that you’ve wanted to solve for ages but have never found the time. Even if you don’t get anything you can use out of the event the process of getting there will be worthwhile. And who knows, you might build a million dollar product for your company.


Photo of Code by Lindsey Bieda.

Written by Andrew Wilkinson

February 2, 2012 at 2:08 pm

Posted in management

Tagged with , , ,