Learning for Learnings sake
Learning at Work
My pathway into software development was unconventional. At college I studied Maths, Physics, Chemistry, and Biology. I dropped out of a theoretical physics degree and tried to make it as a pro basketball player. I started building android apps as a hobby. I enjoyed building things and problem solving. It was fun and satisfying to push my creations out into the world, then see that strangers were finding them useful.
To go from messing about with my own projects to working professionally as a developer was a very steep learning curve. And I did that learning on the job. I was learning so much and was so fuelled by the motivation of my expanding skills. The money wasn't great, the company cultures were often terrible, toxic even, and the products I was building were entirely uninspiring. None of that mattered to me because I loved the feeling of growing and learning.
The importance of acquiring new skills never diminished to me. As my career progressed into a leadership role, I have always pushed to make that a part of working culture. Always attempting to encourage and facilitate learning opportunities for myself and my colleagues wherever I can.
Code Breaks at Naveo Commerce
How it works
I am currently the Head of Development at Naveo Commerce and one of the initiatives that I am most proud to be part of is our code breaks.
The concept is simple: a code break gives every team member X number of working hours carte blanch to work on whatever they want to work on, individually or teaming up with others. It doesn't have to be related to our product or our tech stack. It doesn't have to lead to usable output.
In fact, the only requirement is that each project should give a short presentation of what they did and what they learned. Our code breaks allocate 2 days per person during the final 2 weeks of our regular 8 week cadence, with the presentations taking place in the following week.
How it started
We have arrived at this point after many iterations and tweaks to the concept, with numerous successes and failures along the way. Back in 2019 our inaugural code break was confined to a set time block. Pitches on a Monday; work to be completed on the Tuesday, and Presentations on the Wednesday.
Each pitch had to be accompanied by a benefit statement for how it would be of use to the company. In this first attempt we got some good results. Participants enjoyed the exercise; we achieved some good R&D work, and it even led to a product feature being green lit. So why did we change the formula?
For one, the participation level was lower than we would like, feedback suggested the time constraint was a big factor in this. People with approaching go-lives or heavy workloads on that particular Tuesday didn't feel able to join in.
Another cause for tinkering was that people wished to participate in multiple projects but couldn't do so if they were concurrent. The biggest thing I wanted to change was to remove the benefit statement. My position is this.
Being forced to define the benefit upfront kills off projects before they even start.
How its going
In our more recent code breaks we had several ideas that were explicitly connected to our product and domain. We also had ideas that were purely a fun exploration of an interesting technology.
One project was making use of a voice recognition library to input search terms. In the presentation the developer owning the project was able to demo a functioning application, correctly interpreting his speech.
Later, we had a discussion in the product management team about how our products might be able to use voice recognition in a completely unrelated context to search.
The developer who pitched the code break idea was then a participant in the scoping of that new product feature. They took ownership of the development of that functionality into the product, which is satisfying and energising for everyone involved. It really rings home the value of these kind of initiatives. If you would like to hear more about this, we will be hosting a webinar on development with voice input & output. You can sign up here
领英推荐
Cross Training
Code Breaks are a relatively easy sell. The cost is minimal; the benefits are apparent, and demonstrable in fairly short order. Cross training requires at least two employees with a reduced capacity for their normal workload for an extended amount of time. The "payoff" for the company can take a significant amount of time to materialise. Despite this, I am a staunch advocate for cross training subject to it being the right match.
So, what makes a good match?
One example that I have seen over and over is for UX/UI designers cross training in UI code. It is a logical progression that can improve collaboration between design and development.
Rather than developers trying to duplicate a high fidelity mock up into code, a designer can create the UI code while a developer wires it up to actually function. Obviously, this may not be an improvement to the team if the designer has no interest in learning code or if the developers in the team really love coding UIs and would be disappointed to give it up. This leads us to the next point
I have often seen cross training fail because either the trainer or the trainee has no real interest and is forced into it because of circumstances in the business. If you have an employee whose role is becoming redundant, you won't retain them by forcing them to learn a new job that they don't want to do. It needs to be a joint effort to find a direction that the employee will be motivated to do. For the trainer, they need to enjoy teaching and coaching, we can all remember that school-teacher who seemed to hate teaching. How much did you actually get out of their lessons?
The worst example I can recall witnessing was a company who decided to axe all marketing, then expected the marketing assistant to transition to work as the financial assistant within a month. Insane. Learning a new skill to a professional level takes time. Companies need to acknowledge that when they go down the cross-training course.
Why we Love Learning
In writing this article I spent a small amount of time researching why we - as humans - enjoy learning. I won't go into a huge amount of detail because I don't have the expertise, but I will mention the concept that I found most fascinating. Neoteny.
The phenomenon of adults in a species retaining the curiosity found in juveniles.
In most animal species, adults lose the genetically driven desire to learn more. In some animals, most notably humans, this is not the case. This, in part, explains why last year I was just as excited to learn to ski in my twenties as my two- & three-year-old children were.
We have the phrase "child-like wonder", but as it turns out human wonder persists through adulthood too.
Better Approach
As well as my role at Naveo, I am a cofounder of Better Goals, where promoting learning for the sake of learning is a key part of our ideology.
We build an application that is primarily built for use by product development teams to set and achieve their goals. An important aspect of this is the functionality to match work needing to be done with the people in a team or company with the relevant skills to perform that work.
We have incorporated cross training into the Better App mechanism. In addition to matching already skilled individuals to work, the app will also match people
interested in learning or developing skills to those who can coach them. Plus, the opportunities to practice skills within the goals of a company.
This approach enables companies to cross train in a way where progress is visible, giving management reassurance and giving employees the encouragement and positive reinforcement, they need to persevere.
If you are interested to hear more about Better and what we do, then please reach out to me directly or through our website bettergoals.io