How to Write SAR Competency Narratives That Pass Review

A competency self-assessment narrative is the unit of evidence in a competency-based P.Eng application. Most Canadian regulators assess your experience against the Engineers Canada framework of 34 competencies in 7 categories, and for each competency you write a short account demonstrating that you personally exercised it. The dominant structure is SAR: Situation, Action, Result. A reviewer who has never met you, never seen your projects, and does not know your discipline reads these narratives and decides whether you have shown the competency. The narrative has to carry that weight on its own.

It helps to remember what the narrative is not. It is not a job description, not a project summary, and not a list of things your team accomplished. It is a focused argument that you, individually, applied a specific competency and that something measurable resulted. Everything below serves that single goal.

Situation (roughly 15 to 20 percent of the narrative): set the scene in one to three sentences. Name the project, the engineering challenge, and the constraints that made it non-trivial: a budget, a regulatory requirement, a tight schedule, a difficult site. Give the reviewer just enough context to understand why the work mattered, then stop. A long situation section is wasted space.

Action (roughly 60 to 70 percent): this is the core, and it is where weak narratives fall apart. Describe what you did, the engineering judgment you exercised, the analysis or design you performed, the tools, codes, and standards you applied, the alternatives you weighed, and the decisions you made and why. This is the part the reviewer is grading. If your action section is two sentences, no result and no situation can save the narrative.

Result (roughly 15 to 20 percent): state the outcome and tie it back to your action. Was the design built? Did the analysis change a decision? Were there measurable effects: cost avoided, schedule held, a safety margin achieved, a permit obtained, a peer review passed? A concrete result is what proves your action had impact and demonstrates professional judgment.

The reviewer is assessing you, not your team, so the narrative must be unmistakably about your individual contribution. Write "I" and own your actions. The most common failure mode is the slide into "we": "we designed the system, we selected the equipment, we presented to the client." When a reviewer reads "we," they cannot tell what you did versus what the senior engineer beside you did, and an unclear contribution is treated as no contribution.

It is fine, and honest, to acknowledge that engineering is collaborative. The skill is in being precise about the boundary: "Working within a four-person design team, I was responsible for the hydraulic analysis and the outlet structure design, while my colleague handled the geotechnical assessment." That sentence credits the team and still makes your scope crisp. Replace passive, hedging verbs ("was involved in," "assisted with," "participated in") with active ones that name a real action: designed, analyzed, calculated, specified, evaluated, recommended, directed, reviewed.

If there is one ratio to internalize, it is this: the majority of every narrative should describe your action. A useful rule of thumb is 60 to 70 percent on the action, with the situation and result sharing the remainder. Reviewers consistently see the opposite: narratives that spend three sentences setting up a project, one vague sentence on what the candidate did, and a tidy closing line about success. That distribution demonstrates nothing.

When you draft, write the action section first and at length, then trim the situation to the minimum that makes the action legible, and add a result that closes the loop. If you cannot fill the action section with specific engineering content, that is a signal: either you have chosen a competency this experience does not actually demonstrate, or you need a different project for this entry. The fix is to change the example, not to pad the situation.

Numbers turn a claim into evidence. "I improved the design" tells a reviewer nothing; "I revised the pump configuration, which reduced the station energy demand by roughly 18 percent and eliminated one standby unit" demonstrates impact and judgment. Wherever you can, attach a quantity to the result: a percentage, a dollar figure, a flow rate, a load, a number of days, a count of deficiencies resolved.

Quantification also disciplines your thinking. Forcing yourself to state the result in measurable terms surfaces whether the work actually had an effect or whether you are describing activity without outcome. When a result genuinely cannot be quantified, for example a learning outcome or a process improvement, state it concretely anyway: what specifically changed, what you would do differently, how you applied the lesson on the next project. Avoid empty closers like "the project was completed successfully," which assert nothing a reviewer can verify.

Each narrative should target one competency, occasionally two that are genuinely related, and demonstrate it convincingly. A common mistake is cramming four or five competencies into one experience to save effort; the result is that none of them is shown in enough depth to satisfy a reviewer. Depth beats breadth. It is far better to demonstrate one competency thoroughly than to gesture at five.

Use the language of the framework deliberately. If the competency concerns applying codes and standards, name the specific code and explain how applying it shaped a decision. If it concerns the social or environmental impact of your work, describe the actual impact you weighed and the trade-off you made. Read the wording of the competency you are addressing and make sure your action section directly answers what it asks. The seven categories span technical work, communication, management, teamwork, ethics, the social and environmental context, and competencies specific to practising in Canada, so most candidates can find a strong, distinct example for each rather than recycling one project everywhere.

The rejections cluster into a handful of recurring patterns. Vagueness is the most common: a narrative that could describe any engineer on any project, with no specific problem, method, or decision. The "we" problem is next: a contribution so blended into the team that the reviewer cannot isolate what the candidate did. Then there is the missing or hollow result, where the action is described but its impact is never established.

Other frequent causes: overloading a single narrative with too many competencies so none is shown convincingly; choosing an experience that does not actually demonstrate the competency claimed; impenetrable jargon that a reviewer outside your sub-discipline cannot follow; and work that reads as technician-level rather than as the application of professional engineering judgment. Almost every rejection traces back to one root issue, the reviewer could not clearly see the candidate exercising the competency. Write each narrative so that a busy reviewer, reading quickly, cannot miss what you did, how you did it, and what resulted, and you remove the reasons narratives get sent back.