Topics discussed included:
- Learnings from 5 years of true continuous deployment by Per Mellqvist, CTO at Funnel
- How to educate engineers on management by Vicky Wills, Director of Engineering at Zego
- How to build a strong developer brand for attracting talents by Jane Silber, ex-CEO at Canonical
- How to manage a distributed teams by Rian Liebenberg, CTO at Kobalt
- OKRs implemented for engineering teams by Robert Salesas, CTO at Aircall
- How to build and manage an open-source project with a strong community by Emile Vauge, CEO at Containo.us
- How to think about cybersecurity from the early days by Dave Palmer, Director of Technology at Darktrace
- Best practices to create, build and scale your API by Paolo Negri, CTO at Contentful
- Building a remote team from Day 1 by Frédéric Plais, CEO at Platform.sh
- Building and fostering product-focused engineering teams by Ed Bishop, CTO at Tessian
- Scaling your engineering organization from 3 to 300 by Neil Turner, CTO at GoCardless.
I had the chance to attend the session led by Neil Turner, CTO at GoCardless. Neil has scaled the GoCardless engineering organisation to over 300 people. He gave us very practical tips on how to identify when it’s the right time to change the organisational structure as startups scaled:
- When your lead engineers start having too many people reporting to them and are forced to spend 80% of their time in management, it is generally a good sign it is time to change. Ideally, a lead engineer should not directly manage more than 5-6 people.
- When an engineer can represent a single point of failure. If you remove anyone from the organisation overnight, without a soft transitioning, your company should be standing up without encountering critical issues. It if is not the case, then it means you should establish more redundancy across the organisation. Nobody should be irreplaceable.
- In a similar way, if onboarding a new developer on the code repository takes over 6 months, it means it has become too complex and needs to be reorganised in a more simple and documented way.
- Up to 80 engineers, everyone should recall every name. Otherwise, there is a communication problem and you need a new format.
Online events — a few key learnings
Finally, we thought it would be helpful to share a few learnings from organising a remote event. Remote events might not suit every use case but I predict they could represent a great alternative for a number of physical events.
- As you remove the travelling burden, it’s easier to convince great people to attend and speak. You can hope to attract very high profiles as they won’t need to spend as much time as for a physical event and will get an even bigger audience.
- People can join easily but they will churn almost immediately if the content does not fit their purpose. For one-to-many interactions like talks or panels, you need to keep the format short (<45 minutes) and very concrete. Save time for a Q&A in the end, and use the chat and polls features to keep the sessions very interactive.
- Most interactions should happen in small group sessions (<10 people) where everyone can actively get involved with video on. In remote events, you don’t have physical and logistics constraints, so don’t hesitate to organise a lot of breakout sessions with specific topics.
- Save some time for networking and serendipity. Creating conditions where people can bond is probably the hardest challenge in a remote event. Arguably this is the same problem as for any video conference interactions. So it’s important to create opportunities for people to meet randomly. Hopin’s Networking feature (a ‘chat roulette’ style feature which randomly pairs with other attendees) is a good example of how to do this.
Thank you again to all of our guests and speakers. We were delighted to host the event and we hope it provided our CTOs with some actionable tips and some long-standing relationships. We will try to keep the CTO collective running every year. We promise next year it will happen in person 😉
