I Statements in Career Episodes: EA Assessment Guide

An Engineers Australia assessor does not read your career episode as a story. They read it the way an auditor reads a claim: line by line, deciding which actions carry your name and which belong to the team standing behind you. That is why I statements in career episodes outrank every other stylistic choice you make. The first-person voice is the mechanism that tells the assessor which technical decisions were yours, and a strong project written in the collective “we” becomes evidence the assessor cannot attribute to you at all.

Competitor guides tell you to swap “we” for “I” and stop there. That advice is correct and nearly useless, because it never explains what the assessor does with the pronoun. This piece does, and then hands you a repeatable method for pulling your individual contribution out of genuinely shared work.

Why Engineers Australia assessors read for I, not we

How competency attribution works in the MSA assessment

Your Migration Skills Assessment (MSA) submission is judged against the Stage 1 Competency Standard, which groups its competency elements under three headings: PE1 covers the knowledge and skill base, PE2 covers engineering application ability, and PE3 covers professional and personal attributes. Every element in the standard must be evidenced somewhere across your three career episodes.

The connection is made in the Summary Statement. That document is a table, not an essay: it maps individual career episode paragraph numbers to the competency element each paragraph proves. When an assessor checks whether you meet PE2.1, they turn to the paragraphs you nominated and look for you doing the work. A paragraph whose subject is “we” states that a group characterised the problem. It does not state that you did. In the Summary Statement’s logic, that paragraph cannot be claimed as individual evidence, and the element goes unproven no matter how sophisticated the engineering was.

The pronoun matters because it determines whether a paragraph fills a cell in the attribution table or leaves it empty.

The gap between team credit and individual evidence

The engineering-application group makes the expectation explicit. Its elements are about what you personally conduct and manage on a project, not what the team delivered around you. Engineers Australia expects team work. What it refuses to do is let team work stand in for individual capability.

That refusal has a dedicated home in the standard. The professional-attributes group (PE3) assesses collaboration and teamwork in their own right: exactly the skills you might be tempted to describe in the plural, such as reliable delivery, clear communication within a team, and mentoring. Because your teamwork is scored under PE3 separately, writing PE2 evidence in the first person costs you nothing. The two are measured apart. Padding your engineering paragraphs with “we” does not earn teamwork credit; it only strips the individual attribution PE2 demands.

What makes a valid I-statement in a career episode

The three components every I-statement must contain

An I-statement earns its place only when it carries three things: an action you took, the technical decision inside that action, and the outcome your decision produced. Miss the decision and you have described a task. Miss the outcome and you have described an intention.

Treat it as a short equation you can run on any sentence. Input: the specific thing you did. Logic: the engineering judgment that shaped how you did it. Output: what changed, measured or observed. “I selected a duty-standby pump arrangement after modelling three configurations against the 2040 demand forecast, which held delivery pressure within tolerance during peak simulation.” The action and decision sit in the first clause, the reasoning in the second, the outcome in the third. Every part does work an assessor can map.

Why “I helped” and “I was involved” fail the evidence test

“I helped design the drainage system.” “I was involved in the structural review.” “I assisted with commissioning.” Each fails for the same reason: it reports participation and nothing else. No decision can be attributed to you, and no outcome can be credited. “Helped” could mean you led the calculation or fetched the drawings, and the assessor will not assume the generous reading. Vague first-person verbs also weaken your communication evidence under PE3, so a hedged sentence can miss on two fronts at once.

How to extract your personal contribution from a team project

Mapping your sub-role before you write anything

Before drafting a sentence, map the project as an org chart with one node highlighted: yours. Write down the deliverables the team owned, then draw a line from each to the person actually accountable for it. Your job is to find the deliverables, and the fractions of deliverables, that trace back to you.

Put this on paper first, because writing chronologically buries your contribution inside the team’s narrative. Map the role, then write.

Isolating the decisions only you made

Contribution is not the same as presence. For each deliverable you touched, ask a sharper question: what decision here would have gone differently if someone else had made it? The load path you chose, the algorithm you rejected, the tolerance you set, the sequence you resequenced. Those become PE2 evidence. Attending the meeting where the decision was ratified does not.

Converting team we sentences into individual I-statements

Four before-and-after transformations, annotated to PE elements

Once you know the target element, the rewrite becomes mechanical. Watch the same collective sentence split into action, decision, and outcome across four disciplines.

Civil and structural. Before: “We found the retaining wall was failing and replaced the drainage.” After: “I traced the wall’s movement to hydrostatic pressure behind a blocked subsoil drain and specified a geocomposite drainage layer sized to the catchment, which arrested the deflection over the following wet season.” (PE2.1, characterising a problem with no obvious solution.)

Software and IT. Before: “We built the payment integration.” After: “I designed the payment integration and chose an idempotency-key pattern to stop duplicate charges when the network retried, then validated it against twelve edge-case transaction flows before release.” (PE2.4, design carried through to validation.)

Mechanical. Before: “We redesigned the conveyor to cut downtime.” After: “I recalculated belt tension and drive loading for the incline and selected a lagged pulley to eliminate slip, which removed the recurring stoppages that had been stalling the line.” (PE2.1, with PE1.2 technical depth.)

Project coordination. Before: “We coordinated the subcontractors to stay on schedule.” After: “I sequenced three subcontractors’ access to the plant room and resolved an HVAC-versus-electrical clash by resequencing two work packages, holding the fit-out to its original handover date.” (PE2.5 project conduct, with teamwork surfacing for PE3.)

No two rewrites share a shape, and that matters almost as much as the pronoun. Four identical templates signal a formula to an assessor, not an engineer.

When we is acceptable and when it signals a competency gap

There is exactly one place “we” belongs: setting the shared brief. Use it to describe the objective the team was given, the collective deliverable, or the scope you all worked toward. “Our brief was to upgrade the pump station to meet projected 2040 demand” orients the reader honestly and costs you nothing, because it makes no competency claim.

Every sentence after that orientation should carry “I.” The moment “we” reaches a technical decision, an analysis, a design choice, or a validation, it has walked into PE2 territory and taken your evidence with it. If you genuinely cannot rewrite a technical sentence in the first person, that signals the contribution was not individually yours. Choose a different example rather than overclaim.

Applying I-statements across all three career episode sections

The three sections do not carry the same first-person load, and treating them identically is one of the most common structural errors in CDR submissions.

Background: context first, personal action light

Background sets the scene: the organisation, the project’s purpose, your position in it. Personal-action density is deliberately low here. State your role and responsibilities in the first person, then let the shared brief do its work. Overloading Background with I-statements reads as strained, and none of your PE2 evidence lives in this section anyway.

Personal Engineering Activity: where density is assessed

Assessors weigh this section hardest, and it should be the densest with valid I-statements. Nearly every paragraph you nominate in the Summary Statement comes from here, so nearly every paragraph needs the action-decision-outcome structure carrying your name.

Below is a two-paragraph extract from a team-based pump station upgrade, first as most engineers write it, then rewritten with the satisfied element flagged.

As drafted: “On the pump station upgrade, we assessed the existing capacity and found it short of projected demand. We modelled several configurations and chose a duty-standby arrangement. We prepared the hydraulic calculations and issued the design to the contractor.”

Rewritten: “I assessed the existing pump capacity against the 2040 demand forecast and identified a shortfall of one duty pump under peak flow. [PE2.1] Modelling three configurations, I selected a duty-standby arrangement because it met the redundancy requirement without oversizing the wet well. [PE2.4] I completed the hydraulic calculations, verified the selected duty point against the system curve, and issued the validated design to the contractor; the project was built without a capacity variation. [PE2.5]”

Same project, same team. The rewrite fills three attribution cells the original left empty.

Summary: reflecting in first person on your decisions

The Summary is reflective, and it stays in the first person. Here you interpret the decisions you made and the lessons you drew, not the team’s collective experience. “I would now run the demand model earlier in concept” is evidence of professional judgment. “The team learned a lot” is attributable to no one.

How to audit your career episodes before submitting

Auditing I statements in career episodes comes down to two repeatable passes you can run on any draft.

A pronoun-to-competency check for any draft

Run the first pass with one question per sentence: if I claimed this paragraph in the Summary Statement, could the assessor point to me? Highlight every “we,” every “the team,” and every passive construction (“it was decided,” “the design was completed”). For each, either rewrite it into an I-statement with a decision and an outcome, or confirm it belongs to the acceptable brief-setting context. Anything left over is a gap you can close before an assessor finds it.

Patterns an assessor flags before you do

Three patterns give a reviewer pause: clusters of “we” around the technical decisions, “helped/assisted/involved” verbs standing in for real actions, and passive voice hiding the actor. Across every revision of Engineers Australia’s career episode guidance, the through-line has not moved: individual attribution, demonstrable per element, is the standard. Reading your own draft against these three patterns is the cheapest quality check available.

To see where career episodes sit inside the whole submission, and what else assessors score against, read the complete CDR report guide next. It places the career episodes, the Summary Statement, and your CPD into one picture, so you can see how your I-statements feed the final assessment.

Questions Engineers Ask About I-Statements in Career Episodes

Can I ever use “we” in an Engineers Australia career episode?

Yes, in one place: describing the shared project brief, team objective, or collective deliverable, where you are orienting the reader rather than claiming competency. Every technical decision, analysis, design, and action after that should be written as “I.”

What if my entire project was team-based? How do I write my individual role without overstating it?

Map your sub-role first, then isolate the specific decisions that would have gone differently without you and the outcomes your actions produced. Write those in the first person. Team-based projects are expected and common, so claiming the decisions that were genuinely yours is not overstating anything.

How many first-person statements should appear in a single career episode?

No fixed count applies. The Personal Engineering Activity section should be dense with action-decision-outcome I-statements, because nearly every paragraph you cite in the Summary Statement comes from it. Background carries far fewer, and the Summary reflects in the first person on decisions you made.

Does Engineers Australia reject CDRs for overusing “we”?

No documented rule sets a pronoun-count threshold. What is documented is that each competency element must be evidenced by an individually attributable paragraph. Overusing “we” fails that test in practice, because a collective sentence cannot be mapped to you in the Summary Statement, whatever the tally.

What is the difference between an I-statement and simply listing the tasks I completed?

A task list reports what happened (“I ran the calculations”). An I-statement adds the technical decision inside the action and the outcome it produced (“I ran the calculations, selected the duty-standby option for its redundancy, which met demand without oversizing”). Assessors credit decisions and outcomes, not activity.

Do I-statements need to appear in all three career episode sections, or only in the Personal Engineering Activity section?

All three, at different densities. Background states your role in the first person but stays context-heavy. Personal Engineering Activity carries the highest I-statement load. The Summary reflects in the first person on the decisions and lessons. The pronoun stays first-person throughout, even where the density drops.