Building a Learning Organisation

Question from a Product Engineering leader at a fast growing start up

How do you provide learning and growth for engineers in the absence of a solid technical leader in the org?

First of all, congratulations on asking the question. This is a step many never take and the fact that it’s a question for you means the growth of the team is assured. Now on to specifics.

Let’s be clear about the crux of the issue - you will pay the price for learning whether you choose to or not. Systems are complex and entropy is relentless - understanding how they work and how they fail takes effort. There’s no free lunch here. However, some lunches are cheaper than others. So what are they and where does one find them?

The cheapest lunch of all is to embrace learning as part of the job and allocate time and resources for it - consciously. Learning is one of the highest RoI activity young engineers can do AND it compounds. Given the leverage that tech provides, the difference can be the difference between incredible success and total failure. What does this mean?

It means that not all learning is ‘on the job’ learning. Yes, engineers learn a lot on the job but they’ll get stuck if that’s all they do. The temptation to put learnings into production or align them with business needs is strong. All the ‘Lean’ series of books say just one thing - learning is a business need all on its own, not subordinate to ‘features’.  

So how to operationalize this?

In any organisation there is a ‘way’ in which work happens. So the operating principle here is to stick your learning outcomes into the same process that ensures product and business outcomes. This varies from org to org but can largely be summarised as ‘budgets’ and ‘accountability’

Allocate Budgets

Money Budgets - Nothing happens in any org without a budget. And if something has a budget it signals that it’s a priority for the org. So have a Learning and Development (L&D) budget. At @shaadiTech we have a budget that you can spend on whatever you want, no questions asked. Reduce the friction here as much as possible (no approvals required below the budget) and follow up on whether it’s being utilised. If it’s not being used, ask questions. I am yet to see anyone abuse this policy. We also have a librarian who curates these resources so they’re easy to find, avoids duplication etc.

Time Budgets - As they say, “Management require rigor. Leadership requires jigar (heart. Well, technically liver, but it’s meant as heart is in English)”. So have the jigar to push timelines back to accommodate learning. You will find instead that timelines stay pretty much where they are and successes are more. A seasoned team growing in learning pays for itself many times over. (Remind me to tell you the story of how we started doing TDD at @shaadiTech)

Allow Learning to Happen

Architect for Freedom - The single biggest impediment to learning on the job is restrictions on how one does things. So where possible, architect the system for high cohesion and loose coupling. This means separate subsystems can be used and swapped out with better ones, leaving engineers free to experiment.

True Story - One of the recent big engineering wins here involved plugging in DynamoDB into a system because after studying dozen odd data stores it was found to have the precise feature set that would reduce overall system complexity by an order of magnitude. All of this was possible because of the underlying system architecture.

(Remind me tell you the story of how we ended up with the only known server-side Swift API in production)

Go on, Bleed a Little - Everyone knows about the bleeding edge of Tech. What is often overlooked is that Tech has two bleeding edges - the leading edge and the lagging edge. You only get to choose which one you bleed on.

An organisation that doesn’t prioritize learning not only manifests in arrested development of engineers but also in a system that is running End-of-Life versions of your stack because ‘shipping user value’ is the only priority.

Build a Learning Culture

Learning Culture? What’s that? A Learning Culture is one which takes it for granted that learning is to happen and consciously provides the conditions and encouragement for it.

We’ve already talked about how to signal that learning is a priority for the org leadership - budgets (time and money). Publicise them widely, curate the learning resources well and ask questions when the budgets aren’t spent. But there’s a lot more that you can do. A little bit of seriousness can make all the difference .

Operationalise a library, with librarian - Commandeer some admin resource to be the librarian. Most learning resources are now digital, especially during lockdown. Have one place where they can be found. Make space for bookshelves in the office (whenever that happens next)

Maintain a ‘Suggested Reading’ and ‘Required Reading’ List - Here’s an awesome starting point from GoJek Tech.

True Story - I once printed out several dozen copies of ‘Out of the Tar Pit’ and ‘No Silver Bullet’ and left them on each engineer’s desk. Random pop quizzes followed. Most engineers ended up reading part of it. One senior engineer dived deep into these papers, took extensive notes and emerged on the other side a completely different engineer. And since he was senior the sweetness of that learning spread through his teams. One hit is sometimes all one needs.

Share the Joy - At @ShaadiTech we have a weekly check-in called “What Are You Reading These Days And What Can we Learn From It?” Some excerpts -

As you can see, these are not necessarily engineering books. That’s perfectly ok. We’re after holistic development.

Maintain an Internal Blog - Nothing crystallises learning as much as writing. It allows one to take a distanced and abstracted view of what one has been working on and makes concrete ideas that one is carrying around in one’s head. At @ShaadiTech we operate the blog on the principle that this is for the primary edification of the writer. Any benefit to any reader is a bonus. Any blogs that make it to https://tech.shaadi.com are doubly so.

Spread the Learning - One of the big problems in any organisation is ensuring everyone’s running an updated model of the org and system in their heads. There’s little point building cool stuff if it never gets used by the rest of the organisation. To solve for this we have monthly Demo Days at @ShaadiTech. This is where engineers get to show off the cool stuff they’ve built. This works great for engineers who are usually shy about publicity - it gets them in front of the organisation in an environment they’re comfortable in, it inspires other engineers to do cool things and it spreads the learning through the org.

BYOT - BYOT is short for “Bring Your Own Talk”. It’s a communal viewing of a tech conference talk followed by a discussion. The format is very specific

• the price of entry to the event is a suggested tech talk. This means that you can’t get in unless you watch talks already and have a good one to share.
• Once everyone’s proposals are in, everyone votes on which talks they’d like to see in the allotted time.
• Watch the talks.
• Discuss.
• ….
• Profit?
  

This works better in smaller orgs and team specific because what the Data Engineering Team finds interesting may not interest the Android team.

TL;DR

To come back to the original question - yes it’s very very much better to have an experienced leader and mentor to accelerate learning outcomes for an engineering team. However, building a learning organisation is not hard and very valuable. Engineers are in the job for the dopamine hit of learning. Your job as their manager is simply to allow the space, time and money for this to take place.