How to Build a Great Engineering Culture - Tanja Lichtensteiger - Sky Betting & Gaming

How to Build a Great Engineering Culture - Tanja Lichtensteiger - Sky Betting & Gaming

Tanja Lichtensteiger of Sky Betting & Gaming discusses how to build a great engineering culture and how it can help you build better software.

(This post is part of a collection from the Sustainable Digital Delivery event hosted by Conflux at the Leeds Digital Festival 2019)

Key points:

  • Engineering culture is it is all about the people

  • Happy engineers build better products

  • Main ingredients for good engineering culture:

    • People & teams, if you don’t get this right, you won't have a chance in hell to build great engineering culture.

    • Hire for potential, attitude and resilience - technical ability comes second

    • Ingredients for job satisfaction: autonomy, mastery, complexity

    • Squads - it’s good to have squads that are loosely coupled to minimise blast radius (two pizza team)

    • Psychological safety - let them be who they are at home to be at work, encourage diversity, no ego

    • You need people to be comfortable to fail - fail fast, learn fast

    • Chaos engineering - try it out

  • Build better people - people = asset, invest in their learning, help them become better

Slides:

M is for MVP (or is it?) - Clem Pickering - Infinity Works

M is for MVP (or is it?) - Clem Pickering - Infinity Works

Clem Pickering of Infinity Works discusses how an MVP is not exactly MVP and how we should change the definition to establishing regular, iterative delivery.

(This post is part of a collection from the Sustainable Digital Delivery event hosted by Conflux at the Leeds Digital Festival 2019)

Key Points:

  • MVP - minimum viable product - just enough features to make the client satisfied.

  • M - maximum not minimum, clients insist everything is minimum

  • M - marketable - generally suggests that it would need extra polish, extra features to make sure it is marketable

  • V - immoVable - (M is for Must!) - MVP is commitment, once it is there, it is fixed

  • M is for Must (oScoW) - the idea is - must, should, could, won’t.

  • P - is for permanent - once the feature is there - it is never coming out!

  • Ideally you should move towards:

    • M - multiple, M - is for Monthly - when you come from once a year, once a month release cycle is a good change.

    • V - valuable

    • P - experiment

  • Challenge the concept of MVP - focus instead on establishing regular, iterative delivery, take the tube not the release train.

Slides:


Describe your APIs with OpenAPI - Lorna Mitchell - Nexmo

Lorna Mitchell (Nexmo) - Describe your APIs with OpenAPI

Lorna Mitchell of Nexmo discusses how using OpenAPI can make your project evolve even without your imput.

(This post is part of a collection from the Sustainable Digital Delivery event hosted by Conflux at the Leeds Digital Festival 2019)

Key points:

  • Decribing APIs - describe RESTfullHTTP API in a machine readable way:

    • Produce API reference documents

    • Auto-generate code SDKs

    • Use description in other developer tooling

  • OpenAPI - API description language formerly known as "Swagger", an open standard, supported by industry.

  • Spec-First API design

    • That's what’s magic about it - it is open, there is so much that you can do about it.

  • The project you don't just ship but live and evolve.

Slides: