In this podcast Shane Hastie, Lead Editor for Culture & Methods, spoke to Jim Rose of Circle CI about building a great engineering culture in a distributed, remote team.
Key Takeaways
- Hiring engineers is a difficult task
- Working in a completely remote organisation takes a particular type of person
- It’s crucial that the engineering teams understand and empathise with their customers
- You won’t find new and creative ways to solve problems unless you experiment and try new things, and some of those things won’t work
- Ensure that your recruiting and hiring practices match the values of the company and that the onboarding process reinforces this
- Ensure there is no “in vs out” – ensure everyone has the experience irrespective of where they are located
Subscribe on:
Show Notes
- 00:25 Introductions
- 02:18 Hiring engineers is a difficult task
- 02:44 The implications of having a remote engineering culture
- 03:34 Looking for people who either have an aptitude in the technical stack, or have an interest in learning as they go
- 04:25 Making the recruitment process a conversation with the candidate to identify if they are interested in the things the organisation needs
- 05:45 A great culture needs people with the right mindset
- 05:54 It’s crucial that the engineering teams understand and empathise with their customers
- 06:58 Clarity around goals and values is even more important when the organisation is distributed and remote
- 08:20 The first release of a product is the first step on a long journey
- 08:38 Teams need to feel empowered to take chances, and that failure is OK
- 08:58 You won’t find new and creative ways to solve problems unless you experiment and try new things, and some of those things won’t work
- 09:48 Focus on customer value and recognise that it’s OK to take chances
- 10:05 The most respectful interpretation – assume good intent and that that anything someone does has the organisation’s best interests at heart
- 10:48 This approach is even more important in a remote team because of the limited visibility and communication bandwidth
- 11:29 Telling the story of how the teams have evolved over time
- 12:12 Even in distributed teams no one should code alone, form teams that are close enough in time that they can work simultaneously
- 13:20 The guild model allows communities of practice to form that span teams
- 14:05 The danger of having teams that have some people collocated and others distributed
- 15:34 Different ways in which the teams come together in person in order to get to know each other – all hands, small hands and call hands
- 17:28 Defining value is context dependant and unique to each team – defining the customer and defining value is key to the context
- 18:02 Identifying the customer of a service can be hard – think about who is the consumer of the work that the system does
- 19:28 Create value for users and find the edges of what is possible and interesting in the product
- 20:19 Ensure that your recruiting and hiring practices match the values of the company
- 20:44 Things the candidate conversation needs to cover – what’s important to us and what’s important about the way we work
- 21:15 The onboarding process is vital to helping establish the culture we want in the company
- 22:32 The story of what happened when the onboarding process didn’t match with the recruitment experience
- 22:55 There’s nothing more disheartening than a poor onboarding experience
- 23:28 The importance of clarity in team goals
- 23:48 The risks of crossing the Dunbar’s Number (~150) threshold
- 24:05 As the organisation grows the “just ask” communication breaks down and you need more explicit clarity around goals and KPIs
- 24:48 If you don’t codify outcomes and goals as the organisation grows beyond ~150 people then there is the potential for serious misunderstanding
- 25:26 The trick with distributed, remote teams is to start from the basis of overcommunicating, and that’s good
- 25:54 Ensure there is no “in vs out” – ensure everyone works off the same experience and basi
Mentioned: