Petr wanted to be part of the decision-making. His manager offered him an hour.

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 figures, conversations, and workplace situations are part of this fictional example.

When you have a goal but nowhere to practise it

Petr finally had a development roadmap he actually used. It wasn't another document listing things that might be useful to learn someday. Every morning he spent a moment looking at it, checking his current focus and reminding himself what he wanted to pay attention to at work. After a recent client meeting, he had also deliberately changed the order of his priorities. Explaining the business impact of technical solutions had become more urgent because of a specific deadline, and once the meeting was over, that urgency had dropped again. Even so, Petr decided to keep working on it. With the same working priority score of 1.00 as trade-offs, continuing in this area made sense to him.

He was still interested in whether he might eventually move from being a senior developer into a role with architectural responsibility. But in his first meetings with Igor, he had realised that such a move probably wouldn't just mean more complex technical tasks and a bigger say in technology choices. He would have to learn how to prepare decisions involving costs, deadlines, product needs and risks. Above all, he would need to explain technical considerations to people responsible for those things without requiring them to understand the implementation.

He understood why that mattered. He even had a few questions he could use to structure his own explanations. But when he looked at an ordinary working week, most conversations of that kind happened somewhere else. Petr took part in technical discussions, consulted colleagues on solutions and occasionally had a chance to explain something to a client. Decisions about larger investments or priorities, however, were usually handled by his project manager together with other members of management.

So at his next mentoring session, Petr brought up a problem that had bothered him on the project for a long time. In his view, technical debt had been steadily growing. Developers kept pointing it out, but substantial changes rarely happened. There was always something more urgent, some new feature or deadline that took precedence. Petr increasingly felt that those decisions would go differently if management really understood how much extra work the current state of the system was creating.

"Sometimes I wonder whether our manager can even explain it properly to management," he tells Igor. "He's the one discussing those technical issues on our behalf. But when I see what gets prioritised afterwards, I sometimes feel like they just don't grasp the impact of the technical debt."

"And do you know how he explains it to them?" Igor asks.

"Well, I'm not actually in those meetings."

"So you don't know."

Petr leans back in his chair. "Well, when you put it that way..."

"Tell me what you actually know. You raise technical problems, but some investments keep getting postponed. That's the outcome you can see. What you can't tell from that is whether your manager explained something badly, whether management didn't understand it, or whether they understood perfectly well and chose to prioritise something else."

Petr wants to object, but he can't think of a concrete example to support his original conclusion. He knows the technical cost of some decisions. He knows how much unnecessary work he believes they create for the team. What he doesn't know is which options and consequences are actually discussed with management. Until now, that hadn't bothered him much. In fact, it was convenient to assume that if he were in the room, he could explain the importance of some of those problems better.

"But that's exactly the kind of decision-making I want to get involved in," he objects. "If I want to be an architect one day, I don't want to just wait for someone to make a decision and then complain that it was wrong."

"That's a sensible reason," Igor replies. "I just wouldn't build it on the assumption that your manager is failing at something. What if you tried to find out whether you could contribute to preparing one of those decisions instead?"

Petr thinks for a moment. He has regular 1:1 meetings with his manager, and they've already talked about his development several times. He doesn't need to invent a special route to management or try to claim responsibility he doesn't yet have. He can start with an ordinary question: is there an opportunity to try out the work he needs to learn?

He didn't get a seat at the meeting

At their next 1:1, Petr first explains what he wants to work on. He doesn't start with technical debt or criticism of how decisions are made on the project. He describes his current development goal: learning to prepare a technical argument that allows someone outside development to assess the benefits, costs, constraints and risks of a proposed approach. Most of his experience is still in implementation itself, and he lacks experience of how this kind of input is used in real decisions.

"You talk to management about technical issues regularly, right?" Petr asks his manager during their 1:1.

"Yeah. We have a meeting roughly once every two weeks where we cover quite a few things. Sometimes we discuss technical decisions, investments or risks that we need to explain to people outside development. Why?"

"I was wondering whether I could join sometime. I don't want to start making decisions there straight away. But I'd like to see how those discussions work and maybe get involved in one of them eventually."

The manager considers it, but doesn't leave Petr wondering for long.

"I wouldn't bring you into those regular meetings yet. We discuss things there that have nothing to do with your project, and I don't want to add another meeting to your calendar every two weeks. You've already got plenty to do. I still need you to focus mainly on development."

Petr is disappointed. He hadn't expected to become part of management tomorrow, but he had imagined he might at least get to listen. These were exactly the discussions he needed to understand. For a moment, it feels like the same problem as technical debt: to gain more responsibility, he needs experience, but without more responsibility he can't get that experience.

The manager continues before Petr can explain why he wouldn't mind another meeting.

"That doesn't mean you can't work on it, though. If you want to try preparing input for a decision, we can pick a specific technical topic. How much time would you need for a first attempt?"

Petr tries to picture what he would actually deliver. He doesn't want to prepare an extensive analysis of every available option. He needs to take a problem he understands technically and try to describe it for someone whose concerns go beyond implementation details.

"I'd give myself about an hour for a first version," he estimates. "And then I'd need to go through it with you to see whether it's even usable. Maybe half an hour?"

"We can try that. We'll pick something I genuinely need to explain further up. You prepare your view, we'll look at it together, and I'll decide what to use. I'll still go to the management meeting on my own. Does that make sense to you?"

Petr nods. It's not exactly what he wanted, but he hasn't just been promised that someone will look at his development someday. They've agreed on concrete work, during working hours, that can help the manager with something he would need to deal with anyway. The limits of the exercise are clear, too. Petr will prepare the technical input and receive feedback; the manager will remain responsible for the final message and for the discussion with management.

When he describes it to Igor later, his disappointment is still a little visible.

"I wanted to see how decisions really get made. For now, I'll be preparing materials for someone who'll go to the meeting instead of me."

"And what did you actually want to learn?" Igor asks. "How to sit in a meeting, or how to prepare information someone can make a decision from?"

"The second one. But of course I'd like to be able to lead that discussion someday, too."

"Then I wouldn't dismiss this first attempt. You'll prepare something for a real decision, and the person responsible for communicating it will tell you what's usable and what's missing. That's already a pretty good opportunity to find out where you stand."

Petr considers that. He could have kept pushing to attend the meetings, but for now he'd only be negotiating for more time without having anything to show. This way, he has a chance to make a first concrete attempt. And if it reveals something important that he's missing, it won't just be a vague feeling that he needs more experience.

When you want to develop in an area that isn't part of your day-to-day responsibilities, asking for a new role or access to every meeting where that work happens may not be the best first step. First, try to identify which specific part of that responsibility you could take on within a limited scope. Ideally, your output should also be useful to the person giving you that opportunity. Petr didn't negotiate a place in the decision-making meeting, but he got a real topic, preparation time and feedback from someone who would use the result.

Of course, you won't always find an opportunity like that. In that case, you can take an older decision and prepare the supporting material retrospectively, or practise a conversation with a simulated non-technical stakeholder, perhaps using AI. That can be useful for an initial exercise. Just be clear about what you're actually testing. A simulation can help you uncover weak arguments or questions you can't answer. It cannot replace a real workplace context, actual relationships, the consequences of a decision or the person responsible for them.

A problem he knows well. And that's why he finally wants to fix it.

The manager eventually chooses a topic Petr has worked on many times. It's an older shared part of the application that evaluates pricing rules, discounts and certain customer exceptions. Its original structure may have made good sense, but over time new products, special commercial terms and other cases that didn't fit the original design were added to it. The result isn't a completely broken component. It's simply a part of the system where changing one thing while being reasonably confident you haven't broken something else is getting harder and harder.

Petr knows the problem well. The rules are intertwined, some changes affect seemingly unrelated calculations, and the automated regression tests don't cover every important combination. Even a relatively small change requires a developer to understand several connected paths first and then spend enough time verifying the result after implementation. When that happens repeatedly, it is no longer just annoying code. It consumes team capacity that could be used for other work.

And right now, the team needs to change this part of the application again. Petr estimates that the current change would take about four developer-days and one additional day of testing. Technically, there's nothing stopping them from continuing as before. But Petr thinks that since they're already touching this part of the system, now might be a good time for limited refactoring: separate the most problematic rules, reduce their coupling and add tests so that similar changes cost less time in the future.

It's exactly the kind of problem he's been describing as technical debt for years. This time, though, he can't settle for saying that they should finally fix it. He has to prepare material for someone who will need to decide whether to make the investment and, potentially, defend its priority to other people.

During mentoring, they briefly return to how he should approach his first attempt.

"If you want to explain why we should invest time in this, what will that person need to know?" Igor asks.

"What the current state costs us. How much the change would cost and what we'd save afterwards. And of course which risks it would reduce, or what new risks it might introduce."

"And what do you have so far?"

"Mainly that the code annoys me," Petr admits.

Igor smiles. "That's a good starting point for your own motivation. But it probably won't be enough to support an investment decision."

"Thanks. That's exactly what I needed to hear."

"Then try to find out which of those costs you can estimate reasonably. You don't need to produce a universal methodology for technical debt right now. We need a first concrete attempt with this particular case."

Petr starts with the change history. He goes through older tickets from roughly the last eight months and finds fifteen more significant changes affecting the problematic part of the application. Using the available data and his own knowledge of how the team works, he estimates that each such change took an average of about three developer-days and another day of testing or regression verification. It's not an exact accounting of every minute the team spent in the code, but it's a more concrete basis than repeatedly claiming that work in this area is unnecessarily expensive.

Looking at the figures together, he's struck by how much time they represent. Fifteen changes at four mandays each amount to roughly sixty mandays over eight months. And that's still just a selection of more significant changes to one part of the application, not the total cost of developing the product.

He then briefly discusses with his colleagues what scale of intervention would make sense. They don't want to rewrite the entire pricing system or turn the project into a long architectural initiative. Their working idea is narrower: the refactoring would occupy two developers for roughly a two-week sprint, with additional time for testing, review and verification. The total estimate comes to approximately 23 mandays. But that work would already include the change the team needs to deliver right now.

Petr writes the numbers 23 and 5 next to each other for a moment. If they implemented the current change without refactoring, the estimate would be five mandays. So it wouldn't make sense to claim that the refactoring adds all 23 mandays. Compared with work the team would have to do anyway, the additional investment would be eighteen.

What remains is to estimate what the change might deliver. Petr and his colleagues assume that once the rules are separated and the tests are added, a similar future change could take about one developer-day and half a day of testing. It's still a working estimate. No one has done the refactoring yet, and they can't know whether every future change will behave the same way. But for the purpose of a decision, they can compare the current state with the expected state after the change.

In the material he prepares, Petr eventually sets out the following inputs. For the calculations, he uses the abbreviation MD for manday:

Beneath that, he adds the calculation that interests him most:

textEffort over the past 8 months:          15 × 4 = 60 MD

Additional refactoring investment:     23 - 5 = 18 MD

At the same change frequency afterward: 15 × 1.5 = 22.5 MD
Expected savings over 8 months:        60 - 22.5 = 37.5 MD
Expected monthly savings:              37.5 / 8 ≈ 4.7 MD

Indicative investment payback:         18 / 4.7 ≈ 3.8 months

Petr feels fairly good about the result. A payback period of around four months for the additional investment seems like a strong argument, especially given how often this part of the application changes. At the same time, he notes that the calculation relies on two important assumptions: future changes will arrive at roughly the same frequency as in the previous eight months, and the estimated savings on each change will actually materialise. If hardly anyone touched the pricing rules for the next six months, or if refactoring didn't make the work as much simpler as the team expects, the payback would look different.

Besides saving time, they also expect a lower regression risk. With better-structured rules and relevant combinations covered by tests, changing one case should be less likely to break another without anyone noticing. Petr doesn't include that benefit in the payback calculation. He doesn't have evidence that would let him assign it a reasonable financial value, and he doesn't want to invent a number just to make his argument look stronger.

When he then prepares a short recommendation for his manager, he realises for the first time how big the difference is between saying "we should finally clean up that code" and explaining what the company might gain from the effort invested. He doesn't need to teach anyone how the pricing rules are implemented. He can show how much capacity the current state appears to consume, how much a limited change would cost, and under which assumptions the additional investment might pay for itself.

In the final section, he writes his recommendation: since the team needs to work in this part of the system again anyway, he believes it makes sense to do the limited refactoring now. That would also address the current change, make future modifications easier and reduce part of the regression risk.

Petr knows these are estimates. This time, though, he can show where they come from. And if his manager challenges them, they can at least discuss concrete assumptions rather than whether technical debt is generally good or bad.

Six weeks until delivery

Before the next management meeting, Petr and his manager set aside the agreed half hour. Petr opens his material and starts explaining where he got the historical frequency of changes, what he included in the refactoring estimate, and why he subtracts the five mandays the planned change would consume anyway. He's also prepared for questions about whether fifteen changes are representative enough and whether a similar change really would drop to one and a half mandays after refactoring.

The manager goes through the numbers. He asks about the origin of some of them, but doesn't challenge most of the argument.

"This is much more useful to me," he says. "I can see roughly what the current state costs us, how you arrived at the additional investment and what we might get back according to the estimate. This is something we can actually discuss."

Petr is pleased. It's not that he expected praise for a table, but he finally feels he doesn't have to argue with his manager about whether the technical problem even exists. The material offers figures they can work from and a clear recommendation. He's about to explain the difference in regression risk as well when the manager stops him.

"But I still have one question. Why should we do it right now?"

Petr hesitates. "Well, because we're going to be changing that part anyway. And if we don't refactor it, we'll keep paying unnecessarily high costs for further changes."

"I understand that. I'm not asking whether this investment ever makes sense. I'm asking whether it's a good idea to make it now, when we have an important delivery in six weeks."

Petr looks at his estimate. Five mandays for the current change, twenty-three for the refactoring option. The difference is eighteen. Of course, that's not a trivial amount of work, but according to the plan, the team should be able to manage both. He doesn't feel he's proposing something that would automatically put the release at risk.

"I looked at that," he replies. "Based on the current estimates, we should still make the deadline even with the refactoring. I'm not saying it'll come for free, but we're not that tight on time."

"If everything goes according to the estimates, maybe," the manager concedes. "But I can't allocate practically all our remaining capacity and assume nothing else will happen over the next six weeks."

Petr has heard something like this many times, usually when someone was explaining why important technical work couldn't fit into the plan. This time, though, the manager doesn't stop at a general demand for contingency. He points out that the plan has to account for known absences, but also for things no one can estimate precisely today. Someone could fall ill, a production issue could appear, one of the current tasks could turn out to be more complex, or the team could hit a blocker that takes several days to resolve. And sometimes another request arrives that the company simply has to prioritise.

"Any of that can happen at any time," Petr objects. "If we postpone every bigger change because of it, we'll never deal with the debt."

"I agree that wouldn't work," the manager replies. "But that doesn't mean we should use up our contingency every time an investment looks economically attractive. I have to consider what happens if something else then goes wrong."

Petr returns to the plan. He still thinks they might be able to fit in the extra eighteen mandays. They work with deadlines like these all the time. More than once, a delivery has slipped by a few days without anything particularly dramatic happening. It was unpleasant, they had to explain the delay, but the project carried on.

"We've worked this close to the limit plenty of times," he says. "And sometimes we've gone a little past the deadline. Usually it wasn't that big a deal."

"That's true," the manager nods. "But those deadlines weren't all the same."

Petr looks up from the document.

"This delivery is tied to an important commitment we've made to one of our major clients," the manager continues. "If we're late, it could mean a considerably bigger problem for the company than with some of the past releases you're comparing it to. I'm not saying your numbers are wrong. And I'm not saying we shouldn't do the refactoring. I just don't want to use up nearly all our contingency ahead of a deadline where a delay could have much more serious consequences."

Petr is quiet for a moment. Just a few minutes earlier, he'd expected them to argue about the effort involved in refactoring or how many future changes would actually come. In his view, he'd already calculated everything important. But the manager hadn't challenged his calculation. He'd added another problem that Petr had barely addressed in his recommendation.

"So you'd rather postpone it?" he asks.

"Maybe. But I don't want to reach a conclusion right now just because we're talking about refactoring. I need to assess how much of our contingency we can afford to use before this delivery and what we're risking if we don't have it. Your material helps me understand the cost of the technical investment. That's important. It's just one part of the decision."

Petr is about to make another argument about future savings. Then he realises he'd only be repeating something the manager has just acknowledged. He could probably refine the 3.8-month estimate into a slightly different number, but that still wouldn't answer why it makes sense to expose this particular deadline to more risk.

Only now does he realise that they've been talking about slightly different decisions all along. Petr was trying to show that limited refactoring could be an economically worthwhile investment. The manager needed to decide whether the team should undertake it in the coming weeks while also meeting an important commitment. The questions are related, but a positive answer to the first doesn't automatically settle the second.

If you were in Petr's place, wouldn't it be a shame to throw away his calculation just because the manager didn't accept the recommendation to refactor immediately? Petr found out something useful: he managed to translate a long-standing technical problem into an approximate consumption of capacity, separate the work that was already necessary from the additional investment, and build an economic argument the other side could work with. That has value in itself.

At the same time, notice what his material couldn't establish. A payback estimate says something about the assumptions under which an investment might be worthwhile. It doesn't automatically tell you when to make it. When a decision involves two legitimate needs, describing one of them well isn't enough. You also need to understand the constraints and consequences of the other. That's where the difference may lie between a technically sound argument and material that can support a specific decision.

What Petr had actually prepared

After the meeting, Petr returns to his material. At first glance, he can't find any mistake in it. The fifteen changes over eight months match what he found in older tickets. The effort estimates are grounded in the team's work. He correctly subtracted the current change from the total investment and didn't pretend to be certain about future savings. He even mentioned regression risk separately without inventing a financial value for it.

And yet he doesn't leave the conversation feeling that the work is finished. The longer he looks at the document, the more clearly he sees how much his own experience with this troublesome part of the code influenced the way he prepared it. He knew exactly why he wanted the refactoring. For years he'd watched simple changes grow complicated and seen how much attention their testing required. When he finally had the opportunity to prepare an argument for management, he focused on demonstrating that cost as convincingly as possible.

To some extent, he succeeded. The manager didn't reject the figures, appreciated their usefulness and could see why Petr recommended the investment. But Petr had attached one more conclusion to his recommendation, a conclusion that didn't follow from those figures as directly as he'd thought: if the investment was sensible and, on current estimates, fitted into the plan, then it should be done right now.

He opens the section on payback and rereads his assumptions. The future frequency of changes, the expected effort after refactoring, the eighteen additional mandays. All of that is information about the investment itself. But there's almost nothing about the importance of the upcoming client delivery. Nor does the material explore what it would mean for the plan if an estimate proved wrong, or how much contingency the team could afford to consume in this situation.

This doesn't mean he should automatically agree with the manager. Perhaps the limited refactoring really could be completed safely before delivery. Perhaps waiting would make more sense. And perhaps there's a smaller option that would solve part of the problem with less impact on available capacity. Petr doesn't yet have enough information to defend any of those conclusions. But when preparing his recommendation, he acted as though he did.

At the beginning, he wanted to get closer to decision-making because he felt people outside development didn't understand technical problems well enough. Now he's had his first chance to prepare material for one of those people and found that the gap may also be on his side. Not because he couldn't calculate an approximate cost of technical debt. And not because he couldn't propose a sensible investment. He was missing part of the context that determined whether it was right to make that investment now.

Petr writes down what went well in his first attempt and, beside it, the questions he couldn't answer. He also keeps the original material. He doesn't want to rewrite it afterwards to make it look better than it really was. The difference between his recommendation and his manager's response shows him something he could easily have overlooked while studying communication in general.

Then he pauses once more at the last sentence of his recommendation. He wrote that it made sense to refactor now. He can explain why refactoring might make sense. But that word, now, is more complicated.

And if his next piece of decision-support material is going to genuinely help someone decide, he'll need to work out what else he must know before writing it again.