Petr thought he didn't have access to the information. Then he realized he hadn't asked.

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

The information he didn't have

After talking with his manager, Petr kept his original analysis open for a long time. For the first time, he'd had an opportunity to prepare a technical recommendation for a real decision, even though he wasn't yet responsible for making the final call. It concerned limited refactoring of interconnected pricing, discount and customer-specific rules. He had reviewed the change history, estimated the effort with his colleagues and calculated that, compared with simply completing the current task, the refactoring would require about eighteen additional person-days. If changes continued at the same frequency and the other assumptions held, the indicative payback period was just under four months.

His manager hadn't rejected the numbers. On the contrary, he'd said that the analysis was something they could work with. But then he'd asked why the company should make the investment right now, with an important delivery due in six weeks. Petr replied that, according to the estimates, both should fit into the schedule. His manager reminded him that a plan couldn't consume almost all available capacity and rely on nothing going wrong before delivery. What was more, the deadline was tied to a significant commitment to an important client, not just another date on the project plan.

Petr left with an uncomfortable realization. He had made a case for why refactoring could pay off in the long run, but he'd prepared it as an answer to whether the technical investment was worthwhile at all. His manager needed to decide whether the team should do it in the coming weeks, and what risk that would involve. Those weren't the same question. And no final decision about the refactoring had been made yet.

At their next mentoring session, Petr tells Igor what he took away from the conversation. This time he isn't trying to defend his calculation all over again. He knows he'd added up the planned work without giving enough attention to uncertainty in the estimates, possible production issues, absences or other unexpected demands. He has also realized that different deadlines don't necessarily carry the same consequences just because the company missed some dates in the past and the project carried on.

"I was able to work that part out afterward," he says. "My capacity estimate wasn't complete nonsense. I just treated the fact that the work fit on paper as almost a guarantee. And I treated that deadline like all the others."

"And what still doesn't sit right with you?" Igor asks.

"The commitment to the client. That was probably the most important information in the whole conversation, but I didn't have it beforehand. I wasn't in those management meetings, and I wouldn't find anything like that in commit history or tasks. How am I supposed to prepare a good recommendation when I don't have access to the context people use to make the decision?"

Igor lets the question hang for a moment. Petr expects advice on how to get into more management meetings, or perhaps how to deal with these limitations as a developer. Instead, he gets another question.

"How do you know you couldn't get that information?"

"Because I don't attend those meetings," Petr replies, a little irritated now.

"That explains why you didn't hear it there. But before preparing the recommendation, did you try asking how important the deadline was? Or what would happen if you missed it?"

Petr draws breath, but has no answer. He went through the numbers, the change history and the technical risks. He prepared for someone to challenge his effort estimate or the likely frequency of future changes. What never occurred to him was to check whether circumstances missing from the technical brief could change the entire recommendation.

"No," he finally admits. "I didn't ask. I assumed that if there was something that important, my manager would tell me himself."

"Maybe he would have, if you'd explained what you needed the information for," Igor replies. "And maybe he wouldn't have been able to tell you everything. But those are two different situations. One is not having a piece of information. The other is not being able to obtain it. You haven't even checked the first possibility yet."

Petr thinks about how he usually works. When a new feature, a customer or a broader product plan is being discussed, he mainly focuses on what the team will need to implement. He treats the business reason, the customer's expectations or the connection to other commitments more as an introduction, taking from it only what he needs for the technical design. Sometimes that's enough. But if he wants to prepare recommendations for people who also make decisions about priorities, budgets and risk, he can't decide in advance that all of this is merely irrelevant context surrounding the real work.

"So should I start attending product meetings and reading everything the company sends out?" he asks.

"That would be a good way to fill your calendar and still not know what you need," Igor replies. "It's not about knowing everything management is dealing with. It's about knowing what decision you're preparing the analysis for, and what could change the weight of your arguments. Sometimes you'll hear that context when the roadmap is presented, sometimes in ordinary communication. And sometimes you simply ask your manager. For example, what the deadline means to the company and what commitment is behind it."

"And if he won't tell me?"

"Then at least you know you don't have that information, and you can say so in the recommendation. That's still better than making a decision based on an assumption you haven't even noticed you're making."

Petr thinks back to his original analysis. Nowhere did he explicitly claim that an important client commitment didn't exist. He simply left it out of the calculation and the conclusion. In effect, he had assumed its absence without saying so. Now he can see that his problem isn't only how accurately he translates technical effort into person-days and risks. He also needs to establish which information matters to the decision being made right now, and which of it he is missing.

When you're preparing a technical recommendation without the full business or product context, that doesn't automatically mean you need access to every management meeting. Start with the decision itself. What needs to be decided, why now, what deadline or commitment affects it, and what happens if an assumption doesn't hold? You may already have some of the answers, you can ask for others, and some really won't be available. Those last ones, though, can be marked as uncertainties in your analysis. There's a difference between "I don't know this" and "I didn't even realize I needed to know this."

Not a new goal. A different next step.

Petr feels like opening his entire development roadmap and rewriting it. After all, he's just discovered that he looked at a technical decision from an incomplete angle. But then he returns to his current focus. He's still working on explaining the business value and impact of technical solutions. He deliberately chose this development goal some time ago, and after one urgent client meeting had passed, he decided to stick with it even though its working Priority had dropped back to 1.00, tying it with trade-offs again.

"So should I reconsider my priorities?" he asks.

"Has anything changed about which capability you want to develop right now?" Igor asks in return.

"No. I've mostly discovered what I'm still doing wrong within it."

"Then why change the goal? Try telling me what, specifically, you'll do differently next time."

Petr searches for the right words. Writing "understand the business better" would be easy, but it wouldn't help him prepare his next recommendation. He needs a step he can either take or not take in real work, not another general aspiration. Eventually he returns to the exact situation from the first attempt: he had the technical facts, but before finishing his argument he hadn't established what decision he was using them for, or what context he lacked.

Under his existing focus, he adds this to the roadmap:

textNOW
Explaining the business value
and impact of a technical solution
Priority: 1.00

NEXT STEP
[ ] Before my next recommendation, actively find out the decision context
    and identify important information I'm missing.

That doesn't mean sending a questionnaire to every stakeholder on every task. Before his next recommendation, he should clarify who is deciding what, what the intended outcome is, what constraints and consequences could change the decision, and whether any of those things are merely assumptions he hasn't checked. The technical comparison of options, costs and risks doesn't become irrelevant. It simply should no longer be the first and only source of his answer.

Petr reads the new line once more. This time he didn't need a new formula, a new priority table or another broad capability to study. His first attempt had left him with a more specific question, and with Igor's help he'd turned it into one task he could try at the next suitable opportunity. He doesn't yet know whether that will actually change how he works. You can't establish that in a mentoring session by looking at a well-written note.

Six weeks and another technical decision

About six weeks later, the team moves on to the next part of the product roadmap. The earlier deadline is behind them, but that tells us nothing about the refactoring decision or how the delivery went. Petr is facing a different problem at work. On the morning of a meeting where the next planned feature will be presented, he briefly opens his roadmap as usual. Under his current focus, he sees the new task too: find out the decision context before making a recommendation, and acknowledge important unknowns.

He doesn't yet know whether the meeting will lead to anything for which he'll prepare a technical analysis. But he decides to try one thing differently. When the discussion turns to customers and the product, he won't wait only for the part where someone starts describing the implementation. He'll listen to why the feature is being built in the first place.

The team is introduced to a bulk import feature for pricing and discount rules. One important customer needs to upload a larger set of its own rules at once instead of entering them manually. Only a few larger imports per day are expected for the first version. The customer doesn't need immediate processing, but it does need to know whether an import completed correctly, be able to track its status and recover sensibly from errors. Other customers might use a similar feature later, but it's not yet clear to what extent or when.

This time, Petr doesn't just note that an import needs to be implemented. He also writes down who the first version is for, what volume is currently expected and what a good outcome means to the customer. When the technical options come up later, he has something to return to.

The import itself should be processed asynchronously. The team has two reasonable options. It could use the background job mechanism already employed elsewhere in the application. The team knows it and knows how to operate it; it can track processing status and handle retries and error recovery. Based on the current assumptions, it should handle the expected volume without major new infrastructure requirements. The other option is a more general event-driven solution. That would provide a better foundation if the import eventually became a much larger integration mechanism. But it would introduce new infrastructure, additional implementation work and operational complexity now, when that volume hasn't been confirmed.

As before, Petr is supposed to prepare a recommendation for his manager. His first instinct is to start comparing the technical characteristics of the two options. He does, of course, need to do that. But this time he notices one missing piece of information in the brief, without which a technically correct comparison could lead to the wrong conclusion: Is expansion to other customers a real commitment in the near future, or only a possibility for now?

He puts together the main differences he can currently support:

The table alone isn't enough. If the company has a concrete plan for a broader rollout, higher initial costs might be well justified. If it's only a hypothetical future, the team could be paying for complexity it doesn't need now. Petr doesn't want to make another recommendation by silently replacing missing information with his own assumptions.

So he asks his manager whether additional customers and significantly higher volume are already part of an actual plan, or whether this is just one possible direction. This time, he gets an answer before finishing his analysis. Broader use is a real possibility, but the company doesn't currently have a confirmed rollout or volume that would require it to build the first version as a high-capacity integration platform.

That doesn't give Petr a ready-made technical solution. Nor does he learn the exact volume of future imports. But he gains an important distinction between a present commitment and a possible future. He can now explain why certain technical properties and costs deserve different weight in the current decision than they would if a larger rollout had already been confirmed.

A recommendation that allows for change

Petr returns to his analysis and adds the context of the first version to the comparison. He doesn't leave out the technical arguments. He still needs to consider operational reliability, error recovery, implementation effort, future scaling and the cost of a possible change. But he no longer assesses all these properties as though they carried the same weight in every company and at every moment.

In his recommendation to the manager, he writes that the existing background job mechanism makes sense for the first version. With only a few imports expected each day, it should be sufficient; the team has experience with it and doesn't need to add new infrastructure for this feature. For the current customer, being able to track imports, retry safely and recover from errors matters more than preparing for high volumes that haven't been confirmed.

He doesn't reject the event-driven option as technically wrong. He recognizes its advantages for more integrations and substantially greater load. But for today's requirements it would mean more work and complexity in anticipation of something that isn't yet a concrete plan. Petr also spells out the cost of his recommendation: if the volume or breadth of use grows significantly, part of the processing may need to change and the company will pay for some work again. That's why he suggests separating the processing itself from the rest of the feature, so that a possible future change isn't unnecessarily coupled to the entire import.

When he hands the analysis to his manager, he doesn't just explain which technology came out ahead. He explains under which current assumptions the recommendation holds, and what would need to start looking different for it to deserve another review. He doesn't have a universally best architecture. He has a recommendation for a specific situation, including the risk he's willing to propose accepting with the simpler solution.

His manager reads through it and responds differently than he did during the refactoring discussion.

"This analysis is something I can use," he says. "It's clear why you're recommending the simpler option for the first version, what we'd be adding with the more complex one, and what risk we're leaving for the future. And you're not just arguing that event-driven would be more technically interesting."

Petr realizes that this time his manager doesn't first have to ask what decision the analysis is supposed to support. It starts from the first customer's needs and what has actually been confirmed about possible expansion. That doesn't, of course, mean his recommendation has to be accepted without reservations.

"There's one thing I'd still add," his manager continues. "Can we be more specific about when we should reopen this decision? At a certain number of customers, a certain import volume, or maybe when another type of integration comes along?"

Petr looks at the final paragraph. He wrote that he'd revisit the choice if volume became significantly higher or use became broader. But he hasn't backed the word "significantly" with anything concrete. He doesn't want to make up a threshold on the spot that sounds precise but has no basis in verified requirements or operational data.

"I don't know exactly yet," he admits. "I know which changes would matter. But I don't have enough information to set a specific trigger."

His manager nods. The question remains open. His reaction doesn't tell us which option the company will eventually implement, how it will work, or whether it will ever expand to other customers. Petr has, however, received feedback on something he actually prepared, along with another question his current analysis doesn't yet answer.

When you choose a technical option that makes sense for today's situation, it doesn't mean it must remain the right choice under every circumstance. Sometimes accepting the risk of a future change is more sensible than paying today for complexity you don't yet need. What matters is naming that trade-off and not pretending you know the future precisely. And if you say "we'll revisit this when conditions change," it's worth asking what change you'll actually be watching for. Petr doesn't have that threshold yet. But that gives him a useful next question, not a reason to pretend the second attempt was pointless.

What actually changed on the second attempt

When Petr compares the two analyses, the difference isn't simply that he was dealing with two different technical problems. In the refactoring case, he started from the change history, built an economic argument and only learned in the conversation with his manager that the decision depended on important delivery and client context. Six weeks later, he reminded himself of the new roadmap step before the product meeting, picked up on what mattered for the first version and spotted another gap while preparing the recommendation. This time he actively asked about the possible rollout before reaching a conclusion.

In both cases, he relied on technical reasoning. The first time, he could make a rough calculation of the investment and its possible payback, but didn't give enough attention to the circumstances of the decision. The second time, he compared two viable technical options, their costs, operational implications and accepted risks, and added verified current context. He didn't skip the technical work. He changed the order of the questions he asked and how he handled information he didn't yet have.

For now, the second attempt shows a concrete change in Petr's behavior, not proof of a new level of ability. His manager called one analysis usable, but that didn't mean Petr was now a fully fledged architect, nor did it confirm that the chosen technology was right or what its future outcome would be. He asked another question Petr can't yet answer. The change in his approach can be compared. Whether that approach will help him in the long run, and what the company will actually do, remain unknown.

At the start of this part of his journey, Petr expected that he needed better access to decision-making. After his first attempt, he discovered that sometimes he needed to do something much simpler: recognize what to ask, and not be afraid to flag an important uncertainty in his analysis. That insight went from mentoring into his roadmap, and from the roadmap into another real situation at work. The manager's new response also showed that learning needn't end there. One more precise question can lead to another.

Until now, Petr has mostly returned to how to change his next step. All the while, he's been working from the model of architectural responsibility that he and Igor developed at the beginning. That model has remained unchanged so far. But what if new information from the environment where he hopes to take on that responsibility one day changes his original idea of the goal itself? Then revising one task in the roadmap won't be enough.