It is becoming dangerous not to engage AI in everything.

The more AI is engaged, and the more diverse this engagement, and the more spread within all departments of the organization, the higher the competitive edge of the organization. On the flip side, the less the spread of AI in the organization, then the bigger the threat to the survival of the organization.

Who should lead this spread of AI? In the beginning, it is the AI enthusiasts and the AI champions that lead this tranformation. But at some point, it must be the Department Managers that will take on the responsibility of the full AI engagement within their departments.

On the S-curves this process looks like this:

And lastly, a Telegram channel has been created under the name – “AI Community – Engineering City”. I recommed all to join the EC AI community there.

In the previous article, we said that “AI Must be Everywhere”.

Now, we want to add “Workflow Automation Must be Everywhere”.

And the directive for survival becomes:

“AI + Workflow Automation Everywhere”,

or,

“AI + WFA Everywhere”,

where, WFA stands for Workflow Automation

On the organization level it would look like this:

The purpose of any automation is to create free time for organizations. Organizations need free time so it can spend it on research and development of new products. The more the free time that the organization can create, the more it can spend on research and development of new products. As such, everything other than research and development must be automated.

The formula that organizations strive to achieve is this:

TR&D →  TWorkflow → 0 

Here, TR&D is the time that organizations can afford to spend on research and development, and Tworkflow is the time that organizations must spend on everything else.

Workflow automation software is a software that frees organizations from spending time on workflow processes, meaning that it drives it to zero: TWorkflow → 0.

Workflow automation by itself is not new. It has been there for a long time. But recently two things have happened – the software has become very simple to use (everyone now can create an automation program), and the availability of AI for everyone.

There are two software packages that have been recommended for workflow automation. Both can incorporate AI into the automation process:

1. n8n (n8n.io)

2. Make.com (make.com)

Both are simple to use, however, n8n is a more sophisticated package that can automate more complex workflows. Its advance usage needs the knowledge of some programming concepts. I would recommend this for those who have programming skills. Make.com is even easier to use than n8n, yet it does not allow for more complex workflows. It does not require any programming, so, I would recomment this one for all non-programmers. It is also easier to start with.

In solution companies (companies that create customized solutions for customers), the engineers have a constant direct communication line with the end-user. The skills of speaking to customers, the skills of negotiating the technical requirements with the customers, the skills of presenting & defending technical proposals to customers, the skills of changing the technical requirements during development, the skills of factory acceptance tests to the customers (FAT), and site acceptance test at customers’ site (SAT) are the normal skills that engineers in solution companies naturally develop.

This makes it very natural to see engineers turn into Business Development Managers (BDMs) with time. This is because BDMs in solution companies are some of the most technical savvy and the most market savvy people in the company.

Hence, it is only natural to see engineers turning into BDMs in solution companies, and this must be encouraged.

You may also want to read the article “Products Sale vs. Solution Sale vs. Service Sale” (EC Journal 19/2023).

The CTO (Chief Technology Officer) is the person responsible of three main things:

1. Defining the main technologies that a company uses.

2. Always scouting for new technologies.

3. Introducing new technologies to the company.

Technologies could be categorized into different pockets, for example:

1. Technologies used within the products of the company. For example, the CTO could have defined NI technologies to be the main technology used in the company products – PXI platform, cRIO platform, …

2. Professional Technologies used in developing company products. For example, LabVIEW, Altium Designer, and SolidWorks.

3. Technologies produced by the company.

4. Productivity Technologies. These are the office and process tools, like, for example, MS Office, Google Services, workflow automation technologies, computer brands, …

Since technologies, in big part, define the performance of company products and the productivity of the company, this means that the CTO is the responsible person for both performance and productivity.

The third responsibility (the introduction of new technologies into the company) is the hardest to do. This is because here, the CTO will encounter an enormous resistance from all employees. Why? Because the employees have learned the old technolgies and are using them in their daily work. In its extreme, the introduction of a new technology could mean to wipe out completely the old technology and having to learn the new technology. But not only that, new technologies also introduce new processes.

The resistance can be enormous. But on the flip side, if the CTO fails to carry out these transitions, then the company loses its competitive edge over the competitors and ultimately die, taking down with it all the employees who resisted the move to the new technology.

The below picture captures this image perfectly.

It is only much later, when all the resistance has been overcome, and the staff has been well trained on the new technology that we get the following picture:

On the S-curves, this process looks like this:

The introduction of AI and the Automated Workflow technologies into the company is of this genre.

The question – “Do you have a student?” could be re-phrased to – “Do you live in the Future?”

When we only focus on the current project, we live in the present:

When we start thinking about the next planned project, we start thinking a bit forward and start thinking on the re-distribution of current resources for the next project.

When we start thinking about future projects, we start thinking about the future state. Here, we need to already engage university students since most likely new technologies will be used in the future projects – technologies that university students will have either already acquired, or can easily acquire:

When we start thinking about futuristic projects, then we start thinking beyond the foreseeable future. Here we need to already engage high-school children, because it is them that can already feel the future that we cannot yet see:

The assumptions here are that:

1. The students can acquire new technology skills faster than the professionals,

2. The high school children see the future better than the adults.

In other words, if we want to already live in the future, then we must have a university student working with us and have a high school child next to us.

The point is NOT to teach them, but to engage them. It is us who should be asking them, not them asking us. We should do this to our benefit, we should do this to gain a competitive edge in the markets of the future. The point is to see the future through them.

Do you agree with this article?

The student projects in the EC must be qualitiatively different than the student projects given in the universities. This is because the EC enables things that the universities can’t have in principle. And that is that the students study and live in the EC among professional engineering companies. The student projects are given by companies and led by professional engineers. This opens up possibilities that are unique to the EC, and we must take full advantage of it. The student that studies in the EC matures much faster, gets engaged in productive work much earlier, and is exposed to all the nuances of a professional engineering companies from the very start.

We believe that the following elements should be present in every project given in the EC – this includes the Bagrevand 21 projects, the internship projects, the courseworks, and the diploma projects. Even the high-school projects must have them. Here there are:

1. A wholistic problem statement

2. Technology research

3. AI

4. Team project

5. Multiple age groups

Below is a write-up on each of these elements:

1. The project must start with a wholistic problem statement. A wholistic problem statement is not just the technical requirements. It includes the context of the problem statement, why it appeared, what crisis or limitations it needs to resolve, the history of the problems statement (meaning what previous problem statements were solved before getting to the current problem statement, the trend in the evolution of the problem statements, possible next problem statement). The problem statement must be company specific. It must show how it fits the market strategy of the company, the competition, the business aspect, the economic aspect, …. In short, the

   problem statement and its resolution must be part of the company’s plan, and the work must benefit the company where the project is given and carried out. (Please also read the article - “The “-3 +1” Methodology in Generating the Problem Statement” (EC Journal 11/2025)).

2. The project must engage AI in one form or another. One of the places where AI can be engaged is in the solutioning phase. (Please also read the article – “Speculations on "Diploma Theses" in the age of AI” (EC Journal 9/2025)).

3. The project must reach the POC and Prototyping stages in every project. This must be possible because of the enormous time that will be saved from engaging AI in the project. Together taken (POC + Prototype), this is the technology research stage for which the ARC (Advanced Research Center) had been setup. This must benefit the companies where the student carries out his project. This fact alone must make it interesting for the companies to adopt students for their projects.

4. The student must work in a team with different disciplines (mechanical, electronics, embedded, control, software, manufacturing, …). In other words, the project must be bigger than the student part. The student must see that engineering projects are holistic projects where many engineering disciplines are involved. This will show the student that he is a members of a project team, where people rely on each other and depend of each other to reach the overall project goals. This by itself has a great educational value. This will develop the system view in students’ mind.

5. The project team must be multi-generational. Meaning that it must have different age groups in it, including high-school students. The ideal project will have professional engineers, university students, and high-school children working together – each contributing to the level that they can.

Most of these elements must be present in a project to be called an EC project. Otherwise, the project does not need to be done in the EC.

In short, a student project must be a microcosm of a professional, commercial project. The student must see all the dimensions and views of an engineering project. (Please also read the article - The Different Views of a Commercial Product. EC Journal 11/2025)).

Dear EC Community,

This is to announce our next EC Meet-Up Day, which will take place on August 8 (in one month).

The theme of this Meet-Up will be “AI in EC”.

Each company is requested to present on how they use or intent to use AI in their work.

Here are the themes of last years’ Meet-Ups:

2023. Company Introduction. Each company introduced itself to the community.

2024. ARC introduction. We split into discussion groups about possible Research project within each lab of the ARC.

2025. AI in EC. This year.

Thank you, Engineering Association