How our Engineering team work as a Learning Organization
Sounds probably like a buzz word — but that does pretty much capture an essential attribute for an Engineering team nowadays.
Great teams has a core philosophy of continual improvement — Mark Roberge
It’s not just about how to learn as individual.
It’s about how to learn most effectively as a team, acquire knowledge that are most relevant to upcoming challenges, from past experience; inside or outside.
Work Rules, the book on management in Google, has a dedicated chapter on it which inspired many concepts below. Facing this challenge everyday, I would like to share:
- What’s the challenge
- Deep dive into What we believe
- How we do it
What’s the challenge
Often, individuals in your team are great self-learner. It’s somehow a confirmation bias, since otherwise one can hardly work as a startup engineer.
I’m proud to tell you our members are extremely eager to learn. Not to mention like many good engineers they are always interested to deep dive in technologies, keep up with latest trend, hack stuff, consume and share lots of articles everyday. More cool is they formed study groups by themselves and watch tech videos together during lunch. We got really good books on the table which unlike those under the monitor in my home, they are indeed popular among our engineers.
Having curious and self-driven individuals is for sure the most vital factor for a team to learn. Meanwhile, it’s not enough.
Learn as a team
There could be expertise the team need to learn but no one is focusing. Lessons from past sprints could lapse away easily and mistakes be repeated if retrospective is not done properly. Or members might be fixing the same bug twice.
Some people say knowledge creation often happen in network, when people work together. Modern software development is highly diversified, who is most likely to work on domain X with stack Y for the problem Z? Your teammate. You need to take the opportunities to make the whole greater than the sum.
It’s different for every team. We are a 4-pizza startup engineering team so big Bootcamp like those in Facebook or Google just won’t work for us. We also can’t adapt the same culture of those research arms in giants like Disney or Twitter, which publish really good paper including how to simulate the uniform of a running police.
However, we are much inclined to Holacracy where engineers are able to identify priorities and solve the new challenges coming up everyday themselves, which might not be true in larger firms. On top of that we have a philosophy on self-improving which empowers ourselves to move quick and absorb knowledge from others.
What we believe
Here I’d like to illustrate some principles I share with my colleagues, which are in my opinion more important than the tactics.
- Passion is key
- It’s about Process
- Build expertise Inside the team
- Maximize the diffusion rate
- Be Measurable
- Know the unknown unknowns
Passion is key
We believe people learn best when they are passionately interested. That interest is often driven by craftsmanship and need, probably from problems faced or recurring patterns found at work.
Personally I read lots of “Peopleware” books, because I find understanding the social side of project teams is crucial to build any great software. However I can’t force engineers who are focusing on deep learning or how-to-build-the-best-payment-box-ux to read those books. Everyone has different priority and perspective.
Also, in today’s workplace you need to put yourself into employees’ shoes. Every member has their own career plan so the point is to understand them and see how could the employee and company grow together. If one is interested to grow in, such as Mobile apps specialization, try your best to provide that learning opportunity.
It’s about Process
As mentioned, at modern work especially those in startup, there is new challenges everyday. You can’t host a big bootcamp then expect member to become a Pro without the need of keeping up. The team needs a process for continuous improvement — which if you consider learning as an investment, it’s the monthly saving plan that generates compound interest.
More importantly, we are often overwhelmed by daily work or urgent deadlines and set aside learning even though they could be a better investment. It is indispensable to enable everyone to learn at work and form habits to do so. Process breaks procrastinations.
Furthermore, it’s often the action items that matters after you learn, which is hard to track without a process.
Building expertise inside the team
Work rules mentioned the best trainer is often inside the team. He/She understands the specific job challenge and the domain best; able to give constant feedbacks with real-life examples and diffuse the knowledge across the team.
Part of it is about hiring such best talent and expertise. There is however an important note — It’s not about hiring the most experienced. For us, we look for people with potential to grow on different expertise. We have members from knowing no-Scala-at-all to being an expert in the team. I myself did only very basic map-reduce application before, while now I am building out an end-to-end Spark-based data analysis pipeline. For sure we understand there are many more brilliant experts out there , but in early stage startups Potential often works better.
Maximize the diffusion rate
Then, right expertise are not enough. You will need to take extra efforts to ensure learning happens.
We won’t be able to have members hosting different classes like G2G at Google, which makes more sense with certain scale. However, we do have members leading study groups or sharing frequently at particular topics.
Some people teach better when writing. Some are best at giving talks or face to face peer code reviews. Which works also depends on your team’s culture. What’s critical here is to enable these learning mechanisms, such that your experts can ride on them. Some other approaches include naming Guru/Champion as an advisor on expertise. Think Scrum master. Web Performance evangelist. Ensure members reach out to him, also the other way round, on those matters.
The other side on this, is to encourage members Thinking out loud. A highly transparent culture is definitely beneficial to learning. We always encourage sharing of the problem you are facing, your constraints and approaches taken, and do so early. Others seeing that can often provide valuable input like suggestions on libraries to use or design patterns related. The blog post you are reading now, is one of the way we try to learn.
The great scientific management book, First: break all rules, recognize defining the right outcome as one of the keys to improve employee performance. Same applies for learning.
After all, quantifying learning at workplace is much more complicated than at University. There is no GPA. (which is GREAT and free up people for real stuff) Are all these effort effective? Are those learnings align with business objective? According to Work Rules the most useful way to approach this problem is to measure by behaviour change.
There is an extremely well example in Hubspot. They created a training curriculum for their newly join sales, which makes the process not only systematic but measurable. There is both quantitative and qualitative review after the training, including an examination and a sales role-play.
Six months later the trainee got a chance to evaluate which part of training is most helpful at work, so the team can fine tune what to be included. The data on training performance is also used to correlate with actual work performance and hiring heuristics, to iterate the process.
Yet an even bigger advantage for being measurable. You can set up proper experiment with measurements and the result is visible to everyone. One thing struck me in the Hubspot book Sales Acceleration Formula is their showcase in using experiment to drive changes in organization culture. Instead of old-school “kick off” with lots of trainings and tedious talks by managers, their new sales framework learnings are being adopted organically by employees outside the experiment even before it’s official, simply because the results are obvious.
Knowing the unknown unknown
We engineers are familiar with the word deprecated. Technologies obsolete quick. One job satisfaction of being a software developer is you are continuously amazed at things being done in new ways.
Once you have identified the solid problem and designed for solution, it’s often not hard to drill down to learn about the details, like going stackoverflow or code tracing.
The harder thing is, your team could be reinventing, say, a module with a competent open source counterpart, just because you are not aware of it. I had an experience spending nights on a less mature infrastructure module, then in a meet up in SF, while drinking beer I heard from the framework author they are now focusing on the new alternative and I should swap.
It’s important to learn about the possibilities. And a good thing about learning as a team is you could learn much boarder.
How we do it
- Weekly Engineering Session
- OKR (Objective and Key Results) framework
- Expertise-based Chapter
- Hacking Github as a knowledge base
- Process for continuous and timely feedback
- Share often, at right channels.
- Stay connected with the world
- Nudge for good
It’s a process — we do it every Friday. This ensure we have a chance to discuss at least the topic of top priority, and every week we learn something new.
Topics include sharing on latest stack like FalcorJS or ReactJS, 3 lessons learnt in rolling out the new module or common mistakes in Scala found in code reviews. Since it’s a meeting for everyone most are highly relevant stuff, but still with the exploratory elements in tracking potential useful stack or tools. The session is also a great opportunity to align understanding and foster us to talk in the same language.
One challenge is evaluating its effectiveness. We are planning to do the Work-Rules-way I mentioned, sending survey periodically to ask members which session is most helpful for their work, in terms of behaviour change.
OKR (Objective and Key Results)
One important part of culture in our team is we adopted Google’s Objective Key Results framework, not for official performance review but a peer-based improvement mechanism.
It’s voluntary for members to join. Everyone set his/her own objectives; we update our progress at slack every week and a retrospective session is hosted monthly.
One of my personal objectives is to deliver the data analysis pipeline processing millions of record on a particular domain. Everyone knows that so there is some peer pressure to keep me up. More importantly, I will mention challenges I am facing and how I am trying to tackle them. Then it’s often received with feedbacks and suggestions, saying e.g. Andrew Ng’s course has a chapter explaining Logistic regression very clearly and I should take a look for my analysis. Or I have used this library before and there is some sample code for your reference.
Some are higher level like what skills to grow at if I want to be a data engineer; and what objectives I have good potentials to achieve. It’s a pure peer session so we are very honest to discuss these matters.
All in all, the session is great to understand what is each other passionate at, and it’s useful to note which expertise the team is now lacking, are there someone working on it or it’s time for hiring. It fosters lots of peer learnings, like you can see members lending books to each others and followed up to talk about big ideas.
We are largely inspired by Spotify’s structure on Agile and we borrowed the concept of Chapter & Guild.
A Guild is a more organic and wide-reaching “community of interest”, a group of people that want to share knowledge, tools, code, and practices. Chapters are always local to a Tribe, while a guild usually cuts across the whole organization. Some examples are: the web technology guild, the tester guild, the agile coach guild, etc. — Scaling Agile @ Spotify
We name our groups Chapters given our size, although it functions more like the Guild mentioned above. Our examples include Ops/Architecture/Data/Front-end Chapters, which advocate best practices, host regular review and setup milestones for that across services/functions.
The key here is to break down skills into smaller areas, e.g. Modelling postgres as a temporal DB, best practices in ScalalikeJDBC etc. Each chapter keep track of them and look for best person on it. Once you do that, it is also easier to distribute the workload — the chapters create processes to encourage everyone to do their part of knowledge sharing.
One final point on chapters is they make the challenges more visible. Members in chapter can see easier how they could contribute and probably take part in roles they had less experience with, e.g. scripting to plug in new source for the data pipeline. This results in great knowledge exchange.
Hacking Github as a knowledge base
Linus famously saying “Show me the Code”. Attend to details is always important, while if the information on systems is messy and overwhelming, it defeated the purpose.
As a small team we don’t really like those gigantic knowledge-base tools, instead we use what everyone’s using already — Github. No not the wiki as it’s hard to search. Instead we hacked to use a repo’s issue tracking feature.
We have a dedicated repository named as “knowledge-base”, there we raise discussions on question or suggestion with code examples, tagging fellow engineers. Sure enough, for more complex problem we chat face-to-face, but the issue tracker is a great way to see Who has question/know-how on What. For consolidated knowledge like confirmed conventions or summary. we then commit as markdown into the repo itself.
Process for continuous and timely feedback
My colleague made a good point — if you see Lean startup, Scrum, Design Sprint, they are all about learning quick with fast feedback loop.
Many things are obvious looking backward. We host retrospectives every quarter to review if our milestones are met. These milestones are clearly quantifiable action items, with example as “Ensure all client side endpoints are HTTPS protected with the right cert”. When we found we are not able to achieve them, it could due to loss of focus or lack of expertise — we take the lesson and plan for improvement in next quarter.
Besides, we engineers all know the importance of on-the-job training. Hopefully you will agree with me that Code Review is so important. It not only improves the code being reviewed now, it improves the code being written in future — it train up the engineers. Application-specifics, conventions are often learn in this way. We also try to carry out review on overall design before a line of code is written, which is essential to align our understanding of the problem and reduce the cost of changing architecture if needed. People learn best with right feedback at right time with the right context.
Stay connected with the world
Although the story is about learning effective as a team, a crucial point is actually on how to learn outside the team. We are fortunate enough to live in a world with open source culture, where most insanely great engineering works are free for you to learn from. Also, especially in San Francisco, there are all sorts of meet ups to connect with community and you could probably host your own. (We will do that soon!)
It’s often beneficial to go (nice) meet-ups or even just watch videos together with a few colleagues. You learn more by exchanging ideas and of course it’s good for social with the beers.
Connecting to the world allow you to learn from world-class expertise. It could be hard to invite Martin Odersky to our office to talk Scala, but we could watch his brilliant lectures without hassle. It’s also important to turn on the explanatory mode — keeping up with what the world is talking lately and knowing the unknown unknowns.
As far as I know, many tech companies will sponsor members to conference, like in Twitch employees can go a gaming competition of their choice every year. These are attractive good practices. However, as an earlier stage startup we can’t guarantee everyone this opportunity since we have better priorities. Some of us do travel (We’re, proudly, Hong Kong based) for conferences but not too often.
We might missed the networking part, still, for the technical part we can easily catch up with many of them. We keep track of a list of conferences on Trello that are most relevant to us, then we mark ourselves on which that are interesting. Each member will then send out summary to the team highlighting what is important to us. By doing this we 1) suggest what is out there 2) know Who is learning What 3) consolidate most relevant knowledge.
Share often, at right channels.
We love Slack and we have lots of channels like #foodforthought for members to share inspiring articles. To be specific, we have engineering channels like #eng-backend-arch, #eng-data, #eng-ux #eng-scalalang (eng for engineering) where engineers share & talk about their interested topics. Often being shared are nice new libraries, articles on design patterns, takeaways from reading a book and so-on. Topic is key here, it ensure information flow into who are interested but not being spam.
There are also study groups for most relevant topic among members, like Scala or Domain-Driven-Design. It’s not that hard to organize, which we usually pick a classic book on the topic and go through a chapter together every week. It is however hard to be effective without a few of my colleagues’ effort to take up complex problems and explain it clearly to the team. I’m so thankful for them, as the sessions are so helpful in backing us up to go from PHP/Monolithic to Scala/Microservices.
Nudge for good
We’re lazy. Engineers in particular, my teammates said. Nudge is the behaviour science concept saying that we bias our choices unconsciously, and that could be influenced.
There are little things you can do inexpensively and easily, while they pay off a lot. We allow members to buy any books they find useful and claim expense, where we also got good physical copies at office. We provide flexible hours and encourage members to go to events they consider meaningful. We are building our event space at office so our members gain easy access to outside talents and brilliant talks.
We also have curated lists of good articles / videos by skills and group them into “difficulty levels”, similar to this in Scala. My colleague can say (in OKR): I’m done with the readings in Lvl1, doing lvl 2 next week. This is creating practical guides with sense of “Achievement unlocked”.
You can often see these simple things spark off organic discussions, say my colleague talked to me about Bounded Context when he saw me reading the Implementing DDD after lunch. What you need is often not “tricks” but carefully crafted recommendations and streamlined process to enable your members to learn and diffuse their expertise.
There’s always more to be learned
Read The Clean Coder and see the coding practices in Dojo, Kata(Ch6), think about what’s lacking in CS educations and how should we structure juniors’ learning on the craftmanship(Ch14). Or you start a book club. And many more.
Your team will need to keep learning on how to learn, together.
I hope this helps your team and it will be great to leave your comment, helping us to learn. If you want to know even more, you can join us.