The University of Trike
Aug 31, 2016
At TrikeApps, we value growth mindset and a desire for continuous individual improvement in our staff above most other personality traits. As a part of our commitment to investing in our people, we built the “University of Trike” - a repository of structured knowledge in the form of courses, to provide learning paths and a skills directory.
The lightbulb moment came after recognising three problems we needed to solve.
Problem 1: Time allocated to personal development isn’t used properly unless there’s a framework.
Our crew can allocate up to one day a week on personal/professional development. But we found that just giving them the time was not enough to see them use it; some people felt uncomfortable taking it when there was delivery pressure (when isn’t there delivery pressure?) and others just didn’t know what to do with it. It wasn’t obvious that worthwhile projects were being undertaken and the expected outcome of projects was not well-communicated. Two developers wanting to brush up on Elixir, for example, might be unaware that they could be working together to attempt something more complex and leverage the other’s experience.
Problem 2: An intranet can become a graveyard for content and ideas if not nurtured properly
TrikeApps had a tremendous team wiki, but it started to resemble a place where great ideas went to die — reams of pages for software development best practices, checklists and brain dumps. While you could generally discover it via the search function, learning what was and wasn’t there — particularly for new staff members — was daunting. It quickly began to age as pages became the domain of subject matter experts who no longer had the time or inclination to update them.
Problem 3: Talented people will be underutilized if few people understand the skillsets available
The Trike team had a wealth of different skills that were invisible to others, causing duplication of learning effort in particular technologies and programming paradigms. Finding the best person to consult with on a particular type of problem was a trial-and-error process.
The makings of a solution
I listen to audiobooks on my daily commute and I was listening to the writeups of the annual EDGE questions — specifically This Idea Must Die: Scientific Theories That Are Blocking Progress. An author named Brian Christian had submitted a piece called Scientific knowledge structured as “literature”.
Christian posits that a decentralised revision control system like Git would be superior to scientific journals as a repository of scientific knowledge. Christian argues that publication of this knowledge on GitHub, allowing anyone to contribute, would make scientific papers “living documents, open not only for scrutiny, censure and approbation, but for modification.”
This encapsulated the benefit of Trike’s continued use of the wiki, but it got me thinking: Git is a tool that our developers use every day to curate content, in whatever structure a normal file system can support.
What does a useful knowledge structure look like?
Firstly, it needs to organise the course material (topics for learning). Secondly, to identify sensible pathways through the courses (how the learnings will help you progress through the organisation). Thirdly to organise coursework submissions (proof of learning). And finally, to recognise course completion through awards (where you’ll discover who knows what).
Where are we now?
At the time of writing, the University of Trike Git repository houses 48 courses in all manner of soft (e.g. organisational skills, communication skills) and technical skills (e.g. Ruby, Rails, Haskell). We continue to add courses almost every week as people explore or improve their knowledge of topics. Trikelings have earned 110 badges and have these displayed proudly on their Honour Board. We’ve identified study pathways for each role in our organisation, including new starters, and we monitor the team’s progress along those pathways. Staff from our sister companies have asked for access so we added some entry points for those outside the technical sphere (an introduction to Git, for example).
We have plans to grow the university. Sure, it’s not perfect and the format has received mixed reviews. But the shared vocabulary has provided invaluable improvements to our communication; the codification of knowledge levels helps us easily see what each level actually represents; and hearing statements such as, “it sounds like you’re having the same problems Joe was having, and Organisational Skills 101 helped him a lot” or “if you want to see a good example of refactoring, go through Jack’s submission to Refactoring 101 commit-by-commit” suggests we’re doing something right.