Human first — Welcoming new software engineers at Kiron
Kiron provides free online academic and professional learning opportunities for refugees and underserved communities worldwide, and we’re tackling some of the biggest issues in digital education and digital equality — All within the budget constraints that come with life at an NGO. You better believe that we want new team-mates to hit the ground running. But our culture is not just about results…
We want our new team-mates to be effective as soon as possible, and to love working here. To that end, we have revisited and revised our on-boarding steps for software engineering Kironistas.
We have made a checklist (short, forkable, on Github) for tasks to have finished by the end of your first day, first week and first month. At the end of one month, you can go over this list with your department lead and make changes to it for the next person. It’s not overly complex or ambitious, because we simply don’t need it to be… It’s just what we think is the best way to say hello to a new team: Human first.
Here’s how we built it, in four easy steps…
- Start with people and principles.
Lots is written about an engineer’s first day at a company, how to get her/him to commit to the master branch by the end of the first day, etc, etc... and yeah, this is in our new on-boarding, a little bit — We want a new developer to feel happy and all-set-up at the end of day one, but more important to us is an introduction to our company mission and principles.
For most new Kironistas, this will have started with their very first interaction with Kiron— probably a phone/hangouts interview, where we discuss how we work and our culture. It continues before they begin, when they receive a useful employee handbook and then, on their first day, an introduction to Kiron, our products and to the entire office from our fantastic People team.
Sure, there’s a new laptop for you, and maybe a Kiron sticker if you really want to cover up that fruit on the back of it, but there’s no neatly-packaged company swag with ill-fitting t-shirt or branded water bottle waiting at your new desk. Just some other humans, and maybe a few people-in-the-computer working remotely, who want to help you feel welcome. And hopefully someone will warn you about all the hugs. There is a lot of hugging at Kiron.
We are an ambitious and fast-moving young organization, but it’s more important to us that a new teammate knows to join the #shoutout-kironista colleague appreciation slack channel than knows the intricacies of our Kubernetes cluster or our GraphQL schema. That will all come later... First, we eat lunch.
2. Immersion in the tech and in the product.
Hopefully this is somewhat obvious: Getting to know our tech stack is an important step to becoming useful and effective as an engineer at Kiron. But, getting to know what other teams are working on (and crucially, why) is also a critical part of being an engineer here. Join stand-ups, join the company sprint review, present at the company sprint review, meet a student or two. This will get you in on what’s happening broadly and quickly.
A lot of our architecture is geared towards not only both speed of development but hireability and learnability — so we use many technologies that have strong support, strong user bases and enable a modern development and deployment strategy. Our stack is typically React + GraphQL + Postgres, with a strong sprinkling of Laravel PHP for some of our internal tools — All technologies that are widely used, all of which have great developer support and an active community, and all of which our prospective hires will have a high chance of being exposed to before (not that it is an absolute requirement for the job).
We don’t have any rigidly mandated development setup because 1) we haven’t needed one so far and 2) we trust you to get this right with your colleagues. We have approaches we like — standardized deployment pipelines, static code analysis, type checking, Cypress tests, and unit tests, plus a sensible default for a lot of things (e.g. “code goes in a git repo”) are all in place but there’s no one approach that you must take, just like there’s no one IDE that you simply must use. Some approaches may be better than others, and longer-serving or more senior engineers will be around to guide you and give feedback on your work as you go. We make sure that a new engineer is checking in regularly with one of the “oldies” of the Kiron tech team, but this is more to get feedback and improvements from fresh eyes than it is to force engineers into one shape or size.
If I have seen further it is by standing on the shoulders of giants — Isaac Newton
For similar reasons, by building on top of broadly used, open source technologies and countless open libraries from tech giants like Facebook and Google, we make sure that as much of our attention as possible can be zeroed-in on those problems unique to our students and to our products. React, GraphQL and Laravel may or may not be something that you’ve been exposed to in the past, but you should take whatever work time is needed (as should all of us) to get up to speed and then stay at speed so we can keep building on top of these tools. Any sprint should include a flexible little chunk of this time to help you, and you might need more at first than you will later.
3. Foster a user-focus obsession.
One of the perils of working in a NGO providing a service to refugees and disadvantaged people is that the people giving us money and the people who use our service are not the same group.
Yes, partners and funders want us to have a positive impact, and our goals are often aligned (btw, that’s why we love working with partners — They provide us and our students with opportunities that fit our mission and that wouldn’t otherwise exist), but we don’t have quite the same immediate existential imperative on finding the right audience with the right product as, say, a social-media startup does.
Given this fact, and given that one of our core principles is to be student focused (our version of user focus), how do we foster that? For us, this begins with constant reminders while we work: All of our four different product development teams answer these questions for every piece of work they do — How does this benefit our students? Does it move the needle for them?
Regular, extensive user testing with our fantastically helpful and open student-base along with information radiators placed around the office let us know if our work actually does move the needle. It’s addictive: Once one person starts obsessing over a number they want to see rising, it’s not long until the whole team is. This approach has enabled us to double the number of our students over the past few months, and double our student retention over the last year.
Product Owners ask and answer these questions of each other regularly too, and involve and include new and existing engineers alike in roadmap discussions to further embed new Kironistas not only in the product but also in the why of our work — Student impact.
Finally, everyone’s gotta do a bit of customer support. If Bezos does it, so can you.
4. Create an environment for growth
Under the codename of Project Aristotle, Google spent several years conducting research into what makes a successful team. The number one factor they found: Psychological safety. A team that can take risks and fail, whose members can share new ideas without fear of ridicule and where anyone can safely make new suggestions is already taking the first step to success.
At Kiron, we want exactly these types of teams to form, and it all starts during your on-boarding. There is no better time to ask a stupid question, to make a mistake or to simply just get lost than in your first few weeks of any new endeavour, and we want you to do all of those things multiple times in your first few weeks at Kiron (Making a mistake isn’t on the checklist explicitly, mainly because you won’t just be making mistakes in your first month!).
And how do we encourage this, exactly? First, attend your team retros to share your insights on how things have started, join the monthly Engineering community meeting, where everyone gets an equal voice in what we collectively use our 10% time to do — A side project, technical debt work, learning, whatever. Your opinion is just as valid as an engineer who’s been here for years. Finally, take part in our semi-regular “Open Monday” sessions where you can learn from others, or even do some Mob Programming: Joining a team of non-engineers to try and finish some quick short tasks but without the benefit of everyone knowing exactly what they’re doing. It’s fun, and it can bring out something in you that you didn’t know was there… A teacher!
The end
So after all that, what’s left to do? Well, you should give the next newbie the same human gesture someone gave to you: Improve the checklist and look forward to welcoming new team-members with the same warmth that you received when you started.
Thanks for reading, improvements to any of the points in our checklist are welcome in the form of pull requests and issue reports.
All the illustrations in this post are from my excellent colleague, Enrique Medarde
If you’re interested in joining our team and trying out our new engineering on-boarding checklist, take a look at our open positions.
And finally, if you want to know more about Kiron and support our mission, please visit us and sign up for the newsletter.
