Petr's Journey Towards Architectural Responsibility

Petr was considering a move into software architecture because he wanted more influence over long-term technical decisions, especially those involving technical debt. But as he explored the role, he realized that influence doesn't necessarily mean having the final say. It can come from being able to explain the costs, risks, and consequences of different technical options to the people making those decisions.

He also realized that a role like this could involve significantly less hands-on coding. That made him question whether what he enjoys most is writing code or solving complex problems. He could still solve complex problems in a different kind of role.

For now, he's keeping software architecture as a possible direction. Before planning his path into a new role, he needs to find out what the day-to-day work would actually look like and whether it's what he really wants.

Petr and his mentor reviewed several capabilities important to his idea of the architect role. When it came to handling technical trade-offs, he estimated his current level at around 2 out of 5, while the working target was 4 out of 5. The difference showed room for development, but by itself did not explain what Petr actually needed to do differently.

For example, Petr could recognize technical debt. But when his mentor presented a situation where a cleaner solution would take six weeks while the company needed a result in three, Petr focused mainly on the technical drawbacks of the faster option. For the person making the decision, however, knowing that technical debt will arise is not enough. They need to understand the available options, their benefits, constraints, and the specific risks they would accept by choosing one.

This revealed what Petr's development gap actually was. It wasn't simply about "getting better at trade-offs", but about being able to prepare a decision so that the benefits and accepted risks of each option were clear. The gap had existed before the rating, but describing it precisely showed what Petr could actually work on.

It doesn't make sense to tackle every important development area at once. Petr therefore compared his five development goals based on expected value, required effort and current urgency. The numbers were meant to make his assumptions clearer, not make the decision for him.

Evaluating technical alternatives, their trade-offs and the risks he would accept scored just as highly as explaining the business impact of technical decisions (both 1.00). The first was almost an entirely new practical capability for him; the second represented an even larger development gap, but he also expected it to require more effort.

Rather than look for an artificial difference in the numbers, Petr chose to focus on trade-offs first. He deliberately left the other area for later.

That's the point of prioritization. Not to produce a perfectly precise ranking, but to decide where to direct limited capacity now. "Later" doesn't mean "unimportant", and the decision can be revisited when circumstances change.

Petr chose working with alternatives, trade-offs and accepted risks as his first development priority. But "getting better at handling trade-offs" isn't a task he could simply start doing.

Together with his mentor, he broke the goal down into smaller capabilities and focused on one specific area: being able to identify the risk being accepted and explain its impact. But even that needed to become something he could actually do.

His first task was to take one familiar technical decision, look back and compare at least two possible options, and describe the benefits, costs, constraints, specific risks and their impacts for each.

At that point, he didn't need to keep breaking down the entire development goal. He knew where to start, what to produce, and what he could check through his first attempt. The result didn't have to be good on the first try. The point of that first attempt was to reveal what he needed to improve or break down further.

That gave him a usable roadmap: his current development focus, a concrete next step and other goals left for later. Petr briefly revisited it each morning and checked once a week whether his priorities still matched the current situation.

When an upcoming client meeting came up, Petr shifted his attention to a different area: explaining the business value and impact of a technical solution. He had previously put that goal aside for later, but a specific near-term need made it more urgent. His original work on trade-offs hadn't lost its importance; only what made sense to focus on right now had changed.

After the meeting, the temporary urgency was gone and both goals once again had the same priority score. But during his weekly review, Petr decided to keep focusing on explaining business impact. He enjoyed that area and wanted to keep working on it. He didn't need to invent a new number or an artificial difference between equally rated goals. Priority scores helped him compare his options, but they didn't make the decision for him.

The point of a roadmap, then, isn't to plan your entire development in advance or set a fixed order of tasks. It's to give you a next step concrete enough to start with, while leaving you room to consciously change your current focus when circumstances change or you decide differently.

Petr wanted to get better at explaining the business impact of technical decisions, so he asked his manager to let him attend leadership meetings. His manager declined. They agreed on a smaller step instead: Petr would have about an hour to prepare material for a real technical decision, then they would spend half an hour reviewing it together. His manager would remain responsible for deciding what to use from the material and what to present to leadership.

Petr didn't gain access to leadership meetings or get a new role. He did get a chance to practise a specific skill on a real task, with real context and the possibility of feedback. His manager, meanwhile, could get useful input for his own work rather than simply spending time on Petr's development.

When looking for development opportunities, the main question doesn't have to be how to take on an entirely new responsibility. It often makes more sense to find out which part of that kind of work you could get involved in today. If such an opportunity isn't available, you can start with a simulation, but it can't replace real workplace constraints or the consequences of actual decisions.

Petr prepared for his first attempt as well as he could at the time. He knew that saying the old code was difficult to maintain wouldn't be enough to justify refactoring. So he reviewed the history of changes, calculated how much work they had taken, estimated potential savings, and prepared a recommendation explaining why the refactoring should happen now.

His manager didn't question the calculations. He did, however, point out something Petr hadn't accounted for. The team had an important commitment to a major client due in six weeks, and the refactoring could use up the capacity buffer they might need if complications arose. Petr had therefore prepared a reasonable recommendation, but without a piece of information that could fundamentally change the decision.

That's where the value of a first attempt in real work lies. You can study the theory, prepare carefully, and do the best you can with what you currently know. Yet it may take a real situation to reveal what you still haven't considered. Petr's analysis wasn't necessarily wrong. Practice showed him where it was incomplete.

After his first recommendation, Petr assumed he couldn't have known about an important commitment to a client because he didn't attend management meetings. But his mentor asked: "How do you know you couldn't have found that out?" Petr realized he hadn't even asked how important the deadline was or what missing it would mean. He had mistaken information he didn't have for information he couldn't obtain.

You don't need access to everything management knows to prepare a good technical recommendation. But you do need to actively look for context that could change the weight of your technical arguments. Some of it may come up in everyday company communication; for other things, you can ask your manager. And if you still can't get an important piece of information, you should flag it as an uncertainty in your recommendation rather than assume there is no further context.

Petr therefore isn't changing his development goal, only the specific next step on his roadmap: before his next recommendation, actively seek out the decision context and flag important information he's missing. The feedback doesn't stop at a realization; it is reflected in a concrete step Petr has planned for his next attempt.

Technical decision-making doesn't start only when implementation options are being compared. Important information can come up as early as the initial briefing, and some of it needs to be actively sought out.

When a new bulk-import feature was introduced, Petr also paid attention to customer needs, expected volume and potential future expansion. Later, while comparing the existing background-job processing with a new event-driven solution, he realized he didn't know whether rolling the feature out to more customers was a concrete plan or still just a possibility.

Rather than fill that gap with his own assumption, he asked his manager. Only after clarifying this did he prepare his technical recommendation.

So the difference from his first attempt wasn't just in the quality of the document he produced. Petr started actively paying attention to relevant context from the moment the work was introduced and sought out missing information before a decision was made. This change in his approach shows that he had put the lesson from his earlier experience into practice.

Petr's development plan was based on a reasonable understanding of his target role. But new information from his company showed that part of this understanding needed refining.

Petr's manager brought back new information from a discussion with company leadership. A possible architecture role at the company could also involve technical collaboration with customers. Petr might therefore need to understand the relevant parts of someone else's system without access to its source code or the opportunity to study every detail. What would matter is quickly identifying key relationships and constraints, separating facts from assumptions, and finding out what information is still missing before a joint decision can be made.

Petr knows his own product well, but that isn't the same as building a sufficiently useful working model of an unfamiliar environment. His original understanding of the target role wasn't wrong; it simply hadn't captured this particular need precisely enough.

This also changed how he viewed one of his development gaps. Systems thinking in an unfamiliar environment became more urgent, and its indicative priority score increased from 0.33 to 0.83. That doesn't automatically make it his highest priority, but it is a reason to reconsider his roadmap.

One possible next step would be to prepare a simple model of the relevant systems, their relationships, constraints and open questions before a suitable technical discussion with a customer, then refine it afterward.

The important point is that a development plan doesn't have to be wrong to need changing. If new information changes one of its important assumptions, the decisions based on that assumption need to be reconsidered too.

In Petr's case, the change reached all the way back to his original understanding of the target role, affecting the development gap, its priority and his next steps. He doesn't have to start from scratch or rewrite the entire plan. Because the individual parts of his roadmap are connected, he can adjust precisely those conclusions affected by the new information.