Knowledge Transfer in Software Development Discovery
Fryderyk Pryjma8 April 2026
Knowledge transfer in software development hits me the hardest right at the beginning of a project – in that moment when a lead lands on my desk and I try to make sense of a few sentences, a PDF, or a half-remembered conversation from a conference corridor. Before any line of code exists, before any official "project" begins, there is already an intensive learning process going on between the client and the IT organization.
In our case this is usually custom, tailor-made software. We are not heavily productized as a service organization. That means each time I go through this, the discovery flow, the design operations, and the project management approach have to be aligned to a specific context, not to some idealized "standard project". We build primarily on top of our learning experiences.
Alongside running Effect-Driven Design – my UX studio – and WCAGLab, the accessibility implementation brand, and leading discovery in a software development company, I am also working on a PhD at WSB University on knowledge transfer in software product creation, especially the learning process linked to AI.
Knowledge transfer as the backbone before any code is written
When I look at our software development process through this lens, one thing is obvious: until the source code is actually written, we mostly operate in the space of interpretations. What the client says, what they send over as documentation, what I hear, what I filter, how I retell the story inside the company – all of that is still knowledge transfer, not implementation.
It is a multi-layered exchange. On the client side, someone interprets business needs or board-level strategy and compresses it into a request. On our side, I interpret this request and pass it further to technical leads, designers, project managers. Every step is a potential distortion, but also an opportunity for learning if we are conscious about it.
Thinking about software development as knowledge transfer first, and only then as coding, gives me a surprisingly powerful diagnostic tool. Instead of asking only "where did the plan fail?", I can ask "at which handover did knowledge actually get lost or misaligned?".
From lead to first briefing: how discovery really starts
In practice, in our IT service company, everything begins with a lead. The path a lead takes is already part of the story. Sometimes I meet someone at a conference; we talk for twenty minutes, they sketch their pains and ambitions, and a few days later I get a follow-up email. Sometimes a structured enquiry lands in our inbox with an attachment, short scope description, maybe a non-disclosure agreement. Sometimes it is something far more formal like public procurement documents.
That lead usually reaches people in business development or partners group first and then is forwarded to me or someone else responsible for discovery. Already here we have multiple layers of knowledge transfer: from the first contact on the client side, through whoever forwards it internally, to me, and then further.
Tailor-made software and why one fixed process does not work
Because we work with custom software development rather than rigid packages, I cannot simply push every project through one fixed discovery funnel. Our method is deliberately more open, less constrained. There is a cost to that, but the benefit is that we can match knowledge transfer and discovery depth to the real risk and complexity of the project.
Every time I start that initial analysis, I begin with whatever the client has already provided. Often I need two or three conversations before I feel comfortable even thinking about an offer.
Explicit and tacit knowledge in the first discovery conversations
On the surface we talk about scope: what features, what modules, what kind of users, what systems they already have. That belongs to explicit knowledge – something that can be written down, described, documented.
But very quickly I start hunting for tacit knowledge – things that are not written down, but completely change how we should approach the project. I ask a lot of "why" and "tell me about the last time…" type questions. Those stories, analogies and episodes are what I often rely on to understand the real shape of the system.
Tacit knowledge also appears in the way people talk about priorities. When they repeat certain constraints or concerns, when they hesitate at specific topics, that tells me where the real organizational pain points are.
Translating client reality into internal organizational learning
Once I feel I have enough of a picture, I move into internal translation mode. This is where knowledge transfer shifts direction: from "client to me" to "me to my organization".
I collect my notes from calls, reread emails, revisit any documents they shared, and sometimes re-listen to audio from meetings. In parallel I sketch rough structures: flows between systems, possible user journeys, list of main actors and their goals.
Then I sit down with the architect or tech lead and describe the whole thing. I do it verbally, in my own words, but I support myself with sketches, sometimes quick diagrams, sometimes even very rough user stories.
At this point I am already consciously compressing and filtering knowledge. The architect does not need every anecdote; they need clarity on the main goal of the system, the approximate functional scope, the amount and nature of integrations, any non-functional requirements, and the constraints around budget or time.
There is also an important detail here: very often the person I speak to on the client side is not the final decision maker. So by the time the information reaches me, it is sometimes already second-hand. When I then pass it to our technical team, it becomes third-hand. Being aware of this chain helps a lot in correcting misalignments early.
Estimation as a mirror of our knowledge transfer quality
Based on this internal briefing, the architect or tech lead starts building an estimate. This is where software development, project management and knowledge transfer collide in a pretty unforgiving way. Estimation in IT is difficult even with perfect inputs. When the knowledge transfer is shallow, it becomes essentially educated guesswork.
For me, this estimation step is a kind of mirror. If we struggle heavily, if everything is vague, if the risk buffer needs to be absurdly high, it usually indicates that somewhere earlier the knowledge transfer in discovery was not deep enough.
When we do not know enough: discovery workshops as structured knowledge transfer
There are many cases where I simply have to say: we do not yet know enough to price this responsibly. In those scenarios I treat the discovery phase itself as the main "product". We suggest a separate, typically fixed-price discovery engagement with workshops and analysis.
During these sessions we rely heavily on visual and collaborative methods. We sketch flows, draft simple mockups, map functional and non-functional requirements, and check our understanding of priorities. The goal is to deepen knowledge transfer, surface tacit understanding, and move as much as possible into explicit, shareable artefacts.
Internally, this is also design operations in action. Discovery is not separate from operations; it is the first iteration of those operations.
The offer as the first shared knowledge artefact
Once discovery gets us to a certain level of clarity, the direction of knowledge transfer flips again. Up to this point the main motion was client to us. Now it becomes us back to the client.
We prepare an offer that captures our understanding of what is to be built, describes the proposed software development process, explains the design operations we suggest, and outlines the project management structure and responsibilities.
I see this offer as more than a sales artefact. It is the first stable, sharable expression of a shared mental model between two organizations.
Why I keep coming back to this lens
In many of my posts I circle around design operations, research ops, tenders, RFPs and the day-to-day reality of product and software development management. Underneath all of this I see the same pattern: what really differentiates good IT organizations from the rest is how deliberately they treat knowledge transfer.
Discovery is not just a pre-sales formality. It is a core learning process. Design operations are not just "how designers work"; they are about how knowledge flows through user research, UX decisions and implementation constraints.
And this is why I wanted to unpack this specific phase here: not as a theoretical model, but as a real sequence I go through every week, where discovery, design operations, project management and knowledge transfer are not separate disciplines, but one intertwined learning process that starts long before the first commit appears in the repository.
Further reading
Read about basic concepts of knowledge transfer here
More about my space of research and beginning of PhD journey here