What working on both sides taught me about contractors and employees

For much of my career, consulting has overlapped with embedded engineering and leadership roles. I have entered organizations from the outside, but I have also stayed inside teams long enough to live with their decisions, incidents, workarounds, and handoffs.

Working on both sides changed how I think about the familiar comparison between contractors and employees. The conversation usually begins with price. The contractor has a day rate that looks expensive before lunch. The employee's cost disappears into salary bands, benefits, recruitment, management, equipment, onboarding, retention, and several budgets that nobody puts next to one another. The comparison is tidy. Reality, as usual, is different.

Then come the familiar stereotypes. Contractors are fast, direct, and result-oriented. Employees are committed, understand the domain, and remain long enough to deal with the consequences.

There is enough truth in both descriptions to make them useful, but neither describes the whole job.

In my experience, contractors are often better at entering a system. Employees are usually better at living with it.

This is not a character judgment. It is what the two positions trained me to see. When I arrive as a consultant, I carry patterns from other organizations. When I work inside a team, I carry the memory of this one.

Neither view is complete.

What I notice when I enter from the outside

When I enter a new organization as a consultant, I have one unfair advantage: the organization is not normal to me yet. The twelve approvals, the release that needs six people in a call, the service nobody wants to touch, and the decision that has travelled through three steering groups still look strange.

I have also experienced the other side. Inside a company, I may see exactly the same problems, but I have had more time to learn which ones can be challenged, which ones will consume a month of discussion, and which ones everyone has agreed to step around. Yesterday's temporary workaround becomes today's process. Given enough time, the process acquires an acronym and becomes official.

Consulting across several projects makes these patterns easier for me to recognize. I can often identify a familiar queue, ownership gap, architectural constraint, or process whose purpose is no longer obvious before the organization has finished explaining why its situation is unique.

Every organization is unique, of course. Several are unique in surprisingly familiar ways.

That speed is valuable. It is also where I have to slow down.

A pattern is not the same as an explanation. An unusual validation rule may protect a contractual exception. A manual approval may reflect operational learning that is not documented elsewhere. An apparently confusing service boundary may follow a business boundary that is invisible in the repository.

I can name the pattern quickly and still have only part of the context needed for a decision.

The people who have lived with the system have something my breadth cannot replace: memory of consequences. They remember which customer depends on the strange behaviour, which migration was attempted before, and why a technically beautiful proposal changed when it reached operations. Some of that is real domain knowledge. Some of it is organizational folklore that nobody has revisited for years.

The difficult part is knowing which is which.

I can be more direct from the outside

My team is valued partly because we say things directly. We raise concerns that other teams have become comfortable with, question decisions that already have institutional momentum, and say when a proposed direction does not survive contact with the actual system.

I find that easier from the outside. As a consultant, I have fewer promotion paths to protect, fewer old disagreements attached to the current one, and less reason to pretend that a senior stakeholder's favourite idea is merely “a promising direction that may need further validation.”

Sometimes the useful sentence is simply: I do not think this direction will give us the result we need.

That does not make me naturally braver when I consult or naturally more cautious when I work inside a company. The position changes the relationships around the conversation. Employees understand the history behind a proposal and know how today's discussion will affect tomorrow's collaboration. That context can make disagreement more deliberate.

External status creates room for directness, but directness is useful only when it comes with curiosity. A confident outside perspective should still make space for the people who understand the domain, explain its constraints, and will continue the work after the engagement. My independence matters most when I use it to make the organization more capable, not more dependent on me.

Directness is not a personality trait in this context. It is part of the product.

One engagement changed how I think about continuity

The narrowest version of contracting is easy to recognize. A group arrives, delivers a project against a defined scope, presents the result, and hands it to the employees who will operate and evolve it. The project is complete. Production, with its usual lack of respect for milestone dates, has only just become interested.

I have seen that model, but one of my recent engagements showed me the opposite. We worked on a time-and-materials basis with dedicated ownership. We had enough continuity to remain with the decisions, operate around their consequences, and adjust when reality disagreed with the original plan.

We were contractors on paper and long-term owners in practice.

That experience changed my view of continuity. It is often discussed as though it comes automatically with an employment contract. It does not. I have seen employees rotate to another team, accept a promotion, mentally leave long before resigning, or protect one narrow responsibility while the product deteriorates between organizational boundaries.

A contractor can remain for years and care for a system through several generations. An employee can leave after six months. Badges are excellent at opening office doors and less reliable at predicting ownership. The operating model tells us more: who owns the result, who receives production feedback, who is allowed to make decisions, and who is still present when the first confident assumption needs revision.

If contractors are treated as temporary hands, they will usually produce temporary ownership. If they are given context, trust, and responsibility for continuity, the line between an external and internal team becomes much less useful.

Urgency works better with continuity

I am usually brought into an organization because it wants movement. A migration needs a clearer direction, an architecture decision has remained open, or a team needs capability it cannot build quickly enough. There is an important objective and a clear expectation that something should change.

That pressure can be healthy. From the outside, I am more likely to cut through the landscape and ask which constraints are still real today. When I am embedded in the organization, I see more of the dependencies, stakeholders, historical constraints, and possible future consequences surrounding the same decision.

That makes veni, vidi, vici tempting. Latin also looks excellent on a steering committee slide. It is a useful mindset for creating momentum, but not a complete operating model.

Speed matters when the organization needs a decision or a bounded result. Continuity matters when that result must be operated, explained, and changed over time. The best engagements treat those as one responsibility: create movement now while leaving the team more able to continue without external help.

The same balance helps employees. Stewardship brings valuable care for dependencies and future consequences. An outside perspective can help turn that context into a timely decision. One provides momentum; the other makes the momentum sustainable.

Good contractors bring urgency without pretending that tomorrow does not exist. Good employees protect continuity without using tomorrow to postpone today.

The two roles made different costs visible

As a consultant, I know my cost is difficult to ignore. Hours are recorded, rates are visible, invoices arrive, and somebody reviews them. Invoices are refreshingly literal documents: every workshop, investigation, and implementation has a number attached to it.

In engineering leadership roles, I have seen how much less visible the cost of an employee can be. Employee costs prefer a distributed architecture. Salary is only the easiest part to see; recruitment, interviews, onboarding, equipment, benefits, management time, internal coordination, retention effort, paid absence, unfilled positions, and the time required to become effective are spread across the organization.

More importantly, employee investment is evaluated over a longer horizon. Domain knowledge, trusted relationships, and operational memory grow over time, while their value rarely appears next to one project budget.

A new rectangle on the organization chart does not automatically create movement, just as an external day rate does not automatically create expertise. Employees need the authority and environment to move an outcome. Contractors need enough context and continuity to make their contribution last.

But comparing a contractor's rate with an employee's salary is not financial discipline. It is comparing an invoice with a fraction of a cost.

The useful question is not how much a day costs. It is how much it costs to reach a useful result, how long that result continues producing value, and what capability remains after the people who created it move elsewhere.

An expensive contractor who helps a team reach an important decision sooner may be cheaper than extending uncertainty. A strong employee who preserves domain knowledge and improves that decision over time may be worth more than any short engagement.

Price is visible. Waste is patient.

I now look for the missing behaviour

Some organizations hire contractors for work that actually needs permanent ownership. A sequence of external people can add useful capacity, but retaining domain knowledge becomes difficult when every engagement has a separate end date.

Others hire employees when they need a focused intervention or an outside perspective. New employees can become durable owners, but they need time to build context and relationships before they can see the organization with the same contrast as someone arriving from elsewhere.

When I help make this choice, I begin with the behaviour the organization is missing. Does it need breadth from somebody who has seen the pattern elsewhere? Directness from people who can challenge internal comfort? Urgency around a bounded result? Or does it need deep domain memory, durable product ownership, and somebody who will still be there for the fifth version of the decision?

Sometimes the right answer is deliberately both. Contractors can notice what has become familiar, while employees explain which unusual parts carry real business history. One side brings contrast; the other protects context.

That works when neither group is treated as the only source of truth. Employment status does not guarantee a particular contribution. Both groups can create value, share knowledge, and strengthen ownership when the operating model allows them to work as one team.

Employment status is metadata. Ownership still needs an architecture.

Working on both sides taught me that entering and staying are different skills. The strongest teams help the people who enter understand what it means to stay, while the people who stay remain open to what a fresh perspective can reveal.