Engineering systems for consistency and impact

Published on January 03, 2022

This is foundational series article. Read more here

Tagged: #engineering #management

Follow me on twitter for more posts like this

Your most impactful engineering is done before you write any code.

It’s important to have some systems around how you approach problems to make sure you’re consistent every time.

These are some of the techniques I use to make sure I’m covering as many angles as possible when doing my pre-coding engineering.

Pre-engineering engineering

These are some questions I use to check my knowledge of a problem before I think about specific technical solutions

  • Do we understand the problem? Does it even need code?
  • Is there a hard launch date? When will we start communicating the change
  • What documentation will be needed?
  • How will we measure success? When will we measure success?
  • When will the feature or product be revisited and reviewed for success?
  • Will we need UX and UI? How much heads up will this need?
  • How will this change impact other important services?
  • Are there any regulations that need to be followed here? Are there any legal requirements?
  • What assumptions have been made so far?
  • Does the system need to fall back to a useful state?
  • What are the risks? Are we dependent on any third party teams or services?
  • What kind of extra resources will we need to run this in production? Will it need new infrastructure?

How to evangelise an engineering change to company leaders

As an engineer you will have to sell a proposal upwards to your leaders. These folks are short on time so be concise. Follow this as a guide

  1. Start with the conclusion.
  2. What’s the problem you’re solving and why does it matter?
  3. What are we currently doing about this problem?
  4. What are our competitors or industry leaders doing?
  5. What’s your solution?
  6. What’s the cost?
  7. What’s the cost of inaction?
  8. The action items

(This list isn’t mine - I think it came from a presentation somewhere. I didn’t note who created it so let me know if you know who it should be attributed to!)

How to evangelise an engineering change to other engineers

If you’re introducing a new platform or a new process to an engineering team you should plan some systemic evangelisation to make it stick. This will take multiple sessions! We wouldn’t have successful products without marketing them and we won’t have successful change without evangelising it.

  • Use Lunch & Learns to show how, use Show and Tells to highlight successes
  • Embed yourself in a team to help integrate your new thing
  • Hackathons to encourage platform usage

Solution introspection

The best code is no code at all. Run through this list for any large piece of work as a quick sense-check that you’re not making a big mistake in your engineering proposal before writing any code.

  • The existing solution is too bad. We have to rewrite it from scratch.
  • This software is too unmanageable. Adding operational complexity will help.
  • This problem has never been seen before. We have to use the bleeding edge to solve it.
  • Adding network hops to the system will make it faster somehow.
  • Running systems and open source projects are the same and should be built the same way.
  • I can add value to this command line tool by writing my own wrapper for it.
  • The programming tasks represent the majority of the effort.
  • Functional tests!!
  • We can just deploy the code with our version control tool.
  • I want logical decoupling, therefore I must have physical separation.
  • Bureaucracy solves everything.
  • Bureaucracy solves nothing.
  • These two teams use the same noun, so they should use the same code.

(This list isn’t mine - I think it came from an article somewhere. I didn’t note who created it so let me know if you know who it should be attributed to!)

Start from the impact

Impact mapping is used to collaboratively set business goals. You can start from the behavioural change that you want to see (the WHY) and work backwards to find the steps you have to take to get there.

Impact mapping was developed for UX mock-ups but it works just as well for engineering impacts. Impact mapping works nicely with one of my favourite planning techniques - what, how, who, why, when.

In this case you start with WHY and use that to fill in all the other pieces in a structured way - WHY do we need it? -> WHO will be needed -> HOW you could impact the WHY => WHAT steps you need to take.

"impact map"
"impact map"

Map solutions to enterprise integration patterns

This is closer to coding than the other topics in this article but still important. Once you have a high-level rough solution in mind you should try mapping it to enterprise integration patterns by Gregor Hohpe and Bobby Woolf.

Just like in software patterns, the enterprise patterns provide us a language to discuss common approaches and solutions. By normalising the language we can increase the speed that our proposals can be understood.

The enterprise integration patterns are described here:


Most of the engineering work you do is not coding. You’re gathering information, synthesising it, thinking about it, packaging it, proposing solutions.

Consistency via systems helps ensure your repeated success and prevents regressions in outcomes. Start creating your own list today!

Let me know if there are any systems you use that I haven’t listed here! I’m always keen to learn new skills!

Darragh ORiordan

Hi! I'm Darragh ORiordan.

I live and work in Sydney, Australia enjoying the mountains and the ocean.

I build and support happy teams that create high quality software for the web.

Contact me on Twitter!

Read more articles like this one...

List of article summaries


How engineers can help deliver software effectively

Delivery managers and team leads have the responsibility to deliver a software system via an engineering team.

Your customer wants every feature to work perfectly and they want it delivered yesterday. Your team wants to learn and grow.

It’s a tough role managing all the stakeholders and creators in a project.

Engineers can help drive great delivery by empathising with and supporting the delivery manager or leads in a project team.


How software engineers can avoid commoditisation

Engineers spend most of their learning time on technical implementation content. Things like new frameworks, languages or cloud platforms.

But turning solutions into code is a tiny part of what you do and it’s getting less valuable year by year.

As we’ve seen with “no-code” and tools like GitHub Copilot, the implementation part of our role is increasingly becoming commoditised.

You could generalise that the value an engineer brings to a team is their ability to analyse problems and synthesise context. The part of your role as an engineer that will never be replaced by “no-code” or AI is this high level cognition.

The true human aspect of being an engineer is working in a team and considering other people’s ideas, emotions and thoughts while solving these problems.

So shouldn’t you train these meta-cognition skills as much as you train the specific technologies?

Every engineer should spend time learning and applying general tools for thinking. These tools are applicable to almost all problems so the compounded payback on your invested time is huge.

Clearer thinking will amplify all the other skills you have and any frameworks or tools you learn will give you results for the rest of your career.

Like any skill, improving the way you think takes deliberate study and practice.

These are some of the tools and systems for thinking that I refer back to all the time.


20 questions for a valuable code review

I recently had an interesting discussion around the value of doing code reviews and the value of mandatory code reviews.

I think code reviews are extremely valuable and should be done by most organisations and teams.

A valuable code review will

  • pass institutional knowledge around the org
  • help all engineers grow their skills
  • maintain quality in the face of all the other time pressures your team faces

But how do you keep a code review valuable?