scaling dev teams with purpose
TRANSCRIPT
Scaling Dev Teamswith
Purpose
HelloHello, I’m Rob.
I’ve been at this stuff for quite a while now.
I’ve worked in small, medium and massive companies.
I’ve managed teams through high growth and necessary reductions.
The consistent management challenge: purpose.
I work at Lost My NameWe make personalised books for children.
☞ Founded in 2012
☞ Number of books sold: 1.66m+
☞ Number of customers: over 750,000
☞ Number of countries: 178
☞ Created books for 97,827 different names
Lost My Name
☞ 2012: founder and friends
☞ 2013: founder + 2 developers
☞ 2014: ~8 developers in 1 team
☞ 2015: ~20 developers in ~4 teams
☞ 2016: ~25 developers in ~5 teams
☞ We’re hiring!
This talk is about creatingthe right environment so thatdevelopers feel connectedto your mission as your startup scales
Scaling from original team to multi dev stream complexity
Small is simple. Small is great.
☞ Everyone involved and empowered in decision making
☞ Instant feedback
☞ No constraints or legacy code to maintain
☞ Documentation is a waste of time
It’s a great time to be alive.
Growth is fun.
☞ Every new person is AWESOME
☞ Quick to get started and master the codebase
☞ Individuals can still make big differences
☞ Growing the team is a buzz
☞ Decoupling begins
Things always get more interesting at scale
☞ Dependencies
☞ Boundaries
☞ Hand-offs
☞ Knowledge sharing
☞ Roadmap alignment
Developer Disconnect
Unfortunately the more you scale the more likely you are to encounter Developer Disconnect from a small number of people.
The 4 elements ofDeveloper Disconnect➀ Defensiveness
➁ Disempowerment
➂ Detachment
➃ Drudgery
Spotting developer disconnect #1: Detachment
“What’s the pointin doing that?”
Spotting developer disconnect #2: Defensiveness
“It’s easier if Ido it myself ”
Spotting developer disconnect #3: Detachment
“That doesn't affect us, it’s theother teams problem”
Spotting developer disconnect #4: Drudgery
“Sorry I can’t help,I have to do [TEDIUS_TASK]”
Spotting developer disconnect #5: Disempowerment
“Only [HERO_DEV]knows how to do that”
Spotting developer disconnect #6
“Working here isn’tlike it used to be”
We need to challengedisconnect by restoring
purpose
Clarity from managers#detachment
☞ CTO/VP Engineering/Head Of */Product Lead ← do they have clear meaning in your organisation?
☞ Leaders should deeply understand development
☞ Carefully manage roadmap vs vision
Break down silos#defensiveness
☞ No heroes for low bus factor
☞ Discipline meetups
☞ Cross functional squads around key deliverables
☞ Persistent teams with rotation
☞ Mini conferences / away days
Automated build & deployment#drudgery
☞ Developers should code with whatever tools they choose
☞ BUT standardise build chain to get that code to customers, including server provisioning, deployment, CI, build and test
Document hard to change things#disempowerment
☞ These are the key decisions in software history
☞ Usually accumulate most technical debt
☞ Document context
☞ Create time for alternatives and build backlog
Pay down technical debt#disempowerment
☞ Make space in sprints and roadmap
☞ Developers want to feel they are improving the system
☞ Don’t be a feature slave
SummaryFight developer disconnect by ensuring there’s purpose from above and below.
We can beat disconnect by1. Defensiveness → Break down silos2. Disempowerment → Document, Pay down tech debt3. Detachment → Clear leadership and intra-team comms4. Drudgery → Automate
But remember: you can’t take everyone with you.
Thanks for listeningI hope that was useful.
Twitter: rwatts_LinkedIn: robertjoelwatts