This document discusses strategies for sustaining team growth at a startup. It begins by introducing the author and their experience scaling engineering teams. It then addresses potential trust breakers like outages or lack of communication. Some solutions proposed include creating defined processes, providing more visibility, and helping engineering managers scale. The document provides tips for engineering managers, such as solving problems early and tracking team fatigue. It also offers recommendations for improving processes, code reviews, quality assurance, deployments, hiring, and onboarding.

1. Sustaining your Team Growth
Fred de Villamil
Aircall, Oct 26th 2018

2. About me
● 15 years doing the fireman in
(hyper)growing startups
● Working on both technical and
organisational levels
● Passionate about leadership and scaling
large infrastructures
● Open source contributor since 1996
● Author, speaker and startup advisor
Fred de Villamil
Twitter: @fdevillamil

3. LACK OF TRUST

4. Trust Breakers
● Poorly delivered release, outages
● Unexpected delays
● Lack of communication inside and outside
the engineering teams
● Interpersonal problems
● Losing your culture by hiring too fast
● Product VS dev VS design VS QA
● Lack of visibility inside the company
● Opportunity roadmap
● Tech VS business
● Lack of roadmap / strategy visibility

5. ● Create defined, publicly available
processes
● Help your Engineering Managers scale
● Be lazy, automate
● Create the right communication channels
● Provide visibility
Restoring Trust, Step by
Step

6. Engineering Managers

7. ● I'm a para-shit, taking every problem that
might prevent the team to achieve the
company's goals
● Success are the team's, failure are my
responsibilities
● Engineering teams works for the company,
I work for the team
● Fixing people problems before they
become a team problem
How Can I Help you?

8. The Clear Contract
Define your leadership / working style
● What I will do for you
● What I won't do for you
● What you can do with me
● What you can't do with me
Share with your team members, 1:1
● Ask them to do the same exercise
● Listen to their vision, share yours
● Find trade offs so you can work together

9. Working with Remote Teams
● Don't treat remote teams as a whole unless necessary
● Communicate! Communication should not be one sided
● Include remote colleagues into existing projects
● Ask remote colleagues to review your code, even if it takes time
● Have remote colleagues do your code review
● Setup communication tools: video chat, Alice Standup Slack bot…
● Have at least 2 hours of overlapping work time

10. Solving Team Members Problems
● Solve problems as they arise, don't wait
for a people issue to become a team
issue
● If things get personal, escalate or delegate
● Empathy is the key but you're not
Mother Theresa
● Meet your leads at least once a week
● Use neutral places as much as possible,
keep closed meeting rooms for the big
thing
● Talk, then write, for what's not written
does not exist
● Ask advice from the HR early enough,
that's their job

11. Track your Team Fatigue
● Started when I was managing an ops
team after 2 burnouts
● Different KPIs for developers, ops,
designers…
● Sometimes, you need to force people to
take a break
● This is not rocket science
KPIs
● Interruptions and context switching
● Ops: incident and oncall hours
● Calculated weekly and on a sliding month
Tools
● Jira: what has no ticket does not exist

12. Improving processes

13. ● Too many processes lower productivity,
no processes kill it
● Processes must be written, known and
accepted
● "Old timers" have more difficulties to
adapt to new processes
The Process Paradox
● Adapt state of the art processes to your
reality, not the other way around
● Processes should have a purpose, not
become a purpose
● A good process is an automated process

14. ● A mix of Scrum and Kanban
● Give time to the unexpected
● Accept that a sprint is not immutable
● Include all the stakeholders
Daily Organization
● 2 weeks sprints
● Demo at the end of sprint: invite the
whole company, include the design
progresses
● Daily standups including Design, PO, Ops
& QA
● Sprint retrospectives: what can be
improved?
● Sprint planning on Friday so we know
what we'll do on Monday

15. Improving Code Reviews
● Code reviews should not be code validation
● Do the review next to the developer, or by video call
● Have the juniors review senior engineers code, they'll learn a lot
● Ask different (random) people to review your code
● Take your time and be patient

16. Building a QA that Works
● The QA team should not belong to the tech / product department (CFO /
CEO)
● Hire QA engineers, not testers: former developers or ops, to build the
CI/CD toolchain
● Build from the bottom: engineers first, managers second

17. QA for everybody to everybody
● Automate, automate and automate again! (Jenkins, CircleCi, Slackbots…)
● Unit tests → developers (runit…)
● Functional tests → PO / PM (cucumber), they are the product specs
● Integration tests → QA + Ops: test the whole chain
● Manual tests → outsource!

18. From Dev to Production
● Developers write the deployment recipes
● Developers write the monitoring probes
● API should have an endpoint with version, deps, build info and self
documentation
● No deployment on Friday!

19. ● 2-3 hours to discuss a new architecture, refactoring...
● Open to everyone interested in the topic
● Leave the door open: people can join anytime and leave anytime
● Finish with a deliverable
Open Brainstorming Rooms

20. Hiring and onboarding

21. An Effective Hiring Process
The process
1. Screening call with the candidate
2. The candidate meets 2 random people
from the team
3. A 2-3 hours technical whiteboard session
with an engineer + lead
4. A leadership / organisation meeting with
the CTO
5. For senior / leads, start with meeting the
CTO
Goals
● Keep it short
● Do the team members want to work with
the candidate?
● Cultural fit > technical skills
● Average: 9 days between the screening
and go

22. ● From simple to extremely complex
questions until they can't answer
anymore
● Not used to write off a candidate but
know them better
● Help a new joiner overcome their
weaknesses
● Build homogeneous teams where people
can learn from each other
The Skill Set Assessment

23. Onboarding New Colleagues
● The best place to learn about the company is at the customer support
● Give every newcomer a "mate" from a different service who help them
navigating in the company
● Have every engineer work in 2-3 different teams or product for a month
each, then choose what they love the most

24. Thanks!
Question?