Petr Thought He Knew What He Was Missing. Then They Started Talking About Specific Situations.

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 numbers in this example are working estimates, not objective measurements of ability.

Twenty-five items and one uncomfortable question

Petr left the previous session with a much more concrete picture of what a software architect does. He and Igor had gone through Petr's own research and the mentor's independently prepared perspective. Instead of a single, nice-sounding definition, they had ended up with a working model containing 25 competencies and responsibilities. Petr also knew by now that greater technical influence did not necessarily mean more decision-making authority, that he would probably spend more time talking to people and less time coding, and that even in architecture, the compromises that frustrated him so much on his current project were unlikely to disappear.

He was still interested in that direction. But now he had run into another problem. When he opened the list, he saw plenty of things he could improve at. He just had no idea where he actually stood. He worked with some of those things every week, knew others mostly from discussions, and with still others he wasn't sure whether he and Igor even meant the same kind of work by the same words.

"So, should I take all twenty-five items and rate myself now?" he asked at their next session.

"You could. But first we need to find out whether we're thinking of the same work when we talk about each competency," Igor replied. "Take systems thinking, for example. What exactly does someone need to be able to do? If we don't agree on that, you can fill in twenty-five numbers and we still won't know what you're actually rating."

"So we should write a definition for each item?"

"We don't need to turn it into a dictionary. Let's take a few specific situations from your work instead and use them to see what you can already handle, and what you'd need to be able to handle in the target role."

To start with, they chose five areas. They weren't all the competencies of an architect, or a complete diagnosis of Petr's abilities. They were a working selection that would let them explore what it meant to compare a specific expectation for the target role with specific experience in the present.

"And how do we compare them?" Petr asked. "It's one thing to say I do something. But how do I know whether I already do it well enough?"

"We'll use a scale from zero to five as a tool. For each ability, we'll set a working target level and then try to estimate where you are today. I just don't want you to guess the number based on how you feel. I need to hear what you actually do at work."

"So if we set four as the target for a competency, does that mean that at level four I can already work as an architect?"

"No. It's a target for one specific ability, not an overall assessment of your readiness for the role. And we're still working with a picture of an architect that you'll need to verify at a particular company. That's why we need to know what you actually mean by each ability."

"And if I give myself a two now?"

"Then you'll tell me which experiences that estimate is based on. Maybe you'll keep it after we talk. Or maybe you'll discover you're counting something that is related to that ability but isn't actually the same thing."

Petr nodded. A moment ago, he'd simply wanted to assign scores to the list. Now he was beginning to see that he'd need to explain the reason behind every number.

This isn't an exam that will give Petr a verdict on whether he's ready to be an architect. We're taking five specific abilities from his working model of the target role and comparing two things for each one: how well he believes he'd need to perform it in that role, based on his current understanding, and what real experience he has with it today. The point is to find specific development gaps he can work with, not reduce an entire person to a single score.

For orientation, we're using a 0-5 scale. 0 means practically no experience, 1 mainly theory or a few initial, limited attempts, and 2 some usable practical experience. Higher values suggest progressively greater independence, depth, and reliability; 5 might roughly represent very deep expertise, perhaps even the ability to teach others. These are not rigidly defined levels, the intervals between them are not necessarily equal, and this is not an objective measurement of ability.

If we set a target level of 4/5 for one competency, that doesn't mean Petr is 80% ready to become an architect. It means that, in our working model, he should be able to use this particular ability at a fairly high and reliable level. We still need to check what that means against real work situations. And when Petr then says, "I'd probably give myself a two here," he's talking about his current estimate of that same ability, not the entire role. The difference between 2/5 today and 4/5 as the target is not a precisely measured deficit of two units. It's a reason to examine what he can actually do, what he has experience with, and what he's only assuming.

If you want to try this yourself, choose one specific ability you think belongs to your target role. Describe what using it at work should look like, and think back to situations where you've actually used it. What could you handle independently? Where did you need help? What do you only know in theory or from watching other people work? Only then write down a working target level and your current estimate side by side. If you discover along the way that a single label hides several different abilities, adjust the description or the rating. The goal isn't to get a nice-looking number, but to know what makes sense to work on next.

A database he'd never heard of

They started with systems thinking. In their working model of the role, this was one of the most important abilities: seeing the system as a whole, its boundaries, connections, and the effects of changes. For the next part of the exercise, they set the target at roughly 4/5.

"I'd probably give myself a two here," Petr said. "I know our product well, but not the whole company. What if I have to decide something involving a database I've never even heard of?"

Igor let him expand on the thought. Petr talked about other teams, technologies he didn't use, and internal systems he could barely see into. The longer he talked, the longer the list of things he didn't know became.

"And do you think that, as an architect, you have to know how to administer that unfamiliar database yourself?" Igor asked.

"Probably not. But I should know something about it."

"Sure. But what?"

Petr paused. Eventually, instead of naming technologies, he started asking questions. What is that part of the system for? What are its inputs and outputs? What does it depend on? What are its limits and guarantees? What happens if it goes down or its behavior changes? And who will he need to involve if a decision depends on a detail he doesn't know himself?

This was already how Petr approached larger tasks. In his own product, he regularly dealt with dependencies between components and thought about what a change would affect elsewhere. He had simply assumed that good systems thinking also required deep knowledge of every technology in use.

"So I've mixed systems thinking, broad technology knowledge, and deep expertise into one rating," he summed up.

"Exactly. And those are three different things."

After their conversation, he raised his estimate from 2/5 to roughly 3/5. Not because he'd learned something new in the last twenty minutes. He had finally described more precisely the ability he was rating. The gap from the working target of 4/5 remained: he needed to carry this way of thinking into unfamiliar parts of an environment, quickly establish what mattered for a decision, and recognize where he needed more context or a specialist.

When half the solution has already been decided

Petr wasn't as pleased with the next item. It concerned breaking down a larger problem before implementation.

"I deal with complicated stuff all the time," he objected. "And larger tasks are exactly what I enjoy."

This time, Igor focused not on the complexity but on the point at which Petr became involved in the work.

"Imagine there isn't any implementation yet. You're given a broader product problem. You have to design the main parts of the solution, their responsibilities, dependencies, and unknowns before the team starts coding. How often do you actually do that?"

"Well... from the very beginning like that? Not much. Usually something already exists. And quite often I only figure out what the problem is once I start digging around in it."

That didn't mean Petr couldn't deal with complexity. Quite the opposite: he was experienced at it. He could untangle a problem that emerged during implementation, understand the connections, and gradually adjust the solution. But that was a somewhat different ability from designing the structure of a larger solution before the first implementation compromises had already shaped it.

Here, his current estimate stayed at 2-3/5 against a working target of 4/5. Petr didn't resist that conclusion much. He was genuinely drawn to this area. It was precisely the sort of work he'd like to get more often, instead of only reaching the larger decisions after the team was already partway down the road.

Then they moved to trade-offs and accepting risk. And the conversation became less comfortable.

"Well, this one's at least a two," Petr declared. "I'm pretty reliable at spotting technical debt."

Igor reminded him of a simple situation: a cleaner solution would take six weeks, but the company needed a result in three. Petr immediately began listing everything the faster option would damage. Worse extensibility, further complications, work that would have to be redone someday. All of them legitimate technical arguments.

"And what is the person deciding on those three weeks supposed to do with them?" Igor asked.

Petr returned to technical debt, but Igor kept asking. What were the realistic options? What would each one cost right now? What exactly might go wrong later, and with what impact? Which decisions would be easy to change, and which wouldn't? Which risks could Petr describe from a technical standpoint, and who had the authority to accept them on the company's behalf?

After a while, Petr realized why they had returned to this topic for the second time. Last time, he'd understood that "good enough" didn't have to mean not caring about quality. Now he was discovering something less pleasant: being able to point out a bad compromise didn't yet mean being able to prepare a decision that someone else could actually make.

"So if I say, 'This will create more technical debt,' I haven't really given them enough information yet."

"Sometimes it's a good start. But if you need someone to weigh a deadline against technical risk, you have to show them the concrete consequences of both options. You don't have to decide for them. You have to give them a chance to make an informed decision."

Petr had initially written down 2/5. After this discussion, they settled on an estimate of 1-2/5 against a target of 4/5. The range was deliberately broad. Petr could already handle some parts, but he wasn't yet routinely doing the whole job of working with alternatives, benefits, costs, and accepted risks.

The meeting he only half listens to

For the business impact of technical decisions, Petr initially rated himself at 2-3/5. He had a good reason: he was invited to product discussions, and the project manager occasionally asked him about the product's technical possibilities. It wasn't as though Petr had never seen anything outside development.

"And when the meeting isn't about anything technical, what do you do?" Igor wanted to know.

"What do you think? I have my laptop open and finish some task. When they start talking about something I can contribute to, I listen."

Petr said it as though it were obvious. Time was limited, there was plenty of work, and meetings could drag on. In his mind, he justified it by thinking that no one else was going to do his tasks for him. But until then, he hadn't thought much about what he was missing by switching his attention like that.

"So sometimes the context is right in front of you," Igor said. "You just choose not to follow it. How are you going to explain the business impact of a technical solution to someone if you don't even properly understand what they're trying to achieve with the change?"

Petr could have argued that this was the product manager's job. And to some extent he'd have been right. He didn't have to take responsibility for the product or for commercial commitments. But if he wanted to influence a technical decision with product or customer consequences, he couldn't wait until someone asked him for a technical opinion to start thinking about those consequences.

Suddenly, his original 2-3/5 didn't look so convincing. Being in the meeting didn't mean he could actively work with its content. He and Igor agreed on a working estimate of 1/5 against a target of 4/5.

Petr didn't feel good about that. Unlike breaking down complex problems, this area didn't particularly interest him in its own right. And now he could see that he'd literally spent some of his opportunities to learn working on another task with his laptop open.

The last selected area was facilitating technical discussions. Here, Petr was fairly confident he deserved a three. When colleagues got bogged down in a detail, he could bring them back to the purpose of the meeting. Sometimes all it took was saying, "Hey, this probably needs a separate discussion."

"And what if they're talking about something you're really interested in?" Igor asked.

Petr burst out laughing. "Then before long I'm deep in that detail with them."

That was exactly the difference. Petr could keep a discussion on track as long as he maintained some distance. Once he had a strong technical opinion of his own, he became one of the people making the meeting run long. His 3/5 rating stayed, but the gap from the 4/5 target finally had a concrete shape: keeping track of the discussion and its purpose even when the subject drew him in.

So what did they end up with?

When they put all five areas side by side, it looked surprisingly simple on paper:

Petr looked at the table for a while. His systems-thinking score had gone up. His scores for trade-offs and business impact had gone down. Yet in none of those cases had what Petr could actually do at work changed between the beginning and end of the conversation. What had changed was how precisely he understood what he was rating.

"So if we come back to this in six months and my number is lower, it doesn't necessarily mean I've got worse," he said.

"Exactly. Maybe you'll simply have a better idea of how much you still don't know. That's why we need to look mainly at specific experiences and behavior, not at whether the number is going up."

If you try a similar comparison yourself, don't start by deciding how many points to give yourself. First work out what you mean by the ability, in what situations you actually use it, and how you'd recognize the difference compared with your target role. You might be quite good at solving complex implementation problems without having much experience designing a solution before implementation. Or you might be present when product decisions are being made without actively engaging with their context.

A number is useful when it helps you ask a better question. It isn't a certificate of readiness or an objective test. And if your estimate goes down after an honest look at concrete examples, that isn't necessarily bad news. It would be worse to keep planning your development around an ability you'd imagined differently from how you actually want to use it.

Five areas. How many will he start working on now?

At last Petr had something he could work with. But his first instinct wasn't especially helpful.

"All right," he said, "so I have to get better at all five."

"Maybe eventually. But do you have the capacity to deliberately develop all five at once?"

Petr looked back at the table. He couldn't put his regular work aside. If he added five big development goals on top of it, he'd probably end up with a nice list and very little actual progress.

So Igor suggested they stop asking, "What am I missing?" and look at a different question: "What makes sense to start with, and what can I consciously leave for later?"

They used a simple formula:

Priority = Urgency + (Value / Effort)

Value described how significant an improvement that ability could bring Petr. Effort was a rough indication of how much capacity developing it would take. Urgency captured a concrete reason something had to be addressed right now, such as a deadline or a need someone had at work. This wasn't a calculation of the objectively best career plan. It was a way to stop shifting their assumptions depending on which goal happened to look more interesting at a given moment.

They used a few simple guidelines for Value. If Petr was already using an ability regularly and needed to improve by roughly one level, they used a value of 1. If he had a usable foundation but needed a more substantial improvement of perhaps two levels, Value could be 2. If he was barely using the ability at all and needed to start putting it into real practice, Value could be 3. A particularly large gap, such as three levels, could add +0.5. So could substantial usefulness outside work. In a specific situation, the personal significance of an ability could also matter, perhaps enough for Petr to rate its Value directly at 3. This wasn't a scale where every decimal place represented a measured difference.

For Effort, they used a rough distinction for small tasks: 1 for something taking a few hours, 2 for roughly a day or two of work, and 3 for something longer or difficult to estimate. But Petr wasn't rating tasks he could finish in an afternoon. He was rating whole development goals. All five therefore started with Effort 3.

"And couldn't we give the thing I enjoy a slightly lower Effort?" Petr asked. "If I don't have to force myself to do it, it'll be easier."

"Adjustments like that make the most sense for specific tasks. With goals this big, I'd normally leave it at three. But for two areas you already have a pretty clear sense of how they affect you, so we can take that into account for this working estimate. It doesn't create a new rule for everyone."

Finally, they looked at Urgency. None of the five goals currently had a specific external deadline or stakeholder request that would move it ahead of the others. So all five got 0. If circumstances changed, that number could change too.

That left one thing: explaining why each goal had exactly those input values.

Two ones that mean different things

For systems thinking, Petr now had 3/5 against a target of 4/5. This meant extending an ability he was already using, so Value 1. No significant personal adjustment or urgency. Effort 3, Urgency 0, giving Priority 0.33.

For breaking down a larger problem before implementation, he had 2-3/5 against 4/5. The ability wasn't new to him, but he needed a more substantial step forward, so he chose Value 2. Here Petr allowed himself, for the first time, to account for the fact that he genuinely enjoyed the work. Compared with other goals, he expected less internal resistance, so for this specific estimate he lowered Effort 3 -> 2.5. With zero Urgency, that gave Priority 0.80.

Trade-offs were more sensitive for Petr. The working estimate of 1-2/5 against 4/5 suggested that he was barely using the full ability to prepare a deliberate decision in practice. So he chose Value 3, the baseline Effort 3, and Urgency 0. Priority came out at 1.00. He didn't increase Value by another +0.5 for a three-level gap: the current rating was deliberately a range of 1-2, not a precisely measured one. Petr and Igor didn't want to pretend to a level of precision they didn't have.

For business impact, his current estimate was 1/5 against a target of 4/5. That was a substantial step from an ability Petr was barely using in practice. The baseline Value 3 got a +0.5 adjustment for the three-level gap, making Value 3.5. But Petr also knew very well how much he disliked focusing on the nontechnical parts of meetings. So for this estimate he increased Effort 3 -> 3.5. Urgency remained 0, and Priority once again came out at 1.00.

"So the thing I least want to work on ended up with exactly the same score as trade-offs," Petr observed.

"Because the gap from your target is bigger at the same time. The same final number doesn't mean the same reason."

That left facilitation. Petr already used this ability at roughly 3/5 and was aiming for 4/5, so the baseline Value was 1. But then he added something that hadn't come up while they were rating his work competencies.

"This would actually help with my friends, too. We play Dungeons & Dragons, and sometimes we can spend half an hour debating what to do. And of course I join in as well."

Igor smiled. Petr knew this problem of his well outside work, too. Because the ability would also be useful in another part of his life, they increased Value to 1.5. With Effort 3 and Urgency 0, he got Priority 0.50.

The resulting table was fairly easy to read:

Petr spent a while trying to decide whether the resulting order was really right. Systems thinking interested him, after all. Breaking down problems interested him even more. And if he simply tried to improve at what felt pleasant, he wouldn't have to push himself so hard.

But Igor brought him back to the purpose of the table. It wasn't supposed to pick what Petr would enjoy. It was there to help make visible why a particular area might make more sense for him right now, and roughly how much capacity it might demand. Besides, the numbers weren't precise enough to say that 0.80 was objectively a fixed percentage worse as a development investment than 1.00.

"So we have two goals at one," Igor said. "We don't have to spend another twenty minutes figuring out how to create a difference between them in the decimal places. Which one do you want to start with?"

Petr returned to the problems on his project. To how often he'd seen technical debt somewhere, pointed it out, and watched nothing change. After the previous session, he'd begun to admit that, alongside decision-making authority, perhaps he also lacked a better way to describe a compromise so that someone could actually decide on it. And that was what interested him more right now.

"I'd start with alternatives and trade-offs. I want to find out whether I can argue for something with more than just 'this isn't technically clean.'"

"All right. And business impact?"

"We'll leave that for later. Not because it's less important. I just don't want to do both halfway right now."

For the first time that day, Petr felt he wasn't being judged only by what he couldn't do. He'd made a decision about where to put his attention, and he could explain why he'd chosen that area.

When two areas score similarly high, you don't have to squeeze more decimal places out of the model. Ask what assumptions lie behind the numbers, whether some can reasonably be checked, and whether you have a real reason to start with one area over the other. Your decision can include your own preference. What matters is knowing you're using it, rather than disguising it as the result of precise mathematics.

And one more thing: "later" is not the same as "unimportant." You can have two equally strong development goals and still consciously leave one alone, because focus is itself a limited resource. If reality changes, you can reconsider the order. But you don't have to keep everything active just to avoid missing out.

Now and later

In the end, Petr kept only one active development focus: working with alternatives, trade-offs, and accepted risk, with a working Priority of 1.00. He put business impact (1.00), breaking down a problem before implementation (0.80), facilitation (0.50), and systems thinking in an unfamiliar environment (0.33) into the LATER group. He wasn't removing any of them from his working model of the target role.

But when he looked at his notes again a little later, he spotted one more uncomfortable problem. The selected priority sounded good, but there still wasn't anything he could actually do with it.

"Get better at working with trade-offs," he read aloud. "Sounds nice. But what am I supposed to do with that tomorrow morning?"

Igor looked at the same sentence. "That's exactly the next question. Now we know what you want to focus on. But you still don't have a step you can actually take."

At least Petr could now see the difference. A more specific idea of the target role hadn't been enough. Knowing the gap between where he was and where he wanted to be hadn't been enough either. And even a well-reasoned priority wasn't a plan yet.

They would still have to build one.