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.
Meet Petr
Technical debt has been piling up on Petr's project for some time. It isn't one major disaster that everyone can point to because of a particular incident. It's more a collection of smaller decisions that have made part of the application increasingly difficult to change. The developers have raised the issue repeatedly, but Petr feels management isn't giving it as much attention as it deserves. Some of his colleagues have almost given up trying. Petr hasn't, at least not yet, although he's getting tired of being able to describe the problem quite precisely while having very little influence over what the company actually does about it.
And he's certainly not an inexperienced developer encountering a complicated project for the first time. He has around eight years of professional experience across two companies, including almost five years with his current employer. During that time, he's worked in several teams, contributed to two larger products and got to know quite a few people outside his immediate team. Colleagues come to him to discuss technical problems, and he tends to get larger tasks that require understanding several parts of the system at once. He's occasionally invited to product discussions as well, because he can explain what the existing technical solution allows and where its limitations are.
He still enjoys programming. It's just that programming stopped being the main part of his working day a long time ago. If he wants several uninterrupted hours to implement something, he has to deliberately make time for it. Otherwise, his day easily disappears into consultations with colleagues, meetings and problems where other people need his knowledge of the system.
Petr is beginning to wonder whether it's time to move somewhere further in his career. He's attracted by greater technical responsibility, the opportunity to influence the system's long-term direction and perhaps a little more weight behind his arguments when decisions are made about things like technical debt. Software architecture comes to mind. If he were an architect, maybe he wouldn't have to keep watching problems emerge that he'd warned people about in advance.
But that last part is still mostly his own assumption. Petr doesn't actually know what decision-making authority an architect would have in his company. He doesn't even know whether such a role would really help him address the problems that bother him today. And there's one important question he's barely considered so far: what would change about his own work if he actually became an architect?
First, figure out where he actually wants to go
Petr realizes he wants to continue growing professionally, but he's not sure which direction to take from his current position as a senior developer. He therefore decides to discuss his options with a mentor. During his first sessions with Igor, they explore several possible career directions. Architecture emerges as something Petr finds interesting enough to investigate properly. Not as a final decision about the rest of his career, but as a working hypothesis.
Igor doesn't start putting together a list of technologies Petr should learn or courses he should take. Instead, he gives him homework: develop his own working understanding of what a software architect does. What does that person do during an ordinary week? What are they responsible for? What capabilities do they need? How is their work different from that of a senior developer? And what aspects of the role are still unclear to Petr?
Petr should look wherever he can find information that helps him form a reasonable picture. He can read job advertisements and articles, watch talks, discuss the topic with AI or speak to someone who already does the job. For the important things he discovers, he should note where the information came from. Not because he's expected to submit an academic research paper, but so that during their discussion they can distinguish between a particular person's experience, a claim from a job advertisement and Petr's own assumptions.
Meanwhile, Igor independently prepares his own model of the same role. Petr won't see it in advance. At their next session, the point won't be for Petr to reproduce the mentor's list correctly. They'll compare two different perspectives. If those perspectives differ, they'll have something worth discussing.
Twelve points and a few unpleasant surprises
Petr takes the assignment quite seriously. He goes through job advertisements for architecture positions, reads articles about the differences between senior developers and architects, watches a talk, discusses the topic with AI and speaks to a former colleague who now works as a software architect. Gradually, he puts together twelve areas that seem important to him.
Some parts of the list fit him almost perfectly. An architect should understand the system as a whole, design larger changes before implementation begins, know their way around technologies and integrations, and consider long-term maintainability. That's exactly the kind of work Petr finds attractive. Even today, what he enjoys most about larger tasks is the moment when he has to untangle the relationships between several components and find a solution that makes sense as a whole.
Things get more interesting when he starts putting question marks next to some of the points. An architect should influence technology choices and technical direction. But does "having influence" also mean "having the authority to decide"? Three different job advertisements suggest three different scopes of responsibility. And if an architect is supposed to take care of security, why does the company have a security expert? Is an architect really expected to understand absolutely everything in depth?
Then there's communication. His former colleague explains that when he moved into architecture, what surprised him wasn't so much the increased technical complexity as the amount of time he spent aligning people and teams. An architect has to explain decisions, defend compromises, listen to objections and sometimes convince people who aren't concerned with implementation details at all. Petr remembers his current working days, when consultations make it almost impossible to get back to his code. If architecture involves even more of that, the change might not be nearly as attractive as he originally imagined.
The question that bothers him most is how much an architect actually programs. Some sources describe a role with almost no regular implementation work. His former colleague occasionally builds a prototype or verifies an idea technically himself. Petr would like to stay close to code. He wouldn't mind programming less than he does today, but he doesn't particularly like the idea of reaching a point where he practically never builds anything with his own hands.
The last surprise is rather less glamorous. His list also includes documenting architectural decisions, their reasoning and the context behind them. According to his former colleague, it's one of the things architects do more frequently. Petr's first note is brief: "Ugh."
Still, he doesn't remove it from the list. He actually understands why it should be possible to find out, six months later, why the team made a particular decision. He's just not excited about the prospect of spending most of his time writing documentation instead of code.
So he arrives at the next mentoring session with a fairly good list. And considerably more doubts than he had before doing the homework.
Two models on the same table
Petr shows Igor his work first. Only then does Igor open the model he prepared independently. At first glance, the comparison is encouraging: both consider a system-wide perspective, architectural design, technical debt, long-term maintainability, communication and compromises between alternatives to be important parts of the role.
"So I wasn't completely off the mark, then," Petr remarks.
"No. But the goal wasn't to match my list either. What's more interesting is where the two lists differ."
And that's where the conversation becomes considerably less comfortable for Petr. Igor's model places greater emphasis on defending technical opinions, making decisions under uncertainty, working through other people, facilitating discussions and translating between the technical and business worlds. In his view, an architect doesn't necessarily have to be the best programmer in the room. It's often more important to bring relevant perspectives together and help other people make informed decisions.
Petr returns to a concern that kept appearing more and more often in his notes. "So even more communication and even less programming? People already come to me almost all day. If that's going to become even more intense, then maybe architecture isn't actually what I'm looking for."
Igor doesn't try to reassure him by pointing out that architects sometimes write code too. "Yeah. That's quite likely. I wouldn't even say 'maybe'. If you go in this direction, it's very realistic that you'll spend less time programming and more time communicating."
That's not exactly what Petr wanted to hear. He'd been thinking about having more influence over technical decisions, not a career in which he'd exchange his last uninterrupted coding hours for another calendar full of meetings. But Igor doesn't conclude that Petr is heading in the wrong direction. Instead, he asks him something else: "What exactly do you enjoy about programming?"
Petr thinks for a moment. "When I get some complicated problem and have to untangle it. Figure out how to make the whole thing work. And then see that it actually works."
"And writing the code itself? The syntax, implementing it line by line? Is that the part you don't want to lose?"
"Not entirely, I guess. But I like getting into that state where I'm completely immersed in something and actually building it for several hours."
Suddenly, it becomes clear that the sentence "I want to keep programming" means several different things. Petr enjoys solving complicated problems, designing solutions, focused work and having a tangible result to show for his effort. And yes, programming too. But it isn't at all obvious that he'd lose all those other things if he spent less time writing code. Some of them might also be part of architectural work. Others might turn out to be more important to him than he currently realizes.
So Igor doesn't close off either option. If Petr discovers that everyday implementation is genuinely irreplaceable for him, it might make sense to explore a different senior technical role, perhaps some form of tech lead. But if what fulfills him most is untangling problems and designing solutions, architecture could still be worth pursuing. They can't decide that now. Petr therefore keeps it as his working career target, but he now knows he needs to examine his expectations much more carefully.
This is where I'd stop you for a moment as well. When you say there's something you enjoy about your current work and don't want to lose as you move forward in your career, what exactly do you mean? The activity itself, or something that activity allows you to experience? With programming, it might be writing code, concentrating deeply, solving problems, designing solutions or seeing a tangible result. Those needs are related, but they're not the same.
When you compare other career roles, try looking at their ordinary working week rather than their titles. What would you probably do more of, what would you do less of, and what would you have to give up? No universal list of competencies can answer that for you. What matters is the difference between your idea of a role and what that role would actually look like for you.
If we have a security expert, why does the architect need to deal with it?
Petr's list raises another question that seems perfectly reasonable at first. He gets stuck on security. "But we have a security expert in our company. So why is the architect supposed to handle that? I definitely don't want to become a security expert."
Instead of introducing another list of required knowledge, Igor distinguishes between two things: who is supposed to perform the specialist work and who, within the scope of their role, is accountable for making sure that area is properly addressed in the resulting architecture. A security specialist can perform an analysis, propose measures or identify specific threats. An architect doesn't have to become a security expert, but if they're accountable for the resulting architecture, they can't overlook an area that's essential to the whole design.
"You don't have to do the security expert's job," Igor explains. "But if you're accountable for the resulting architecture, you need to recognize that security has to be addressed, know whom to involve, understand enough of what they're telling you, and make sure their input actually makes it into the design."
Petr realizes that he'd been imagining an architect as someone who personally had to know more about every important technical area than anybody else. But that would be a fairly absurd requirement. When designing a larger system, individual parts may be understood much more deeply by the people who specialize in them. An architect needs to recognize when that expertise is required, understand its implications and make sure it isn't lost when decisions about the overall system are made.
This applies to security, but depending on the particular system, it can also apply to operations, databases, infrastructure or other specializations. Petr adds an important distinction to his understanding of the role. That doesn't mean, however, that everyone with the title of architect automatically has the same accountability. Where exactly the boundary lies is something he'll have to verify later for a specific role and employer.
"Good enough". Two words Petr isn't particularly fond of
When the comparison reaches the topic of choosing between alternatives, Petr encounters the term "good enough". Igor uses it to mean a conscious compromise. But Petr immediately remembers his experiences on the current project.
"I'm a bit allergic to 'good enough'. In our company, it often means we'll do it quickly, add some more crap to the system and fix it sometime later. And that 'sometime' never comes."
This is where the conversation returns to the very reason Petr started considering architecture in the first place. He wants long-term technical problems to carry more weight in decision-making. Igor doesn't dismiss his frustration. He simply distinguishes a badly understood compromise from one that can be made consciously.
"Good enough doesn't mean you're unaware of the problem. Quite the opposite. As an architect, you should be able to say: We can deliver this option faster, but by doing so we're accepting these specific risks."
Petr can easily say that the faster option will create technical debt. But what exactly will that debt cause? Which future change will become more expensive? What could go wrong, and what would the impact be? Which risks are acceptable because of the current deadline, and which should no longer be acceptable? Those aren't purely technical questions. Some consequences need to be decided by the person responsible for the product, the deadline or a commercial commitment.
"You don't have to decide that the company should accept the risk," Igor tells him. "But you do have to make sure that the person making that decision actually understands what they're accepting."
Petr realizes that greater technical influence might not come only from receiving a title and the authority to tell other people what to do. Sometimes it comes from being able to translate a technical problem into specific consequences that the company can actually use to make decisions. If someone consciously accepts a risk in pursuit of another objective, that doesn't necessarily mean they failed to understand the technical arguments. And if Petr can't describe the cost of a compromise in any terms other than "technical debt", perhaps part of the essential argument is still missing.
It isn't an entirely comfortable realization. He came in thinking that an architectural role would finally give him more influence over the decisions that frustrate him today. Now he's discovering that he might be able to start doing some of the work needed to build that influence while he's still a senior developer. And that even as an architect, he might not have the final say over which business risks the company accepts.
Imagine a situation where you're convinced your company is overlooking a technical problem. What would someone need to know about it if they make decisions based not on architectural purity, but on deadlines, costs, customer commitments and accepted risk? And do you even know who has the authority to make that decision?
The point isn't to abandon your technical opinion or automatically assume management is right. But it's equally insufficient to assume the other side doesn't understand the problem. Try separating the technical argument itself from the decision it's supposed to inform. Sometimes you'll discover that you need to explain the argument better. Other times, you'll find that you've genuinely reached the limits of your authority. Those are two different situations, and they call for different next steps.
Ugh. Documentation.
Petr's homework also included one item that Igor's original list hadn't emphasized quite as strongly: documenting important architectural decisions. Petr still has the same spontaneous reaction to it. "Ugh."
Igor doesn't respond with an enthusiastic speech about the beauty of documentation. Instead, he explains why he now sees it as something more than administration.
If an important decision, including the reasoning behind it, exists only in the heads of a few people, it becomes increasingly difficult to use over time. A new colleague doesn't know why certain constraints exist. Another team revisits an option that was rejected long ago because nobody knows the reason. And six months later, someone removes an apparently unnecessary compromise without understanding what problem it originally solved.
"These days, AI can take over a large part of the actual writing and structuring if you set up the process sensibly," Igor says. "What's more important for you is recognizing which decisions are worth capturing and what context mustn't be lost."
That doesn't suddenly make writing documentation Petr's favorite activity. But he begins to distinguish between endlessly producing documents and being responsible for preserving important decisions. Along with their reasoning, assumptions and constraints. And because Petr was the one who brought this point into the conversation, they add it to their shared working model. The mentor's list isn't an answer key; Petr's perspective can help refine it too.
As they continue, they refine several other areas that Petr hadn't explored as thoroughly during his research. An architect doesn't necessarily manage the capacity of an entire team, but should be able to contribute to estimating the technical effort of different alternatives. For some changes, they need to look at the outcome of an entire feature or solution, rather than just individual lines during code review. They need to involve specialists, lead technical discussions even when they personally prefer one option, and understand the broader business context of decisions. The more areas they work through, the less Petr sees an architect as simply someone who's technically one level above a senior developer.
Instead of one definition, Petr now has a working model
At the end of the session, everything could be reduced to a few attractive words: system-wide perspective, communication, decision-making, responsibility. But Petr would quickly run into the same problem when trying to develop further using such a definition. What exactly is he supposed to imagine when someone says "be able to make decisions"? How does he know whether he "has a system-wide perspective"? And how is he supposed to compare his current work with a role whose requirements remain that general?
So Petr and Igor keep their model considerably more concrete. It contains 25 distinct competencies and responsibilities that they can later examine one by one. For example: seeing important relationships across a system; breaking down a large problem before implementation; comparing alternatives, including their costs, limitations and accepted risks; bringing in the right expertise and integrating it into a design; explaining technical consequences to someone accountable for a business decision; leading a discussion while listening to opposing views; or ensuring that an important decision and its context aren't lost.
But Petr still hasn't answered the question of whether he should become an architect. His list isn't a universal definition. In fact, he doesn't yet know how his own company would define the role, who would have which decision-making authority, how much time communication would take, or whether the position would actually allow him to influence the things that made him consider it in the first place. He'll have to investigate all those questions gradually in a specific environment.
Even so, by the end of the session he sees architecture differently than he did at the beginning. It's no longer just a higher technical role that might give him more influence. It may be a job where he spends less time writing code, more time working with people and more energy preparing decisions for which he might not even hold the final responsibility. Some parts still appeal to him. Others are much less attractive than he expected. And some of his original concerns have turned out to be more complicated than he thought.
He hasn't gained certainty that he chose the right target. He's gained something he can finally work with: a sufficiently concrete picture that he can compare against his current reality and continue adjusting as he learns more.
If you were to take one thing away from Petr's first step, it wouldn't be a list of software architect competencies. That list could look different in another company. What's more interesting is how it came about: Petr first tried to describe his target role himself, the mentor brought an independent perspective, and together they looked for places where their ideas differed. Not so that one of them could win, but so Petr could identify which assumptions were worth verifying.
Perhaps you can build a similar working model for a role you're considering. It doesn't have to be perfect, and you don't have to get everything right. But you need something more concrete than a job title before you can start asking useful questions: Which parts of this am I actually doing today? Where do I have experience, and where do I only have an assumption? And what would it mean for me if some of those assumptions turned out to be wrong?
That's exactly where Petr goes next. Now that he can at least provisionally describe where he wants to go, he needs to look at a much less comfortable question: where does he actually stand in relation to that target today?