How to Engage Engineers in Ministry: Do’s and Don’ts

Share It :

How to Engage Engineers in Ministry: Do’s and Don’ts

In an ideal church, all whose hearts have been touched by God’s love will volunteer and dedicate themselves to serve God and His people, no matter how big or petty, difficult or easy the tasks are. But most churches operate by the 10-90 rule, where 10 percent of the people do 90 percent of the work. The other 90 percent may be viewed as dead weight, but a better alternative is to see them as untapped resources, with potential to be unlocked.

Engineers, I believe, are a major untapped group in Adventist churches and ministries. During the past 10 years in the ministry circuit, I have encountered many engineers who wish they could use their skills for God. The musicians can perform at church, the elocutionists can preach, the school teachers can teach, the doctors can do health seminars, but what can the engineers do? “Engineering is so unrelated to ministry,” many of them lament.

At the same time, these engineers are actually itching to work for God’s kingdom. Many may be involved in church life, perhaps by helping out with children’s program or housekeeping tasks on Sabbaths, but this is not where their highest potential is realized. Engineers’ primary gifts are in design, building systems, and problem solving. When these gifts are matched with real needs in God’s kingdom, the effect can be explosive.

If you’re a pastor/elder/ministry leader and you have trouble motivating the engineers in your congregation or group, here are some tips on how to make ministry more palatable to engineers.

1. Engineers like to work on defined projects.

Engineers work in terms of projects. If you want to get the engineers’ attention and participation, frame your ministry efforts as projects. This is not just a verbal maneuver. Projects mean that you have specific goals, a clear starting point, and a clear ending point. Projects need to have success factors—a list of criteria that determine whether the project is finished or not. When all the points are accomplished, then you can say, “This project is finished.”

This means that if you have a lofty goal like changing the world, you need to break that down into smaller, accomplishable projects. What you don’t want to do is to put engineers on maintenance tasks—the type of work that will never be done. These tasks actually suck the life out of engineers and burn them out quickly.

For example, you may task an engineer to build your church’s website, which is a finite activity—it can be finished. Maintaining the website, however, is another story; there will never be a stopping point to this activity. Ideally, you’d want to move the engineer to another project and get someone else to maintain the website and generate the content consistently.

DO: Put engineers on specific projects.

DON’T: Put engineers in ongoing maintenance jobs.

2. Engineers need clear specifications.

When you put an engineer on a project, you need to be ready with clear specifications. These include what you want to be done, what (finite) scope the project encapsulates, what resources are available, what the constraints are, and what the deadline of the project is. Things like, “Just build it; we’ll worry about the detailed features later” just don’t make sense to engineers. They’re not wired to work in abstract terms. What is it that you want them to build? If you don’t specify the requirements up front, whatever they build may not be suitable later on, and they’ll have to rework their project. This is inefficiency and waste: an engineer’s nightmare.

Preplanning is key. Make sure you’ve given the project a lot of thought, and be ready with some “napkin sketches” of your vision. You may even recruit an engineer to help you formulate the problem before you set the project in motion.

DO: Plan ahead; define specifications.

DON’T: Leave the requirements vague.

3. Engineers thrive on teamwork and focus.

Engineers like to work in teams. They can split the work into pieces and join them together in an iterative manner. Teammates also serve as error-checkers and personal motivators. The people you put in the team, however, matter.

When engineers work, they can focus on one thing for many hours. They need to be left alone, because they don’t want to break that train of thought, which, once lost, will take a long time to get back to. They also tend to work sequentially, meaning that they will finish one task before going to the next one.

Some people can work by jumping from one task to another without finishing one thing first. If the work gets done, this method of working is just as viable. But, for the sake of everyone’s mental health, you don’t want to put these individuals in the same team as the engineers. They will only distract each other, which will drive everyone crazy.

DO: Let engineers focus.

DON’T: Team them up with multitaskers.

4. Engineers prefer work hours rather than meetings.

Engineers like working on things, not talking about working on things. If you want the engineers to engage, minimize the meetings and teleconferences. Schedule work hours instead, which are portions of time in which all the teammates are working simultaneously. They may be working individually on their own parts, but the fact that everybody’s working together gives a certain excitement and synergy to the work. At the end of the work hours, everyone can give brief updates on their stopping points and tasks done, and everybody leaves feeling productive and energized.

During these work hours, it is crucial that team members can communicate with each other quickly. If your project can be done remotely, require everyone to be online in one way or another (e.g., Gchat, Google Hangout, or email) so that each person can get feedback on their work or get information from a teammate instantaneously. Interactions are mostly casual, as long as the job gets done, which promotes creativity in problem solving and design. The team not only accomplishes tasks, it also becomes a kind of think tank that can spew out other creative projects later on.

DO: Schedule work hours.

DON’T: Schedule unnecessary meetings.

5. Engineers want actionable items.

If you must hold meetings, have a clear agenda (clear reasons why you need to meet) and talking points. These points should be topics that cannot be resolved unless everyone meets in this way. Prevent nebulous tangents. For less important or non-team items, use other means of communication.

One comment on status updates: keep these short. The purpose of meetings is for the team to move forward to the next task items, not to review past work. Some updates are key, but detailed updates should be done via email beforehand. Also, some updates are not relevant to all team members, in which case team members should communicate with the team leader at another time.

These meetings also need to end with actionable items—what each person will do by a certain time. Avoid vague language. For example, while a sentence like “Let’s all work together to advance God’s kingdom and be a blessing in our communities” may be technically true and get a lot of amens, there is no actionable item contained in that statement. It’s too vague. You don’t want to end meetings this way. What does “working together” mean? Are we going to split some work? Instead, a sentence like “Let’s meet at the church at 9:00 a.m. next Sunday to shovel snow from people’s driveways” is actionable since everyone knows what to accomplish.

DO: Define meeting agenda and actionable items.

DON’T: Use vague language.

6. Engineers like getting things done.

When engineers set their minds to a project, all they want to do is to get it done. Anything that hinders that goal is seen as waste and inefficiency. Thus, do what you can to minimize bureaucracy and politics. Add a person in the team who can deal with administrative and political matters so the engineers can stay on their tasks.

Another problem that projects tend to have is creeping scope. At first you want five things, but as time goes on the five becomes seven, then 10… Instead of continually expanding the scope of the project, do iterations or stages. Let the team finish the first project (with maybe a few additional items), then start another project (version 2.0) to address the other needs. You can’t expect two or three times the number of tasks to be done in the same amount of time. (See this article for more about effective projects.)

There is a euphoric feeling when something is finally built or a problem is solved. Multiple small projects that are finished are better than one big project that is never-ending. Even Jesus said, “It is finished.”

DO: Minimize bureaucracy. Let projects finish.

DON’T: Think that small changes are easy. They’re mostly not.

Following these tips means you are playing to the engineers’ strengths and making it easier for them to want to work. When you can’t follow these tips, for whatever reason, they are pointers to the risk factors and potential sources of frustration when engineers are involved. So give them some thought, and enlist the engineers in your church!

This article was originally published on the Adventist S.T.E.M. blog.

Share It :


About the author

Josephine Elia Loi

Josephine Elia Loi is a chemical engineer working in the energy industry at a Fortune 100 company. She holds a Ph.D. in chemical engineering from Princeton University. Josephine resides in Chicago, Illinois, where she spends most of her spare time reading and writing. Visit her blog at