Getting Lost in an Aerospace Company in Montreal

Some workplaces impress you with a presentation.

Others impress you because it takes a week to learn how not to get lost inside them.

My memory of visiting an aerospace company in Montreal belongs to the second category.

In 2010, I wrote a long entry about the place.

At the time, I was interested in all the technical facts.

Simulation systems.

Software.

Hardware.

Engineers.

The scale of the operation.

But years later, what survives most clearly is not a specification.

It is the atmosphere.

A huge building near an airport.

Aircraft appearing constantly outside.

A cafeteria where the staff seemed to develop opinions about what you would and would not like to eat.

Security procedures capable of turning an ordinary laptop into an international diplomatic issue.

And somewhere below, among the simulators, a Turkish flag.

That is the kind of detail memory keeps.

The company was close enough to the airport that aircraft seemed to arrive every few minutes.

When you work around aerospace, you would think airplanes eventually become background noise.

Maybe they do for the people who stay there every day.

For a visitor, they do not.

An aircraft descending nearby is still an aircraft descending nearby.

You look.

Then another arrives.

And another.

The place constantly reminds you what the work is connected to.

This is one of the differences between engineering as something studied at university and engineering as something done in the world.

At university, systems exist mostly as diagrams.

Boxes.

Signals.

Arrows.

Inputs.

Outputs.

Equations.

You can spend hours discussing a system without ever seeing the physical thing it eventually belongs to.

Then you enter an aerospace facility and the abstraction acquires weight.

The software runs somewhere.

The simulator has walls.

Cables.

Racks.

Seats.

Displays.

People.

A machine that once existed only as an idea in a lecture now occupies an entire room.

That transition is important for a young engineer.

It changes scale.

The computer on your desk is no longer the whole system.

It is one small part of something much larger.

Sometimes absurdly larger.

The building itself taught this lesson before the engineering did.

For roughly the first week, I wrote, you were still learning how not to get lost.

That may have been an exaggeration.

It did not feel like one.

Large technical organizations have their own geography.

Corridors that look identical.

Restricted areas.

Doors controlled by badges.

Stairs that appear to lead somewhere useful and somehow do not.

Floors connected in ways that become obvious only after you have made the same wrong turn several times.

A new employee or visitor develops landmarks.

Turn at that machine.

Pass the meeting rooms.

If you see those elevators, you have gone too far.

Do not use that staircase.

Eventually the building becomes understandable.

Until then, you are navigating by experiment.

Which is, I suppose, appropriate for engineers.

Even smoking became an engineering problem.

Smoking was not allowed inside.

Reasonable.

So you had to go outside.

Also reasonable.

Unless your desk happened to be in the middle of the building, far from an exit.

Then the trip from desk to cigarette could approach twenty minutes.

That changes the economics of smoking.

You no longer take a cigarette break.

You launch an expedition.

Leave desk.

Walk.

Pass corridors.

Reach exit.

Smoke.

Return.

By the time you are back, you may be ready for another cigarette.

This is not an efficient system.

Perhaps it was an accidental smoking-cessation program.

I did not describe it that way then.

I simply noticed the absurdity.

Technical workplaces are full of these contradictions.

A company can design extremely sophisticated systems while everyday human behavior remains wonderfully primitive.

We build simulators capable of recreating complex machines.

Then somebody spends fifteen minutes searching for the correct meeting room.

We engineer systems with enormous precision.

Then lunch is decided by the woman behind the cafeteria counter looking at you and saying, in effect:

“You will like this.”

“You will not like that.”

That cafeteria stayed in my memory because the people working there were friendly enough to comment on what suited you.

It was a small thing.

But small things often determine whether a foreign workplace feels cold or human.

You can be surrounded by impressive technology and still remember the person serving lunch.

Perhaps especially then.

Technology is expected to be impressive in an aerospace company.

Warmth is more surprising.

I also remember how international the place felt.

Different nationalities.

Different working styles.

Different accents.

Different assumptions about work.

My old entry contains the broad generalizations of a younger engineer observing everyone and trying to create categories quickly.

The French.

The Chinese.

The Turks.

Who worked hardest.

Who canceled meetings.

Who was easier to communicate with.

Looking back, I would be more careful with those conclusions.

A handful of colleagues cannot represent entire countries.

But the underlying experience was real:

for the first time, work was showing me that engineering culture was not one culture.

People could solve the same technical problem while having very different ideas about meetings, urgency, hierarchy, time, and communication.

That is something no textbook explains very well.

Technical standards cross borders more easily than human habits do.

A protocol is a protocol.

A voltage level is a voltage level.

A requirement can be written down.

But what does “urgent” mean?

What does “tomorrow” mean?

How directly should you disagree with someone?

How late can a meeting begin before it is considered late?

When should you stay at work?

When is it perfectly acceptable to leave?

These are not engineering questions.

Yet international engineering projects depend on them constantly.

One of the funniest contrasts I noted involved meetings and working hours.

A person from one culture might treat a personal plan as a completely acceptable reason to move a meeting.

Someone else might accept a task and appear at an hour when no reasonable human being should be voluntarily entering an office.

At the time, I judged these differences quickly.

Now I think I was observing something more useful:

productivity does not have one costume.

Being physically present for long hours does not automatically mean better work.

Leaving on time does not automatically mean indifference.

Different organizations develop different bargains with their employees.

That was another thing Montreal showed me.

There were companies where work seemed designed to occupy your entire identity.

Others treated work as an important part of life without pretending it was the only part.

For a young engineer trying to imagine a career, these observations mattered.

You are not only choosing what technology to work on.

You are choosing environments.

Cultures.

Managers.

Cities.

Ways of spending days.

This is easy to underestimate when you are a student.

A job advertisement is mostly nouns.

Software engineer.

Embedded systems.

Simulation.

C++.

Linux.

Aerospace.

The actual experience is verbs.

Commute.

Wait.

Meet.

Debug.

Explain.

Eat.

Walk.

Argue with security.

Try to leave the building with the same computer you entered with.

That last one deserves special attention.

Security was serious.

Again, reasonable for the environment.

The interesting part was that getting a computer into the building could be easier than getting it out.

You could arrive carrying a machine.

Forms were checked.

Permissions were given.

Everyone understood why it was entering.

Then later you tried to leave with it.

Suddenly the object became suspicious.

Where is this going?

Whose is it?

Was it authorized?

But I brought it in.

Yes.

And now you are taking it out.

Exactly.

That is the plan.

Security systems have their own logic.

The engineer approaches the problem with causal reasoning:

The computer belonged to me before entry.

It entered with me.

Therefore it can leave with me.

Security approaches it with procedural reasoning:

Show me the authorization.

In theory, these systems protect extremely valuable information and equipment.

In practice, there are moments when you stand beside a guard trying to explain the biography of a laptop.

It is difficult to feel like part of the technological future during such conversations.

One detail in the building affected me more than I expected.

There were only a small number of Turkish employees compared with the thousands of people around them.

Yet down where the simulators were located, there was also a Turkish flag.

A flag is a simple object.

Usually I do not think much about one when I see it at home.

Outside the country, context changes it.

Suddenly it is not decoration.

It is evidence of connection.

Someone from here worked here.

Something involving your country passed through this place.

A tiny familiar symbol appears inside a huge foreign technical environment.

You notice it.

I did.

That may be one of the reasons travel matters for engineers.

It changes the meaning of scale.

You see enormous organizations and realize they are still made of individuals.

You see technology produced internationally and realize your own work can enter that network.

You see how much you know.

You also see how much you do not.

That second lesson is usually larger.

University can accidentally make technical knowledge feel complete.

You pass the course.

You understand the chapter.

You solve the problem.

Then professional systems introduce hundreds of things that were never on the exam.

Legacy software.

Certification.

Procurement.

Security.

Configuration management.

Hardware that must survive real conditions.

People from different disciplines using the same words differently.

Tools developed twenty years earlier that everyone still depends on because replacing them would be madness.

You begin to understand that engineering is not a clean march from old technology to new technology.

It is layers.

Old systems supporting new systems.

New interfaces wrapped around old assumptions.

Decisions preserved because changing them would cost too much.

The real world contains technical archaeology.

That fascinated me.

My 2010 entry tried to capture all of it at once.

The impressive parts.

The irritating parts.

The people.

The food.

The planes.

The long walk outside for a cigarette.

The security guards.

The international workforce.

The Turkish flag.

Reading those observations now, I can see a young engineer doing something engineers often do when entering a complicated system:

mapping it.

Where are the important components?

How do people behave?

What works?

What is ridiculous?

Where are the bottlenecks?

Where is the cafeteria?

How do I get outside?

How do I get back to my desk?

The questions were not all equally important.

But together they created a picture.

That is what I remember most about Montreal.

Not one technical lesson.

The feeling of entering a much larger machine and slowly learning where I was inside it.

For the first few days, I could barely find my way through the building.

Perhaps that was appropriate.

Early in a career, you are doing the same thing everywhere else.

You think you are learning a company.

Really, you are learning the size of the world you have just entered.