Stop Asking Your Engineers to Be Marketers

There is a conversation that happens repeatedly inside architecture, engineering, and construction firms.

Leadership recognizes that the company needs to do a better job staying in front of clients.

Someone says:

“We need our project managers and engineers to do more business development.”

Everyone agrees.

Lists are created. Expectations are communicated. People are encouraged to pick up the phone, check in with former clients, attend more industry events, and reach out to prospective clients.

And for a while, it works.

Calls get made. Lunches get scheduled. People reconnect with old contacts.

Then a project deadline hits.

A client has a problem.

Someone needs a proposal by Friday.

A project goes over budget.

Utilization becomes a concern.

And gradually, business development activity slows.

Six months later, leadership has the same conversation again.

“We really need our engineers doing more BD.”

Maybe the problem isn't the engineers.

Maybe we're asking them to do a job they were never hired, trained, or wired to consistently perform.

Engineers Can Be Exceptional at Business Development

I want to make an important distinction.

I'm not suggesting engineers, architects, project managers, and other technical professionals shouldn't participate in business development.

Quite the opposite.

They can be some of the most effective people in the entire business development process.

Put a good engineer across the table from a client with a difficult technical problem and watch what happens.

The engineer understands the problem.

They ask intelligent questions.

They can discuss possible solutions.

They recognize complications that someone without their technical background might miss.

Most importantly, they establish credibility.

That credibility is enormously valuable in AEC business development.

A professional Business Development Director may be able to create access, develop the relationship, understand the opportunity, and get the meeting.

But when the conversation becomes technical, the client often wants to talk to the person who might actually help solve the problem.

That's exactly where your technical people belong in business development.

The mistake is assuming that because they're valuable at that moment, they should also be responsible for creating all the moments that lead to it.

Maintaining a Relationship and Managing Business Development Are Different Things

Consider one of the simplest requests we make of technical professionals:

Call your clients.

It sounds easy.

And occasionally it is.

The engineer knows the client. They've worked together. They probably like each other. There's no uncomfortable introduction required.

So leadership makes a push.

Call three clients this week.

Reconnect with former clients.

Take somebody to lunch.

Activity increases.

But maintaining that cadence indefinitely is another matter.

The engineer's project responsibilities have deadlines.

The relationship call usually doesn't.

The client deliverable needs to go out Thursday.

The call to the former client can happen Friday.

Friday gets busy.

So it moves to Monday.

Then something else happens.

The call doesn't feel urgent because nothing bad happens when it isn't made.

That's one of the fundamental challenges of AEC business development:

Project delivery has immediate consequences. Business development has delayed consequences.

Skip a project deadline and someone notices today.

Skip a relationship call and nobody may notice for six months.

Until the firm discovers that the next project went to somebody else.

Now Ask Them to Call Someone They Don't Know

Maintaining existing relationships is only part of growth.

What happens when the firm wants to enter a new market?

Develop a new account?

Meet a developer they've never worked with?

Build relationships in a new geography?

Now we're asking the technical professional to do something very different.

Find someone they don't know.

Figure out how to reach them.

Pick up the phone.

Introduce themselves.

Explain why they're calling.

Create enough interest to continue the conversation.

And do it repeatedly.

Some engineers and architects are naturally good at this. Some genuinely enjoy it.

Many don't.

That shouldn't surprise us.

Prospecting is a professional skill and a repeated behavior.

Yet AEC firms routinely ask people whose careers are built around technical expertise and project delivery to suddenly become prospectors because the company needs more work.

Then we become frustrated when they don't do it consistently.

“Everyone Is Responsible for Business Development”

This is one of the most common phrases in professional-services firms.

And at one level, I agree completely.

Everyone affects business development.

The receptionist who answers the phone affects the client's perception of the firm.

The project manager who responds quickly to a problem affects the next purchasing decision.

The engineer who finds a creative solution builds trust.

The accounting department that sends an accurate invoice affects the client experience.

The principal who stays connected with a longtime client strengthens the relationship.

In that sense:

Everyone is responsible for business development.

But there's a management problem hidden inside that statement.

If everyone is responsible for business development, who is accountable for making sure it actually happens?

Those are different things.

Everyone can participate.

Someone still has to own the process.

Your Most Expensive Technical People Shouldn't Be Doing the Administrative Work of BD

There's also an economic question.

Consider the value of a senior engineer, architect, construction professional, or principal.

Why would we want that person spending hours:

researching companies,

looking for contact information,

monitoring procurement sites,

updating CRM records,

trying to remember who needs a follow-up,

researching attendees before an event,

coordinating calendars,

tracking down project information,

or organizing pursuit activity?

Those tasks matter.

But they don't necessarily require the firm's most valuable technical resource.

Business development should be designed to leverage technical talent, not consume it.

The technical professional should enter the process where their knowledge, reputation, relationships, and expertise create disproportionate value.

That means somebody else has to build the runway.

The BD Department Should Create the Moment

This is where I think many AEC firms misunderstand the relationship between technical professionals and business development professionals.

The job of a BD department isn't to replace your engineers in business development.

It's to put your engineers into the moments where they're most valuable.

Find the opportunity.

Research the account.

Understand what's happening.

Determine who the decision-makers are.

Find the connection.

Develop the relationship.

Make the introduction.

Schedule the meeting.

Research the people attending.

Establish the objective.

Prepare the technical professional.

Then put the right person in the room.

At that point, let the engineer do what the engineer does exceptionally well:

Understand the problem.

Ask intelligent questions.

Demonstrate expertise.

Establish credibility.

Help the client see why your firm may be able to solve the problem.

Then, after the meeting, the business development function goes back to work.

What did we learn?

What changed?

Who else is involved?

What's the next action?

Who owns it?

When should we follow up?

How does this affect the opportunity?

What does the CRM need to capture?

When should the technical professional come back into the conversation?

That's a business development system.

It doesn't eliminate technical involvement.

It makes technical involvement more valuable.

Stop Fighting Project Delivery

There's another reason this matters.

AEC firms make their money by delivering projects.

So when business development and project delivery compete for the same person's time, we shouldn't be surprised when project delivery wins.

It should win.

The client with an active project deserves attention.

The deadline matters.

The deliverable has to get finished.

The project manager has responsibilities to the client, the team, and the firm.

The problem isn't that the engineer chose project delivery over a prospecting call.

The problem is that the company's business development system required the engineer to make that choice in the first place.

A functioning BD department keeps the growth process moving while technical professionals are doing the work the company hired them to do.

When their participation is needed, bring them in.

When it isn't, keep moving without them.

Business Development Should Make Technical People Better at BD

I don't believe the answer is to excuse technical professionals from business development.

We should do the opposite.

Teach them how to recognize opportunities.

Help them ask better questions.

Show them how to listen for future work.

Encourage them to maintain important relationships.

Prepare them for client meetings.

Help them understand how their project performance affects future revenue.

Give emerging leaders opportunities to build relationships earlier in their careers.

But don't confuse developing business-development awareness throughout the organization with making every employee responsible for running the business-development process.

Those are very different ideas.

A great BD function should make it easier for technical professionals to participate.

Instead of:

“Go find some prospects.”

Give them:

“We've been developing a relationship with this organization. Here's what we know. Here's the opportunity we see. Here's who will be in the meeting. Here's what they're dealing with. We think your experience on this particular project will resonate with them. Can you join us?”

Which conversation is more likely to produce something valuable?

This Is Where an Embedded BD Department Fits

For some AEC firms, the answer is an internal Business Development Director or a complete internal BD team.

For others, fractional business development or an outsourced business development department can provide the infrastructure without requiring the firm to build the entire function internally.

The organizational principle is the same either way.

Business development needs someone accountable for keeping it moving.

Someone should be looking outward while the project teams are focused on delivering today's work.

Someone should be developing relationships before an RFP appears.

Someone should be creating opportunities for technical professionals to use their expertise where it matters most.

At BD-AEC, that's how we think about an embedded business development department.

We're not trying to replace the firm's principals, engineers, architects, project managers, or technical leaders in the sales process.

We need them.

But we don't need them doing everything.

Let Engineers Be Engineers

AEC firms invest enormous amounts of time developing technical talent.

We hire engineers because they're good engineers.

We hire architects because they're good architects.

We develop project managers because they're capable of leading complex projects and client relationships.

Then, when we need more work, we sometimes turn around and tell all of them:

“Now go be marketers.”

And we're disappointed when the behavior doesn't last.

Maybe we should stop trying to turn every technical professional into a business development professional.

Instead, build a business development function that identifies opportunities, creates access, maintains momentum, manages the process, and brings technical professionals into the conversation precisely when their expertise creates the most value.

Your engineers should absolutely be part of your business development team.

They just shouldn't have to be the business development department.