Carly Guthrie shares what she’s learned about why people quit

There are a number of ways to keep your best people, but no silver bullet. As you think through your own retention strategy, remember the following:

  • Recognize that employees have lives outside of work — cultivate a deep respect for employees’ time.
  • When employees leave because of their boss, it rarely comes from personality mismatches; it stems from a lack of confidence.
  • Counteroffers are (an expensive) band-aid; they won’t fix an employee’s fundamental unhappiness.
  • Building a genuine sense of community is crucial to employee retention. Make sure your hiring process incorporates and heavily weighs cultural fit.
  • Hashing out a concrete “work from home” policy can improve employee happiness/retention, but it’s largely dependent on your organization’s needs. Make sure you’re being fair across the board.
  • Good mentorship happens organically, and should be directed by employee interests and growth. It also creates another opportunity for a natural, short feedback loop you can definitely use.
  • It’s never too early to invest in good HR, whether it’s processes or people. This can absolutely include HR contractors. An outside perspective can be invaluable for founders who need big-picture reality checks.

via This is Why People Leave Your Company

10% time at Hooroo

IMG_0484 2

Recently the team at Hooroo got together and identified that our regular 10% time, every Tuesday arvo from 1pm, was falling short of the benefits and results we were originally aiming for when we put it in place over a year ago. We decided this wasn’t on and have made a few changes to help reinvigorate this valuable part of working at Hooroo.

Firstly, we asked ourselves why we have 10% time in the first place and agreed that it’s an opportunity for experimentation, to discover the benefits of new tools and technologies and to generally demonstrate what we can achieve with our own initiative. It also gives us some head-space from our current projects in play, which in turn provides time to reflect and assess better ways to deliver solutions.

There was some uncertainty within the team about what a good 10% time experiment is. We decided that “experiments” needed some clarification:

Experiments, by definition, must start off with a hypothesis. This should be something that can be reasonably related to the objectives of our delivery team (development, product, design) and the direction of the wider Hooroo Group in general. Whilst we want this time to be fun and free of the pressures of regular “work”, we need to remain mindful that 10% time experimentation should relate to a potential benefit for Hooroo. That still leaves a massive amount of flexibility for us to innovate.

We can do things like:

  • Investigate the relevance of a new JavaScript framework that we think will boost our productivity
  • Create new internal tools or improve existing ones to solve problems/inefficiencies that we or our colleagues experience
  • Create additional measurements to understand the size of a known problem or opportunity
  • Scope-out an MVP for an entirely different way to engage a subset of our users
  • Hack on some hardware to investigate the place of physical devices either for us or our customers

Along with the unclarity about what a good 10% time experiment was, there was some confusion about the expected outcomes from the rest of the Hooroo Group. Some team members were feeling pressure to always work on an idea that would be relevant or interesting to everyone within our company.

We quickly realised that outcomes was another area that needed clarification. Highlighting that it’s ok to fail was the key message amongst the team and is a huge part of our learning and experimentation process.

If we’re picking suitable experiments, then the output mechanism should be obvious depending on what we’re investigating. For example, we don’t expect people to showcase a new highly-concurrent HTTP framework to the entire company, but we would expect to see some fruits from that labour. Even if it’s a 10 minute brown bag session with a few slides or a demo for the technical team.

We identified a number of different ways that 10% time projects may be communicated:

  • Release it for the team to use
  • Demo at a showcase
  • Brown bag session with a few slides
  • Email and explain what you discovered
  • One-on-one catchup with specific stakeholders
  • Reports / data to feed into another project or another experiment

‘Failed’ experiments shouldn’t be excluded from this communication. Demonstrating what failed and why is a valuable exercise and needs to be shared.

So what are we changing with 10% time at Hooroo?

1. Move to Tuesdays fortnightly, all day (instead of every Tues arvo). This should allow us to be more focused from the moment we arrive at work in the morning. It was clear that kicking off a 10% time experiment every Tuesday afternoon was ripe for distraction. A clean “cut over” from our regular projects in play was becoming more and more difficult each week. Having a whole day for 10% should fix that.

2. Create an “In progress” wall. We’ve put up cards and avatars for visibility and we’ll use it much like our regular wall to track how things are progressing and what’s ready to have outcomes communicated.

3. Have a dedicated 10% time stand up. We’re going to use the end of our Monday 4pm tech session for this as that’s when we’re all together already. It will also allow us to hit the ground running on Tuesday mornings with no requirements to be at a stand up or huddle etc in the way.

4. Sit in pairs away from our usual desks and project areas. We’re going to try gather around a common area of the office and create a good atmosphere. This also communicates out to the rest of the Hooroo Group that 10% is underway and it’s being taken seriously.

Really looking forward to seeing how these changes impact the success of 10% time at Hooroo. If you have any questions, feel free to ask via Twitter.

Thanks Stu Liston, Hooroo’s Development Manager, for helping out with this post.

Hack Days FTW

So awesome. TaskRabbit’s new business model & product direction was born out of a company Hack Day.

In August, TaskRabbit held a hack day devoted to reimagining the service. “If you started TaskRabbit today,” Busque asked her team of roughly 50, “what would the world look like?” A product manager named Andy Jih became interested in what he called an “invitation” model, in which someone posting a task could ask a small handful of taskers for help. After many iterations, that led the company to create its new model, which uses algorithms to instantly match clients with a selection of taskers. Internally, the newmodel came to be codenamed Booker T.

TaskRabbit is blowing up its business model and becoming the Uber for everything.

Stable values

Bob Martin reflects on the early values underpinning the agile movement highlighted in the book “Extreme Programming Explained” by Kent Beck.

“I believe the practices persist because they are based on a firm foundation of stable values. Values that Kent Beck described in Chapter 7 on page 29 of his book:

  • Communication
  • Simplicity
  • Feedback
  • Courage.

I could try to argue why these are the right values; but I think they speak for themselves. What software craftsman would reject any one of those values? What software craftsman would not strive to ensure that each one of those values were represented in their work? These values are values of software craftsmanship.”

Read Bob’s full remarks here.

Arbitrary References to Waterfall and Agile

“To be as predictable as possible and to maximize time to ROI, we need to have clear conversations around the characteristics of the teams that are best suited to the problems we are trying to solve.

Understand if your project is convergent or divergent, determine the appropriate amount of planning, assess if your project would benefit from phase based or value based sequencing, and whether functional separate or collaborative teams are the best way to build software.”

Great read.

Developer & Product Pair Programming

Each Friday for the past couple of weeks I’ve been pair programming with one of the UI developers on the team at Hooroo. It’s not uncommon for development & test teams to partake in pair programming but it is certainly new for me in my product management role. The benefits have been clear and I would certainly recommend it.

Pair programming is an agile software development technique in which two developers work together at one workstation. One writes the code (referred to as the “driver“) while the other observes (known as the “navigator“). The roles switch frequently which increases knowledge sharing and the number of opportunities to review the current task.

Pairing at Hooroo

I’ve found product manager & developer pairing requires a slightly different role for the “driver”. Instead of mainly writing code while being the “driver”, the product manager is able to “drive” by spending time with the developer clarifying desired feature or functionality detail. This allows the developer to observe, provide feedback, and continue to ask questions in the role of the “navigator”.

That opportunity to ask questions, clarify requirements, and provide direct feedback is special because it isn’t something developers always get the chance to do with their product manager.

For the product manager and developer, the role of the “navigator” is quite similar to regular pair programming as code is being written by the developer and the impact to the UI of the feature being developed is still reviewed constantly. The conversation isn’t as technical as it would be with two developers pairing but it’s important for product managers to have at least a minor technical understanding of various programming languages and pairing is a great way to progress that.

After spending a couple of days over the last few weeks pair programming with a developer, I’ve found the main benefits to be:

  • Higher levels of focus on the feature/functionality being delivered
  • Fewer interruptions and distractions
  • When interrupted, the “navigator” (quite often the product manager) can deal with the problem while the “driver” (more often the developer) continues on
  • Higher levels of satisfaction finishing up at the end of a day
  • Closer working relationships with teammates
  • Greater knowledge amongst the team on objectives and product development plans