location_city Sydney schedule Nov 28th 04:30 - 05:00 PM place Grand Ball Room 1

We engineer our systems to be reliable. The profession has maintained a keen focus on approaches to testing to best ensure that everything goes right. We expect our people to think through potential failures and architect them to be resilient regardless. But despite our best efforts, unexpected failures will always occur.

This talk discusses ‘safety engineering’ – the design of IT control systems for when unforeseen circumstances arise. Drawing on the experience of implementing a safety program within a HFT company the talk will cover where safety systems sit in the overall architecture, what they do, and when to invest in them. Finally, the talk will cover the practical aspects of implementing a safety regime within a company.


Outline/Structure of the Talk

  1. A background anecdote of where our company's safety journey began, the Knight Capital meltdown of August 2012.
    1. The incident wiped out a large company in a morning.
    2. The "cause" was a combination of deployment error and a repurposed feature toggle.
    3. Management asked what prevented the same thing happening to their company. Luck
  2. A physical world example of safety engineering, the recent failed Soyuz launch. Contrast with an older example, the Challenger disaster.
  3. Introduce the idea safety engineering: the design of systems to manage unexpected failure. Contrast:
    1. Reliability engineering. Ensuring that a system works as expected and does not fail. Dealing with "known knowns" through practices including testing (backed by appropriate operational practices).
    2. Resilience engineering. Accepting that there are various predictable failure modes within a system, and designing and architecting a system to be resilient to those "known unknowns" failures.
    3. Safety engineering. Accepting that not all circumstances are foreseeable - "unknown unknowns", but that the behaviour of the system, while it may no longer be able to fulfil its mission, still needs to act "safely"; to protect the physical, financial, legal, informational, and/or reputational security of the organisation.
  4. Describe that safety engineering requires a different approach that is unfamiliar to many engineers because it involves finding solution without working out how the underlying system is working.
  5. Key point. Emphasise: The enemy of safety is hubris.
    1. Anecdote. Consider the Titanic; engineered to the highest reliability and resilience standards, but a failure in the safety systems: not enough lifeboats! So obvious!
    2. Follow-up anecdote of the SS Eastland which became top-heavy with lifeboats that were made mandatory after the Titanic, capsized, and killed more people than the Titanic sinking.
    3. Safety engineering is hard because it's needed in exceptional circumstances, when the consequences of getting it wrong are highest.
    4. The enemy of safety is hubris.
  6. Safety engineering involves the design of controls. Broadly, controls fill three roles:
    1. Validate the state of the system.
    2. Validate the (outward facing) behaviour of the system.
    3. Containment.
  7. Design constraints on controls:
    1. Independent of the main system.
    2. Orthogonal to the main system (i.e., not just an independent replication of the main system).
    3. System-oriented rather than component-oriented.
    4. Minimal.
  8. Discuss when to invest in safety engineering.
    1. It's not a typical investment, and you can't calculate value in the same way. It's more like insurance where the expected value is negative but greater protection against catastrophic loss.
    2. Investment in safety must be the decision of the client since it's for them to decide what their risk profile is.
    3. Different companies will have different desires to invest. In some cases (particularly where physical safety is involved, but also in other regulated industries) it will likely be a legal requirement.
    4. The same company may have a different desire to invest over its lifetime. Consider a start-up -vs- that company 10 years later which may by then be worth > $1B.
    5. General rule: if you're expecting positive value from safety engineering, you probably should be spending more time on reliability and resilience.
    6. Our management was surprised by our answer to the Knight Capital question because we'd never really talked about it. We found a mismatch between their "low risk" expectations and our "be in the market" assumptions. It required a big cultural shift.
  9. Optional aside: the finance industry approach to quantifying operational loss, the LDA from Basel II. It's problematic for this kind of case: lots of good data required, backwards-looking not forward predicting, problems of dealing with unlikely events (black swans).

Part 2: Implementing a safety program

  1. Talk through some of the actions we took to establish a safety program.
    1. A very clear top-down directive
    2. Deep engagement from senior people
    3. Focus on risk culture
      1. An approach to incident reviews which forced deep engagement
      2. Explicit education ( / indoctrination). The idea of stories as organisational memory of why safety is required, and some thoughts on building these kinds of narrative.
  2. Talk through some of the challenges we found
    1. We treated it as a software development problem and massively failed. The human processes are a huge component and require constant attention. (Physical world example: annual fire evacuation drills are done for a reason.)
    2. Developing controls isn't "fun" for most people. For a trading company, with remuneration tied to company profits, working on negative-expected value projects has misaligned incentives. We made some attempts at ensuring we got the financial incentives right ("punishing" risky behaviour, appropriately rewarding risk-minded work), but it wasn't a complete success.
    3. Not cheap.
  3. Talk through some of the outcomes.
    1. Much improved safety (beware hubris!).
    2. Much improved efficiency at managing incidents: earlier detection, better tools for resolving, faster resolution.
    3. We have a much improved detector of things being "not quite right" which feeds back to our reliability and resilience work, though hard to value.
    4. There was a dream that by having a great set of controls that we could be more "pragmatic" about the engineering quality of our primary system: it may go down (for us, not the end of the world), but we would be "safe". This went back and forth a bit. My take: it's a potential "moral hazard" to be relying more on the safety systems. The intent is to reduce the overall risk profile. Consequently, bumping into the controls is treated as a serious incident.


  1. Reliability vs resilience vs safety engineering
  2. Controls: Validate state, validate action, containment
  3. Controls: Independent, orthogonal, system focus, minimal
  4. Choice to invest sits with the client, but requires an open conversation
  5. The enemy of safety is hubris.

Learning Outcome

  • Safety as a distinct property from reliability and resilience.
  • Different types of controls.
  • When to invest in safety engineering.
  • Practical considerations for instigating a safety problem; cultural and technical.

Target Audience

CTOs and Engineering Managers of scale-up and larger companies

schedule Submitted 2 years ago

Public Feedback

    • Herry Wiputra

      Herry Wiputra - Scaling Engineering Teams for Growth

      30 Mins

      Your startup has been very successful, it is growing very quickly and it is putting a lot of pressure on your team to meet the needs of the market. It is a really good problem to have. You added more people to your development team but you noticed that you are not getting the same ROI as you did in the past, in fact, it is a declining ROI, you are just not getting the outcome that you look for.

      Operating a 10 people engineering team is different to 50 people engineering team. It is different to operating 100 people engineering team. In this talk, Herry will tell the story on how he scaled the engineering team in Campaign Monitor from 20 to 70 engineers in order to unlock growth.