November 5, 2020

Five Lessons Learned Working as a Global Development Engineer

The author, Bryan Sherrill, is an E4C Research Fellow with a background in global development engineering.

In a single day on the job, development engineers can act as a mechanical engineer, environmental engineer, project manager, and community liaison. One of the pitfalls, however, is the temptation to “fix” perceived problems without consulting the communities in which they are working. It’s easy to get overwhelmed by the enormity of the challenges in underserved communities and take action without considering the views of the people who live there. This outcome is common in engineering for global development. I have seen the poor execution of good intentions lead to dozens of failed projects, and thousands of wasted dollars.

To stop the waste, and to help improve the work we do, I’ve identified five lessons learned while collaborating on projects across the globe. Learning these lessons can minimize a project’s shortcomings and add new perspectives on the design and implementation of engineering for global development projects.

Forget what you learned in school

No, not everything. Certainly, engineering practice and the methodology involved is critical to success. I am referring specifically to the commonly taught tools that engineers use to solve problems they encounter.

For example, I came across a surprising discovery while testing well water in Haiti with the non-governmental organization Pure Water for the World. Every well tested came back with high levels of E. coli. This helped to explain the high child mortality rate from gastroenteritis in the region. The adults, however, were not affected. Speaking with some local experts, I learned that adults had built a natural immunity, and if E. coli was removed and reintroduced later from a broken or failing system, they would no longer be protected. Consequently, it was a tradeoff, the solution not as black and white as I had been taught.

Become a part of the community

There is an expression that to speak to people in a second language is to speak to their minds, but speaking to them in their native tongue is to speak to their hearts. A successful development engineer should not just acknowledge local language and culture, but become part of it. We should use language and culture as tools for communicating our intentions. While in Miramar, Guatemala, a Guatemalan engineer and I met with the community to discuss building trenches to divert water from homes periodically destroyed by flooding. The village elders quickly fought our idea, claiming they could continue to live without this fix. I realized that our identity as outsiders caused mistrust, so I decided to help dig the trenches. Showing the elders my dedication to both the project and their community ultimately helped sway their opinions and consider the benefits of the trench design.

Listen with your ears, not your mouth

In working with a group of Mayan Spiritual guides on the revitalization of a sacred cave site in the Guatemalan highlands, I became aware of how much more productive it is to listen rather than to speak. In listening to stories of sacred rights, natural ecology, and cultural practices, I was invited to see private ceremonies, hear stories, and learn about the history of the Mayan people. By hearing from the people instead of speaking to them, opportunities became available. The culmination of the effort was a sacred site redesign that honored Mayan culture and created a space from which future generations could learn.

Channel Socrates

Socrates developed a method of instruction whereby students and teachers considered an issue together through dialogue rather than lecture. This teaching style, now known as the Socratic Method, is a helpful skill in development practice. I first learned of the effectiveness of communal conversation working in Eastern Kentucky coal country while studying in college. Throughout the course of the project, I became aware that creating a common space to share ideas allowed new ideas, information, and project goals to arise. The community’s voice came through loud and clear, unmarred by my voice or that of my colleagues. Now I begin my relationship this way with every community with which I have worked, using it as a catalyst for the community to orient its own goals.

It’s not a sprint, it’s a marathon

I spent time in South India improving anaerobic digestion processes for cooking gas, designing rainwater harvesting systems to survive drought seasons, and monitoring groundwater for irrigation. In each project, changes in finances and timelines occurred often. The reality of development engineering is that plans and timelines will always change and things will always take longer than anticipated.
Understanding that a project will never go according to plan should be part of the plan. Learning to create multiple options within the project scope, accounting for additional time ensures that the project will be completed in the long run.

About the Author

Bryan Sherrill is an E4C Research Fellow who is also pursuing a MPA in Development Practice at Columbia University. While his background is in water resources engineering, Bryan is now developing renewable energy policy for large-scale offshore wind development with the World Forum for Offshore Wind.

Leave a Reply

Join a global community of changemakers.

Become A Member