An embedded engineer inside your team

What embedded actually means

An embedded engineer works inside your team's cadence rather than alongside it. Same board, same repository, same code review rules, same definition of done. Your product owner sets the week. The engineer is employed by an outside firm, and the outside firm remains accountable for the quality of the work, the substitution if someone leaves, and the insurance behind all of it. The engagement is a contract for a service, not a seat on your payroll, and everything that makes the model useful or dangerous follows from holding those two facts at once.

The word gets used loosely, so it helps to say what it is not. It is not a fixed-scope project where a firm disappears for six weeks and returns with a deliverable. It is not a staffing placement where a résumé arrives and the vendor's involvement ends at invoicing. Embedded sits between: the firm owns the engineering standard, the client owns the priority queue.

That split is the whole design. A fixed-scope project is efficient when the requirement is stable and expensive when it is not, because every change of mind is a change order. A hire is efficient when the need is permanent and expensive when it is not, because the cost does not stop when the work does. Embedded is built for the case in between, where the direction will change inside the quarter, the work has to live in your systems, and the need has a horizon somewhere between three months and two years.

The three models, side by side

Most comparisons put the three models in a table with a price column and stop. Price is the least informative column, because it prices an hour rather than an outcome. What separates them is control, ownership, and exit.

Dimension	Embedded engineer	Agency or consultancy project	Full-time hire
How work is defined	A standing scope of services plus your backlog, refreshed weekly	A fixed statement of work with acceptance criteria negotiated up front	A role description and whatever the manager assigns
Who sets the week	You set what; the firm sets how and holds the quality bar	The firm's delivery lead, against the agreed scope	You set both
Time to first useful change	Days to weeks, gated almost entirely by access	Weeks, because discovery precedes building	Months, counting search, notice period, and ramp
What you own at the end	Whatever the assignment clause says; write it down	The delivered artifact, plus licensed background tools	Everything, by operation of employment
How it ends	On written notice, typically 15 to 30 days	On acceptance of the last deliverable	Severance, notice, and a rehiring decision
Where estimate risk sits	Shared: you carry scope, the firm carries competence	The firm, if the price is fixed	You, entirely
Cost of changing direction	A conversation	A change order	A conversation, but only after the ramp is paid

Read that table against your own situation and the answer usually falls out. A team that knows what it wants built and will not change its mind should buy a fixed-scope project. A team that will still be doing this work in three years should hire. A team that needs senior hands on a moving target, in its own codebase, starting this month, is describing the embedded case.

The cost line most people compare is the wrong one

The comparison that gets made is an hourly rate against a salary divided by 2,080. It is wrong in both directions, and the parts that can be computed exactly are worth computing before anyone argues about the parts that cannot.

Start with what is arithmetic. An employer pays 6.2 percent Social Security tax on wages up to the annual taxable maximum, which is $184,500 for 2026, and 1.45 percent Medicare tax on all covered wages with no cap. The employee owes a matching 6.2 and 1.45 percent, plus an Additional Medicare Tax of 0.9 percent on wages above $200,000 that the employer withholds but does not match. Federal unemployment tax is 6.0 percent on the first $7,000 of each employee's wages, reduced to 0.6 percent when state unemployment taxes are paid in full and on time, and higher in credit-reduction states. State unemployment tax sits on top of that and varies by state and by the employer's experience rating.

Then come the lines that vary too much to quote as a single multiplier honestly: health and retirement benefits, paid leave, workers' compensation, hardware, software seats, recruiting fees or internal recruiter time, onboarding time from people who are already busy, and the months the seat sits empty while the search runs. Any honest hire-versus-engage model has a line for the vacancy period, and most models skip it.

An embedded rate is higher per hour than a salary per hour, and it should be. It carries the payroll taxes above, benefits, equipment, insurance, overhead, recruiting the firm already did, the bench that covers an absence, and margin. In exchange the meter runs only on hours worked and the commitment ends on notice. Compare total cost over the real horizon of the need, ramp and vacancy included.

Ramp is the real cost, and you pay it every time

Every model pays a ramp. The question is how many times you pay it and who holds the context afterward. A hire ramps once and keeps the context until they leave. An agency ramps at the start of each engagement and takes most of the context away at the end. An embedded engineer ramps once and stays long enough for it to pay back, which is the argument for embedding rather than buying a sequence of short projects.

Ramp cost is dominated by access, not by learning. Learning a codebase is a known quantity for a senior engineer. Waiting eleven days for a repository permission, a data-warehouse role, and a VPN profile is a schedule loss nobody planned for. The highest-return move in week one is to put a name on access and give that name a deadline.

Step six is the one buyers skip and later regret. A handoff rehearsal at day 90, while the engagement is healthy, converts a dependency into a capability. Discovering in the last week that nobody else can run the deployment is how a working system becomes an orphan.

Who owns the code

This is where the embedded model has a sharp edge that a hire does not, and it is worth understanding rather than delegating entirely to counsel. Under 17 U.S.C. 101, a work made for hire is either a work prepared by an employee within the scope of employment, or a work specially ordered or commissioned that falls into one of nine listed categories: a contribution to a collective work, a part of a motion picture or other audiovisual work, a translation, a supplementary work, a compilation, an instructional text, a test, answer material for a test, or an atlas, and only if the parties expressly agree in a signed written instrument.

Software is not on that list. Calling a software engagement "work for hire" in a contract does not make commissioned code a work made for hire, because the category does not exist for it. What transfers ownership of contractor-written code is a present assignment of copyright, in writing. The practical language is an assignment clause that assigns all right, title, and interest in the deliverables, backed by a further-assurances clause and a fallback license in case any assignment fails.

Three details belong in the same clause. Background intellectual property: an engineering firm brings its own libraries, scaffolding, and internal tools, and you want a perpetual, irrevocable license to use them inside the delivered system. Open-source obligations: know which licenses entered the build, and require a dependency manifest as a deliverable. And in AI and data work, name the assets that are not source code. Prompts, evaluation sets, labeled data, fine-tuning artifacts, and model weights are all things a contract can be silent about, and silence is where disputes start.

Classification, and why engaging a firm is different from engaging a person

A buyer who puts an individual contractor on the team calendar, sets their hours, and reviews their performance has built something that looks like employment to more than one government agency. Engaging a firm under a written services agreement is a different posture, and it is different because of facts, not labels.

The IRS evaluates worker status under three common-law categories: behavioral control, meaning whether the payer controls what the worker does and how they do it; financial control, meaning who controls the business side, including how the worker is paid, whether expenses are reimbursed, and who provides tools; and the type of relationship, including written contracts and whether the worker receives employee-type benefits such as a pension, insurance, or vacation pay. Either party can file Form SS-8 for an official determination, which the IRS says may take at least six months. A worker who believes they were misclassified files Form 8919 to report uncollected Social Security and Medicare taxes.

Some states apply a stricter test. California's ABC test carries a business-to-business exemption at Labor Code 2776, and its conditions describe the healthy version of an embedded relationship precisely: the service provider is free from the control and direction of the contracting business in performing the work, has a written contract stating the payment amount and rate, maintains a separate business location, is customarily engaged in an independently established business of the same nature, can contract with other businesses, advertises itself as available to provide the services, provides its own tools and equipment, negotiates its own rates, and sets its own hours and location. All conditions must be met, which is why "we treat them like staff" is a sentence with legal consequences.

At the federal labor level this is genuinely unsettled right now, and pretending otherwise would be misleading. The Department of Labor published a proposed rule on February 27, 2026 to rescind the current independent contractor analysis at 29 CFR part 795 and replace it with the analysis adopted in the January 2021 final rule, with modifications, and published a separate proposed rule on joint employer status on April 23, 2026. Both remain proposals. The durable advice does not depend on which version wins: build the relationship so that the facts support it under any of the tests, and have a lawyer in your jurisdiction read the actual arrangement rather than the template.

• The firm directs the how — technical method, working hours, and professional development stay with the engineering firm; you direct outcomes and priorities.
• No performance reviews in your HR system — feedback goes to the firm's lead, who owns the correction and the substitution.
• No employee benefits — no company insurance, no equity, no paid leave, no participation in employee programs.
• Contract in the firm's name — an invoice from a company, not a personal-services arrangement dressed as one.
• A written scope of services — even for open-ended work, with a stated objective, a rate, a notice period, and acceptance language.
• Equipment from the firm where feasible — with a documented exception when your security policy requires managed devices, which is common and defensible.

Federal work has a line that commercial work does not

If the embedded engineer will sit inside a government program office, the analysis changes, and it changes because of a rule with teeth. FAR 37.101 defines a nonpersonal services contract as one under which the personnel rendering the services are not subject, either by the contract's terms or by the manner of its administration, to the supervision and control usually prevailing in relationships between the government and its employees. FAR 37.104(a) defines a personal services contract by the employer-employee relationship it creates between the government and the contractor's personnel, and FAR 37.104(b) states that agencies shall not award personal services contracts unless specifically authorized by statute.

FAR 37.104(c)(2) frames the test as a facts-and-circumstances judgment, with the key question being whether the government will exercise relatively continuous supervision and control over the contractor personnel performing the contract. The descriptive elements it lists are the ones an embedded arrangement naturally accumulates: performance on site, principal tools and equipment furnished by the government, services applied directly to an agency function, comparable services performed by civil service personnel, a need expected to last beyond one year, and a service whose nature reasonably requires government direction or supervision. None of those alone converts a contract. Together, with a government manager assigning daily tasks, they describe the thing the regulation prohibits.

Two neighboring rules matter for the same arrangement. FAR 7.503(a) states that contracts shall not be used for the performance of inherently governmental functions, and its examples include the direction and control of federal employees and the awarding and administering of contracts. FAR 7.503(d) lists functions that are not inherently governmental but approach the line, including contractors participating in any situation where it might be assumed that they are agency employees or representatives. FAR 37.114 closes the loop: contractor personnel attending meetings, answering government telephones, and working in situations where their contractor status is not obvious to third parties are required to identify themselves as contractors.

A third rule surprises people doing advisory-adjacent work. FAR 9.505-4 requires a contractor performing advisory and assistance services that gains access to another company's proprietary information to agree with that company to protect it and to use it only for the purpose furnished, with the contracting officer obtaining copies of the executed agreements. An embedded engineer who will see a competitor's data inside a government environment is inside that rule.

One caution on citations. The Revolutionary FAR Overhaul is rewriting FAR parts in plain language and removing non-statutory material, with agencies implementing through class deviations, so section text and numbering are moving in places. Confirm the deviation text your contracting activity uses. The substance above is statutory in origin and is not the part that moves.

Access decides the schedule, especially with regulated data

On commercial work, access is a ticket. On regulated work, access is a project. If the engineer will touch controlled unclassified information on a defense program, the security requirements arrive through the contract clauses and the schedule has to respect them. NIST published Special Publication 800-171 Revision 3 in May 2024, superseding Revision 2 from January 2021; which revision binds a contract is set by that contract's clauses, not by which one is newest. The DFARS rule "Assessing Contractor Implementation of Cybersecurity Requirements" was published on September 10, 2025 and took effect on November 10, 2025, phasing certification requirements into solicitations over time.

The practical consequence is that the engineer's laptop, network path, and account provisioning are contract terms rather than IT preferences. Decide before the start date whether the work happens on your managed device inside your enclave or on the firm's device inside its own compliant environment, write the answer into the agreement, and let the security team see it early. Discovering the answer in week three costs the whole ramp.

When each model is the right answer

Hire when the need is permanent and the knowledge is your product. If the system being built is the thing your company sells, and the roadmap runs past two years, employment is the cheapest way to hold the context. Bringing in an engineering partner to build the first version and hand it to a team you are hiring in parallel is a common and sound sequence.

Buy a fixed-scope project when the requirement is stable and the risk should sit with the vendor. A migration with a defined end state, a defined integration, an assessment with a defined question. Write acceptance criteria, fix the price, and hold the line on change orders.

Embed when the target is moving and the work has to live in your systems. Modernizing something that is running in production, standing up a data platform while the requirements are still being discovered, adding a capability your team will own afterward, or covering a specific senior skill for a defined stretch.

Use a short engagement first when you cannot yet evaluate the work. A scoped two-to-four week piece with a written output tells you more about an engineering firm than any reference call. You learn how they write, how they ask questions, and whether the estimate held.

What to put in the agreement

Embedded engagements fail on ambiguity far more often than on competence. The following belong in writing before the first day, and none is unusual to ask for.

• The named engineer, and the substitution path. Who is doing the work, and what happens if they cannot. A firm that commits to a name and a replacement standard is easier to plan around than one promising "a senior resource."
• Rate, minimum and maximum hours, and how overage is approved. A ceiling protects the buyer; a floor keeps the engineer's week reserved.
• Notice period for termination, in days, either direction. Fifteen to thirty days is typical and keeps the option value of the model intact.
• A present assignment of copyright in the deliverables, plus a license to the firm's background tools, and a further-assurances clause.
• Confidentiality with a defined term, and a clean carve-out for the firm's pre-existing knowledge and general skills.
• Security requirements, named explicitly: device policy, data handling, where code may be stored, and any regulated-data clauses that flow down.
• Exit artifacts as deliverables, not courtesies: runbook, architecture notes, dependency manifest, credentials rotation list, and a handoff session.
• Conversion terms. If you may want to hire the engineer later, price that now. A stated buyout is cheaper than a dispute.
• The direction clause. One sentence stating that the client directs the objectives and the firm directs the manner and means of performance. That sentence is the classification posture in miniature.

How to tell it is working after 30 days

Judge the engagement on evidence a manager can see without a status meeting. Changes are merged and deployed, not sitting in a branch. Review comments show the engineer reading the surrounding code rather than only their own. Questions arrive in writing, early, and about the right things. At least one decision has been written down where the next person will find it. Estimates given in week two held in week four, or the miss was flagged before the deadline rather than at it.

The counter-signals are just as legible. Work in progress grows while completed work does not. The engineer is waiting on access nobody has escalated. Every conversation is a status update and none is a design argument. A senior engineer who never pushes back is either not senior or not engaged, and both are worth catching in month one.

Bottom line

The choice among an embedded engineer, an agency project, and a hire is a choice about how much you expect to change your mind, where the work has to live, and how long the need lasts after the first release. Price per hour ranks below all three. Set the arrangement up so the facts match the label: the firm directs the how, you direct the what, the assignment of the code is in writing because commissioned software is not a work made for hire, and on federal work nobody drifts across the personal-services line. Then measure it on merged changes and written decisions after thirty days. Handled that way, embedding buys what a fixed-scope project cannot: the ability to change direction on a Wednesday without renegotiating anything.

Frequently asked questions