In my perfect world getting started would be easy.
Looking back at some of the things I’ve done it seems that getting started was never the problem. Picking up a new sport isn’t really hard, and even in the worst case (snowboarding anyone?) it usually gets much better in a few days. Picking up an instrument isn’t too hard either, at least the ones I’ve tried, and getting to a basic level of competency doesn’t take that much time and effort.
But there’s one thing I still found hard every single time I attempted it – settling into a new job. The challenges most new-hires face, regardless of the specifics of the role, are completely predictable. They often include a feeling of being lost, no clear notion of purpose or expectations, and a general diminishing of self worth. Simply put, even the most experienced and competent veterans deteriorate to feeling like complete noobs.
Why does that happen all too often? Why don’t on-boarding plans and boot-camps help alleviate these feelings?
An interesting parallel to the new job experience is playing a video-game for the first time. The problem of engaging a new player, much like engaging a new-hire, is about the speed by which they get to feel comfortable in their new skin. Research shows that getting a new player to feel engaged within the first few minutes of play is one of the top predictors of video game rating and sales. So understanding player engagement become a very important thing for game designers.
In 2006 Scott Rigby and Richard Ryan, founders of Immersyve, published the Players Experience Need Satisfaction model. The PENS model describes and measures player experience along three distinct axes – competence, autonomy, and relatedness. Their research has shown that high marks on these three categories strongly correlated with sustained player engagement. They demonstrated that game designers can create player engagement by creating an environment where players felt capable, were able to make meaningful choices, and were given an opportunity to positively interact with other actors.
Now, let’s consider what that means in the professional environment of the modern knowledge organization. When a new-hire joins the organization we would need to make them feel competent – able to do their job well on day-one, autonomous – make decisions about what they should be doing and how they should go about doing it, and relate to the people around them – have meaningful and symmetrical relationships with colleagues. That doesn’t sound very hard but when you come to think about it, most organizations do the exact opposite. Too often new hires feel crippled by the need to learn a lot of new systems, tools, and processes before they can express the skills and capabilities they were hired for. Their first few weeks are typically pre-planned for them or they get assigned an endless stream of small meaningless tasks, such as bug fixing, that supposedly help them get to know the systems, tools, and processes they need to do “real” work. And their relationships with their peers initially boil down to begging others to help them figure out even the most basic of things.
In my perfect world getting started would feel completely different.
New-hires would arrive to find a working machine on their desk, pre-loaded with a quick, well planned, bullet-proof tutorial on the development environment. They should be able to create a new service/application from scratch and get it built, tested and deployed to the production environment during the first hour on the job. This requires competent IT and dev-tools people to create and maintain a working, consistent, and lightly documented development, test, and build environments. Regardless of bringing in new-hires, this is something every sane organization should invest heavily in. Every glitch and waste in the environment is multiplied by the number of engineers in the organization. In almost every conceivable case all such issues are cheaper to fix than they are not to fix.
After those first hour or two, the new hires get presented with the long wish-list every engineering team has. All those features, tools, and research projects that never seem to float to the top of the priority list but that every engineer really wants to see done. This list should not contain bugs – only things that have measurable incremental value either to the customers or to the developers or both. The new-hires choose one or two items from the list (or make up their own if they already have an idea) and go off to build them over the next couple of days. Similar process can be followed for non coders, looking at items like data analysis, market research, product definition, or usability studies. Whatever the case may be, the new hire should decide and execute their decision to create real impact within the first few days on their new role.
Once basic competence and autonomy have been demonstrated and established, the new-hire should be paired with another team member engaged at some high-value activity such as creating new designs, implementing a significant piece of software, or testing a new product concept. Whatever the task is, the new hire is put in a position to quickly become an authority on some meaningful aspect of the team’s activity and start creating symmetric relationships with their peers. The same can be achieved for people in management positions who should be paired on tasks their team members are doing which they are also able to accomplish (hopefully, there are at least a few of these).
Following these steps, a new-hire can experience competency, autonomy, and relatedness within the first few days of their new job, helping engage them and get them immersed in the new environment, and thus significantly shorten the ramp up curve that plagues knowledge-workers, without trying to turn such roles into overly documented and process-driven jobs.
But that may only work in my perfect world.