If I Were a Software Engineer With “Open to Work” on LinkedIn, I’d Be Learning to Work Like a Forward Deployed Engineer

If I Were a Software Engineer With “Open to Work” on LinkedIn, I’d Be Learning to Work Like a Forward Deployed Engineer

There are a lot of very good software engineers looking for work right now.

Some have ten years of experience.

Some have twenty.

They know Java, .NET, Python, JavaScript, React, AWS, Azure, databases, APIs, microservices and CI/CD.

And many of them are still waiting.

If I were one of them, I would ask myself a difficult question:

Am I marketing myself for the job market that existed five years ago—or for the engineering market that is being created right now?

Because I believe something important is changing.

The engineer companies increasingly want is not simply someone who can receive a Jira story and implement it.

They want someone who can walk into an unclear business problem, figure out what really needs to be solved, use AI and software engineering to build the solution, get it into production, and prove that it worked.

That is the world of the Forward Deployed Engineer.

And you do not need to work for AWS, OpenAI, Anthropic, Palantir or another major technology company to start operating this way.

You can start becoming one now.

What Is a Forward Deployed Engineer?

Forget the title for a moment.

Think about the behavior.

A Forward Deployed Engineer can enter a customer or business environment and say:

What are we actually trying to accomplish?

Then:

What systems already exist?

Then:

What is the smallest thing we can build that proves the solution?

And finally:

Can we put it into a real environment and demonstrate that it produces the intended outcome?

That is considerably different from:

“Give me the requirements and I’ll write the code.”

The Forward Deployed Engineer owns more of the journey.

They can work with the customer.

They can understand architecture.

They can investigate an unfamiliar repository.

They can use AI.

They can write software.

They understand APIs and data.

They can test.

They understand deployment.

They can observe what happens in production.

And most importantly:

They can connect engineering activity to a business outcome.

That combination is becoming incredibly valuable.

The Learn, Teach, Master Forward Deployed Engineering Framework

At Learn, Teach, Master and Intent-Driven-Engineering.com, I use a simple operating model:

ENTER → INTENT → DISCOVER → BUILD → EVALUATE → PROVE → DECIDE → EXTRACT

You don’t need another 600-page engineering methodology.

You need to learn how to move through this cycle successfully.

1. ENTER

Learn how to enter an unfamiliar problem.

This is an underrated engineering skill.

You may not know the codebase.

You may not understand the business.

The documentation may be terrible.

People may disagree about the requirement.

Systems may have been built by teams that disappeared three years ago.

That’s normal.

The job is not to complain about the ambiguity.

The job is to begin reducing it.

Ask questions.

Look at the system.

Talk to the people.

Find the constraints.

Understand why the problem matters.

A Forward Deployed Engineer becomes comfortable saying:

“I don’t understand this yet—but I know how to find out.”

2. INTENT

Before you build anything, establish intent.

I use four foundational questions:

Intent — What are we trying to accomplish?

Inputs — What information, systems and constraints do we have?

Outputs — What must exist when we are finished?

Success Criteria — How will we know it worked?

That becomes the initial engineering contract.

Not a 200-page requirements document.

Not endless meetings.

Enough context to move.

That is Intent-Driven Engineering.

3. DISCOVER

Now investigate the environment.

Look at:

Repositories.

Architecture.

APIs.

Data.

Dependencies.

Cloud infrastructure.

Authentication.

Security.

Tests.

CI/CD.

Observability.

Existing automation.

Customer workflows.

Technical debt.

The point isn’t to become an expert in everything before beginning.

The point is to acquire the minimum sufficient context to make the next good engineering decision.

AI has made this dramatically easier.

An engineer who knows how to use modern AI coding tools can inspect a codebase, trace dependencies, understand APIs, analyze logs, identify gaps and generate working hypotheses at a speed that simply wasn’t possible a few years ago.

But AI does not eliminate engineering judgment.

It makes engineering judgment more valuable.

4. BUILD

Then build something.

This sounds obvious, but it is where I think the modern engineering world is separating.

A Forward Deployed Engineer is not primarily producing recommendations.

They produce working software.

Use whatever tools make sense.

Claude.

GitHub Copilot.

Codex.

Cursor.

AWS.

Azure.

Google Cloud.

React.

Python.

.NET.

Node.

Agents.

MCP.

Skills.

Hooks.

APIs.

Traditional software.

AI software.

The tools are secondary.

The objective is:

Turn intent into a working result.

5. EVALUATE

This is where AI engineering becomes real engineering.

Don’t ask:

“Did the demo work?”

Ask:

Did the tests pass?

Did the agent select the correct tools?

Were the outputs accurate?

Is it secure?

Is the latency acceptable?

Does it fail safely?

Can we reproduce the result?

What happens when the data is bad?

What happens when an API is unavailable?

What happens when the user does something unexpected?

Can another engineer understand what we built?

A Forward Deployed Engineer expects the solution to be challenged.

6. PROVE

This may be the biggest career lesson I could give another engineer today:

Stop telling people what you know. Start showing people what you can prove.

Don’t tell me:

“I understand agentic AI.”

Show me the repository.

Don’t tell me:

“I know AWS.”

Show me the running architecture.

Don’t tell me:

“I understand RAG.”

Show me the retrieval evaluation.

Don’t tell me:

“I understand CI/CD.”

Show me the pipeline.

Don’t tell me:

“I can modernize legacy software.”

Show me before and after.

Your portfolio should increasingly contain evidence, not claims.

7. DECIDE

This is where Progressive Intent enters the picture.

Engineers have another problem:

We don’t always know when to stop.

The software works.

The requirement has been satisfied.

But we see something else we could improve.

And something else.

And something else.

Soon a feature becomes a framework.

The framework becomes a platform.

The platform needs an orchestration layer.

And six weeks later nobody remembers what the original problem was.

Progressive Intent asks a simple question:

Did we satisfy the intent?

If yes:

STOP.

Capture the result.

Deploy it.

Measure it.

Anything else requires new intent.

That starts another cycle.

This protects engineering teams from uncontrolled complexity while still allowing continuous improvement.

8. EXTRACT

This is how one engineer becomes an organizational advantage.

At the end of every project, ask:

What did I learn that the next engineer should never have to rediscover?

Maybe you created:

A reusable skill.

An AI prompt.

A testing pattern.

A deployment template.

A security check.

An agent.

A hook.

An MCP integration.

A CI workflow.

An intent template.

A reference architecture.

A troubleshooting guide.

Capture it.

The next project should start ahead of where the previous project started.

That is how engineering organizations become smarter.

What Would I Learn If I Were Looking for Work Today?

If my LinkedIn profile said Open to Work, I would want to become demonstrably competent in these areas:

1. Customer and business discovery

Learn how to understand the problem behind the ticket.

2. Intent definition

Learn how to turn ambiguity into an actionable engineering objective.

3. AI-assisted software engineering

Become extremely comfortable building alongside modern AI coding systems.

4. Repository-level AI

Learn how AI works inside real codebases—not just chat windows.

5. Agentic systems

Understand tools, agents, context, orchestration, RAG, memory and evaluation.

6. APIs and integration

Modern enterprise software is mostly systems talking to systems.

7. Cloud

You don’t need every certification ever created.

You need to understand how production systems actually run.

8. CI/CD

A solution isn’t finished because it runs on your laptop.

9. Testing and evaluation

Traditional tests plus the emerging discipline of AI evaluation.

10. Security and governance

Especially when AI has access to tools, data and enterprise systems.

11. Observability

Logs, traces, metrics, costs and production behavior.

12. Business outcomes

Learn to answer:

What changed because we built this?

Build Yourself an FDE Lab

You don’t have to wait for someone to give you the title.

Create your own laboratory.

Take an old application.

Or an open-source project.

Or build something small.

Give yourself an intent:

“A user needs to accomplish X. Build the smallest production-capable system that proves it can be done.”

Then run the entire lifecycle.

ENTER

Understand the problem.

INTENT

Define the objective and success criteria.

DISCOVER

Understand the technology and constraints.

BUILD

Create the solution.

EVALUATE

Attack your own assumptions.

PROVE

Produce evidence.

DECIDE

Determine whether the intent has been satisfied.

EXTRACT

Turn what you learned into something reusable.

Then put the result on GitHub.

Write about it.

Create a diagram.

Record a five-minute demonstration.

Explain the architecture.

Explain what went wrong.

Explain what you changed.

Explain when you decided to stop.

Now imagine doing that four or five times.

Your LinkedIn profile changes.

You are no longer saying:

“Senior Software Engineer seeking opportunities.”

You’re demonstrating:

“I take ambiguous business problems from intent to working software and production evidence.”

That is a very different professional story.

The Four-Person FDE Pod

If you want to take this even further, get three other engineers who are looking for work.

Create a four-person team.

One person concentrates on Intent and Customer Discovery.

One concentrates on Application and AI Engineering.

One concentrates on Platform, Integration and Cloud.

One concentrates on Testing, Evaluation, Security and Production Evidence.

But everyone builds.

Give yourselves a problem.

Give yourselves a week.

And build it.

Then switch responsibilities and do it again.

You’ve just created your own Forward Deployed Engineering training program.

No permission required.

Your Career Is Becoming a Portfolio of Proven Intent

I have spent a long career in software engineering.

And one thing I believe very strongly now is this:

AI isn’t eliminating the value of great engineers.

It is changing what makes an engineer valuable.

Typing code is becoming cheaper.

Producing business outcomes is not.

Understanding ambiguity is not.

Making good technical decisions is not.

Taking responsibility is not.

Knowing when something is good enough to ship is not.

Proving that it works is not.

Those are increasingly the valuable skills.

So if you’ve been looking for six months and wondering what certification to take next, perhaps try something different.

Pick a real problem.

Write the intent.

Build it.

Prove it.

Publish the evidence.

Then do it again.

Don’t wait for someone to make you a Forward Deployed Engineer.

Start operating like one.

Learn. Teach. Master.

Intent-Driven-Engineering.com

Intent → Discovery → Build → Evidence → Decision → Reuse

That is the framework.

And for any software engineer trying to figure out where they belong in this next generation of engineering:Start here!

them.