How to Write Strong EGBC Competency Examples: Structure, Evidence and the 0-5 Rating Scale

To write a strong EGBC competency example, describe one specific situation using the Situation-Action-Outcome fields and write in the first person: I, not we. Keep Situation and Outcome brief, put the detail into Action, and explain the engineering judgments you personally made. Choose work with a real problem, your own responsibility, and enough complexity to support the self-assessed rating you claim.

This article is for the applicant staring at a blank example box or trying to improve a thin draft. Whether you are still learning the 34-competency framework or already working category by category, the hard part is turning a real project into evidence that a validator can confirm and an assessor can understand.

Guidance for this task is split across two EGBC documents. The April 2024 engineering applicant guide is the current guide and contains the compliance rules, while the earlier 2017 competency guide still contains useful writing mechanics. For platform-specific details such as character limits, the article treats the older guide as practical background and keeps the current Competency Assessment System as the final point of reference.

Quick Answer: How Do You Write a Strong EGBC Competency Example?

A strong EGBC competency example uses one real workplace situation, explains your personal Action in detail, and ends with a clear Outcome. It should show the specific competency, not your whole job. The strongest examples name the problem, your decision, the standard or constraint you worked under, how you checked the result, and why your self-rating fits the responsibility, risk and complexity of the work.

What Are the Fields in an EGBC Competency Example?

An EGBC competency example is built from structured fields, not a free-form essay. The current system asks for the work context, validator, dates, Situation, Action, Outcome, Canadian environment flag and self-assessed rating.

The character limits below come from the earlier 2017 competency guide. They are valuable working guidance because they show the intended balance between the fields, but applicants should confirm the exact limits in the live form before final submission.

Field	Purpose	Length
Employer and Position	Your employer and role at the time of the work	–
Validator	The person with first-hand knowledge who can confirm this example	–
Start and End Date	The period the example covers, usually month and year	–
Situation	A brief overview of one specific situation or problem	300 characters
Action	The actions you took, including engineering judgments you made	1200 characters
Outcome	The impact your actions, solutions or judgments generated	300 characters
Canadian Environment Example	Whether the experience was gained in a Canadian environment	Yes/No
Self-Assessed Competency Rating	The 0-5 level you believe the example demonstrates	0-5

The practical lesson is simple: Action holds the detail. If Situation and Outcome sprawl, you lose the space where the assessor needs to see your decision-making. Point form is permitted in the narrative sections and is especially useful in Action because it helps you keep each decision visible.

Is Your Experience Even Worth Writing Up? The Three-Part Test

Before writing, test whether the experience is strong enough. The earlier EGBC guide gives a practical filter: a good example should involve a unique problem, your responsibility for the outcome, and work substantial enough to show competence.

• Was it a unique problem? The work involved a problem without an obvious pre-determined solution, not only routine application of a standard procedure.
• Was the outcome yours? You had full or partial responsibility for delivering the result, rather than merely observing or attending.
• Was it substantial? The work typically took at least a month to accomplish, or otherwise had enough complexity to justify the example.

Use this filter before drafting. It is faster to reject a weak candidate example early than to polish it for hours and still have it returned because it never showed enough responsibility, risk or engineering judgment.

This test also helps applicants who have too many possible projects. Do not start with the project that sounds most impressive to an outsider. Start with the project where your own decision is easiest to prove. A smaller assignment where you owned a technical choice can be stronger than a major project where your role was mostly observation, coordination or data collection.

Detail level also depends on project scale. A very large or obviously complex project may need less background. A smaller project may need more explanation because the assessor cannot see the complexity unless you make it visible.

How to Write the Situation Section

The Situation section should set up one specific problem in a small amount of space. It is not the place for company history, a full project background or a generic job description.

Include only what the assessor needs to understand your Action: the project or task context, your role at the time, the technical or managerial problem, and the constraint that made the situation meaningful. If the example came from a larger project, describe the slice of the project that matters to this competency.

A useful Situation often answers four quick questions: where were you working, what was the problem, why did it matter, and what was your role when it arose? If the situation cannot be explained briefly, the example may be trying to cover too much at once.

The reuse rule matters here. If one project supports several competencies, parts of the Situation may repeat because the same context can be relevant more than once. That does not mean the whole example can repeat. The Action must still be tailored to the specific competency.

How to Write the Action Section

Action is where the assessment is won. It is the longest section and the place where the assessor looks for the competency itself: what you personally did, why you did it, and what judgment you used.

• Write in first person. Use I, not we, even when the work was part of a group project.
• Name your exact duties and contribution. Avoid vague phrases such as participated in, involved with or assisted with.
• Explain engineering judgment, not only tasks. Show what you considered, compared, checked, rejected or escalated.
• Make complexity visible. Include project size, constraints, key issues and your responsibility where they matter.
• Use point form if it helps keep decisions and evidence clear within the character budget.

The key rule is that assessors cannot rely on implied evidence. If the Action section does not say how you verified a result, managed a risk, made a judgment or handled a constraint, the assessor should not have to infer it from the project context.

For technical competencies, Action should usually show the chain of reasoning. Name the standard, design basis, field constraint, calculation, review comment, inspection result or stakeholder requirement that shaped your decision. For non-technical competencies, name the professional choice: how you communicated, escalated, balanced resources, resolved a difference or recognised a limit in your authority.

Avoid passive wording. A phrase such as the design was checked hides who did the checking and how. A stronger Action explains that you compared the result against a standard, used an independent calculation, reviewed assumptions with a senior engineer, or reconciled conflicting information before recommending the next step.

The most common waste of Action space is repeating Situation. If the context is already clear, move quickly into your decision-making: the options you compared, the standard you applied, the calculation you checked, the stakeholder you consulted, or the change you recommended.

How to Write the Outcome Section

Outcome should state what changed because of your Action. It is not just a closing sentence that says the task was completed.

Good outcomes explain consequence: a risk mitigated, a design verified, a cost avoided, a non-compliance corrected, a safer method chosen, a client decision supported, or a lesson learned that improved later work. Keep it brief, but make the result visible.

If the outcome was not fully successful, do not hide that. A professional outcome can be a controlled revision, a documented limitation, a safer escalation, a rejected option, or a decision to seek additional review. EGBC is assessing competence, not whether every project ended perfectly.

Lessons learned fit naturally here when the competency invites reflection, but they should not replace the actual result. An assessor still needs to know what happened because of the action you took.

Can You Use the Same Project for More Than One Competency?

Yes, you can use the same project for more than one EGBC competency, but not by repeating the same example. The same Situation may support several competencies; the Action section must show a different decision or responsibility for each one.

One design project might support a technical example through a calculation you independently verified, a communication example through how you explained a constraint to a client, and a professional accountability example through the point where you identified work outside your scope. Same project, different competency evidence.

The failure mode is repetition. If several Action sections sound like the same paragraph with the competency number changed, the project is doing too much work and the evidence is too thin. Also remember that examples do not need to cover every month of the four-year experience period. EGBC’s older writing guidance encourages applicants to select their strongest examples, and recent experience is acceptable.

A practical method is to create a project-to-competency map before writing. Put the project name in one column and list the genuinely different decisions it can support in another. If two competencies point to the same decision, keep only the stronger match and find a different experience for the other competency.

What Rating Should You Give Yourself?

Give yourself the rating the written example can support. The best calibration is to read your own Action section and ask how much supervision you needed, how much responsibility and risk you carried, and how complex your own work was.

The Competency Rating Scale Summary gives a compact way to check whether your self-assessed competency rating matches the evidence.

Level	Direct supervision required	Responsibility and risk	Complexity of your own work
1	Significant	Minimal	Minimal
2	Considerable	Some	Some
3	Some	Considerable	Moderate
4	Minimal	Significant	Considerable
5	Autonomous	Total	Significant

If your example describes following a supervisor’s direction on a low-complexity task, the text does not support a level 3 no matter what number you enter. If it shows you making a reasoned decision, managing consequences and working with some supervision, it is closer to the level 3 expectation used by most categories.

EGBC’s current guide adds two cautions. Applicants are not expected to be working at level 4 or 5, and applicants should avoid rating themselves below the required minimum. If the honest rating is below the minimum, the answer is usually stronger evidence or more experience, not a hopeful number.

Discuss ratings with validators before submission. A validator who has direct knowledge of the work should not be surprised by either the example or the level you selected.

The rating should also fit the category minimum. Most categories require an average of 3.0, while Project and Financial Management and Social, Economic, Environmental and Sustainability require 2.0. This article does not re-teach the full category table, but the point matters here: your example should be written strongly enough to support the rating you need, not merely the rating you hope will pass.

What a Strong EGBC Competency Example Demonstrates

A strong example demonstrates evidence, not polish. Because EGBC prohibits third-party-written examples, this section describes what strong evidence contains rather than giving model text to copy.

• One specific situation, dated and tied to a named employer and position.
• A problem with no obvious pre-determined solution.
• Actions written in first person, describing decisions rather than duties.
• Explicit engineering judgment: what you considered, what you rejected and why.
• Independent verification where the competency calls for it, especially for technical results.
• An outcome that states a consequence, not only completion.
• A self-assessed rating the written evidence itself supports.

Think of this as an evidence checklist, not a template. The assessor should be able to identify the competency, your role, the judgment you made, the risk or complexity involved, and the outcome without needing to guess what happened behind the scenes.

A strong example also has clean boundaries. It does not try to prove three unrelated competencies in one box. It does not spend half the space explaining the employer. It does not sound like a marketing description of the project. The writing stays close to the competency and makes your contribution verifiable.

What Gets a Competency Example Sent Back

Examples usually become weak when the applicant hides the personal contribution, asks the assessor to infer judgment, or claims a rating the text does not support. Use this list as a diagnostic before submission.

• We instead of I: the example describes what the team or company achieved, but not what you did.
• A job description instead of an instance: the writing explains your normal responsibilities but not one specific situation.
• Vague verbs: participated in, involved with and assisted with leave your contribution unclear.
• Implied evidence: the example assumes the assessor will infer the judgment from context.
• No independent verification: especially risky for competency 1.5, where verification is the point of the competency.
• Insufficient context on small projects: the complexity is obvious to you but invisible to the assessor.
• Unsupported rating: the narrative describes closely supervised, low-complexity work while claiming level 3 or above.
• Repetition across competencies: several Action sections say substantially the same thing.

This list is grounded in EGBC’s own writing rules and competency wording. Applicant communities and commercial courses often report similar problems, but the regulator’s guidance is the standard that matters.

The most repairable drafts usually have real experience underneath them. The problem is not that the applicant did nothing useful; it is that the evidence is buried under team language, project background or unsupported rating claims. Revision should bring the real decision to the surface, not invent a stronger story.

Can You Write About Confidential Work?

Yes. EGBC’s earlier writing guidance explains that assessors generally do not need a high level of confidential detail. They need enough evidence to be satisfied that you can practise competently.

Generalise identifiers, not reasoning. You can protect the client, site, asset, product or technology while still explaining the engineering problem, your decision, the constraint, and the outcome. A phrase such as confidential industrial facility may be acceptable if the engineering judgment remains visible.

If supporting documents genuinely help, add them only where disclosure obligations allow. When in doubt, protect the confidential detail and make the professional reasoning clearer.

For example, you may be able to describe a confidential processing facility as an industrial site, a proprietary tool as analysis software, or a named client as a public-sector client. What should remain specific is the engineering logic: the hazard, the constraint, the calculation, the design change, the review path and the outcome.

Practical Rules Before You Submit

Before submitting, check the draft against the actual assessment constraints. A strong writing style will not fix examples that are in the wrong discipline, unsupported by validators or below the required rating.

• Every one of the 34 competencies has its own example.
• Examples are within the engineering discipline named on your application.
• Experience is, where possible, from within the last seven years.
• Each Action names decisions you personally made.
• No two Action sections say substantially the same thing.
• Each self-assessed rating is supported by the text above it.
• Every example is assigned to a validator with direct, first-hand knowledge of that work.
• You have discussed the ratings with your validators before submitting.

Drafts can be built over time. Interim validation may allow specific competencies to be validated before final submission, but EGBC’s current guide advises applicants who already have more than the required four years of experience not to use interim validation.

Do not leave validator alignment until the end. If a validator does not remember the work, was not close enough to the task, or disagrees with your level of responsibility, the example can stall after you have already invested time in writing it. Choose evidence and validator together.

What EGBC Does Not Allow

EGBC does not allow applicants to use Artificial Intelligence or third parties to create or embellish workplace examples. That rule appears in the April 2024 applicant guide and is central to how this article should be used.

This is especially important because the older 2017 guide still contains useful writing mechanics but predates the AI and third-party prohibition. Anyone using that older guide alone may miss the current compliance boundary.

Legitimate help means understanding the framework, choosing truthful projects, organising your own evidence and improving clarity about work you actually performed. It does not mean invented projects, exaggerated responsibility, fake validators, AI-written examples, contacting validators for you, or promising a registration outcome.

This boundary protects the applicant as much as the regulator. A polished example that cannot be verified is weaker than a plain example that truthfully explains real work. The goal is not to sound impressive; it is to make genuine professional competence readable, specific and confirmable.

Frequently Asked Questions

1. How do you write a good competency statement?

Use one specific situation, write in first person, put the detail into Action, explain your engineering judgment and end with a concrete outcome.

2. How long should an EGBC competency example be?

The earlier EGBC guide listed 300 characters for Situation, 1200 for Action and 300 for Outcome. Applicants should verify current limits in the live system.

3. Can I use the same project for more than one competency?

Yes. The same project and parts of the Situation may be reused, but the Action section must be specific to each competency and entire examples cannot be repeated.

4. What is the Situation-Action-Outcome format?

Situation sets up the problem, Action explains what you personally did and decided, and Outcome states the effect of your action.

5. Should I write I or we in my competency examples?

Write I. EGBC wants to see your personal contribution, even when the work happened in a team.

6. What rating should I give myself on the 0-5 scale?

Choose the rating your example supports based on supervision required, responsibility and risk, and complexity of your own work.

7. Why do assessors send competency examples back?

Common reasons include vague role descriptions, implied evidence, repeated examples, unsupported ratings and missing independent verification where the competency requires it.

8. Can I write about confidential or client-sensitive work?

Yes. Generalise confidential identifiers while keeping the engineering problem, your decision and the outcome clear enough to assess.

9. Do my examples need to cover all four years of my experience?

No. EGBC’s earlier writing guidance says there is no requirement to cover the entire four years through examples; choose your strongest examples, preferably recent and relevant.