I’m a big proponent of play as a means to grow and succeed. In my career I’ve spent endless hours building things that interested me with no thought of recompense or acknowledgement, simply to broaden my knowledge on a particular subject, or chase a particularly intriguing idea. Play provides you with a fun method for exploring your medium without risk or judgement. It also allows you to build the things you wish people would pay you to build, and market the results to help steer your career.

In my conference talks, I frequently encourage others to experiment with interactive media. At first, I would often be asked “where do you find the time?” In answer to this, I started talking about an approach I call “Passionate Procrastination”, which simply involves using time you might otherwise spend procrastinating to build interesting experiments. We all have those moments in our day when we need to step back from the task at hand and let our brains mull things over. I proposed that rather than read Digg, watch videos, or surf Facebook, that time could be used to work on something else that you are passionate about.

When pressed further, I started talking about how little time was actually required. Twenty minutes every day gives you three full work weeks per year to apply to experimental projects. Considering the average American watches more than twenty minutes per day of advertising, this time shouldn’t be that difficult to find.

This seemed to convince most people (or they simply stopped asking) until today when I was yanked unceremoniously into a dotBrighton meeting via Skype and posed a question from an attendee regarding my recent talk at FOTB (I think his name was Paul, but I was a bit distracted, my apologies if I got it wrong). He cited my twenty minute figure, and asked how I was able to accomplish anything in that little time, given that it typically takes a good five or ten minutes to really ramp up on a new task.

I thought it was a great question, and that it warranted a more coherent answer than whatever I mumbled over Skype at the time. For me, there’s three parts to how I use this time effectively:

Firstly, that twenty minutes is an average that I only use as a demonstration of how little daily commitment it requires to accumulate a fair amount of play time. I would guess that most of my experimentation sessions last between 30 and 90 minutes, but I definitely don’t do it every day.

Secondly, it’s important to have a goal ready for when you decide to take a play break. I maintain a list of ideas in a text file on my computer, and glance over it regularly to keep the concepts fresh. I try to think through the implementation of these ideas during AFK (away from keyboard) times, like when I’m showering, or lying in bed trying to sleep (these are my two most productive idea times). This way, when I have some time to play, I’m ready to jump right into writing code and testing if my ideas work.

I also try to disassemble my implementations into small, easily-achievable sprints and accomplish one or two of them during a single break. This helps define and limit your time, as well as giving you a sense of accomplishment which can help propel you when you return to your usual work.

Thirdly, most of my play time is while procrastinating on other work. This means I already have my tools open and ready to go. In fact, I’ll often have a real project and an experimental project open at the same time, and swap over to play when I get momentarily stumped on real work (or just need a quick break). You mileage on this may vary depending on your work circumstances and your boss.

Play offers so many benefits, and it really helps keep working with technology from becoming mundane. Finding time to do it is likely easier than you think, even if it means missing the next Old Spice ad. I’m on a horse!

It’s worth reading through the first four parts of this series if you haven’t already: “Introduction“, “Hiring“, “Orientation“, and “Training“.

Once we’ve finished subjecting our new hires to a week (maybe two in future) of classroom training, we turn them loose on an internal project. The core goals of this exercise are:

• Familiarize new hires with our process and all the steps that go into a project.

• Apply concepts learned during formal training, and continue their technical growth.

• Begin developing their competency in critical secondary skills including estimation, time & project management, project planning, user experience (UX), leveraging existing resources, effective communication, QA and issue resolution.

• Develop skills with tools including development tools, SVN, and Basecamp.

• Start them thinking about value and business considerations for projects.

• Force them to respond to feedback and changes in an agile, responsible manner.

The trainees are informed about this project on their first day at work, and reminded of it throughout their first week so that they can brainstorm ideas in advance. They are also encouraged to run their ideas past people to get feedback. Over the course of the second week they then develop a full project plan, which is maintained and organized in Basecamp.

At the start of this phase (usually the first day of their second week) the trainees are asked to solidify their concept(s) for their internal project, and prepare whatever materials they deem necessary to present it.

The only requirements for the project is that it fit in a 2-4 week timeline, and that it provide value to the company. This value can come in a number of forms; it could be useful, have market potential, have promotional value, contribute to the knowledge of the company, or it could just advance their training in a significant way.

At the end of the first day of this phase, they present their concept(s) to the senior staff, and are presented with feedback as to its viability, value, and implementation. They then revise their concept based on that feedback.

Next, the trainee develops wireframes, defines user flows, and identifies any data requirements for the project. Again, this is presented to available senior staff and revised based on feedback. In particular, we focus on the appropriateness of the user experience, and the completeness of the wireframes, flows, and data requirements to ensure the trainee has a good understanding of the full scope of their project.

The trainee then moves into doing some high-level architecture. They prepare a CRC outline (classes, responsibilities and collaborators), and an I/O spec (input / output for a web or local service). Once again, this is presented and revised.

With the architecture approved, they write up a project plan that includes a timeline, with milestones and micro-deadlines (ie. goals for each day or two).

Once all of this is complete (generally on the Friday of that week), they present their complete project plan (wireframes, architecture, I/O, timelines, etc) to the entire team for feedback and criticism. This lets them receive and filter a range of input, as well as letting them see the more experienced members of the team disagree and debate different ideas.

With their plan complete, they are ready to move on to production, which is the focus of the next article.

If you haven’t read the first two parts of this series, “Introduction” and “Hiring“, I’d suggest starting there.

The first day for a new hire is a busy day of orientation. The goal is to get them set up and comfortable with all of our systems, policies, and processes.

First, they get reintroduced to the whole team and educated on everyone’s roles. They learn who to talk to for specific issues, and who will be guiding them through their training.

They start with the administrative side of things. They sit down with our office manager to sign their employment contract (which they receive in advance so we can answer any questions), fill out forms, talk about payroll, benefits, employment policies (lateness, time off, overtime, external work), and general office polices. We put a lot of emphasis on the core clauses of their employment contract surrounding NDA and IP considerations.

Next, they get set up on all of our systems, and receive training on each. This includes:

• Our network, dev PCs, and connected devices.

• Software, what’s available, how to request serial numbers, etc.

• Our email system, webmail, and signatures.

• Instant messaging.

• Basecamp, project tracking, and writeboards.

• Subversion, checking out / in, branching, creating projects, etc.

• Tracking time, and why it’s so important.

Next we walk them through all of our processes. We outline the full training program they will be going through, including informing them of the internal project they will be building (part 5 of this series). We give them a high-level introduction to our process for delivering projects and doing quality assurance. QA receives a lot of emphasis – what are the processes for testing, identifying bugs, resolving issues, and communicating status back to the project manager. We also talk a bit about our policies for using open source libraries in client projects (ie. usually only MIT licensed or equivalent and only with prior client permission).

Finally we remind them of their NDA, and introduce them to all of the current projects we’re working on. This can be a quick overview, or a more in-depth dive into each project depending on the time available.

Before the end of the day, they are asked to enter all of their time into our time tracking system, and are expected to keep this up to date going forward.

The next article in this series, “Training“, is up.