Petr Konečný is a fictional character. His story is an illustrative mentoring scenario, not the experience of a real client or a documented mentoring outcome. The work situations, conversations, and decisions described are part of this fictional example.
When Petr thought he knew where he was going
Petr felt pretty good about his development roadmap. Not because he had managed to tick off every task or because his role at work had changed dramatically over the past few weeks. He was still a senior developer, still dealing with everyday project work, and still occasionally annoyed by how many technical problems arose from decisions he couldn't directly influence. But he now had a much more concrete idea of what he actually wanted to develop and why.
In his first sessions with Igor, he had tried to put together a working model of a software architect. Back then, he thought architecture mainly meant having more influence over the technical direction of a system. Gradually, though, he realized that the role could involve much more work with people, compromises, decisions under uncertainty, and responsibility for consequences that can't be measured by code quality alone. His original idea eventually became a fairly concrete model of twenty-five competencies and responsibilities. It wasn't a universal definition of an architect, but it gave Petr a useful working basis for thinking about his next steps.
He then started comparing that model with what he actually did and could do. He identified several important gaps, prioritized them, and gradually turned them into specific tasks. He even managed to get room for two attempts at real technical decisions. In the first, he overlooked important client and deadline context. In the second, he asked for the missing information before finishing his recommendation.
His manager described the second write-up as usable. But he added another question: how would the team know when it should revisit the technical solution it had chosen? Petr didn't yet have the evidence needed to define a specific threshold at which reconsidering the decision would make sense. He didn't want to invent one, so he left it as an open question.
That felt pleasantly different from how he used to think. Before, he tended to see a comment like that as a flaw in his technical proposal that he needed to fix as quickly as possible. Now he could accept that a reasonable recommendation might also contain a precisely identified uncertainty. This didn't mean he had become a fully fledged architect or that anyone had objectively measured an improvement in his abilities. But it was possible to compare how he had prepared the first and second write-ups and what he had done differently.
On his roadmap, explaining the business value and impact of technical solutions remained his current focus. He had a specific reason for that, along with several more things he wanted to try in his work. The other development areas were still on hold for later.
And just as he felt his plan was finally making sense, he received information that had nothing to do with any of his next tasks.
An architect who doesn't know the customer's system
Some time later, during a regular 1:1, Petr's manager returns to his long-term direction.
"I've talked about it with leadership, too," he begins. "We don't actually have a separate software architect role here in quite the form you originally tried to describe. But we think it might make sense to consider whether we could gradually define that kind of responsibility around what the company really needs."
Petr pays attention. They've discussed greater technical responsibility several times already, but so far the conversation has mainly been about what he can work on in his current role. This sounds a little different.
"So we might create an architect position here?" he asks.
"Possibly. But I wouldn't call it that yet. We haven't decided whether it would become a separate role, what authority it would have, or who might fill it. We were mainly talking about where we're missing that kind of technical responsibility today, or where it could help us."
Petr nods, a little disappointed. For a moment, he had already imagined that his career plan had taken a substantial step forward. But his manager isn't offering him a promotion. He's only bringing new information about how the company is thinking about technical responsibilities.
One of the topics that came up in the leadership discussion was working with larger customers. Some have their own technical teams, their own systems, and fairly complex environments into which Petr's company's products need to fit. Today, these situations are handled by whoever happens to have the necessary information and whoever is closest to the customer or project. Sometimes that's someone from development, sometimes someone from product, or a manager. But if the company wanted to oversee this kind of collaboration more systematically from a technical perspective, it might make sense to have someone who could act as one of the customer's technical partners.
"But that would mean knowing their systems, too," Petr objects. "And often that just won't be possible. Sometimes we don't even have proper information about every part of our own product, let alone what a customer is running on their side."
"Exactly," his manager replies. "You can't expect them to hand you their entire source code and give you several weeks to study it. You're more likely to get some documentation, a description of the environment, and limited time with the people who understand its individual parts. Then you'll need to decide together how your systems should work with each other, where the boundaries of responsibility lie, and which constraints you have to respect."
Petr imagines a situation like that. He has an integration decision in front of him, but he doesn't know exactly how the other side is implemented. He doesn't know how the customer's systems divide responsibilities, where they store important data, or how they deal with certain operational problems. He can't simply open their repository, go through the services one by one, and build up his understanding the way he does inside his own company.
"And what if I can't tell whether it'll work without those details?"
"Then you'll have to figure out which details you really need. You'll ask their people for some of them. Others may not be relevant. And if you're missing something essential, you simply won't be able to reach a reliable conclusion. But we can't base every joint decision on one person studying their entire system down to the last detail."
Petr thinks about it. In his own company, he has one enormous advantage that he barely notices anymore. He's been there for almost five years. He knows the products' history, remembers some older decisions, knows who to ask, and can often guess where a problem is likely to be before he even takes a proper look. When he needs to verify something, he can usually open the code or ask a colleague.
In a customer's environment, many of those reference points would be missing. And yet his company might want him to help prepare a technical decision with consequences for both sides.
"I still thought of architecture mainly as responsibility for our own systems," he finally admits. "Understanding them as a whole, designing larger changes, keeping an eye on the long-term direction. This is a slightly different kind of work."
"It's not a completely different discipline," his manager replies. "But it is a different context. And if we ever define architectural responsibility here, we should start with what we actually need. Not just a general idea of what a software architect is supposed to look like."
As Petr leaves the meeting, he isn't thinking about whether he should learn yet another technology. He's thinking about something more uncomfortable. For weeks, he's been carefully putting together a plan to get closer to his target role. But the actual shape of that role at his company might be more specific, and different in some respects, than he originally imagined.
And if the target is different, simply continuing down the existing list might not be enough.
Twenty-five items that might not need to be thrown away
At their next session, Petr tells Igor what he's learned. This time, he doesn't bring a new technical problem or a write-up he wants to go through together. He opens the original working model of an architect, with his current roadmap beside it.
"So now I'm not even sure whether we've been working toward the wrong target all along," he says. "When we put together that list of competencies, I was mainly picturing an architect for our products. Now it looks as though the company might need someone who can quickly find their bearings in customers' systems."
"What's actually wrong with the original model?" Igor asks.
Petr starts going through the list. Systems thinking, solution design, technical trade-offs, working with uncertainty, communicating with different people, facilitating discussions, taking business context into account. None of these things has suddenly stopped making sense. In fact, most of these abilities would also be useful when working with a customer's technical team.
"Probably nothing's wrong with it," he admits. "We've just described some things too generally."
"For example?"
Petr stops at systems thinking. When they first assessed this area, it turned out that he could already understand broader connections fairly well in an environment he knew. His difficulty was more with unfamiliar parts of a system. That was when he realized that seeing a system as a whole isn't the same as having deep expertise in every technology it uses. After their discussion, they therefore refined his original estimate of 2/5 to approximately 3/5, against a working target of 4/5.
Now, though, he's looking at a situation that makes the distinction much more concrete. It isn't just a question of whether he understands a component he doesn't normally use. He might need to work with an entire relevant part of an unfamiliar environment, without access to the code, without knowing the history behind its decisions, and without even being able to rely on finding all the necessary information himself.
"So I should learn how to understand an unfamiliar system quickly," Petr suggests.
"That still sounds pretty broad. What does understanding it mean?"
"Well, knowing what it's made of, what technologies it uses, what services, databases, integrations they have..."
"And why do you want to know all that?"
"So I can design a solution with them."
"What kind of solution?"
Petr stops short. In his head, a list of things he'd need to study for every new customer has already started taking shape. But Igor's question brings him back to something they've dealt with before: not every piece of information about a system has the same value for every decision.
"All right," he starts again. "Say we needed to decide how to transfer data between our product and their system. I'd need to know which parts communicate, who's responsible for what, what the constraints are, and what should happen if something fails."
"And would you need to know the implementation of every one of their services for that?"
"Probably not. But sometimes a particular implementation detail could matter."
"Sure. Then you need to find out that particular detail. Or get it from someone who knows it. I'd just start by asking which decision you need it for."
Petr returns to his original wording. He used to associate systems thinking mainly with the ability to see important connections and the impact of changes across a solution. That still matters. But in the target role he's now considering, there's an additional requirement: building that understanding quickly, from limited information, and only to the depth that a specific decision actually requires.
"So I basically need to figure out everything I don't know?" Petr asks.
"That would be a fairly endless task," Igor replies. "It's more about recognizing what you need to know for the decision at hand. What's already confirmed, what you're only assuming, what you need to ask, and which details don't have a significant effect right now."
Petr starts picturing how he would prepare for a conversation with a customer's technical team. Instead of trying to put together complete technical documentation of their environment, he'd first define the decision they were working on together. Then the main systems and boundaries between them, important connections, known technical or operational constraints, and the places where his model relied on assumptions. Only then would he prepare his questions. Some would need to be asked straight away, because he couldn't reasonably proceed without answers. Others might not need to be addressed at all.
That doesn't mean deeper technical understanding is useless. If a particular decision depends on the behavior of a database, an integration interface, or some part of the infrastructure, he has to get to the necessary detail. The difference is that he doesn't try to gather every detail in advance. The depth of understanding follows from the decision, not from how much documentation or code is still available to him.
"That's exactly what I'd like to be able to do," Petr says after a moment. "Look at an environment I don't know at all and not immediately feel that I have to study its entire stack."
"Then you already have a more concrete description of the ability than you did a moment ago. I just wouldn't assume yet that you can't do it at all. You're already using some parts of it. You need to find out what you can transfer into an unfamiliar environment and where you start losing your footing."
So Petr doesn't rewrite the entire architect model. He returns to one part of it and makes it more precise in light of the new information from his company. His original, more general view of systems thinking becomes a more specific requirement:
Within a limited time, build a sufficient working model of the relevant part of an unfamiliar or external technical environment, identify important boundaries, relationships, constraints, assumptions, and unknowns, and investigate only the level of detail needed for a specific architectural decision.
Petr reads the wording once more. It's longer than the original item. But he can now much more easily imagine a situation where he could use it, and the questions that would reveal where his gaps are.
When you're preparing for a role with greater technical responsibility, it's easy to conclude that you need to know more technologies and more systems. Sometimes that's true. But try to distinguish between two things: expanding your technical knowledge and being able to make a technical decision in an environment you'll never know completely.
In the second case, the goal isn't to eliminate every unknown. You need to identify which ones could change the decision, which information you can verify, and where you need to involve someone with deeper knowledge. It's just as important to recognize when you have enough to go on and when you'd merely be replacing missing certainty with your own assumptions. That's work that can matter to an architect even when most implementation details are completely out of sight.
A priority that changed without a single new task at work
Petr wants to move the newly refined systems-thinking ability straight into his current priorities. For the first time, he can see a concrete situation where it might be useful. But when he opens his roadmap, he notices that the area is already there. It's just in the LATER section, with a working Priority of approximately 0.33.
That made sense when they first assessed it. Petr already used a systems perspective in certain situations, so his estimate was roughly 3/5 against the working target of 4/5. He gave the area a Value of 1, since it meant extending an ability he was already using. Effort remained 3, because developing such a broad competency wouldn't be an afternoon's work. And Urgency was 0. There was no specific employer requirement or deadline telling him why he should work on this ability before the others.
Now he sees that zero differently.
"So should I increase its Value?" he asks Igor.
"Why Value specifically?"
"Well, suddenly it looks as though this might be much more important for the role than we thought."
"Has the ability itself changed? Or has a more concrete reason emerged for why you might need it in the environment where you work?"
Petr thinks back to how they built the original priorities. Value reflected the significance of developing an area relative to his current level and target. Effort roughly indicated how much capacity it would require. Urgency captured a specific external reason to work on something right now, such as a deadline or an employer's need.
The new information from his manager doesn't mean Petr gained new abilities during a single conversation. It doesn't prove that his original estimate needs to change immediately, either. And the company hasn't confirmed a new position or any specific task Petr is supposed to take on.
Even so, systems thinking in an unfamiliar environment is no longer just a general ability that might be useful to some architect one day. His company's leadership is now considering a kind of technical responsibility for which it could be important. That's a more concrete reason than his original general idea.
So Petr decides to use the same working mechanism he previously used when a client meeting was approaching. He leaves Value and Effort unchanged for now. He adds 0.5 to Urgency because a relevant employer need has emerged, even though it's still only being considered.
The calculation remains simple:
textPriority = Urgency + (Value / Effort)
ORIGINAL STATE
Value: 1
Effort: 3
Urgency: 0
Priority: 0 + (1 / 3) ≈ 0.33
AFTER THE NEW INFORMATION FROM THE COMPANY
Value: 1
Effort: 3
Urgency: 0.5
Priority: 0.5 + (1 / 3) ≈ 0.83Petr looks at the result. At first glance, it's quite a substantial change. A priority he barely noticed near the bottom of his list now sits at approximately 0.83. But that number doesn't decide what he should do next week at work all by itself.
"So should I move it to NOW?" he asks.
"Look at what you already have in NOW," Igor replies.
Petr opens his current focus: explaining the business value and impact of technical solutions, Priority 1.00. It's an area he deliberately decided to keep working on after the client meeting. He's had room for two concrete attempts, and the second left him with another open question. He has no reason to throw that away.
"I don't want to start two big things at once right now," he says. "And besides, I don't even know whether I'll get to take part in a customer discussion like that."
"So why would you have to switch automatically?"
"I wouldn't. It just doesn't make sense to leave that area completely aside anymore."
This is exactly where Petr's view of prioritization has changed recently. The number isn't supposed to tell him what he must do regardless of everything else. It's supposed to help make the reasons behind a decision visible. Systems thinking in an unfamiliar environment is more relevant now than it was a few weeks ago, but that doesn't automatically make it the one correct current priority.
So Petr keeps explaining business impact as his active development focus. But for systems thinking, he updates the priority, refines the target ability, and decides to prepare a concrete step in case a suitable opportunity comes up at work.
Notice the difference between a development area becoming more important and deciding that you must start working on it immediately. New information can change your understanding of what you'll need in your target role. That also changes the reasons you use to assess individual gaps. But you don't automatically have to abandon everything you've been working on so far.
If your roadmap is based on specific assumptions, you can change the one affected by the new information. Here, Petr hasn't reconsidered his entire life or recalculated every competency from scratch. He refined one requirement of the target role and adjusted its Urgency based on what he learned from his employer. Whether that also changes his current focus remains a separate decision.
A task for a situation that hasn't happened yet
Petr returns to his roadmap. He now has a more specific description and a higher priority for the newly refined area, but he still has nothing he can actually do in his everyday work. Writing down "learn to find my way around customers' systems quickly" wouldn't help much. It's just the competency phrased differently.
"So should I find some unfamiliar application and try mapping it out?" he asks.
"That could be one kind of exercise," Igor replies. "But what would you actually want to practice with it?"
"Building a quick picture of the system from documentation and available information."
"For which decision?"
Petr stops again. For the second time in the same session, he catches himself wanting to start gathering information before he's clarified what he needs it for.
"So I should start with a specific situation," he says. "Like when we're discussing an integration with a customer or a change at the interface between our systems."
"That's closer to what your manager described. And what would you prepare for that kind of discussion?"
Petr starts listing the things that occurred to him while they discussed the new version of the role. First, he'd need to know what decision had to be made and which part of the customer's environment was relevant. Then he'd draw a simple model of the main systems, their boundaries, and important connections from whatever material was available. He'd separate confirmed facts from his own assumptions. He'd record the constraints and the questions without which a reasonable conclusion wasn't yet possible.
"And after the discussion?" Igor asks.
"I'd update the model based on what was confirmed. And I'd leave in the things we still don't know."
"Would you then be able to say whether the model was sufficient for the decision you were dealing with?"
"That's exactly what I'd want to find out."
Petr realizes he finally has something similar to when he first broke down his work on trade-offs. Back then, he'd chosen a familiar technical decision and was supposed to describe at least two options, including their costs, constraints, and risks. This time, he isn't supposed to prepare a recommendation for a specific technology. He's supposed to try building a working picture of an unfamiliar environment from incomplete information, one that can support a decision.
The difference is that he doesn't have any suitable customer discussion arranged yet. His manager hasn't told him he'll be responsible for a new technical partnership or promised him a place in a particular meeting. So there's no point pretending he'll start carrying out the task tomorrow.
But he can put a precise next step into his roadmap for when such an opportunity appears:
textDIRECTION
Software architect / greater technical responsibility
in the context of the company's actual needs
NOW
Business value and impact of technical solutions
Priority: 1.00
LATER
Systems thinking in an unfamiliar external environment
Priority: approximately 0.83
(previously 0.33)
PREPARED NEXT STEP
[ ] If a suitable technical discussion with a customer comes up,
prepare a simple working model of the relevant part of
their environment for a specific decision beforehand.
Capture:
- main systems and boundaries of responsibility;
- important relationships and dependencies;
- known technical and operational constraints;
- confirmed facts;
- your own assumptions;
- significant open questions.
For each area, note why the information is needed
for the decision at hand. Don't try to map the entire
system or every implementation detail.
After the discussion, update the model:
- what was confirmed or changed;
- which important information is still missing;
- whether the model is sufficient for the decision.Petr studies the entry for a moment. In reality, he hasn't done any of it yet. He doesn't know whether he'll get a suitable opportunity or what materials would be available if he does. Even so, he can now describe quite precisely what he'd want to try in that situation and what could later be used to assess his approach.
"And what if that opportunity never comes up?" he asks.
"Then you'll know you don't have it yet," Igor replies. "We can look for another way to practice some parts of it. But I wouldn't treat a hypothetical exercise as proof that you can work with a real customer."
Petr nods. He remembers how he once wanted to attend leadership meetings and eventually got a smaller but real opportunity to prepare technical input. Maybe something similar will work out this time, too. Maybe not. For now, at least, he has a concrete working question he can bring to his manager if a suitable topic comes up.
And, more importantly, he notices one more thing. This task didn't arise because he'd made another mistake in his latest technical recommendation. It arose because he learned something new about the kind of work he wants to move toward.
Going back doesn't mean starting over
When Petr later goes through his notes, he sees the journey so far a little differently for the first time. At the beginning, he mainly wanted more influence over technical decisions. He felt experienced enough that, on some matters, he shouldn't have to just wait for others to decide. Architecture therefore seemed like the logical next step.
But even while building the first model, he'd learned that a title alone wouldn't automatically give him the final say in every technical decision. He had to start distinguishing what an architect is actually responsible for, what information other people need, and where a technical recommendation ends and acceptance of business risk begins. Then he realized he used some abilities less than he'd thought. He chose priorities, built a roadmap, and started practicing in concrete ways.
His plan changed several times along the way. An approaching client meeting temporarily increased the Urgency of explaining business impact. Once the deadline had passed, Urgency returned to its original value, but Petr decided to keep working on that area. That was a change in his current priority based on circumstances and his own decision.
Later, when preparing his first real write-up for his manager, he discovered he'd overlooked an important commitment to a client. During mentoring, he realized he hadn't even tried to obtain the missing information beforehand. So he changed the next concrete step in his roadmap. On his second attempt, he asked about the relevant context before making a recommendation. That was a change in his way of working based on feedback and a new understanding of the problem.
But now something different had happened.
Petr isn't dealing with another question he forgot to ask in his latest attempt. Nor is he responding to a more urgent deadline that requires him to switch focus for a week. He's receiving information that refines his understanding of the target role itself. Suddenly, he needs to go all the way back to what he originally thought architectural responsibility meant.
The original role model wasn't wrong. Petr built it from the information available and it genuinely helped him in the work that followed. He just didn't yet know what form greater technical responsibility might take at his particular company. Now his manager has given him more concrete, though still noncommittal, information about one direction leadership is considering.
And that information gradually finds its way into other parts of his plan. He refines one requirement of the target role. That helps him understand his development gap more clearly. He reassesses its priority against his employer's current needs. He updates his roadmap and prepares a specific step that could let him practice the new ability if the right opportunity arises.
Petr doesn't have to discard the work he's already done. He still has the same experience, the same two technical recommendations, the same open question about a future trigger for revisiting a technology decision, and the same current development focus. He just no longer sees his plan as a path toward a target defined once and for all.
At the end of another session, he opens the architect model and his roadmap side by side again.
"You know what's strange about it?" he says to Igor. "When we first put that model together, I felt like I finally knew what I should do. And the closer I get to that kind of work, the more I realize the role might look a little different."
"That's pretty useful information, isn't it?"
"Yeah. It just took me a while to realize it doesn't have to mean we did something wrong before."
Petr remembers how long he'd originally spent trying to arrive at the correct definition of an architect. How he'd compared job postings, articles, and the experience of a former colleague. How he'd hesitated during his first conversation with Igor at the thought of coding less. And how he'd eventually accepted that he needed a working model he could start with, not a definitive description of every possible architect job.
Now that very model has led him to questions he probably wouldn't have asked without it. And it has allowed him to incorporate the new information instead of starting again.
"So the Framework isn't a set of instructions I go through from beginning to end and then I'm done," Petr says.
"It never was," Igor replies. "You just hadn't had a reason to go back this far before."
Petr smiles. A while ago, an answer like that might have irritated him a little. He wanted a clear plan he could follow to gradually reach greater technical responsibility. But now he understands why such a plan has to respond to new information. If his original idea of the role could never change, he might keep diligently developing toward it even as it stopped matching the work he actually wanted to do.
Petr hasn't become an architect yet. The company hasn't decided on a new role, and Petr still has no experience preparing a technical model of an unfamiliar customer's environment for a joint decision. So his roadmap doesn't contain any newly achieved career outcome.
But it does contain a more precise picture of a possible target responsibility, a more concrete development gap, an updated priority, and a prepared step for a situation in which that ability could actually be put to use.
And Petr now knows that, if he gets such an opportunity, his first task won't be to learn everything about the customer's system. He'll first need to understand what exactly is being decided and which information really matters for that decision.
Perhaps it will turn out that his working model needs another adjustment. Perhaps he'll find that he handles some parts better than expected, and others not at all. And perhaps his next conversation with his manager will bring information that changes his view of architectural responsibility again.
But this time, Petr won't see a change in the plan itself as a problem. What will matter more to him is whether he can explain which new information led him to make the change and what he'll do differently because of it.