Prioritising

There is a tendency amongst engineers to try and scope out the whole problem, and understand it all, and then work on fixing… all of it.

Being able to say this is the most important thing, and then doing that first – even when it is not the most interesting thing, is a super-power. Do this, and when things don’t go to plan, you can drop features instead of pushing deadlines.

When projects slip by the wrong order of magnitude, like something that was estimated in months that slips by quarters, my observation is that it is usually poor prioritisation. Doing things that are interesting rather than important, failing to eliminate known unknowns.

Summarising

Summarising relates to prioritisation. It’s been able to take all the information that you ingest to make a decision and say these are the most important pieces, and not overload everyone else with all your information. It’s being able to pull out of a meeting, or a document, or a workshop, these were the key points.

Being able to draw out the conclusions from a larger thing shows your understanding, and saves everyone else time. Almost everyone will thank you for this.

When people can’t present the key points of their work, it’s vastly more work for anyone else to try and pull them out. They are also more likely to get lost in the details when trying to communicate it (more on that below).

Running a Meeting

I know, we all hate meetings. But sometimes they are inevitable. And actually well run meetings in limited quantities can be really useful.

There are two key things for a good meeting. First: respect people’s time. This means, come on time, and prepared. Secondly: keep it moving, and actionable. Make sure that you kill discussion that is better taken offline, and leave with clear action items, that are communicated back within 24 hours (i.e. an email that says “this is what we are doing next”).

When your meetings are time-efficient, and productive, people might not be enthused about them, but they will appreciate their effectiveness, and thank you for respecting their time.

When meetings are badly run, or lack followup, they are a waste of time, and cause resentment. We all have better things to do than have a pointless discussion that goes nowhere, or worse, results in an unresolved argument.

Presenting

Sometimes it seems almost a point of pride amongst scientists and engineers to present badly. But if you’ve mastered summarisation and prioritisation above, they will be your friend here. Summarise you content rather than trying to fit everything in, and prioritise what is most important. As for meetings, be prepared and respect people’s time.

Presentations are an opportunity to demonstrate your expertise, and influence people’s behaviour. Give a good one, and you’ll stand out as an expert, and a leader.

Bad presentations overload with information, often losing the audience well before any conclusions are offered. The way to demonstrate your knowledge is not to try and cram it all in and expect people to read your slides, even if it convinces of your knowledge it doesn’t convince that you know what to do with it.

Writing

Very similar to presenting and builds upon summarisation and prioritisation as key for what (and what not to!) include.

If you can quickly put together a well-thought through document and circulate it, or formulate a reasoned email response (or request) you’ll have a head start on your peers who are still wondering what to write, or not saying anything at all.

When writing is hard work, a lot of things (design docs, email discussions, review season) become exponentially more stressful and much more work. All of these things are pretty unavoidable, and only get more important as you progress.

Why Bother?

I have to say, that some of the things that I’ve done that have really been the most thankless have fallen under these categories. But! So have many of the things that I’ve done that have been most appreciated, and that have helped me get ahead. A document became a presentation, became… so many other things. Prioritisation and shipping on time translated into a number of benefits. Being able to run a meeting reasonably well, regardless of any other benefits, has at least saved me a lot of time.

I’m not an expert on any of these things, really. I’d say I do them all slightly better than average for an engineer (and for presenting at least the bar is set low). There are plenty of resources out there for getting better at each of them.

What soft non-technical skills do you take advantage of?