Blog

Petr has a roadmap to becoming a software architect. His manager says the company may need a different kind of technical responsibility. Petr refines one capability, adjusts its priority, and prepares a next step without discarding his plan.

After his first technical recommendation, Petr realizes he missed the decision context. With Igor, he changes one next step in his roadmap. Six weeks later, before recommending an approach for a new import feature, he asks about rollout plans. His manager finds the analysis usable, but another question remains open.

Petr wants to be involved in decision-making. His manager doesn't invite him to the meeting, but offers an hour to prepare technical input. The refactoring payback estimate looks promising. The manager asks why they should invest now.

In this fictional story, Petr has chosen a priority but doesn't know what to do next. With Igor, he turns it into a first practical step and a simple roadmap. An upcoming client meeting shows why a change in priority is not proof of improved ability.

In this fictional story, Petr and Igor compare five abilities against a working model of the architect role. Specific work situations change Petr's estimates, and two development goals tie for the highest priority. Petr has to choose where to start.

Petr wants more influence over technical decisions, so he considers becoming an architect. But comparing his expectations with his mentor's perspective raises questions about coding, communication and the limits of his authority.