Many companies want to derive the benefits of an agile approach to software product development but struggle to do so, not least due to legacy processes and infrastructure which seem "too hard" to change. Locomote is a small company on a growth path, and as such we have an opportunity to be principle-driven in how we grow success, avoiding mistakes other companies make as they look to "scale". What do we even mean when we talk about "growing" or "scaling"? What are we trying to achieve? This presentation will invite discussion on some key questions we asked ourselves at Locomote in how we should grow our engineering team, such that we do not create overhead that slows us down and kills our startup culture. Establishing principles for how you want to grow makes decision-making about process, practices and team structures far more straightforward, and aligned with a shared vision of what awesome looks like in your context. Hopefully the audience will come away with some food for thought and concrete ideas to try in their own workplace.

1. Principle-driven
scaling
How to grow value without growing overhead
Neil Killick, Head of Engineering
@neil_killick @LocomoteGroup

2. We have global ambition.
❏ We want to build the best corporate travel experiences in the world
❏ We want to grow from a startup into a global player in international markets
❏ Leaders of the company understand importance of being agile
❏ Quickly seize opportunities
❏ Don’t over-invest
❏ Test ideas/assumptions
❏ Generate value early

3. We must have a vision and
strategy for how we grow.
❏ Don’t be random! What do we care about - Startup culture? Great
workplace? Agility?
❏ What does awesome look like?
❏ How will we get there?
❏ Keep momentum - small changes and experiments

4. This strategy must be
based on principles.
❏ Spotify model is not a “scaled agile framework” - it’s an
evolving outcome of principle-driven scaling - they
thought “how do we grow but stay ourselves?”
❏ Most companies adopting agile are big and complicated
- it’s too hard
❏ Need principles when growing to make good decisions

5. Avoid scaling overhead.
❏ Do we want a hierarchical “chain of command”?
❏ Perpetuates command-and-control, theory X mindset
❏ Puts teams further away from decisions and empowerment
❏ Creates a management cost (i.e. to grow, we need more managers)
❏ “Project” and “program” overhead
❏ Project and program management needs Managers
❏ Pulling down and re-forming teams
❏ Meetings, reporting, heavy governance, etc.
❏ Concrete processes are too hard to change if not working

6. Understand our capacity...
❏ Capacity != Number of people
❏ Capacity = Team or org’s ability to sustainably deliver value in a period of time
❏ Limit demand to capacity
❏ Other businesses get this, software companies often don’t
❏ Provide excellent products and services to existing customers
❏ Minimise overhead of adding customers (e.g. custom solutions,
deployments, meetings, etc.)

7. Then increase it.
❏ Growing capacity through improvement in culture and process is a prerequisite
for effective hiring, and is more effective in itself
❏ Technical debt, firefighting, bugs and support calls (aka failure demand)
squeeze capacity to do value-adding work
❏ Focus on root causes for fast increase in capacity
❏ Encourage understanding and improvement of capacity at team and system
level

8. We must “grow”
our teams...
❏ Create a learning environment where teams can do their
best
❏ Connect teams to the goals of the company and the
customer
❏ Increase probability of new hires resulting in
added capacity

9. But stay small.

10. We must get right balance for
Co-lo v Remote v Distributed.
❏ Distributed opens up worldwide talent pool and round-the-clock productivity
❏ 100% co-located and 100% distributed teams optimise comms, workshops etc.
for all team members
❏ Remote teams where 1 or 2 folks are remote have suboptimal comms
❏ Consider time zones

11. We want teams that
are stable...
❏ Adding/removing folks from teams is risky and often costly
❏ Pulling high performing teams apart is plain crazy
❏ Sub-optimise only one team when hiring to minimise impact
❏ Work flows through teams, not teams around work

12. Autonomous...
❏ Can deliver fully tested, working customer features (i.e. value) on their own
❏ Must be cross-functional to do this
❏ No asynchronous dependencies on teams or tools
❏ New team (or team with new focus) can start adding value right away
❏ Highly scalable, particularly with distributed teams

13. Aligned.
❏ 2 or 3 themes represent current company-wide high level priorities,
deliverables and milestones
❏ Themes have backlogs of tradable options
❏ Teams align to themes until there is more value in other themes (new or
existing)
❏ A team focuses on just ONE theme at any given time (to allow empirical
progress tracking and to respect the priorities)

16. We use our own portfolio
kanban to help us do this.
❏ Make all work visible
❏ Prioritise and order all work
❏ Match demand with capacity
❏ Communicate
❏ Collaborate

17. Big Visible Board
❏ Single source of
truth
❏ Forces
prioritisation
discussions
❏ No hidden work

18. Why a physical board in a
distributed company?
❏ Limited in size which makes it perfect to create focus
❏ Requires people to meet around it to talk about the work
❏ If a sticky note representing the work doesn’t fit on the board, stuff currently on
the board is more important - don’t waste energy on it right now
❏ Too easy to create new (invisible) work in Jira - every item of work added is
potentially delaying existing work in flight, causing compromises in quality to
be made

19. We need to be very good at prioritising!

20. Create goals and a continuous
improvement imperative.
❏ Emphasise product and operational metrics we care about
❏ Place expectation on all employees to continuously improve these metrics
rather than just “deliver features”
❏ High quality vs Deadlines - consistent message
❏ Early and often earned value vs Big risky projects

21. In summary...
❏ Define vision and strategy for how to keep what you care about as you grow
❏ Understand your capacity so you can balance demand, keep nimble and seize
opportunities
❏ “Grow” stable teams, and stay small
❏ Consider impacts of co-located v remote v distributed teams
❏ Create aligned autonomy using goals, continuous improvement and portfolio
kanban
❏ Get good at prioritising by comparing value, not opinion, and making trade-offs

22. Thank you!
Questions / Discussion
Neil Killick, Head of Engineering
@neil_killick @LocomoteGroup