The NPR podcast “Planet Money” recently explored how our social circle is one of the strongest predictors of economic mobility, as well as also touching on the concept of social capital.

Social capital is defined as the “networks of relationships among people who live and work nearby, enabling a society to function effectively. It allows us to leverage social connections in order to solve problems, improve well-being, pursue shared objectives, and take collective action. “

I think we’re now out there again, building it up and striving to make society a better place.

I like social capital. Bring it on.

There’s a 1953 essay by Isaiah Berlin, based on an ancient Greek idea: “a fox knows many things, but a hedgehog knows one big thing”.

The 1953 essay applies this to writers and creatives, dividing them by those who see the world though a single defining idea, versus seeing many experiences and considering the world more complex than a single idea.

I thought this might help categorise businesses, and perhaps knowledge workers too. We should be hedgehogs for the most part (single focus solutions). But no, recognising the complex is essential too. So, maybe this parable doesn’t apply after all.

Specialist expertise in something like piping design, or photography, or materials science might be called a niche specialisation. Having a niche is a good strategy for career building.

Knowing what in particular that you’re good at is a key facet of job satisfaction.

I’ve mentioned before that the four aspects of career building are: community/connection (most work isn’t a solo sport), impact (know how you’re making a difference), autonomy (be able to do some work undirected), and mastery. Mastery is usually in a niche area. It’s difficult to be a master of everything, so pick a niche and go deep.

Good work is often invisible. 

And this is especially true in the infrastructure space: if nothing goes wrong, we’ve done it right.  It’s a case of ‘no news is good news’.  But if no one is talking about the good work being done, it’s easy to forget that it is going on.

In 2015, John Oliver did an entertaining piece called “Infrastructure” – including a fake movie trailer that highlights how boring yet essential infrastructure maintenance is.  It’s a cost on the balance sheet that is easy to cut out. 

There is, apparently, a fine line between appropriate maintenance, and gold-plating. 

Too many documents are created without purpose, without an ultimate owner, nor a defined lifecycle. It’s too easy to start writing a document, when possibly it’s not needed, or there’s already a similar one already in existence.

For any document you think you need to create, establish some associated metadata for the document. Why does it exist, who would notice if it wasn’t created, and, what happens next to that document. And it should be very clear who the audience of the document is.

A strategic documentation approach saves time. Figure out the purpose, role, and lifecycle of that document.

The world works better when the engineering community is thriving.

I think in order to thrive, engineers need to 1) be doing interesting work, 2) feel like their work matters and 3) be working with like-minded but challenging people.

Doing interesting work means stretching ourselves, learning and becoming masters at our topics. Doing work that matters means we’re making a difference, to people’s lives, and to the environment. Working with like-minded but challenging people means group work, teamwork, and belonging to a community of people who are also doing interesting, meaningful work.

Thriving engineers make the world a better place.

When pursuing goals, any kind of goal, commitment is required. To run a marathon, to win a tennis tournament, or to achieve a role or position in your chosen field: these goals require commitment.

To achieve them also requires talent. I’m never going to win a marathon event as I don’t have the talent, but commitment will get me to the finish line.

Talent is important, but perhaps commitment to any goal is more important. There are people out there with the talent to win a marathon race, but won’t because they haven’t put in the commitment to achieve it.

During a discussion with some young engineers about competencies and registration (CPEng, RPEQ), I was pleasantly surprised when the group manager stopped us and said: ethics.

A pause in the discussion.

There’s no university course on engineering ethics in Australia, but it silently underpins everything we do as engineers. Ethics are the baseline for every decision requiring engineering judgement.

I’m currently reading this book, “Engineering and Geoscience – Practice and Ethics”, a 440page textbook, updated from my 1990 reading of it as a required credit course at the University of Alberta. It’s nice to revisit a key topic for all engineers.

Social norms are informal understandings that regulate behaviour of groups. So, not everything we do, or are expected to do, is written into the laws.

Obviously, there are many expected behaviours and norms. Simple example: we should acknowledge people in the elevator. As pedestrians, we should keep left (in Australia). In a work environment, we should be supportive and respectful of other members of project teams and committees, especially when new or not familiar with the team’s developed culture and norms.

Norms can be codified into rules and laws, though I prefer when we can rely on the informal understanding.

Generalists are typically good at a wide variety of things, while specialists (technical specialists) are good at their chosen expertise.

Generalists excel at many things: managing projects, people, scope, risk, quality. Any number of wide-ranging, multi-disciplinary topics.

Specialists dive deep into a topic. They know the topic inside and out, and have ‘done’ it more than a few times, and are known for it.

(And, sure, a very good project manager might be considered a specialist project manager, that’s true).

On projects, and in society, we need both specialists and generalists. You wouldn’t go to your GP for knee surgery.

Engineers can’t be both a subject-matter-expert (SME), AND a people/leadership expert.

This rule will of course have exceptions, which will prove the rule; because the exceptions are, simply, exceptional.

It depends if you develop in-demand, project-based, one-of-a-kind expertise (piping design, overhead wire specifications, bolt connection requirements) pursued deeply and with purpose, and therefore in demand when that skill is required (and meanwhile also being good at a lot of other things).

Or, you focus on and prefer team-based interactions leading to leadership roles (while also being really good technically).

Know which you prefer being: technical expert, or an expert leader/coordinator.

I’m involved in standards development with Standards Australia, and I love just about every aspect of it. The camaraderie, support, networking and exposure to brilliance is remarkable.

One thing that often comes up is the business model of Standards: volunteers contribute to the content (millions of hours and other expenses), and then Standards are sold at a seemingly high price considering how they’ve been made.

One concept to consider is how the social media enterprises (FB, IG, TikTok, LI) have been so successful making billions of dollars *using content created by volunteers*. I wonder if there’s something to integrate there.

When looking for work, consultants often just list the deliverables produced for a client (such as reports, facilitation, designs).

But the buyer wants the benefits; the deliverables are how we get there.

It’s like we don’t “want” a hook in the wall (deliverable), we want to hang a great piece of art on the wall (benefit).

In knowledge work, it’s difficult to make that leap from deliverable to benefit. The benefit isn’t as straightforward as hanging a picture. It’s not always clear in my mind, but it’s a magical shift when we can switch from talking about deliverables to benefits.

I’m fortunate to belong to a number of teams. Read: committees. This is important to me as a solo consultant, since I don’t have access to a ‘corporate team’ culture. I choose to be a soloist, and I also choose to belong to, or chair, a variety of committees and other team-based volunteer roles. This helps me to be connected and collaborative with other humans. It’s important for humans to be part of a community; these technical communities are mine.

I really enjoy the teamwork atmosphere of the committees I’m on. It’s fun, challenging, informative and supportive. Thank you, team-mates.

The purpose of an engineering degree – or any degree with a technical focus – should be that the graduate can do the engineering, science, or technical work. The reasons for getting an engineering degree should not be to be a manager or CEO.

It’s a little contrarian to think this, but there you go. While I agree we need technical people to be able to communicate and collaborate, I also think we need our technical people to want to do the technical work.

Engineers should want to design, build, maintain, solve problems, create new innovations, or better yet, all of those.

We in the knowledge worker space don’t ‘make’ things; not really. Some of us develop designs that eventually get built, but many, particularly in asset management or operations roles, don’t make anything except decisions.

Our decisions are our product.

Credit for the idea of a ‘decision journal’ goes to the writers at Farnam Street, and the headline idea that our “product is decisions” is clever. And products need managing.

A decision journal is quality control for our thinking. Write down, or at least contemplate, key aspects of decisions: consequences (and for who), how you feel, context, possible outcomes, and variables.

I’m Gen-X. (We’re awesome, I know, right?). We’re the generation straddling life’s existence between analogue and digital. We’ve benefitted enormously from, and know to appreciate, the inventions and improvements brought on by the large Boomer generation before us. We also benefit from the youthful enthusiasm of Gen Y and Z, many of whom we report to now.

For knowledge transfer, learning and otherwise helping those coming up behind, something my colleagues and I are trying to understand is: written word or other delivery methods? Maybe textbooks and articles are superior, but maybe we need to embrace audio and video, too.

It’s difficult to be in conversations filled with “gotchas”, where it feels like the other person is just waiting to top your contribution.

Some people seem to need to do the ‘one-upmanship’ in the conversation, such as correcting minor flaws, or expanding on a statement with a know-it-all approach that feels a little icky. But perhaps they are just trying to be helpful.

Wait, in full disclosure of self-awareness, perhaps I do this myself, appearing a little showy while trying to be helpful. They say that what we don’t like in others is something we might be ourselves. Um, gotcha?

The hardest thing engineers (and many other professions) face is trade-offs. The hard reality of many roles, positions, job descriptions and higher pay-grades is that we face impossible decisions where someone or some aspect ‘loses’.

Cost or quality; heavier weight or less strong; noisy operation or faster response; rapid results or accurate results; reliability through redundancy or lower cost production. These are dilemmas faced all the time on engineering projects and in asset management.

Of course, we want to maximise both options, but science and physics, or let’s just call it ‘the real world’, prevents that. We must accept trade-offs.

It’s normal to think of training and learning as linear. That’s to say that “Topic 3” must be preceded by first understanding Topics 1 and 2. In many cases, there are pre-requisites identified that say you can’t know ‘y’ until you know ‘x’.

This is probably mostly true, particularly for factual or mathematical learning. But, as I’ve learned recently, when we bring in ideas, innovation or complex problems, our learning is more of a spiral.

We need to circulate around a whole range of topics, ideas and facts, in and out, up and down, in order to solve complex problems.