We should strive to be present to the task we’re doing at that moment. Lately it seems that I’m constantly thinking about what I’m *not* doing in a moment, or lamenting what I “should” be doing at that moment. Instead of being present to the moment’s task.

But that’s not fair to that task currently in play. Even if that task happens to be swimming laps, which may not seem as ‘important’ as checking emails or reviewing a document.

I’ve only just recently figured out that I’m doing this. Just being aware of it helps me to be more present.

I remember noticing, about 10 years ago, how quickly I went from hardly having anything with a battery, to having many multiples of many things needing charging. Our iphones, e-watches, e-tablets, earpods, and many other e-conveniences, need to be plugged in every so often. Every day, for some items.

I’ve also recently replaced my e-bike with a new-fangled one. It was this first one, Nellie (RIP), bought in 2012, that made me aware of the need to know where a plug-in is. It used to be just about ‘where’s the next toilet’. Now it’s, “can I plug this in there?”

There are sixteen capabilities/competencies/commitments, whatever you might label them as, nominated by Engineers Australia as key achievements for engineers pursuing chartered status.

Writing just 100 words about each of the sixteen has been a challenge. One hundred words isn’t enough for any of them, obviously. But by distilling each of them into 100 words, I now have a greater understanding of how to make them ‘real’.

Key skills for any capability or competency are: firstly the ability to notice when you’ve experienced one, and secondly, most importantly, is being able to remember the experience for when it comes up again.

“Deal with ethical issues” is number one in Engineer Australia’s elements list of competencies required for Chartered status.

It’s true that ‘proving’ you’re ethical is more fuzzy than ‘proving’ you’re good at math or that you can finish your work to a deadline. Proving personal ethicality does require some thought.

But don’t romanticise ethics into grand whistle-blower newsworthy cases with heroes and villains. Engineering ethics are shown in our daily tasks and activities: they are in budgets, in spreadsheets, and in daily decisions like resource planning. Everyday decisions that show what is important to you and your company: that’s ethics.

Way back in 2003, I wrote a paper asking what the definition of a pipeline engineer should be, because even back then I saw the wide range of competencies a pipeline engineer could have. With engineering disciplines blurring, these definitions are getting more important.

Over the years I’ve explored how to measure competency, advised on how to acquire it, and helped with frameworks and mapping to visualise it. Being able to assess, acquire and apply appropriate competencies is a fundamental requirement of professional engineers. Part of that exercise is being able to concisely describe what your expertise (main competency) is.

An element of competence for those of us in knowledge work, particularly engineers, is the ability, and willingness, to take responsibility for our work. We should be able to acknowledge our role in decisions and actions (even if they prove to be incorrect).

Taking responsibility includes performing work in transparent and repeatable ways, so that it can be checked. It shouldn’t rely on black magic.

Responsibility also involves seeking inputs from peers and colleagues, and taking that feedback to make improvements to our work. The reverse is applicable too: providing constructive feedback to our colleagues is a responsibility as well.

We in the engineering arena have several obligations to the community. The “community” will change depending on the nature of work being done. It could be the public, or our colleagues.

When undertaking work, we always need to make it as safe and sustainable as possible. Safe for the workers and the public, and sustainable for the future.

I’m finding these competency platitudes hard to rewrite into something meaningful. Of course we have to be safe and sustainable! The trick is to see that in our everyday tasks, and to apply it when we’re developing spreadsheets and replying to emails.

Identifying and responding to stakeholders is an important task for anyone in knowledge work, including and in particular, engineers who design, construct or operate assets in the public space.

There are the big-picture stakeholders: the general public, the asset owner, the shareholders and the landholders which the asset will be on. These are massive, almost faceless ‘stakeholders’ who deserve more than being faceless. And that takes effort.

The small-picture stakeholders around us are just as important: our colleagues, our manager, the technical expert, the project manager. These stakeholders need for us do to quality work. Don’t let them down either.

In my very first working role, as a “co-op” student (internship) at the Canadian National Energy Board, I was assigned the task of developing a risk management tool for pipeline ruptures. This was in 1992. My deliverable was a rudimentary spreadsheet that calculated risk based on factors such as pipeline characteristics and wind direction. I still have the report.

What screams out at me is that it doesn’t consider *why* the asset failed, nor how to prevent that failure. The deep and specific effort to calculate risk into number should at least be associated with the causes and preventions, too.

Those of us doing “knowledge work” owe a duty of care to the public who are affected by the work done. It is an obligation in the engineering profession, both internally as a person, and externally to the public, to work within the laws, regulations, codes and other instruments which we are legally bound to apply.

It’s sometimes not easy to digest those documents, but we are obligated to take the time to investigate and understand them. Interestingly, norms and values (and ethics) are indicative of legal and regulatory requirements. This is a complex competency which needs some thinking about.

The academic view of communication identifies a sender and a receiver, with a message encoded by the sender and then decoded by the receiver. But that’s somewhat unhelpful when you’re trying to find out whether the widget will actually be delivered on time and on budget.

Communication is obviously an essential competency. The irony though is: “I have too many emails!”. Perhaps communication is more than emails.

Academically, the decoding of your encoded message to the receiver should not make them work harder. In reality, try to make sense. Engineering is as much about collaboration as it is about calculations.

Performance in any job, and performing in life in general, is a given. All the world’s a stage, right? We perform every moment of the day. And sometimes, people are watching.

Performance for a thriving professional engineer might be as simple, or complex, as doing what you said you’d do. Perform as expected; it should be straightforward. Keep to schedules, recognise the cost and safety implications of decisions, and produce high technical quality outputs.

Demonstrating the ability to perform in a role, while applying our ongoing duty of care to the public, is a performance I always like to see.

Before solving a problem, it should be well-defined as a problem, and, preferably, also describe what it looks like when the problem is solved.

But stating a problem isn’t solving the problem.

And problems don’t have to be humungous behemoths. Small, daily action on problems is satisfying too.

Tangible, tacit, sometimes costly and time-consuming steps of taking action creates memorable experiences.

But that’s hard. It’s much easier, and a quicker dopamine hit, to scroll our phones for more problems.

I think taking action on engineering problems means you can clearly state what you did to succeed at solving the problem.

Judgement is defined as the “ability to make considered decisions or come to sensible conclusions”. The problem with that definition is its subjectivity: who decides what the sensible conclusion is?

It’s hard to teach “judgement” in the engineering context; and how to develop the skill is a bit murky. Being exposed to situations requiring judgement might be the best way.

Examples requiring judgement include monitoring the quality of other peoples’ work fairly, diagnosing performance deficiencies, or detecting impending failure of systems, assets, or processes.

Having good judgement is valuable to you and your workplace while being a thriving, effective engineer.

Differentiating between ‘standard’ engineering knowledge and ‘advanced’ engineering knowledge can be a tricky exercise. In my case, as a generalist engineer, I’m a bit hard-pressed to find examples of applying advanced theory-based understanding of engineering fundamentals.

I’ve built many calculation spreadsheets, but mostly for basic math equations. I’ve reviewed many P&IDs (process and instrument diagrams), but whether that’s advanced knowledge is debatable. But I am involved in industry research programs, and so I do keep up that way.

Utilising advanced engineering knowledge is a required element of technical proficiency for professional engineers. And, it’s a differentiator, leading to new innovations.

I remember working on flood mapping for a pipeline crossing a river in Brisbane. I was working with an expert hydrologist in Melbourne. I knew Brisbane’s wet season is in February. The Melbourne expert kept trying to correct me: “it rains more here in winter (July)!” They’d assumed the same weather patterns. They aren’t.

There are plenty of transferable skills unrelated to location, but there is a subset which unwaveringly require local knowledge. Much of this category is unwritten, tacit, and intangible, and you’ll only figure it out by being there.

Local engineering knowledge feeds into overall engineering technical proficiency.

Analysing a problem includes the steps of “define, investigate and resolve”. Identifying the main issue that manifests as the problem is sometimes harder than it seems. It’s often easier to present a solution with the problem not defined, or sometimes the solution doesn’t actually solve the problem.

Also, it seems once we’re into the workaday monotony, we spend more time replying to emails and going to meetings. Hint: those emails and meetings are probably trying to solve problems. Identify them!

Problem analysis is a key element of technical proficiency, and thriving professional engineers embrace the challenge of problem analysis. Daily.

Creativity and innovation are obvious and common requests in job advertisements. But they are a little esoteric when trying to demonstrate evidence of them.

For example, developing a new way to display data isn’t attention-getting “wow” creativity, but look into how data was presented (poorly) for the Challenger O-Ring decision-makers, and we can see how important thinking creatively can be.

And we forget that innovation usually includes quite a few failures before the headline-grabbing “Success!”. Those previous failures can be costly, both monetarily and mentally.

Creativity and innovation are elements of technical proficiency competence, and thriving professional engineers embrace them.

Evaluation is the making of a judgement about the amount, number, or value of something. It’s an assessment of verified input information to identify positive or negative attributes. Often there is a checklist or ranking system to record the evaluation outcomes.

In order to evaluate well, we need to think systematically, and we need understand the interconnectedness of the many decisions involved with evaluation. Evaluating the outcomes and impacts of engineering activities means we think of the future consequences of our actions and decisions.

Evaluation is an element of technical proficiency competence, which professional engineers should strive to do well.

Here’s the list of the competencies that Engineers Australia has identified to obtain “chartered” designation. Like them or loathe them, or wonder how in the world to ‘prove’ you have these, regardless, I think these are a good round up of traits any good engineer should have, chartered or not:

Evaluation of outcomes and impacts, creativity and innovation, problem analysis, local engineering knowledge, advanced engineering knowledge, judgement, taking action, performance, communication, meeting legal and regulatory requirements, identifying assessing and managing risks, engaging with relevant community and stakeholders, developing safe and sustainable solutions, responsibility, competent practise, and dealing with ethical issues.