An Early Lesson About Values in My First IT Job

Based on a LinkedIn post originally published on 13 March 2026

In the late 1980s, in Rio de Janeiro, I started my first real job in information technology.

The company customised an office-administration system originally developed by a British software vendor and adapted for the Brazilian market. Written in BASIC, it supported functions such as:

• payroll;
• accounts receivable;
• accounts payable;
• financial and operational reporting;
• and other everyday administrative processes.

For a young professional, it was exciting. These were real systems used by real organisations. Problems had operational consequences, customers depended on the software and I was being trusted with genuine responsibility.

I was focused on learning the technology and proving that I could do the work.

Then one assignment placed me in a situation for which no technical education had prepared me.

An unexpected visit

One day, I was asked to visit the office of another business partner.

The request itself was unexpected. The transport arrangement made it stranger: a car arrived to collect me, complete with a chauffeur.

In that context, this was unusual enough to make an impression, but I still understood the visit as an ordinary technical assignment. I was there to resolve a computer problem associated with the accounting system.

When we arrived, the nature of the environment became apparent. The building was a fortress-like headquarters connected to one of the most notorious figures operating in Rio at the time.

I will not identify the person. The identity is less important than the professional situation in which I suddenly found myself.

I had arrived as a technician, but the environment made it clear that this was no longer merely a technical support visit.

When business data reveals the business

I began working on the accounting-system problem I had been sent to fix.

While examining the relevant information, I noticed entries whose descriptions appeared to refer to payments made to local police officers.

Seeing such language recorded plainly within business software stopped me cold.

Until that moment, the accounting system had primarily represented program logic, files, reports and customer requirements. Suddenly, it became evidence of the activity conducted through it.

Technical view
    |
    | Accounting application
    | Data records
    | Reports
    | Software defect
    v
Operational reality
    |
    | Who is being paid?
    | For what purpose?
    | What activity does the system support?
    | What am I being exposed to?

The software was not morally neutral in that moment. It was part of an organisational process whose implications extended far beyond whether the code operated correctly.

Complete the immediate task, then leave

I did what I had been sent there to do. I corrected the computer problem, completed the immediate task and left.

That response was shaped by the circumstances. I was young, relatively inexperienced and physically present in an environment whose risks I did not fully understand.

This is an important detail when reflecting on ethical decisions. It is easy, decades later and from a safe distance, to imagine an ideal response. Real situations contain uncertainty, power differences and personal-safety considerations that may not be visible to an outside observer.

Professional integrity does not require reckless confrontation. Recognising risk, protecting oneself and refusing further involvement can be legitimate and necessary decisions.

The more significant reflection began during the journey back.

I started asking what kind of organisation I was working for, what relationships surrounded it and what sort of professional—and person—I intended to become.

Technical responsibility has context

Early in a technology career, it is natural to concentrate on whether one can solve the assigned problem.

Can the program be repaired? Can the data be recovered? Can the system be made operational again?

Experience gradually introduces another category of questions:

• What activity does this system enable?
• Who benefits from the work?
• Who may be harmed by it?
• What information am I being asked to access?
• Is the request legitimate and appropriately authorised?
• What responsibility do I acquire by continuing?

A technically correct action can still contribute to an unethical or illegal purpose. “I only maintain the system” is not always a sufficient moral boundary.

Technology professionals often possess privileged access. They may see financial records, personal information, security controls, internal communications or system behaviour that remains invisible to most employees.

That access creates responsibility as well as technical opportunity.

The importance of context before access

One immediate decision followed from that experience: I would no longer accept company social events or informal invitations without understanding clearly where I was going, who would be present and why my attendance was expected.

Work would be work. Boundaries would be boundaries.

This was not about refusing every unusual assignment or treating colleagues with suspicion. It was about recognising that ambiguity benefits the person who already understands the situation and disadvantages the person being brought into it.

Before accepting an unusual assignment:

Where am I going?
Who owns the organisation?
Why has my presence been requested?
What system or information will I access?
Who authorised the work?
What risks are reasonably foreseeable?
How can I leave or escalate if the situation changes?

Clear context is a basic professional control. It allows a person to make an informed decision before entering an environment or accessing sensitive information.

Boundaries protect judgement

Professional boundaries are sometimes interpreted as inflexibility. In reality, they help preserve independent judgement.

Informal relationships, social obligations and personal loyalty can make it harder to question a request. The more blurred the relationship becomes, the easier it is for inappropriate work to be framed as a favour, an exception or something that should not be examined too closely.

A clear boundary creates space to ask whether the request is legitimate.

A boundary is not merely a restriction placed on others. It is a decision made in advance about how you will behave when pressure, uncertainty or personal relationships make judgement more difficult.

Ethics before formal authority

At that stage of my career, I had no senior title, organisational influence or established professional reputation.

But values do not begin when authority arrives.

A person encounters ethical boundaries long before becoming a manager, architect or executive. The early decisions may be quiet: asking for context, declining an invitation, refusing to conceal a problem or deciding not to return to an environment.

Those decisions form the foundation on which later leadership rests.

A leader who has never developed a personal line under low authority may struggle to find one when the financial and organisational pressure becomes much greater.

What organisations owe their technical staff

Responsibility does not belong solely to the individual engineer.

Organisations should not place employees in sensitive environments without sufficient information, authority and support. A responsible operating model should establish:

• who requested and authorised the work;
• the legitimate business purpose;
• the expected scope of access;
• how unexpected sensitive information should be handled;
• which escalation route is available;
• and how the employee’s personal safety will be protected.

Security policies often concentrate on preventing unauthorised access. They should also help authorised people respond when legitimate access reveals something troubling.

Unexpected sensitive discovery
          |
          v
Do not alter or distribute information unnecessarily
          |
          v
Preserve personal safety
          |
          v
Use a defined confidential escalation channel
          |
          v
Allow authorised legal or compliance review

In a mature organisation, an employee should not have to choose alone between silence, unsafe confrontation and uncontrolled disclosure.

The lesson that remained

That visit stayed with me, not because I handled it heroically or possessed all the answers. I did not.

It stayed with me because it forced an early recognition that technical work exists inside human systems, and those systems carry values, incentives and consequences.

Programming languages, platforms and architectures will change repeatedly throughout a career. The situations in which judgement is required will change as well.

The question of where one’s line stands remains.

Before titles, experience or confidence, I discovered that there were situations in which technical capability was not the most important consideration. Knowing what I would not become mattered more than any technology I could learn.

AI Assistance Disclosure

This article is based on my original ideas, experience, analysis and conclusions. Artificial intelligence tools were subsequently used as editorial and research assistants to review grammar and wording, improve structure and presentation, organise some arguments into clearer logical sections, and help review references to legal, regulatory and technical concepts.

Where relevant, factual and regulatory references were checked against the sources cited in the article. AI assistance does not replace professional legal, regulatory, financial or technical advice, and the final selection, interpretation, opinions and conclusions presented here remain my own.