EO capability guide · 2024 Framework
Managing Information, Problems and Decisions at EO
What the board is really testing when they ask an EO about gathering information, solving a problem and making a call, with one full high-scored answer set beside one that leaves marks on the table.
What the board is testing at EO
The capability
Managing Information, Problems and Decisions is one of the six capabilities profiled for Executive Officer under the 2024 Capability Framework. At EO it is marked through these sub-elements:
- Gathering & Processing Information
- Problem Solving
- Informed Judgement & Decision Making
At EO, this capability is about checking the facts before you act, working out what is actually going wrong, and making a sensible decision you can stand over. The board wants to see you get to the root of a problem rather than treat the symptom.
They are scoring the thinking, so the strong answers make the reasoning visible: where you got your information, what it told you, the options you weighed, and why you chose the one you did.
Knowing when to decide yourself and when to escalate is part of the judgement at this grade. Flagging something to a manager with a recommendation is a good decision, not a failure to decide.
The question shapes boards use
Boards rarely name the capability outright. They ask for an example and score what you say against it. For Managing Information, Problems and Decisions at EO, the question usually lands in one of these shapes:
- Tell us about a time you had to get to the bottom of a problem before you could fix it.
- Describe a time you spotted an error or discrepancy in information or data.
- Give an example of a difficult decision you had to make, and how you reached it.
- Tell us about a time you had to gather information from different sources to resolve something.
A high-scored answer, beside a low-scored one
Same candidate, same true example, two ways of telling it. The difference is not the story. It is whether the board can tick a behaviour and write down a result. Read both, then read the margin notes.
The scenario. A payments team processing a small grant scheme. Before a payment run goes out, the officer notices the totals look higher than usual. The question asks for a time you spotted and dealt with a discrepancy.
I was doing the final check on a grant payment run when the total came out roughly fifteen per cent higher than the previous month, with no obvious reason for the jump. Rather than release it and query it after, I held the run and went back to the underlying list.
I pulled the current file against the prior month and sorted for duplicates, and I found that about thirty applicants appeared twice, because a data import had run once manually and once on a schedule. I checked two of the duplicated records by hand against the original applications to be sure it was a genuine double entry and not two valid claims. Once I was confident, I removed the duplicate lines, kept a copy of the before-and-after totals, and set out what I had found for my supervisor with a recommendation to release the corrected run.
The corrected run went out on time and about forty thousand euro in duplicate payments was stopped before it left the account. I also flagged the twin-import cause so the schedule could be fixed, and that class of error has not recurred.
Why it scores
- Gathering and processing is explicit: comparing files, sorting for duplicates, checking records by hand shows how the facts were established.
- Roots out the cause: identifying the twin manual-and-scheduled import goes past the symptom to why it happened.
- Judgement on escalation: deciding it herself but putting it to the supervisor with a recommendation is the right EO-level call.
- The result is quantified and checkable: about forty thousand euro in duplicate payments stopped before release.
- Prevention closes it: flagging the import cause so it does not recur shows the decision held beyond the one run.
I noticed that something did not look right with one of our payment runs, the numbers seemed a bit off to me. I have a good eye for detail so I tend to pick up on these things. I looked into it and sorted it out before it caused any problems, and then I let my manager know what had happened.
It was a good thing I caught it because it could have been a lot worse. My manager was glad I had spotted it and said it showed good attention to detail.
Why it loses marks
- No method shown: "I looked into it and sorted it out" skips exactly the gathering and problem solving the board is scoring.
- No number: "a bit off", "could have been a lot worse" leaves the board with nothing to measure the outcome against.
- Claims the trait: "I have a good eye for detail" tells the board instead of showing the check that found the error.
- No root cause: nothing about why it happened or whether it could recur, so the judgement is invisible.
Quick take
Common questions
Does escalating a problem make it a weak decision-making example?
What if the data or information turned out to be fine?
Start your example - your first one is free
A free account includes one AI coaching run on your own example, scored against Managing Information, Problems and Decisions the way a board would.
Write my first example