Graphcore’s growing engineering presence in Gdańsk reflects a deliberate investment in building world-class AI systems in one of Europe’s most competitive technical ecosystems. As a wholly owned subsidiary of SoftBank, Graphcore is scaling its end-to-end system capabilities to help shape the next generation of Artificial Intelligence.
For Jakub, Distinguished Engineer in Gdańsk, his career has been shaped by moving repeatedly into unfamiliar territory – from large-scale Linux environments into R&D, then from infrastructure into low-level hardware telemetry – each time starting again from the basics and widening the way he thinks about systems.
Starting with how computers actually work
My first interests were physics, astronomy, and mathematics. I spent a lot of time in school reading about those subjects.
I chose computer science mostly for practical reasons. There were simply more opportunities in software than in physics or astronomy. But what kept me interested was something deeper – the chance to understand how computers work.
Early in my studies I became fascinated with x86 assembly because it removed the abstraction layers. You could see the real mechanics of the machine. That curiosity stayed with me throughout my career. I’m always most interested in problems where the abstraction disappears and you can see what the system is really doing.
The first transition: leaving traditional IT behind
I started my career at Intel as an IT Linux administrator, managing a large-scale Linux environment. It was stable, predictable work, and after several years I was very comfortable in that space.
Then I moved into Intel’s R&D organisation to support engineering teams. That was my first major transition.
Suddenly many of the traditional IT practices I had relied on no longer applied. R&D environments move faster, change constantly, and require a much closer connection to the engineering itself. I had to unlearn many habits and start again from the basics.
In a way it felt like learning the profession for a second time. It also exposed me to the kind of engineering problems I enjoy most – large systems, complex interactions, and the need to understand what is really happening under the surface.
The second transition: from infrastructure to hardware
My next transition came several years later, still inside Intel’s R&D organisation. At that point I was managing large-scale compute clusters in a DevOps capacity. I was very comfortable operating those environments, and I had deep expertise in how to scale infrastructure.
I was told something important by leadership: being extremely strong in one area was not enough to reach the next level of engineering. Their advice was direct – if I wanted to grow further, I needed to understand the hardware itself.
I started learning about low-level CPU behaviour: how processors expose telemetry, how to read hardware registers, and how to collect signals directly from the system without relying on higher-level tools. It was another moment of starting from scratch.
I knew nothing about that area when I began. But over time I realised something important: combining those two perspectives – large-scale infrastructure and low-level hardware behaviour – creates a much more complete understanding of systems. That combination ended up shaping the rest of my career.
Building systems people rely on
During that period I worked on a telemetry collector that could communicate directly with CPUs and retrieve low-level registers during normal system operation. That allowed us to observe what was happening inside servers without installing additional software on them. We could collect signals about processor behaviour and memory health directly from the hardware.
It turned out to be extremely useful. Many teams across the organisation started using the system, and eventually the telemetry data was valuable enough that it was shared externally with partners analysing hardware behaviour.
The part I enjoyed most was not the recognition, it was seeing people use something I had built because it genuinely helped them do their work.
Throughout my career, most of my influence has worked that way. Not through presentations or formal authority, but through technology itself – building systems that simplify work and make other engineers faster. If people start using a tool because it solves their problem, that’s usually the strongest signal that the engineering is working.
What the title “Distinguished Engineer” really means
Becoming a Distinguished Engineer did not change how I work, in many ways, it is simply a recognition of the work you have already been doing. My approach remains the same: stay close to the engineering and continue building things directly.
I learn best through hands-on work. I need to interact with systems, break them, observe how they behave, and fix them again. That process teaches me much more than theory alone.
Even explaining the title can be difficult. In Polish there isn’t really a natural translation for ‘Distinguished Engineer.’ The literal translations are quite funny.
So when family members ask what I do, I usually just say that I’m an engineer. That’s accurate enough.
Advice for engineers aiming for this level
If there is one lesson from my career, it’s that deep expertise in one area is rarely sufficient on its own. The most interesting engineering often happens when two different areas intersect.
For me that intersection was infrastructure and hardware telemetry. For someone else it might be distributed systems and networking, or operating systems and machine learning. The pattern is the same: when you combine knowledge from different layers of the stack, you begin to see problems, and solutions, that others might miss.
Another important point is that engineering leadership does not always look the same. Some engineers influence organisations through presentations, communication, or visibility. That’s valuable. There is also space for engineers who are quieter and focused primarily on the technical work itself. Sometimes your work can speak louder than you do.
Continuing to learn
Even after more than twenty years in engineering, I still feel like I’m learning new things constantly. Right now, one of the most interesting areas is how AI is changing engineering work itself. The pace of change is unlike anything I’ve seen before.
At the same time, the fundamentals remain the same. Understanding how systems behave, questioning assumptions, and reducing complex problems into observable components. That process – discovering how things actually work – is still what makes engineering interesting to me. It’s also a huge part of what makes the problems at Graphcore worth working on.
Graphcore is continuing to grow its engineering teams in Gdańsk. If you’re drawn to systems problems that sit across software infrastructure and hardware behaviour – and you enjoy understanding how things work – take a look at our current opportunities.
