A lot of automation advice is accidentally exclusionary. It assumes people can install what they want, connect whatever they like, and redesign their workflow without needing to account for policy, approvals, legacy systems, or organisational norms. Many engineers do not have that luxury. They work on managed devices, inside defined ecosystems, with obligations that make “just use this new tool” an unrealistic suggestion.
This is why I think engineers need a more grounded framing of automation.
Automation in a corporate context is not primarily about technical freedom. It is about creating leverage inside boundaries.
That distinction matters because it changes what “good” looks like. In a freeform personal lab, good automation might be the most elegant architecture or the smartest integration. In a real enterprise environment, good automation is often the process that quietly removes friction while staying understandable, supportable, and acceptable to other people.
In practice, that usually means three things.
A practical introduction — with real implementation examples at FailureData.com
First, the workflow should start with the tools that are already embedded in the organisation. In many cases, that means Microsoft 365. Word, Excel, Teams, SharePoint, Power BI, Outlook, and now Copilot are not glamorous choices, but they are often the most important ones. Not because they are perfect, but because they are where the work already happens.
Second, automation should focus on the repetitive edge of knowledge work rather than the entire job. Engineers are not just moving information. They are interpreting context, assessing implications, and making trade-offs. The aim of automation should be to reduce the time spent collecting, cleaning, formatting, comparing, and drafting — not to pretend the human element is unnecessary.
Third, a useful workflow should be survivable. That means someone else should be able to understand it. The process should not collapse if one script breaks or one technically minded person leaves the team. Survivability is underrated. But in most workplaces, a modest automation process that the team can maintain is more valuable than an advanced one that only one person understands.
This is where VS Code and Python become interesting. Even in constrained environments, small Python workflows can often create disproportionate value when used carefully. They are excellent for repetitive file handling, data cleaning, tabular transformation, and output preparation. When combined with Excel, Power BI, and Copilot, they become part of a broader productivity stack rather than a standalone technical hobby.
The real mindset shift is to stop thinking about automation as a giant leap. Most meaningful engineering automation is incremental. You do not need to automate everything. You need to identify the recurring points of friction that repeatedly consume time and attention. Then you remove those one by one, in a way that the surrounding environment can actually absorb.
That might mean:
standardising report inputs,
creating a reusable classification script,
building a comparison notebook,
preparing a summary template for Copilot,
or generating review tables automatically before a meeting.
These are not dramatic transformations. But over time, they create a different way of working.
And that, in many organisations, is what real progress looks like:
not a revolutionary system,
but a steadily improving set of practical workflows that respect both engineering reality and corporate constraint.
Until next time :)