Before pressing on with the fact it’s no gimmick let’s step back a minute to what this is. Google and others have notable had 1 day per week (their 20% time) set aside for every engineer or member of staff to work on a completely different project. Some companies have 10%, some put aside 2 days each quarter. Bottom line is that a vast number of companies provide the opportunity for their developers to play with new ideas. This may be related to the work they do – it may be stipulated that it should have business value. It may be a completely free time to explore whatever interests each individual.
How can they afford the loss in productivity?
Seriously? You’re suggesting that people who get a chance to play around with random ideas and innovate without boundaries will somehow be less productive? Not only do most of these companies believe that staff will be more productive at work knowing that they can work on their own interests as well but it’s also a great source of ideas for the product, company or team development.
New technologies can be experimented with, or more product features developed to “proof of concept” stage. You could find that some want to improve the decor in the office or have a desire to explore automation of your processes or tedious tasks. These all sound like wins to me – not just for your product but for the office and company too!
It’s about balance surely?
Maybe. You clearly have a product to deliver and there may be specific expectations or milestones to reach. However consider a shiny new future when your products are developed and directed based on the motivations or interested of your team. Valve does just that – new staff are invited to work on whatever they want! If it’s possible to see business value in what’s being developed then why restrict folk to the work that has been predetermined?
A lot of this builds upon the cross functional team concept where a small team could have complete autonomy to deliver the future of their area of the overall product. Does this fly in the face of planning and delivery? I don’t think so – provided your teams are accountable for delivering value what more could you ask for?
You can’t – Google has them. Strike that – I have them 😉
Clearly I’m joking, but only to a point. Surely every company should be striving to get the best engineers. And they all can!
Who is your ideal engineer?
That’s the big question. If you can define what the ideal team member looks like for you then you can both recruit with better focus and also aim to get the very best of this specific sub-group of engineer. But not at the cost of diversity! Make sure that your definition is clear enough in terms of approach, experience or enthusiasm but do not artificially reduce the different backgrounds these people may come from. The variety of individuals on a team should be considered a strength and will create a higher quality, better thought out product in the long term.
I strongly disagree with the “checkbox approach” that many recruiters use – I.e. 5 years experience in tech X, expert in method Y. It’s important to consider how each new recruit will adapt to your team – enthusiasm and keenness to learn rate far higher in my estimation. After all you want to bring people on to be part of the journey forward not just to bring their skills and apply them to your domain.
Be honest in your recruitment
It may not be comfortable but it’s important to share the lows as well as the highs of the job they will do. You won’t be doing anyone any favors if you sign up a new member of staff and in the first week they realize it was not the job they thought they were applying for. This goes for the highs as well – only advertise and discuss opportunities that are real – do not dangle freedom, responsibilities or pay progression that you cannot truly expect to provide.
Know what defines an engineer in your organization and what you can provide for them. Consider the opportunities and also the challenges. Be open and honest about it.
Remember that “A” people hire other “A” people whereas “B”s tend to hire “C”s. Always be hiring people that are smarter than you – after all they will be doing the real work 😉
One of the questions I get asked most often is how to stay up to date with everything in the fast moving world of software and technology. You know what, it’s not going to be possible to know the ins and outs of the coolest framework in every language. It’s also long past the time when you could know all the various support tools that your team might benefit from using.
Let go of the concept of knowing everything and trust instead that your team, who are working on the actual software development day to day, know the details of the technologies needed to get the job done. Instead focus on a higher level – are there ways the team could be working better together, is communication clear, are people learning a wide range of skills. Where you see opportunity to help improve something then by all means investigate options for the software / tool / platform that might help – but don’t go to your team with solutions, help them to see the opportunity to improve and work with them to get the right solution.
Remember that your team is full of smart individuals at the top of their game (if not then there’s another question to look at) and they have either already seen the problem but not had time to address it, or are going to be much more interested in a solution that they were part of finding rather than one you brought to the table!