Why such big meetings by a CTO
Episode 5 of my CTO series, about communicating vision and team values
· find previous episodes: -1-, -2-, -3- and -4-.
I organised my first All-Hands in December, in the midst of a high-stress period (see my December episode), inviting 13 people to a 15-minute meeting without ant obvious topic. Preparing this first gathering of everyone in my team pulled me out of my comfort zone further than I imagined. So why?
Everyone hates large mettings
Meetings with more than 4 people can very easily become a waste of time. Yet, there are a lot of things that I regularly need to convey to everyone. In a All Hands, I am the only one talking, no time for debates, which is one way to mitigate the problem. Maybe it should be called All Ears instead.
Duration, 15 minutes. Multiplied by the hourly rate of the entire team, it’s already a lot of money, if you think it that way, but it’s not my reason to keep it short. Keeping everyone’s attention in an online meeting after fifteen minutes requires some orator skills.
When? We have a tech meeting every Friday that ends at 12, so I picked Friday noon, knowing that nobody would be in deep focus, nor in a rush to another meeting. Always make sure that large meeting break the focus of as few people as possible.
Who? All the developers are invited, of course, everyone in my team because well, I’m here to talk to them. That’s 10 people. I also invite the Product team, optionally, because they are impacted by what I have to say, which brings the total of attendees to 13, plus myself.
Contents
The whole point of the meeting is to give the team a sense of what is important, to me as their manager, and to the company. Additionally, I’m happy to use it as chance to nurture the team spirit.
As I am preparing the fifth edition, this is the structure that I follow, picking four or five items from this list. Items maked with a * are mandatory.
- Kudos*
I always start with things that went well during the past period. Feature delivery, incident recovery, big client onboarding… - Staff changes
After any change, I show an organigram of who is doing what, in order to stabilise everyone’s idea of where they stand. If we are recruiting, the job description follows, with a call to co-opt someone competent. - Tech KPIs*
This is to me the most important section: more than a real evolution, I want to make sure that everyone knows what we are measuring. Making sure that we improve is a second step, and it comes naturally when everyone has the figures in mind. - E_NPS
HR measures the happiness and loyalty of employees, so I have this section about what we do with the data. This kind of HR initiative is often misunderstood by technical people and many of us will try to avoid filling up the forms. - Engineering practices
I once included a presentation of what a feature’s lifecycle should look like, because after heated discussions, we needed to agree on a pattern, so I presented one and took some feedback. Now I give the floor to our Head of Engineering, who presents if he wants the next big refactoring works, the latest incidents, etc. - Career progression
In June, I added a focus on the mid-year reviews that everyone was supposed to prepare, quickly adding a coat of tech paint of what HR had already presented. - What’s next?
This is one slide, at the end, where I give something to look forward to. It can be anything, I just want to end on a positive note. It is usually illustrated with a picture of food.
Non-subjects
There is one regular communication that my talk could replace, and I take conscious care to avoid it: Product Updates. I do give some view over progress, how far we are on our different initiatives, but only as a way to align everyone on my vision of what is important. There is no demo, no feature presentation, the audience is primarily the developers.
What do I mean by primarily?
Post-meeting communication
In order to prevent the tech team from becoming a siloed startup inside the startup, after the meeting I send my slides to the rest of the company. I don’t really know who reads them, except for the 2 or 3 people who give feedback or ask questions. In my message that presents the link to the pdf, I recap the main good news. For the bad news, let them see inside and read the slides. There is enough noise around a lack of trust in tech, my role is to show that even if we’re not perfect, we’re on a good trend.
The good news is, after four instances of the All Hands, I’m ready to make it a monthly thing, maybe make it shorter if necessary, or take the time to delve a little into some specific topics. The good news is, I’m not freaking out about it anymore, since I received some good feedback, showing me how useful this time is. Funny how getting out of a comfort zone is rarely dangerous.
