Before Jira, Kanban Was a Card on a Factory Floor
How I ended up in electronics manufacturing, what a year on a production line taught me, and why Agile felt strangely familiar when I finally met it
The first Kanban I knew was not a column in Jira. It was a physical card. Someone on the production line needed components, the card went to the warehouse, and the material arrived.
Years later, when I moved into software and somebody explained Kanban to me, I remember thinking: yes, I know this.
Although not exactly. A board in Jira shows you where work is sitting. The original card made material move. It was not a status display — it was a trigger.
That was the first of many moments when I realised my first engineering job had taught me far more about software development than I could possibly have known at the time.
How I ended up in a factory
During my master’s I wanted to be a hardware engineer. Radio, signal processing, integrated circuits — I had spent years going down through the layers and I wanted to work at the bottom of them.
Then my plan to study and move to the United Kingdom became unaffordable, I stayed in Latvia, and I ran into a simple problem: there was very little hardware engineering work to be had. Latvia had relatively few electronics manufacturing opportunities, and the roles that did exist were rarely open to someone without professional experience.
So I was lucky to land at Schneider Electric as an Electronics Product Quality Engineer.
The work was more interesting than I expected. We were moving electronics manufacturing lines from Finland to Latvia, and our job was not simply to relocate them and hope for the best. We had to make sure quality did not deteriorate in the transfer — and, ideally, that it improved.
It was also the only job I have had with a uniform. To go onto the manufacturing floor I wore an ESD jacket and ESD shoes, because static electricity and electronic assemblies do not mix. I have worked in a lot of offices since. None of them required me to be electrically grounded.
Schneider took Lean manufacturing, Lean Six Sigma, 5S, visual management, root-cause analysis and continuous improvement seriously. There were posters everywhere — Lean principles, 5S, quality, safety, visual work instructions.
But they were not only posters. People were trained in the methods and expected to use them. Processes were designed around them. Problems were discussed through them.
Quality was not something that belonged to one department at the end of the line. It was supposed to be built into how the line worked.
I did not realise then how permanently that would lodge in my head.
Learning to draw the work
One of the first things I was asked to do was draw the process. Not the factory building — the work itself.
How does a product move through manufacturing? Where does it wait, where does material stop, and which operation cannot keep up with the one before it? Where do defects get introduced, and where does rework happen?
Manufacturing makes these questions wonderfully difficult to ignore. If one operation is too slow, unfinished products physically accumulate in front of it. The bottleneck may literally be sitting there, taking up floor space.
Queues have mass. Delays occupy space. You can walk up to a problem and look at it.
I have spent every year since in environments where none of that is true, and I have been trying to recreate that visibility ever since.
Sometimes the product was fine. The test was wrong.
A large part of my job was technical failure analysis. Electronic assemblies would fail testing, and I had to find out why.
After enough investigations, patterns emerged. A surprising number of failures traced back to faulty transistors — the same component I had spent a semester in Lund learning to design on silicon, now arriving in front of me as a defect report with a batch number.
But the most interesting cases were not product failures at all.
Sometimes the problem was in the test equipment. A configuration was wrong. An acceptance parameter had been set incorrectly. A threshold was rejecting products that were perfectly good.
The system responsible for deciding whether the product was correct was itself incorrect.
Get Jekaterina Jegoscenko’s stories in your inbox
Join Medium for free to get updates from this writer.
That taught me something I have needed constantly since: before blaming the thing under test, make sure the test is trustworthy. A failing automated test does not automatically mean the application is broken. An alert does not automatically mean the system is unhealthy.
Testing is not outside the system. The test mechanism is another system, and it also needs engineering.
My first daily stand-up had another name
We ran short, structured meetings around the production process, as part of something called Short Interval Management.
A line leader collected issues from the workshop operators and brought them forward. We stood around a visual board showing the day’s performance, the current problems, the actions and who owned them. What happened, what is blocking us, who is doing something about it, by when. Fifteen to thirty minutes, and everybody went back to work.
Years later, when someone carefully explained the daily stand-up to me, the format felt oddly familiar. Short Interval Management is not Scrum, and a production line is not a software team. But the instinct underneath both was the same: shorten the feedback loop, make the current state visible, surface problems early.
Two things about how it worked have stayed with me far longer than the meeting format.
The first is that managers were expected to go and look. Supervisors walked the lines every couple of hours. The plant manager walked the floor two or three times a day, reviewed the boards and initialled them. Functional managers — quality, materials, finance, HR — were expected on the production floor daily.
That was a second communication channel, running in parallel to the meetings. Most software organisations have only the meeting channel. We consume reported status, dashboards and summaries, and rarely go and look at the actual work.
The second is the escalation policy, which had three legitimate reasons to raise a barrier: I do not have the skills to resolve this, I do not have the resources, or I do not have the time.
And one principle attached to it that I have quoted more often than anything else I learned there:
Escalation cannot be viewed as failure. The alternative is hiding or blaming.
That sentence explains an enormous amount of what goes wrong in engineering teams. People do not hide blockers because they are dishonest. They hide them because raising one feels like admitting they were not good enough, and the culture around them has never explicitly said otherwise.
If escalation is not safe, the work goes underground — and everything else you build on top of visibility stops working.
Why I left
I enjoyed that job. It was technical, dynamic, full of real problems, and I was good at it.
I left for a reason people usually leave out of career stories: money.
Manufacturing salaries in Latvia were noticeably lower than IT salaries, and around 2012 the Latvian IT industry was growing fast. International companies were opening development centres, and they were hiring — good conditions, good benefits, decent offices, and considerably more opportunity than the manufacturing sector could offer. I was not planning to leave Latvia at that point, so I had to find my future inside it.
I already had strong programming fundamentals from school and university. The move made sense.
Then I kept seeing one mysterious word
While planning that move, I read a great many job advertisements, and one word kept appearing.
Agile.
Adoption was still relatively new in the Latvian software companies I was looking at, and I had no idea what the word meant. So I put it on my list of things to learn, and eventually attended a conference on Agile software development.
I went expecting an entirely new philosophy. Instead, I spent the day recognising things.
Visualise the work. Make problems visible. Shorten feedback loops. Deliver in smaller increments. Find the bottleneck. Improve continuously. Do not wait until the end to discover the result is wrong. Build quality into the process.
The vocabulary was new. The environment was new. The thinking was not.
I had already seen most of it on a factory floor.
What I actually took with me
I spent barely more than a year in manufacturing. It has informed every engineering role I have had since.
Not because of any single method. Because of a way of looking at systems: when something goes wrong, do not stop at who made the mistake? Ask what in the system allowed the mistake to happen, where the control should have been, and whether anyone could even have seen the problem coming.
Those questions have turned out to be remarkably portable. They work on production lines, on software teams, and — as I have been discovering lately — on systems of AI agents, which have a way of failing that a quality engineer from 1985 would recognise immediately.
That is the next article.
Before software taught me Agile, manufacturing taught me to see the system.
This is the fourth part of a series about how my relationship with engineering evolved — from cassette-loaded games to AI agents.
