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, conversations, and workplace situations in this example are not records of an actual mentoring engagement.
One goal on paper
When Petr looked at his notes after the last meeting, he finally had some kind of order. Of the five areas he had selected, two came out on top: working with alternatives, trade-offs and accepted risk, and the ability to explain the business value of a technical solution. Both received a working Priority of 1.00. Petr decided to start with the first because it connected to problems he had been dealing with on his project for a long time. He consciously put the second one aside.
It felt good, for once, not to end up with another list of things he should be able to do. But the next time he looked at his notes, he ran into a question he hadn't asked himself during prioritization. What exactly does a Tuesday afternoon look like for someone whose current goal is to "get better at handling trade-offs"?
At the next meeting, he showed Igor a line in his notes.
"So this is my priority now. And I have to admit, I have absolutely no idea what tasks I'm supposed to write down for it."
"What would you do if I told you to spend some time on it next week?"
"I'd probably read something. Or wait until we have another decision to make."
"And how would you know you'd actually worked on it?"
Petr stopped to think. He could tick off an article he'd finished reading. But that didn't mean he'd be any better at preparing decisions that involved accepting technical risk. And waiting for a suitable situation at work wasn't much of a plan either, especially when he couldn't even picture exactly what such a situation should look like.
So Igor went back to the original wording and asked what Petr actually needed to be able to do in order to work with alternatives differently than he did today. Petr first started talking about technical debt. How he could recognize a problematic solution, how he knew certain parts of the system would become difficult to change later, and how frustrating it was when people treated those consequences lightly during decision-making.
"But you can already do much of that," Igor stopped him. "What's missing between saying 'this is a bad solution' and preparing something that someone can actually make a decision based on?"
Together, they broke it down into four smaller areas. Petr needed to be able to identify relevant alternatives, compare their benefits, costs and constraints, describe specific risks and their impacts, and finally distinguish his technical recommendation from the authority of the person who would accept the resulting risk on behalf of the company. Even the list itself sounded more useful. Still, Petr couldn't decide where to start.
"Which of those feels like your weakest area today?" Igor asked.
"Probably risks. I can come up with alternatives somehow. But I often end up saying that a solution will create technical debt. I know what I mean by that, but then I can't put it into a form that someone outside development could actually do something with."
So they narrowed the current focus once more: being able to describe the specific risk being accepted and its impact.
"All right," Petr said. "So I should study how to describe risks?"
"Maybe you'll discover that there's something you need to study. But first I'd like to see what you can already do on your own. You've been involved in plenty of technical decisions. Pick one where you felt at the time that we were making a bad compromise."
"I could find several of those."
"One is enough. We don't need to go through the entire history of the project. Try going back to that decision and preparing at least two alternatives. For each one, write down what it brings, what it costs, what constraints it creates, what could specifically go wrong and what the consequences would be. And also what might become more expensive or more complicated later because of it."
Petr was quiet for a moment. One older decision immediately came to mind, something he could start with. But he also realized that he might not know all the original assumptions. He wasn't even sure whether there had really been two meaningful alternatives at the time.
"So you want me to write something even though I might not have all the information?"
"Yes. But don't pretend you have it. If you don't know something, mark it as an unknown. For this first attempt, you don't need to produce a decision document we could immediately send to management. We need to see what you can already break down and where you get stuck."
"And what if I get it wrong?"
"Then at least we'll have a first concrete version we can think about. If you could already do this reliably, we wouldn't need to develop that ability now."
Petr wrote down the task. For the first time in several meetings, his notes contained more than an area he wanted to improve in someday. He had something he could actually open and try to do, without needing a new assignment, a new job role or a special project.
| Current focus | First concrete step | Expected output |
|---|---|---|
| Describe the risk being accepted and its impact | Choose one familiar past technical decision; describe at least two alternatives that were available or realistically possible | For each alternative: benefits, costs, constraints, specific risks, their impacts and possible later costs; explicitly mark unknowns |
"And are we going to break this down into more tasks now?" Petr asked.
"Why? Do you know what you need to do?"
"Yes."
"Do you know what you can try it on?"
"That too."
"Then I'd stop there for now. Once you've tried it, we'll find out whether you're missing some knowledge, need a smaller step, or need something else entirely. Coming up with another ten tasks right now wouldn't help us much."
When you write down "improve communication", "learn to make decisions" or "get better at architecture", you've identified a direction, but you don't have a task yet. That doesn't mean you need to plan out the next six months of work immediately. First, try asking yourself what actually makes up the ability you want to develop. Which part of it can't you do yet? What familiar situation could you try it on? And what will you be able to see after the first attempt that you can't see today?
It makes sense to stop breaking things down once you can get started. The first output doesn't have to be correct or complete. You need to be able to assess it, not declare in advance that it proves you've already mastered the ability. If you don't even know how to identify the smaller parts, your first task might be to figure out what would have to be true for the larger goal to be achievable.
Now he tries it himself
Before ending the meeting, Igor returned to the second area Petr had left for later during prioritization: explaining the business value and impact of a technical solution.
"Now try breaking this goal down yourself," Igor suggested.
Petr looked up from his notes. "But we put that one off until later."
"And that's where it stays. I'm not saying you should start working on it tomorrow. I just want to know whether you can use the same approach without me guiding you through every question."
Petr thought for a moment. He remembered the product meetings where he was invited as the technical person. He would often start explaining the details of a solution because those were the parts he understood well. But he didn't necessarily know what the person on the other side actually needed to decide.
"So the first thing is figuring out who I'm explaining it to," he said. "A developer will need something different from a project manager or someone from product. And I also need to understand what decision we're discussing in the first place."
"What else?"
"Select only the technical information that's relevant to that person. Describe the benefits, costs, constraints and risks. And not automatically start with how the database works when they need to make a decision about a deadline."
Gradually, they arrived at five smaller parts:
- Identify the audience and the decision the information is supposed to support.
- Understand what is relevant to that person and that particular decision.
- Translate the technical solution into benefits, costs, constraints and risks.
- Choose the appropriate level of technical detail.
- Start with the relevant impact and add technical details only when needed.
Petr stopped at the third point. "But 'translate the solution into benefits and risks' is still pretty broad. I should probably break that down too."
This time, Igor didn't suggest anything. He waited while Petr opened his notes and added his own questions: What does the product gain from this? What will it cost now, and what might it save later? What constraint will it create? What happens if we don't make the change? What risk are we reducing or accepting? And does anyone actually need to make a decision based on this information?
"Wait a minute," Petr stopped himself. "We're already dealing with describing risks and impacts under trade-offs."
"And do you need to treat it as two different abilities just because you reached it from two different goals?"
Petr shook his head. He was beginning to understand that development goals weren't separate drawers. The same smaller ability could matter both when designing alternatives and when explaining them to someone responsible for a deadline or a budget. One piece of work done properly could therefore serve more than one purpose. But that still didn't mean he needed to activate both larger areas at the same time.
"So we'll keep the notes for the second goal, but it still won't be active."
"Exactly. Being able to break something into smaller parts and deciding to work on it right now are two different things."
A roadmap that doesn't need its own project manager
When Petr heard the word roadmap, he first imagined a document planning an entire quarter of work. Milestones, dependencies, estimates, deadlines. If he had to prepare something like that for all five development areas, he'd need another free evening. Possibly several.
But Igor expected something simpler from his roadmap. Petr should be able to look at it and quickly recognize what he was focusing on now, what could wait and what his next concrete step was. He didn't need to list every possible future activity for every competency.
So Petr put together a working overview. At the top was still his direction towards a software architect role or broader technical responsibility. Underneath were the prioritized areas. Only one was active, and only that one had a clearly marked next step. The breakdown of the second area remained in his notes, but he wasn't pretending it represented active work yet.
textDIRECTION: Software architect / broader technical responsibility
NOW
Alternatives, trade-offs and accepted risk [Priority 1.00]
- Identify relevant alternatives
- Compare benefits, costs and constraints
- CURRENT FOCUS: Specific risks and their impacts
-> NEXT STEP [ ] Examine one familiar past
technical decision using at least two alternatives;
for each, describe benefits, costs, constraints,
risks, their impacts and later costs
- Distinguish technical recommendation from risk acceptance
LATER
Business value and impact of a technical solution [1.00]
- Audience, their decision and necessary context
- Benefits, costs, constraints, risks
- Appropriate level of technical detail
Breaking down a larger problem before implementation [0.80]
Facilitating technical discussions [0.50]
Systems thinking in an unfamiliar environment [0.33]"That's everything?" Petr asked, looking at the overview.
"What's missing for you to know what to do next?"
"Actually, nothing. It just feels almost too simple."
"Then maybe it's simple enough that you'll actually use it."
Igor showed him that ordinary markers were enough for individual steps: [ ] meant an open task, [x] a completed one, and -> the current next step. No tool would decide for him whether he'd chosen the right goal, but he didn't need to build his own system for it either. A list, a table or an application he actually returned to would be enough.
"And what if something more important than this task comes up at work?" Petr asked.
"Then you look at the roadmap again. We're not turning it into a commitment to ignore everything else that happens. But you'll need to know why your focus is changing."
So they agreed on two simple checks. Every workday morning, Petr would briefly look at his current development priority and whether the day might offer a situation in which he could deliberately put it to use. Once a week, he'd do a short retrospective: what had moved forward, whether his current focus still made sense, and whether circumstances had changed enough to reconsider the order.
Petr set a morning reminder. It was a small thing, but those were exactly the kinds of things that tended to disappear from his attention during an ordinary working day. His own tasks, consultations and meetings could easily fill the day. He wasn't going to make time for further professional growth simply by having it written down in a document.
The meeting that wasn't supposed to be about Petr's development
A few days later, Petr's manager came to see him. A client meeting was coming up, where they would discuss the technical solution for a planned implementation. The client's CEO would also attend. According to the manager, the CEO understood technical matters reasonably well, but had never been a developer himself. He wasn't interested in examining every last implementation detail. He needed reasonable confidence that the company understood what it was proposing, why it was proposing it and what the consequences would be.
At first, Petr mainly thought about the technical questions he might get about such a solution. Then he realized that this was exactly the kind of situation they'd discussed in mentoring. He tended to see the non-technical part of a discussion as something that only concerned him when somebody needed an implementation detail explained. But this time, he might be expected to do something else: help the other side understand what the proposed alternative meant for their goal.
He opened his roadmap. His active area was still working with trade-offs, with a Priority of 1.00. Just below it, however, was the second, previously postponed goal: explaining the business value and impact of a technical solution. Also 1.00.
Until now, neither goal had faced any specific external time pressure. Now there was an actual client meeting he needed to prepare for. So Petr didn't try to invent new mathematics or retrospectively change the value of the entire competency. He adjusted just one thing for the second goal: Urgency.
textPriority = Urgency + (Value / Effort)
BUSINESS IMPACT BEFORE THE MEETING
Urgency 0 + (3.5 / 3.5) = 1.00
BUSINESS IMPACT BECAUSE OF THE MEETING
Urgency 0.5 + (3.5 / 3.5) = 1.50
TRADE-OFFS
Urgency 0 + (3 / 3) = 1.00Petr moved explaining business impact into NOW and trade-offs into LATER. He hadn't deleted his original task or discovered that his priorities from the previous week had been wrong. Circumstances had changed. That was precisely why they had kept Urgency separate from Value and Effort in the model.
At the same time, he noticed that his original work with risks hadn't become irrelevant. Being able to describe what a technical alternative brings, what it costs and what risks it carries is also useful to someone who doesn't want to discuss its implementation details. The two development areas overlapped. Petr just needed to pay more attention this time to which information actually mattered to the client.
Maybe your roadmap contains something you wanted to work on this month, and then a situation comes along where a different ability suddenly becomes useful. That doesn't necessarily mean you made a mistake in your original prioritization. Ask yourself what actually changed. Is it the value of the ability? The capacity required to develop it? Or simply a specific deadline and the needs of the person you're currently working with?
When urgency changes, it can make sense to switch your focus for a while. But don't confuse a change in priority with progress in the ability itself. The fact that Petr got an opportunity to explain a technical solution to a client doesn't prove anything about how well he did it. For now, he only knows what he needs to pay attention to in the near future.
And what if the deadline pressure disappears?
On the morning of the meeting, Petr opened his roadmap. The reminder showed him his current focus, and as he prepared, he returned to a question that had seemed uninteresting to him not long before: What does the person on the other side actually need to know to form a reasonable opinion about the proposed solution?
He didn't want to automatically start with the technical detail he understood best. So he highlighted the benefits, costs, constraints and risks that might be relevant to the client, along with the areas where he needed more context. All of it came from an ordinary morning check of his list. Without it, Petr would probably have focused on preparing the solution as if this were just another technical meeting. Now, at least, he had consciously reminded himself that he wanted to try a different way of thinking during it.
The meeting took place. Petr didn't treat it as proof that he could already explain business impact at an architect's level. For that, he'd need to understand how the other side had used his input, what had worked and what he'd need to change next time. He didn't have that information in his notes yet. But he did know that during preparation, he'd managed to focus on something he had often overlooked before.
At the end of the week, he opened his roadmap for his short retrospective. The deadline that had made him switch focus was now in the past. He had no other concrete reason to keep Urgency elevated, so he brought it back from 0.5 to 0. The Priority of business impact therefore returned from 1.50 to 1.00. Trade-offs had remained at 1.00 the whole time.
Petr hesitated. Last time the scores had been equal, he'd chosen trade-offs. Should he automatically return to his original plan now?
To his surprise, he didn't really want to. While preparing for the client meeting, he'd discovered that when business context wasn't treated as some foreign part of the meeting, but as a question of why a technical solution should be implemented at all, it started to interest him. It was still an ability that would make him uncomfortable in many ways. But now he felt like giving it more attention for a while.
At the next meeting, he described this to Igor.
"I brought Urgency back down to zero, so both of them come out at one again," Petr said. "But I'd keep business impact as my main focus. At least for now."
"Why?"
"I feel like I've mostly been trying to get through those situations without really dealing with them. Now I'm interested in finding out whether I can actually understand that side of things. Not just explain the technical solution when somebody asks."
"Then keep it there. When the scores are equal, we don't need to pretend the formula will make the decision for you too. The important thing is that you know why you chose this."
So Petr didn't invent an additional bonus to justify the new order mathematically. His current roadmap simply said:
| Status after retrospective | Development goal | Urgency | Priority |
|---|---|---|---|
| NOW | Business value and impact of a technical solution | 0 | 1.00 |
| LATER | Alternatives, trade-offs and accepted risk | 0 | 1.00 |
The other three goals also remained in the LATER section, with their working priorities unchanged. Petr hadn't lost his original motivation to address technical debt. And working with trade-offs could still help him as he developed his new focus. He just no longer needed to treat every relevant area as an active task.
Notice that Petr made two different decisions here. First, he switched focus because a specific deadline and a request from work came up. Then he reduced Urgency again because that reason no longer applied. Those were changes in circumstances. Only after that did he decide to stay with the same goal because, with the scores now equal, continuing made sense to him. None of those things is evidence yet that his ability has improved.
A good development roadmap isn't a list you have to follow at all costs, or a system in which you calculate every decision to the third decimal place. It should help you see what you're doing now, why you're doing it and what would make you decide differently. Sometimes a deadline changes. Other times, you only discover what you could and couldn't do after a real attempt. That's a different reason to adjust the roadmap, and you should be able to tell the difference.
The next question isn't in the table
At the beginning, Petr had no idea what to do with an abstract priority. Now he could break down a larger competency, choose a small executable step, build an overview worth returning to, and adjust it when an actual deadline appeared at work. He'd learned how to work with his roadmap. But that didn't mean he'd mastered the competencies written in it.
And his current priority presented another problem. He wanted to get better at explaining technical decisions to people who didn't follow implementation details. For that, simply thinking about those situations or writing them down in a document would no longer be enough.
He needed an opportunity to actually try it. Ideally one where he could see what his explanation had given the other person and what had been missing.
So the question was no longer "what's on my roadmap". It was becoming much more practical: Where can I find room to do this in my everyday work when I don't have that responsibility yet?