What a 1985 Ferranti Internship Taught Me About Technology, Responsibility and Leadership

What Working Around Laser-Guided Weapon Systems Taught Me About Responsibility

Technology leadership lessons can come from unexpected places, and one of mine came from a 1985 internship at Ferranti Electro-Optical Weapons in Edinburgh, Scotland. I was early in my career, working around defence engineering, including laser-guided weapon systems, in an environment where precision, discretion and traceability mattered every day. Part of my role involved entering a clean room each day and conducting an audit of where each assembly was in the build process. The work was covered by the Official Secrets Act, so I am keeping the technical detail deliberately high level. What I can talk about is the lesson that stayed with me: serious technology is never just about the system, it is about the people, risks, process and responsibilities behind it.

Takeaways

A Young Intern in a Serious Engineering Environment

In 1985, I did an internship at Ferranti Electro-Optical Weapons in Edinburgh.

At the time, I did not fully understand how much that experience would shape the way I think about technology. I was young, learning fast and surrounded by people doing work where detail mattered. It was not a casual environment.

The work included exposure to laser-guided weapon systems. I will not go into technical detail. That work was covered by the Official Secrets Act, and there are some things you simply do not discuss publicly, even decades later.

The Law Commission explains that the criminal law provisions protecting official information are primarily contained in the Official Secrets Acts 1911 to 1939 and 1989. It also notes that protected information includes areas such as security and intelligence, defence, and international relations.  

In 1985, the 1989 Act had not yet been passed, so the older Official Secrets Act framework was the relevant backdrop. The 1989 Act later replaced section 2 of the Official Secrets Act 1911 with provisions covering more limited classes of official information.  

For a young technologist, that created a clear lesson.

Some systems carry serious consequences.

You learn quickly that documentation matters. Testing matters. Assumptions matter. Handover matters. You also learn that smart people still need good process, because human memory is not a quality management system. Handy, yes. Reliable under pressure, not always.

The Daily Clean Room Audit

One of my daily responsibilities was entering a clean room and auditing where each assembly was in the build process.

That may sound like a small task, but it taught me a lot.

Each assembly had a status. Each step mattered. Each handover needed to be clear. The point was not just to know that work was happening. The point was to know exactly where each piece of work sat, what stage it had reached and what needed to happen next.

In that kind of environment, “I think it’s nearly done” was not good enough.

You needed traceability.

That word can sound dry, but it is incredibly practical. It means you can follow the work. You know where it started, where it is now, who touched it, what stage it is at and what still needs to happen.

That lesson has stayed with me.

Modern software teams need the same thinking. A founder should not have to guess whether a feature is half-built, waiting for testing, blocked by a decision, or ready to release. A leadership team should not have to chase five people to understand project status.

A customer should not suffer because nobody knew where the work had stalled.

Good process gives people clarity.

And clarity reduces stress.

The Cold War Context Behind the Work

The wider context in 1985 was the Cold War.

The Cold War as the political rivalry that developed after the Second World War between the United States, the Soviet Union and their allies. It says the Cold War was fought mainly through political, economic and propaganda pressure, with limited direct use of weapons between the superpowers.

That context matters.

Defence engineering in the mid-1980s was shaped by a world that expected conflict, prepared for escalation and invested heavily in military technology. Laser-guided weapon systems sat inside that broader defence environment.

There were also active wars at the time.

The Iran-Iraq War began with open warfare on 22 September 1980, and fighting ended with a 1988 ceasefire. The Soviet Union also invaded Afghanistan in late December 1979 and remained there until mid-February 1989.

I would not claim the systems I saw were built for one specific war.

That would be too strong, and it would be the wrong kind of storytelling. The more accurate point is that the work belonged to a Cold War defence world where active conflicts, deterrence and military preparedness shaped technology investment.

That is enough.

You can tell the truth without overreaching.

Ferranti and Edinburgh’s Defence Technology History

Ferranti had a deep connection with Edinburgh’s technology story.

Leonardo’s history of the Crewe Toll site notes that Ferranti’s Edinburgh operation was part of the UK electronics businesses consolidated when GEC acquired Ferranti in 1990, creating a major radar, electronic warfare and electro-optic business. It also notes that Ferranti delivered cockpit display systems for the Tornado programme in the 1980s, and that the Edinburgh site remained connected with advanced radar and electronic warfare work.  

That history matters because it shows the environment I walked into was not a random workshop.

It was part of a serious engineering tradition. Edinburgh was not just a place of universities, finance and festivals. It was also a technology centre with deep defence engineering roots.

As an intern, being around that kind of work gave me a different view of engineering.

It was not glamorous. It was not loose. It was not “move fast and hope nobody notices.” It was careful, structured and serious.

That shaped me.

The Official Secrets Act, in Plain English

The Official Secrets Act is often misunderstood.

People sometimes imagine it as something from spy novels. Secret files. Rainy streets. Men in coats looking suspicious near railway stations.

The reality is more practical.

For people working around sensitive defence technology, it means protected information must not be disclosed without authority. That can include documents, designs, processes, capabilities, locations, communications and other details connected to national security.

In plain English, it means:

• Do not talk publicly about sensitive work.
• Do not share protected technical information.
• Do not disclose details because they make a good story.
• Do not assume time makes every detail safe.
• Do respect the trust placed in you.

That last point is important.

Trust is not only a legal matter. It is a professional one.

Even now, I can talk about the experience, the lessons and the leadership impact. I cannot and will not talk about restricted technical details.

That boundary is part of the lesson.

Good technology leadership includes knowing what not to say.

Technology Is Never Just Technology

Working near laser-guided weapon systems made one thing very clear.

Technology has weight.

A decision is not just a decision. A test is not just a test. A missed detail is not just an admin issue. There are people and consequences downstream.

That lesson has followed me throughout my career.

I saw it later in software development. I saw it in web development. I saw it in digital marketing, where a poorly built system could waste a client’s money. I saw it in CTO roles, where architecture decisions could shape hiring, cost, security and customer experience for years.

The tools changed.

The responsibility stayed.

That is why I often come back to my core belief: people before technology.

Technology exists to serve people. Customers. Staff. Founders. Partners. Communities. The person trying to use the system on a stressful Monday morning.

When technology leaders forget that, projects go sideways.

Precision Beats Cleverness

One of the biggest lessons from that early environment was the value of precision.

Cleverness is useful.

Precision is safer.

In serious engineering environments, vague thinking gets exposed quickly. You need clear requirements. You need good records. You need testing. You need people willing to check their own work and invite others to challenge it.

That applies directly to modern software and business systems.

A SaaS product may not be a weapon system, but the same leadership principle applies. If people depend on it, it needs care.

For founders, this matters.

A vague feature request can become weeks of rework. A missing backup process can become a business outage. A rushed cloud setup can become an expensive rebuild. A poor security decision can become a customer trust problem.

Good technology work is not about making everything slow.

It is about putting the right level of discipline around the work, so your team can move with confidence.

That is the balance.

Move fast, but do not drive blindfolded.

Serious Work Needs Good Documentation

My daily clean room audit taught me that documentation is not just paperwork.

It is how serious work stays visible.

Every assembly needed to be tracked through the build process. If something moved from one stage to another, that mattered. If something was delayed, that mattered. If something needed review, that mattered too.

The audit created a shared view of reality.

That is one of the most useful lessons I carried into technology leadership. In software, web projects, SaaS platforms and business systems, teams often struggle because nobody has a clear view of where the work really is.

Documentation is not exciting.

I know. Nobody starts a business because they dream of creating a beautiful risk register.

But documentation matters.

You need to know:

• Why a decision was made.
• How a system works.
• Who has access.
• Where data lives.
• What happens if something fails.
• How to recover from a problem.
• What was tested.
• What risks are still open.

This is not paperwork for the sake of paperwork.

It protects people.

It protects the business.

It protects the next person who has to maintain the system after the original developer, vendor or internal champion has moved on.

I have seen businesses lose weeks because nobody documented a critical setup. I have seen founders stuck because only one developer understood the platform. I have seen teams afraid to change systems because nobody knew what might break.

That is avoidable.

Documentation is not bureaucracy when it keeps your business moving.

What Defence Engineering Taught Me About Risk

Risk is not something you remove completely.

You manage it.

That was another lesson from early defence-related work. Serious systems are built with risk in mind. People ask what could fail, what could be misunderstood, what needs review and what must be tested before release.

Modern businesses need the same mindset.

Not the same level of process. That would be overkill for most SMEs. But the thinking is useful.

Ask:

• What could go wrong?
• Who would be affected?
• How likely is it?
• How bad would it be?
• How would we know?
• What can we do now to reduce the risk?
• What do we need to document?

That is good leadership.

It is especially useful in software projects, cloud migration, cybersecurity, vendor selection, data handling, disaster recovery and business continuity planning.

For example, if your customer database fails, what happens? If your developer leaves, who understands the codebase? If your cloud bill doubles, who notices? If your payment provider goes down, how do customers pay?

These are not negative questions.

They are responsible questions.

The Human Side of Serious Technology

The best technical environments are not just full of clever people.

They are full of people who respect the work and respect each other.

As an intern, you are not the expert. That can feel uncomfortable, but it is also a gift. You learn to listen. You learn to ask better questions. You learn that experience has value.

That has shaped how I mentor teams today.

Junior people need room to ask questions. Senior people need to explain, not just judge. Leaders need to create a culture where concerns are raised early rather than hidden until they explode.

A strong team is not built by hiring smart people and leaving them alone.

It is built through trust, standards, feedback and shared ownership.

This applies in a defence engineering workplace. It applies in a SaaS startup. It applies in a growing SME trying to modernise its systems. It applies in a local business replacing manual processes with better software.

People do better work when they know why the work matters.

Why This Still Matters to Founders Today

You might be reading this as a founder or business owner and thinking:

“That is interesting, but I’m not building laser-guided weapon systems.”

Fair point.

Most businesses are dealing with more everyday problems.

A messy CRM. A web app that is hard to scale. A developer handover. A cloud bill that keeps rising. A project that is drifting. A security concern. A vendor proposal that feels too technical. A product roadmap that changes every week.

The environment is different.

The leadership lessons are still useful.

Before you make a major technology decision, ask:

• What are we trying to achieve?
• Who depends on this system?
• What happens if it fails?
• What information needs protecting?
• What needs documenting?
• Who owns the decision?
• How will we know it worked?
• What support will the team need?

These questions make technology safer, clearer and more useful.

They also reduce waste.

That is important for SMEs and startups. You do not always have the budget to fix avoidable mistakes later.

The Bridge From Engineering to Technology Leadership

Looking back, that internship was one early step in a much longer career.

I moved through software development, web development, digital marketing, technology leadership and consulting. Along the way, the tools changed dramatically.

But the core lessons stayed surprisingly steady.

Care about quality.

Respect the people using the system.

Think through risk.

Write things down.

Know where the work sits.

Do not let cleverness outrun responsibility.

Build systems that someone else can understand later.

Those lessons now shape how I advise clients.

When I review a software proposal, I am not only looking at the features. I am looking at risk, maintainability, scalability, cost and whether the team can support it.

When I help a founder think through a product roadmap, I am not only asking what can be built. I am asking what should be built, what can wait and what creates real value.

When I coach a team, I am not only talking about process. I am looking at clarity, trust and how people work together under pressure.

That is what technology leadership means to me.

What Business Owners Can Take From This Story

You do not need a defence engineering background to apply the lesson.

You just need to treat technology decisions with the right level of care.

Here are the practical takeaways for business owners:

• Treat technology as a business responsibility. It affects customers, staff, cash flow and trust.
• Ask better questions early. Early clarity is cheaper than late rework.
• Document key decisions. Future you will be grateful.
• Protect sensitive information. Data, access and security are leadership issues.
• Build with maintenance in mind. A system someone else can support is a safer system.
• Listen to experienced people. Good advice can save months of pain.
• Keep people at the centre. The best technology serves real human needs.

That is not overthinking.

That is responsible leadership.

The Lesson That Stayed With Me

That 1985 internship at Ferranti in Edinburgh taught me more than technical discipline.

It taught me that technology carries responsibility. My daily clean room audits showed me that serious work needs visibility, traceability and care at every stage. The more important the system, the more carefully the work needs to be managed.

That idea has stayed with me through every stage of my career, from software development to CTO leadership and consulting.

Build the technology properly, but never forget who it is for.

Frequently Asked Questions

What was Ferranti Electro-Optical Weapons?

Ferranti was a major UK engineering and electronics company with defence technology operations in Edinburgh. Its later Edinburgh history is connected with radar, electronic warfare and electro-optic work through the companies that followed it.

What is the Official Secrets Act?

The Official Secrets Act refers to UK laws that protect official information, including sensitive information connected to security, intelligence, defence and international relations. In practical terms, it means protected information cannot be disclosed without authority.

Can you talk about the laser-guided weapon systems?

Only at a high level. I can refer to the broad context and the leadership lessons, but I will not discuss restricted technical details, designs, capabilities or processes.

What war was current in 1985?

The wider setting was the Cold War, which lasted from 1947 to 1991. Active conflicts at the time included the Iran-Iraq War and the Soviet presence in Afghanistan.

Why is this relevant to business owners today?

The systems are different, but the leadership lesson is the same. Important technology needs clear thinking, documentation, risk management, good communication and a strong focus on the people who depend on it.