The Montreal Office That Felt Different

In June 2010, I wrote about Presagis, a software company in Montreal.

The entry was technical in places.

It mentioned modeling and simulation, embedded systems, visualization software, product architecture, training revenue, Linux support, and the company’s relationship with CAE.

But when I read it now, the technical details are not what stay with me most.

What survives is the office.

The people.

The rhythm.

The feeling that this workplace operated according to rules slightly different from the ones I was used to.

I wrote that Presagis had its main office in Montreal.

Even though it was a software company, I was struck by how many people seemed to work outside direct development.

In my impression at the time, a surprisingly large portion of the company was involved in marketing, quality, or testing rather than simply writing code.

That already challenged a younger assumption.

A software company, from the outside, looks like a place full of programmers.

From the inside, software is surrounded by everything required to sell it, test it, document it, support it, teach it, integrate it, and persuade customers to trust it.

A product does not travel from developer to customer by itself.

Companies are larger than the code they produce.

That seems obvious to me now.

It was more interesting to me then.

The work schedule was even more memorable.

I wrote that there was a minimum of five hours a day and thirty hours a week.

If someone completed thirty-five hours, they could apparently leave around noon on Friday.

I should be careful with the wording here.

This is what I observed and recorded in 2010.

It is not a claim about the company’s policies today.

What mattered to me was the contrast.

Time seemed more negotiable.

The workplace did not look organized around proving that you were sitting at a desk for the maximum possible number of hours.

There were boundaries.

There were expectations.

But there was also room.

That made an impression on me.

Especially because early in a career, many people confuse long hours with seriousness.

You work late.

Therefore you care.

You leave early.

Therefore perhaps you do not.

This logic is easy to absorb because presence is visible.

Thinking is not.

Good judgment is not.

Avoiding unnecessary work is not.

A person sitting in the office at 9 p.m. is easy to count.

A person who prevented two weeks of pointless work through one good decision is harder to measure.

Workplaces often reward the visible thing because the visible thing is convenient.

The Montreal office seemed, at least from my limited perspective, to take a more relaxed view of this.

I also wrote about the games.

Foosball.

Darts.

Billiards.

The time spent playing did not count as work.

That distinction amused me.

You could play.

Nobody would apparently come over and say:

Enough.

Get back to work.

But the clock also did not pretend you were working while playing.

There was freedom without the need to redefine leisure as productivity.

I like that.

Modern workplaces sometimes try too hard to make everything part of the corporate identity.

Games become “team engagement.”

Coffee becomes “culture.”

A lounge becomes “innovation space.”

Fun must be justified in professional language before anyone is allowed to enjoy it.

The office I described felt simpler.

There were games.

People played.

The company did not collapse.

That may be the healthiest possible interpretation.

The younger version of me also noticed compensation.

I wrote that salaries did not seem especially satisfying.

But I also said that, as a place to live and as a starting point, the company could still be a reasonable place.

That is another useful reminder.

A job is never only salary.

Salary matters enormously.

Especially when it is insufficient.

But work is also location.

Colleagues.

Hours.

Learning.

Stress.

Mobility.

Autonomy.

The kind of life possible around the job.

You cannot reduce all of that to one number.

You also should not use “culture” as an excuse for poor pay.

Both truths can exist.

The interesting part is the tradeoff.

People make career decisions using bundles, not isolated variables.

A slightly lower salary in a city you enjoy may be acceptable.

A high salary inside a miserable environment may not.

A relaxed schedule may compensate for one weakness.

A strong learning opportunity may justify a temporary sacrifice.

The balance changes with age and circumstance.

In 2010, I was noticing that balance in someone else’s workplace.

The product itself also interested me.

I described it as having an open architecture.

You could apparently add or remove things relatively easily.

That flexibility impressed me.

Then came one of the more memorable conversations.

I wrote that the company made money from training.

When customers asked why something simple had not been added directly into the product, the joking answer could be something like:

If we added everything, how would we make money from training?

I cannot know how literally that exchange should be taken.

It may have been humor.

It may have reflected a real commercial attitude.

The archive only preserves how I understood it.

But the tension itself is real.

Software companies do not only design products.

They design business models around products.

Sometimes what is technically easy and what is commercially desirable are not the same thing.

That can surprise engineers.

Engineers often assume that if something can be made easier for the user, it should be.

Business asks another question:

What are we selling?

Support?

Training?

Customization?

Licenses?

Consulting?

Convenience?

Complexity can be accidental.

It can also become revenue.

That is uncomfortable.

But useful to understand.

The younger engineer in me still wanted the product to be judged mainly as a technical object.

The company knew it was also an economic object.

Both perspectives are necessary.

Ignore engineering and the product fails.

Ignore economics and the company fails.

The difficult part is preventing commercial incentives from making the product unnecessarily hostile.

That balance remains one of the recurring problems of software.

I was less charitable about Linux support.

The entry says the company could promise Linux support and then become evasive after the sale.

Again, this is my 2010 observation, not a current accusation.

What matters now is the lesson about promises made during sales.

Technical people and salespeople can inhabit very different realities.

Sales wants possibility.

Engineering wants certainty.

The customer hears commitment.

If these three interpretations are not aligned, disappointment is almost guaranteed.

“Supported” is one of those dangerous words.

Supported how?

Officially?

Partially?

Best effort?

Tested?

Certified?

Only on one distribution?

Only under certain configurations?

Words that sound clear during a sales conversation can become painfully ambiguous during implementation.

This is one reason precise language matters in technical work.

A vague promise is easy to sell.

Expensive to fulfill.

The office culture returned at the end of the entry.

After Presagis had been acquired by CAE, I wrote that much of the upper management seemed to come from CAE.

People with private offices would hang notes on their doors.

Simple notes.

In the restroom.

Not in today.

At Friday prayer.

At CAE.

This tiny detail stayed with me.

Not because door notes are extraordinary.

Because they made the workplace feel human.

You knew where someone was.

The note did not need a calendar system, a status dashboard, or a corporate workflow.

A piece of paper was enough.

That is the kind of thing memory likes.

The official structure disappears.

The handwritten sign remains.

I described the employees as friendly, sincere, and young.

I wrote that the atmosphere lacked the stiffness I had seen in some other foreign companies.

That sentence probably says as much about me as it does about the company.

Travel makes comparison automatic.

You enter a new office and compare it with every office you know.

How do people dress?

How do they speak to managers?

How loud is the room?

Do doors stay open?

Do people joke?

Do they eat together?

Can somebody say no to a meeting?

Does hierarchy announce itself?

These details tell you more about culture than official values printed on a wall.

The strongest memories of workplaces are often behavioral.

Not mission statements.

Who laughed?

Who stayed late?

Who could interrupt whom?

Who closed the door?

Who looked nervous when the manager arrived?

Culture lives in these small observations.

The Montreal office felt lighter to me.

That does not mean it was perfect.

The same entry complains about pay, support promises, and commercial behavior.

This is why I trust the memory more.

It is mixed.

Real places are mixed.

A workplace can have friendly people and frustrating policies.

A good schedule and weak compensation.

An interesting product and annoying support.

A relaxed atmosphere and business decisions you dislike.

We often simplify old experiences after leaving them.

Great place.

Terrible place.

Good company.

Bad company.

The original entry resists that simplification.

I liked parts.

Criticized parts.

Observed parts.

That feels closer to life.

Another thing stands out now.

I was watching work culture while still relatively early in my own professional life.

That is an important period.

Before you have seen many organizations, each new one expands your idea of what a workplace can be.

You discover that the rules you assumed were universal are local.

Not every office starts at the same hour.

Not every manager behaves the same way.

Not every company treats Friday the same way.

Not every technical product is organized around the same business model.

This is one of the hidden values of working abroad or visiting foreign companies.

You do not only learn a technology.

You learn that institutions are designed.

The workplace you came from is not nature.

It is one possible arrangement.

That realization creates freedom.

Once you see alternatives, you can evaluate your own environment differently.

Why do we do this?

Because we have to?

Or because we always have?

That is a dangerous question in the best sense.

Travel asks it constantly.

A different office shows different assumptions.

Then you return home carrying those comparisons.

Some are superficial.

Some are useful.

Some are unfair because you saw the visitor version of the company.

Visitors rarely experience the full burden of a workplace.

They do not live through annual reviews.

Office politics.

Long projects.

Bad quarters.

Reorganizations.

Routine frustrations.

A few weeks or months can make a place look better or worse than long-term employment would.

That limitation matters.

My 2010 entry is not an employee satisfaction survey.

It is an observer’s snapshot.

That is exactly how it should be read.

Snapshots are still valuable.

They preserve first impressions.

And first impressions often capture things long-term familiarity later hides.

The games in the office.

The hours.

The notes on the doors.

The youthfulness.

The relaxed interactions.

After years in a workplace, these details become normal.

A visitor sees them immediately.

Maybe this is why outsiders sometimes describe our own environments better than we do.

We stop seeing the obvious.

The Montreal trip also sat inside a larger period of discovering the professional world.

Software was no longer only something written on a computer.

It belonged to companies, contracts, training, support, acquisitions, marketing, quality teams, and customers.

Products had histories.

Organizations had cultures.

Technology had economics.

That widening perspective is part of becoming an engineer.

At university, technical problems arrive cleanly.

Here is the task.

Here are the inputs.

Solve it.

Professional life introduces everything around the problem.

Budget.

Schedule.

Legacy code.

Customer expectations.

Office culture.

Management.

Sales promises.

Licensing.

Training.

Human behavior.

Suddenly the technical problem may be the easiest part.

The old entry accidentally documents that transition.

I went to a software company and noticed the software.

But I also noticed Friday afternoons.

Billiards.

Marketing.

Door notes.

Training revenue.

Management changes.

Friendly employees.

That tells me I was already learning that technology is produced by institutions, not only by engineers.

Years later, I think that may be the more durable lesson.

Products age.

Companies change ownership.

Policies change.

Software versions disappear.

But once you understand that engineering exists inside human systems, you stop evaluating technology in isolation.

Who builds it?

Under what incentives?

Who sells it?

Who supports it?

Who trains the users?

How are employees treated?

What behavior does the organization reward?

These questions shape the product as surely as code does.

Sometimes more.

I would also be more careful today with cultural comparisons.

The old archive contains broad impressions about different nationalities and work habits from that period.

Those kinds of generalizations come easily during international travel because the sample is small and the contrasts feel vivid.

But a few colleagues cannot represent a country.

A few meetings cannot define a culture.

The useful part is the specific behavior observed.

The risky part is turning behavior into nationality.

That is one area where an older reading should be more disciplined.

Keep the scene.

Drop the stereotype.

A person cancels a meeting for tennis.

Interesting.

A person arrives extraordinarily early to finish work.

Interesting.

Turning either person into a national theory is unnecessary.

Experience becomes more accurate when we resist that temptation.

That is another benefit of revisiting old writing.

You can preserve the memory while improving the interpretation.

The event does not need to change.

Your framework can.

This is what I want these reconstructed posts to do.

Not pretend I thought in 2010 exactly as I do now.

That would erase the archive.

But also not repeat every old conclusion as though time taught nothing.

The younger voice should remain visible.

The older voice can answer.

That conversation across time is more interesting than either one alone.

So what remains of Presagis for me now?

Not a product brochure.

Not an architectural diagram.

Not the exact composition of departments.

What remains is a workplace in Montreal where I noticed that people could apparently organize their week with unusual flexibility.

Where a foosball table did not require a philosophy.

Where private offices had pieces of paper on the door explaining where the person had gone.

Where the people felt young and approachable.

Where technical openness existed beside commercial calculation.

Where software was clearly part of a larger business world I was still learning to read.

That is enough for a memory.

Maybe more than enough.

Because when I think back to the places that changed how I understood work, they were rarely the places that delivered one grand lesson.

They were the places that quietly showed me another arrangement was possible.

Another way to structure a day.

Another way to build a company.

Another way for technical work and ordinary life to coexist.

You do not need to adopt every part of that model.

You only need to see it once.

After that, your old assumptions can never again pretend they are the only rules.