Frozen in space and time

Now don’t get me wrong, I love my job, I really do. I don’t think there are many other opportunities in this world where I could get to be a biochemist, chemist, physicist, engineer and software developer all in one day. But I really wish that mistakes weren’t so punishing.

Yesterday afternoon I spent over an hour a half preparing buffers and making sure that they weren’t too acidic or too basic, to then spend nearly 2 hours getting my sample into those buffers. Admittedly I’ve been putting off this experiment for some time now as I couldn’t face an entire afternoon sat in front of a pH meter and centrifuge, but it was with the notion that today would be an easy day. Come in, turn the machine on run the samples, go home.

But as with all good plans quickly unravel. The first problem was that our “chilled water” supply into the lab (used to cool the machines, like a backwards radiator) was distinctly above room temperature and decidedly warm to the touch after the machine was on for an hour. Nothing I’m not used to though in this place, and nothing that I can’t use my imagination to get around.

The second problem is that it takes nearly 2 hours for the sample space in the machine to get down to -263 ºC. Well that’s not a problem, that’s a known constant. The problem is that when you put your sample in and you put it in a millimeter too far, so that rather than hanging in space it’s touching the bottom of the container, freezing it in place and making it impossible to remove.

So my day that should have been:

Working day = (10 samples X (30 mins machine time per sample + 10 mins sample change time)) + 2 hour cooling down time

= 8 hours 40 mins

Instead became an inserted step of wait 30 minutes until the sample space had warmed up enough to loosen the seals and then an hour to take the sample space apart, remove the sample and reconstruct. Another 30 mins later and we were back down to temperature.

1 mm today has cost me 2 hours.

Since then other sample placement mistakes have cost me an hour. But then it’s difficult to correctly insert a sample when it’s completely enclosed and the only measure you have is a single pixel line similar to a heart rate monitor, on a 5 inch screen on the other side of the room.

Ah well, looks like I won’t be going home tonight til gone 9.

UPDATE @ 1841: Well I’ve just had another tube freeze in the cavity and another sample exploded. So I’m done with it for today. I’m clearing up and then I’m going home.


This page previously appeared on morganbye.net[^1][^2][^3]

[^1:] http://morganbye.net/frozen-in-space-and-time [^2:] http://morganbye.net/2012/06/frozen-in-space-and-time) [^3:] http://morganbye.net/uncategorized/2012/06/frozen-in-space-and-time/

How do you define successful engineering leadership?

The Philosophy

Many view technical leadership as being the “smartest architect in the room.” I see it as the opposite. My job is to build a room where I don’t have to be the smartest person because the systems, culture, and communication are so robust that the team can out-innovate me.

The Strategy

  • Alignment: Does every engineer understand how their sprint task impacts the company’s bottom line?
  • Velocity vs. Stability: We aren’t just “shipping fast”; we are building a predictable, repeatable engine that doesn’t collapse under its own weight at the next order of magnitude.
  • The Human Growth Curve: Success is when the engineering team’s capability evolves faster than the product’s complexity. If the team feels stagnant, the tech stack will soon follow.

What is your approach to scaling technical organizations?

The Philosophy

Scaling isn’t just “hiring more people” - that’s often how you slow down. Scaling is about moving from Individual Heroics to Organizational Systems.

The Strategy

  • The 3-Continent Perspective: Having managed global teams, I focus on “High-Signal Communication.” As you grow, the cost of a meeting triples. I implement “Asynchronous-First” cultures that protect deep-work time while ensuring no one is blocked by a timezone.

  • Modular Autonomy: I advocate for breaking down monolithic teams into autonomous units with clear ownership. This reduces the “communication tax” and allows us to scale the headcount without scaling the bureaucracy.

  • Automation as Infrastructure: At petabyte scale, manual intervention is a failure. I treat the developer experience (CI/CD, observability, self-service infra) as a first-class product to keep the “path to production” frictionless.

How do you balance high-growth velocity with technical stability?

The Philosophy

Technical debt isn’t a “bad thing” to be avoided; it’s a set of historical decisions that no longer serve you. Like any loan, leverage can accelerate growth when investments payoff. But if velocity and returns are slowing you need a payment plan before the interest kills you.

The Strategy

  • The ROI Filter: I don’t refactor for the sake of “clean code.” I don’t refactor a micro-service with no users. I refactor when the pain on that debt - measured in bugs, downtime, or developer frustration - starts to exceed the cost of the fix.

  • Zero-Downtime Culture: Especially at scale, stability is a feature. I implement “Guardrail Engineering” where the system is designed to fail gracefully, ensuring that a Series B growth spike becomes a success story rather than a post-mortem.

  • The 70/20/10 Rule: I typically aim to dedicate 70% of resources to new features, 20% to infrastructure/debt, and 10% to R&D. This ensures we never stop innovating, but we never stop fortifying either.