Writing Effective Experience Narratives: Tips for Engineers

Experience narratives are structured written accounts of your engineering work, used to demonstrate that you have acquired the competencies required for professional licensure. In most Canadian provinces, these narratives form the backbone of your licence application, providing the evidence that reviewers use to assess your readiness for independent practice.

Each narrative should connect a specific piece of work experience to one or more competencies from the Engineers Canada framework. The reviewer reading your narrative has never seen your project, never met your team, and does not know your background. Your narrative must stand on its own as a clear, convincing account of your professional contribution.

Think of narratives as the bridge between your work experience and the competency framework. The experience is what you did; the narrative is how you demonstrate that what you did maps to the competencies required for licensure.

The SAR (Situation-Action-Result) method is the recommended structure for experience narratives. Some engineers know this as the STAR method (Situation, Task, Action, Result), which adds an explicit "Task" component. Both approaches work; the important thing is to cover all three elements in every narrative.

Situation (S): Provide context in 1-3 sentences. What was the project? What was the engineering problem or challenge? What constraints (budget, timeline, regulatory, environmental) were relevant? The situation should be specific enough that the reviewer understands why this work mattered and what made it non-trivial.

Action (A): This is the heart of your narrative. Describe what you personally did, in first person. What engineering analysis, design, or review did you perform? What tools, codes, or standards did you apply? What decisions did you make and what was your reasoning? If you led a team effort, clarify your individual role versus the team's collective work. Avoid vague phrases like "was involved in" or "assisted with" -- instead, use active verbs like "designed," "analyzed," "evaluated," "recommended," or "directed."

Result (R): Explain the outcome. What was the impact of your work? Did the design get built? Did the analysis inform a decision? Were there measurable outcomes (cost savings, safety improvements, schedule adherence)? If the project did not go as planned, what did you learn and how did you apply that learning? Honest reflection on challenges is often more compelling than a perfect success story.

Being too vague is the single most common problem. Narratives that say "I performed engineering calculations for a bridge project" tell the reviewer almost nothing. What kind of bridge? What calculations? What codes governed the design? What was the specific challenge? Specificity is what transforms a generic statement into compelling evidence.

Using "we" instead of "I" dilutes your personal contribution. Reviewers need to understand what you did, not what your team did. It is fine to acknowledge that work was collaborative, but your narrative must clearly identify your individual role and contributions.

Overloading a single narrative with too many competencies weakens all of them. Each narrative should target one or two competencies and demonstrate them convincingly. If you try to address five competencies in a single paragraph, you will lack the depth needed to satisfy any of them.

Neglecting the result section is another common weakness. Some engineers write detailed situation and action sections but end abruptly without explaining the outcome. The result is what proves your action had impact and demonstrates your professional judgment.

Writing in overly technical jargon can alienate reviewers who may not share your exact specialization. Use technical terminology where appropriate, but ensure your narrative is comprehensible to a professional engineer outside your specific discipline.

Aim for 200-400 words per narrative. This range is long enough to provide meaningful detail but short enough to remain focused. Most reviewers read dozens or hundreds of applications, and concise, well-structured narratives are appreciated.

Break your narrative into clear paragraphs rather than writing a single block of text. Even though the SAR structure is straightforward, visual separation makes it easier for the reviewer to follow your logic and identify the key elements.

Use specific numbers, dates, and proper nouns where they add clarity. Instead of "a large municipal project," write "a 45-hectare stormwater management facility for the City of Surrey." Instead of "recently," write "in Q3 2025." Precision signals professionalism and credibility.

Proofread carefully. Spelling errors, grammatical mistakes, and formatting inconsistencies undermine your credibility. If you are using AI-assisted drafting tools, always review and edit the output to ensure it accurately represents your experience and sounds like your own professional voice.

AI tools can be valuable assistants in the narrative writing process, but they should never replace your own professional judgment and honest representation of your experience. The most effective approach is to use AI as a structuring and editing aid rather than a content generator.

Start by writing a rough draft in your own words, capturing the key facts of the situation, your specific actions, and the results. Do not worry about polish at this stage. Then use an AI assistant to help you restructure the draft into a clear SAR format, improve the flow, and identify gaps where you need to add more detail.

AI is particularly useful for identifying which competencies your narrative demonstrates. You can describe a work experience and ask the AI to suggest which competencies from the Engineers Canada framework are most strongly evidenced. This helps ensure you are mapping your experience effectively.

Never use AI to fabricate or embellish experience you do not have. This is a serious ethical violation that could result in denial of your application and professional misconduct proceedings. AI should help you articulate your real experience more clearly, not invent experience you lack.

Weak example: "I was involved in the design of a water treatment plant. I did calculations and helped with the design. The project was completed successfully." This narrative tells the reviewer almost nothing specific. What kind of calculations? What aspect of the design? What does "successfully" mean?

Strong example: "During the detailed design phase of a 25 ML/d water treatment plant expansion for Metro Vancouver (2024-2025), I was responsible for sizing the UV disinfection system. I calculated the required UV dose based on the Canadian Drinking Water Quality Guidelines and selected a medium-pressure UV reactor system after evaluating three vendor proposals against performance specifications. I developed the hydraulic profile through the UV channel to ensure adequate contact time at peak flow conditions, using EPA UV Disinfection Guidance Manual methods. The design passed third-party peer review without revisions, and the UV system achieved the target 4-log virus inactivation during commissioning, meeting the health authority's operating permit requirements."

The strong example specifies the project (water treatment plant expansion), quantifies the scope (25 ML/d), identifies the specific task (UV disinfection system sizing), names the standards applied (CDWQG, EPA UV Guidance Manual), describes the engineering judgment exercised (evaluating vendor proposals, developing hydraulic profiles), and provides a concrete result (passed peer review, achieved performance targets). This gives the reviewer clear evidence of technical competence, application of standards, and professional accountability.

Notice that the strong example is still concise -- about 130 words. You do not need to write a novel. You need to write with precision and purpose.