by Jason Murphy, Associate Engineering Manager at Birdie

‍

If, like me, you’re a fan of 80s synth pop bangers and professional growth, then I think you’ll agree with me and The Korgis when we say “Everybody’s Got To Learn Sometime”

Here at Birdie, we understand that as knowledge workers the one aspect that underpins all of our jobs is to be continuous learners.

Over the last few months, as an Engineering Management function, we’ve put our focus on providing our early career software engineers with the best onboarding experience and support to facilitate their learning and development. I want to tell you about some of the processes and policies we’ve implemented and our approach to introducing those changes.

‍

Introducing changes to our systems

When making changes to complex adaptive systems, the Cynefin framework can guide our approach. To quote Liz Keogh’s excellent blog post about Cynefin, “Human systems, particularly, are Complex Adaptive Systems or CASs; systems in which the agents of the system (people) can change the system itself. When we want to create changes in human systems safely, we have to be careful not to make those changes too big or sweeping, because we don’t really know what will happen in any given context, even if we have some good ideas.”

‍

‍

We should take the approach of “probe, sense, and respond”.

So we needed to identify a probe for the problem under consideration.

We work in a high-paced industry and profession where a lot is expected of us and when we’re in the early stages of our careers that can sometimes be overwhelming. Having spoken with our Intern and Associate Engineers, one thing that became immediately apparent was a desire for structure and time.

Having identified what to probe, we identified some actions to take. We went about designing some processes and policies that would address those needs. We broke them down into three categories:

‍

• Explicitness
• Resources
• Deliberate learning and practice

‍

‍

Explicitness

We tried to create some policies that would help early career engineers, and new joiners specifically, with their start to life at Birdie. Some of these suggestions may seem basic, but they were gaps that people were reporting they found themselves in. The main idea is to take as much responsibility off of the new Birdie as possible, so we create tailored onboarding plans for each person so they know what to do over the first weeks of their onboarding and what is expected of them. We also want to put the responsibility on each member of the team to reach out to the new joiner to make sure that lots of pair programming or ensemble programming happens hopefully reducing the “awkwardness factor” a new person experiences.

‍

‍

Resources

We know that the amount of topics and technologies that full stack software engineers in cross functional teams need to know is vast.

• Backend and frontend tools and technologies
• Ops, deployment, monitoring, and alerting tools
• Software engineering concepts such as Test Driven Development, Event Sourcing, Domain Driven Design to name but a few
• Company specific tooling and processes

Where to find good quality information for all of these topics isn’t always obvious. We’ve attempted to tackle this issue by having a collection of all the relevant topics for an engineer at Birdie, and within those topics having curated resources (online courses, videos, blog posts, books).

We also signpost people within the company who are experts in particular topics so that anyone can ask them questions or set up some focussed mentoring sessions.

As well as this curated library of topics and resources, we also have company subscriptions for some learning platforms where people can do short, focused courses on anything they are currently working on, or would like to expand into.

‍

‍

Deliberate learning and practice

Being deliberate about how you go about learning and practicing something is very important.

Imagine you’re learning how to play your favourite song on the piano and you know that the chord progression is C#m7, A#m7, A6, C#m7, G#7, F#m9, B9, B7 (we all know what your favourite song is of course). While playing, you always make a slight mistake when moving from C#m7 to G#7. The approach you’ve decided to take to learn the song is to always play the full progression from start to finish. And now you practice. And practice. And practice. You put hours and hours of practice in. Your dedication cannot be questioned. You make the same mistake on the transition from C#m7 to G#7 most of the time. And after all those hours, you’ve completely internalised the mistake you always make when moving from C#m7 to G#7.

If you do lots of practice on something but in a non optimal way then that’s the way that you will continue to do it, mistakes included.

A better way of approaching this is to focus on what you’re trying to learn and achieve. Since the most immediate issue you have is the transition between C#m7 to G#7, taking 5 or 10 minutes every day just moving from C#m7 to G#7, again and again, is what you should be practicing.

It can sometimes be boring and feel like you’re not playing a song (which of course you’re not). You make mistakes but you correct them in the moment and practice what you’ve learned. You sometimes feel like you’re getting nowhere.

After a week or so, you find that you don’t make that mistake anymore and have built up the skills and muscle memory to nail that transition and when you play the extended progression you don’t make that mistake anymore! You’ve got to where you wanted to be, and in actuality in a much shorter timescale than by just trying to play the whole song again and again.

This principle of deliberate practice extends to any field: identify what you want to learn, zoom in on it, practice that, include it in your wider context.

Finding ways to nurture this approach within Birdie was the final piece of our initial initiative to support the learning and development of our early career engineers and we’ve approached it in two ways.

‍

We’ve started a weekly “code club”

We get together and deliberately practice some aspect of software engineering.

At the moment we’re practicing Test Driven Development. We take a coding kata and we practice the TDD approach

• Red (add a failing test case)
• Green (make it pass in the simplest way possible — this is like moving from C#m7 to G#7 again and again — it can sometimes feel weird and forced)
• Refactor (look for opportunities to “make it better”)

We’ll continue practicing this for however long is appropriate, and then we’ll pick something else to deliberately practice.

‍

We’ve instituted a policy of ring fenced learning time

All of our Intern and Associate Software Engineers have 1 day a week available to them where they can focus completely on learning and not have to worry about “delivery”. It should be related to the context of their squad and Birdie, but within those constraints they are free to use it and approach it however they wish.

‍

‍

Continuing to improve our systems

Much like building software, building systems within a company is an incremental and iterative process. Having introduced these changes to our systems we need to constantly inspect and respond to what we learn so that we can, as Woody Zuill says, “Turn up the good” on what works and, by implication, drop what doesn’t work.

In the context of this case study, the policies and processes we introduce, remove, tweak, and experiment with will be always up for discussion and evolution but will be guided by Birdie’s commitment to “providing our early career software engineers with the best onboarding experience and support to facilitate their learning and development”.

‍

We’re hiring for a variety of roles within engineering. Come check them out here:

https://www.birdie.care/join-us

‍

‍

---

Original article from the engineering at Birdie blog on medium

‍