Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Principle driven scaling - How to grow value without growing overhead

1,151 views

Published on

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.

Published in: Technology

Principle driven scaling - How to grow value without growing overhead

  1. 1. Principle-driven scaling How to grow value without growing overhead Neil Killick, Head of Engineering @neil_killick @LocomoteGroup
  2. 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. 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. 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. 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. 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. 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. 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. 9. But stay small.
  10. 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. 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. 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. 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)
  14. 14. 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
  15. 15. Big Visible Board ❏ Single source of truth ❏ Forces prioritisation discussions ❏ No hidden work
  16. 16. 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
  17. 17. We need to be very good at prioritising!
  18. 18. 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
  19. 19. 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
  20. 20. Thank you! Questions / Discussion Neil Killick, Head of Engineering @neil_killick @LocomoteGroup

×