Skip to content

The Role of a Technical Architect — 3 Perspectives


Jul 22, 2021 - 10 minute read

1829 Technical Architect At Objectivity 416X300
Małgorzata Caban Senior Content Marketing Specialist

She specialises in translation, writing and knowledge management. In her work, she combines her passion for languages with an interest in technology. Privately, she was part of a team of volunteers responsible for the Polish translation of “Baldur’s Gate: Siege of Dragonspear” video game.

See all Małgorzata's posts

Finops Stickad Blog430x300


How is one role within an organisation perceived by different people who hold it? Will all Technical Architects at Objectivity define their role similarly? We invited 3 of our experienced Technical Architects to discuss their work and what they believe is most important about it.

Objectivity’s Bartosz Bojarowski — Chapter Leader Technical Architect, Łukasz Malec — Technical Architect, and Krzysztof Rudnicki — Digital Transformation Consultant, share their experience and insights.

Technical Architect At Objectivity

Bartosz: The Technical Architect (TA) role isn’t always exactly the same in all projects. There are, of course, some common aspects, but their extent may vary. In general, the role requires combining technical expertise with soft skills, being able to talk to both the client and your team. You need to be able to mentor people, point them in the right direction, but also possess enough organisational skills to support the Project Manager (PM). You can say that the PM, Business Analyst (BA) and Technical Architect (TA) form the heart of the team. A lot of things in projects depend on the TA.

Łukasz: In addition to this, to me a TA is someone who’s not focused on a single area, e.g. not only writes code and is fully engaged in programming, but who wants to grow on many different levels. I started my career rather typically, as a developer. Back then, I was being given a list of tasks that I just needed to implement in the code. Over time, I began to realise the broader context behind it, the work of the people who delivered those stories and tasks. I started to understand the job of an architect, someone who needs to translate the client’s requirements into the right words, so developers know how to implement them. I became passionate about it and gained more and more insight that eventually let me pick up the duties of a TA. I still had to learn a lot, obviously, the expertise doesn’t come automatically, there are always surprises you need to deal with. But all of this experience allowed me to join Objectivity as a fully-fledged Technical Architect.

Bartosz: It’s worth mentioning that the TA role can also mean different things at different companies. Often it’s a Senior Developer who’s just getting another job title. It’s not the case at Objectivity. Here a TA isn’t a “better” developer, it’s a different scope of tasks. Proactivity is key in this role. It’s not just about solving issues, the TA needs to identify what actually needs solving. You have to ask the right questions and keep many things in mind, not just the technical matters.

At The Core of The Project

Łukasz: You can say that there are two areas in a project: the problem and the solution. Developers are mostly on the solution side, they already work on an algorithm or some architecture. A TA may also support the solution part, but their role is generally placed in the problem area first. That’s where he or she cooperates with the BA and the client and creates those building blocks that will later be implemented.

Bartosz: The architect is usually involved in all stages of the project, even before the actual problem has been defined. The early work may start as an abstract concept based on pieces of more or less concrete information from a prospective client. A TA needs to be able to put the pieces together, make accurate assumptions, define risks and present the client with a project estimation. Again, the ability to ask the right questions is crucial to form a vision of the product.

Łukasz: Empathy is also vital. You’re exposed to many different people and you need to find a way to get through to them. The better we connect and the bigger trust we build at these early stages, the easier it’ll be to build that shared vision. I dare say that those interpersonal skills can greatly affect the final success of the project.

Krzysztof: You have to understand the client’s needs, but on a different level than the BA. The BA (at least here, at Objectivity) is mostly looking after the functional aspect of what we deliver. The TA, on the other hand, needs to understand the non-functional requirements. These include e.g. system resiliency, survivability, modifiability, extensibility, modularity, integrations with the client’s ecosystem (or an external one), the list goes on. It’s the TA’s job to pay attention to all these non-functional requirements and verify their importance in the context of the project.

Decisions and the Art of Compromise

Łukasz: As Technical Architects, we certainly make some decisions and have a say over the technical aspects, e.g. how the final product will be constructed. However, we are often subject to limitations, resulting from the client wanting us to use a platform of their choice etc. We should treat this as a challenge, to find our way across these limitations and utilise the platform in the best possible way. I often tell my team that development — and, by extension, architecture — are based on the art of finding a compromise. It’s the TAs and BAs who need to find the right balance, understand the client’s priorities and translate them into the architecture’s design.

Bartosz: On one hand, our job is to use what we’ve got, but on the other hand, it’s also to challenge the status quo. You need to form good arguments if you want to convince the client to try a different approach. Sometimes we stick to the original plan, but on other occasions, we can actually show the client something they’d never think of. We can also add that while there may be limitations on the client’s side, there aren’t many that Objectivity forces on you. A TA has a lot of freedom. In the scope of your responsibility, you make the final calls. Still, a TA is expected to lead their team in a way that ensures that everyone understands that their opinions and ideas are being heard.

Krzysztof: I’d like to make a distinction between making decisions and taking responsibility. Everyone wants to decide, but few people want to be held accountable. An architect doesn’t necessarily have to make decisions but rather find that compromise, and do it within all the limits — technical, business or even human. An architect feels accountable first, making your own decision comes second to that. A good TA makes decisions that represent their and their team’s opinion, but more importantly, takes the responsibility for that decision, however it turns out. It may happen that a TA deliberately and responsibly takes on a technical or process debt. If he or she does that, it’s because it’s the best action in this context, and it’s intended at bringing a particular benefit.

The Technology Angle

Krzysztof: When it comes to technology, I like to ask this question first: what’s the goal of an architect’s work? The answer is: to solve business problems. We shouldn’t really focus on technologies because today you can always find the right technology that will solve your problem. We need to think about what problem we’re solving, why and for whom, and what would actually be a good solution. The choice of technology comes second. It’s understandable that a developer would be interested in technology because that’s what he or she will be working with, they have specific interests and preferences. An architect should by definition be agnostic about particular technologies because their job is to translate the business demands into a pattern that will be implemented with a certain technology.

Bartosz: I actually look at it from a different perspective. I find it satisfying to try new technologies (of course, within the client’s limits) and let my team learn new things. When the team is willing to learn more, it can also affect the choice of the technology. If there are several ways to solve a problem, why not ask the team what they’d find interesting.

Łukasz: I’ve worked with several clients and, as the architect, I’ve always been part of the discussion. We can propose some particular tools and solutions to choose from, show strong and weak traits for each one of them. It is crucial to ensure our clients that technology will help them achieve their goals. The architect should, however, understand the limitations and the reasons behind certain decisions.

Bartosz: If we’d like to talk about working with code, we may say there are two standard setups at Objectivity. 1 — the architect doesn’t write code at all, 2 — it’s a 50:50 split with other work. It often depends on personal preferences, and if an architect likes to write code, we try to find a project where there’ll be room for that.

Łukasz: In my time here, there were projects where I did spend some time programming. Still, it was usually as part of building PoCs or laying the foundations for the team to work on.

Krzysztof: I agree with what’s been said and, again, would like to shift the focus to the fact that an architect implements an architecture. He or she can prepare a PoC to show the team what works and what can become part of the final solution.

Bartosz: It’s worth adding that working with code also involves code review. Even if a TA doesn’t write code, they’re still expected to perform the code review with the team and keep an eye on the quality.

Łukasz: This also shows that the TA isn’t some distant figure who just assigns tasks to others, but is part of the team, engaged in their work.

Various Projects, Various Clients

Bartosz: At Objectivity, there is a wide diversity of projects and everyone can find something that interests them. When it comes to project governance, sometimes it’s on Objectivity’s side, and then we just work with a few client stakeholders like a Product Owner or an architect. If the governance is on the client’s side, we act in more of a consulting capacity. It all depends on the specific situation.

Łukasz: We don’t normally recruit people for a specific project, so it’s good if the candidates have some flexibility. There may be a different setup in each project, with more or fewer client representatives in our team. You just need to be willing to collaborate.

Krzysztof: What may be important, however, is that it doesn’t matter if the project is big or small, or what industry or business area it concerns. At Objectivity, we always keep the “human” aspect in mind. It’s displayed in our culture, we emphasise good communication. We’ll also never take on projects that contradict our values. We won’t work on initiatives that may impact someone’s dignity or freedom. There were projects that we decided against because of our integrity. That says a lot about the company you work for. I believe that this company is indeed values-driven, and this means a lot to me.

Growth Opportunities

Krzysztof: Objectivity helps you grow and take new paths in your career. I started as a TA, and now I’m a consultant. It was a big change, one that I wanted to make, and Objectivity made it possible. Here, you can always try your hand at something new. Or, if you prefer, you can expand your expertise as a TA even further. I got the chance to do other interesting things, now as a consulting architect rather than one working with implementation.

Bartosz: I was always interested in working with people, so I got the role of a Chapter Leader Technical Architect. It combines the duties of a TA with the coordination of a team of architects within one tribe. There’s also another role here, a Solutions Architect, which can also be an expansion of the TA role.

Krzysztof: A Solutions Architect looks at the architecture from a different angle. He or she checks how the solutions fit within the client’s organisation and business structure, not how they’re being implemented on their own. This is another layer of architecture.

Why Do They Do It?

Krzysztof: I have a personal mission in my role. I do everything in my power to save the client from failure. My mission is to support the clients in doing things in the best possible way and to protect them from the threat that an unfamiliar technology may pose.

Łukasz: I enjoy working with a team, mentoring, supporting others. I’m always happy to help. It motivates me. Also, if you make money on something you truly enjoy, you spread good energy around you. And if you feel like you need a change, the company can give you the chance to switch projects. Sometimes it may take time, even just to find someone to replace you, but I’ve never heard that someone would be denied this opportunity. Such flexibility is not that common elsewhere, I think.

Bartosz: I like the challenges I’m facing. Sometimes operating with the unknown at the beginning of a project, organising the project from scratch — it gives me satisfaction when we put all the pieces together. I also appreciate the possibility to grow in many different fields.

Krzysztof: When someone asks me why I work here, I say it’s the culture and values. Win-win, agility, people, integrity, excellence — those aren’t just empty words. I know I can always speak up — and I will be heard.

Join Us

If you’d like to join our team, check out our current job listings. Let’s meet and talk about your goals.

Finops Stickad Blog430x300
Małgorzata Caban Senior Content Marketing Specialist

She specialises in translation, writing and knowledge management. In her work, she combines her passion for languages with an interest in technology. Privately, she was part of a team of volunteers responsible for the Polish translation of “Baldur’s Gate: Siege of Dragonspear” video game.

See all Małgorzata's posts

Related posts

You might be also interested in


Start your project with Objectivity

CTA Pattern - Contact - Middle

We use necessary cookies for the functionality of our website, as well as optional cookies for analytic, performance and/or marketing purposes. Collecting and reporting information via optional cookies helps us improve our website and reach out to you with information regarding our organisaton or offer. To read more or decline the use of some cookies please see our Cookie Settings.