The Engineering Lifestyle, Part I

Work. It's all fun and games until someone loses an eye, right? That saying may be well suited for some industries, such as professional sports and knitting, but in the technically driven industry of software engineering it isn't quite accurate. Instead, the saying would be something like “All work and no play makes Jack a dull boy…” This is the challenge of the work we engineers have self-selected for ourselves. There is always some aspect of the job that is dull and mundane, and overcoming this to still achieve great things is often a problem that software companies face. How do you keep your engineers happy and engaged? How do you provide them the freedom and autonomy to innovate, yet still meet business objectives and needs?

Taking a cue from Google and their 80/20 rule, we here at ReadyTalk implemented an R&D concept that we refer to as ReadyTalk Labs. In case you haven't heard or have been living under a rock, Google's 80/20 rule is where an engineer gets to essentially spend 20% of their time working on their own thing (but still company related) and 80% of their time working on Google things. Their 20% time could be spent on almost anything across the company that they are passionate about, but often it ends up having a direct impact on the product. Things like GMail, AdSense and Google News were born from the 80/20 concept.

Our implementation of Labs began as 20% of each iteration. Our scrum teams work in 2-week iterations, so 2 days of every iteration could be spent on ReadyTalk Labs work. This continued for several months, but what we found when we looked back at how it was progressing was that we had not appropriately solved the problem. The challenge we saw in our implementation came down to the basic human challenge of balancing one's time. The engineers were challenged to be available to help work on production issues, or lend a hand to other engineers yet still carve out those 16 hours of Labs time. This usually resulted in engineers actually skipping that Labs time altogether.

So we dove into brainstorming this problem once more, and emerged with a much better implementation of RT Labs. What we chose to do was allow every scrum team to take every 5th iteration as a Labs iteration. It still boils down to 20% of their time, but what this allows is for the teams to really focus on something substantial in their Labs time. It also helps to set expectations with the Product team, so they know that a team that is on their Labs iteration will not be committing to any product driven work for that iteration, which solves the problem of forcing the team to prioritize their own innovation time against product requests. We originally staggered each teams Labs iteration so that at any given time only 1 team for a given product line was working on labs stuff. We have since modified this so that all teams Labs iterations align as much as possible, to allow for more cross-team labs work to occur. You can read more about our Labs time in a recent Denver Post article, "Labs" time elicits ideas at ReadyTalk.

In this day and age, when technology is advancing so quickly and every company is trying to find that next big thing that will launch them into the stratosphere, keeping your top talent happy and engaged should be priority number one. How are you or your company achieving this goal?

Jason Collins (aka JC) is the VP of Engineering at ReadyTalk and the self-appointed Chief Happiness Officer. He's been either writing code or managing engineers for nearly 15 years and has a passion for technology and agile development practices. The happiness of the engineering team is his top priority and he can usually be found wearing a ReadyTalk cape and the infamous "idea helmet" around the office to help keep people entertained. When he's not hanging out with his work family, he's at home with his wife and four boys doing all sorts of geeky things, like playing video games and watching campy Sci-Fi and Action flicks.

Share this: