scaling dev teams with purpose

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.

rw@robwatts.orgwww.robwatts.org

Twitter: rwatts_LinkedIn: robertjoelwatts