Nearly there

So, today is Wednesday. And university is all but past tense. He says with his fingers crossed, for Friday we find out if I actually have to do a viva next week. Which if I do then there shall be 30 minutes of hell next week on Tuesday or Wednesday but then it should all be over.

For those not in the know, a viva is essentially an interview where they ask you questions from any topic that you have studied in your time at university. Typically given to students that are borderline candidates (ie 59%), to determine whether you are actually worthy of being bumped up to the next grade boundary. So potentially a very stressful procedure.

Realistically, I should have comfortably have obtained my 2:1. However, that cynical part of my brain worries. And worries a lot. For my PhD placement is conditional to my getting a 2:1, without I will have no funding and thus be unable to do it. So it’s a dilemma.

But, the ending of exams passed without a hitch. Surprisingly so. Anticlimactic if anything. The last exam was a barely a 2nd year module about machines that I’ve been using for over 4 years now, 6 in certain circumstances. One of my essay questions was even on mass spec, the same topic as my entire Masters project, so if I haven’t done well there I need shooting.

However, some would seem to have done less well. Lady E for example, claimed that she could not turn on her calculator; causing a panic attack and thus spending an hour on the first section (which took me under 20 minutes). Tash refused to talk to me after the exam and went storming off, with only a huff as an acknowledgement. Which is a shame for I believe her to not be going to graduation and so that could well have been the last time I see her. But then that summarizes her mentality for the last 4 years, considering how after the previous exam she stayed at the pub with us all afternoon and had a giggle.

So, a return to Nottingham on Friday or Saturday (haven’t decided yet) from Manchester as she’s not going to the 2nd week of work experience. God knows why really. If she knew she had a viva next week then I’d understand, but as it stands we’re going back for no other reason than escaping Manchester. I suppose, she wants to spend all the time with me that she can before graduation. Which I can understand as after graduation, I don’t know the next time I’ll see her, when she’ll get a job or where. But that’s another post for another day.


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

[^1:] http://morganbye.net/2009/06/nearly-there) [^2:] http://morganbye.net/uncategorized/2009/06/nearly-there

Older post

A new beginning

Newer post

Post results

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.