Moving on

Well today after my return from the land of Lady E, I was awoken early to a busy day. After collecting my things together and having a quick breakfast it was a case of jumping in the car that I practically had to book off of my brother and heading 60 miles down the road to Norwich.

Not to fear, found some Eurphoria to listen to, put the air con on, and with plenty of time it was a very relaxing drive. After parking the car up at the house I walked up the hill to the letting agent. Got the contract and pleasantries out of the way and we headed back down the hill to the house, and an awaiting JC.

After a seemingly endless walk around the house going through the inventory, inspecting the carpet, tiles, kitchen, even examining the number of picture frame hooks on the walls in the hall or heaven’s sake. But after that a pleasant trip to UEA was had, which was great because the whole trip took less than 15 minutes.

An hour sent in the company of bureaucrats was enough to remind me why I dislike them, but I have a job now for the 6 weeks over the summer at £7/hour and 37 hours a week. Which is great. Even if they wont pay me in August, but instead will pay we double in October instead; nice I’m being paid, crap for my finances and paying the bills.

So, being done a bit earlier with my office types earlier than JC was, I got myself back to the car park, lay across the bonnet in the summer sun. Put a bit of chill out on and checked the news on the old iPhone. But further good news came when despite it being the middle of rush hour we managed to get back home in under 14 minutes. Measurement of rooms, discussion of bills, and a few laughs came back at the house. Then we realised that it was fast approaching 6 o’clock and that we’d better head on home.

So, I’m positive about the forthcoming move to Norwich. I have a nice flat that is huge for a reasonable price. I have a good housemate. And I have a job, that is going to be reasonably paid. So, now to sort the whole thing with Lady E and it’ll all be great. That sad I’ve only just got off the phone with her, and we managed to quite happily chat away for over an hour and for it to be not weird or forced. So, come on life. I’m ready for ya.


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

[^1:] http://morganbye.net/moving-on [^2:] http://morganbye.net/2009/08/moving-on) [^3:] http://morganbye.net/blog/?p=21

Older post

Holidays II

Newer post

Last 2 weeks

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.