What Does a Frontend Architect Do? My Monterail Way.

Meet Artur Rosa, he started his path at Monterail directly after graduating from University. Since then he's accomplished plenty, now he's a Frontend Architect and he wants to share his Monterail way. Read on as Artur elaborates on his journey and current position with Monterail.

 

Artur Rosa is a web developer and frontend geek at Monterail. Often over-fascinated by new ideas, rationally using the concepts behind them. In love with Vue, in friendship with React.

 

When did you start working at Monterail?

I've been working at Monterail since 2017—over 4 years now. I started working right after finishing studying IT at the University of Wrocław.

The IT job market is pretty saturated in Poland, why choose Monterail?

I was looking for my first full-time job and considering several companies. The main factor for me was the external audibility of the company.

At the time, Meet.js meetings were organized in Monterail's office, that's when I first got to know the company. I had a chance to meet some people who worked here and talk about different aspects of working at Monterail. I specifically remember liking that they had time dedicated to personal development. 

What was your first role in Monterail?

I applied for Junior Frontend Developer and got the job. Previously, I dealt with frontend and general web development, but I’d call myself more of a web developer. My experience was largely non-commercial— making web pages and dynamic components for my friends. I had very few commercial projects in my portfolio. So Monterail was actually my first full-time CV job in the profession. 

You started as a Junior and got a project right away? What was it?

The first one was an internal project, it changed my career a lot. It was the website for a Vue.js conference, created by Damian Dulisz. Now he's a member of the core Vue team. Back then, he was working with us, and Monterail organized the world's first Vue conference.

For me, Vue was a completely new technology, I hadn’t heard of it yet. The project was a page with a presentation plan, general description, and landing page for this event. It was also written in Vue, which I had no experience with. I was building the page under the watchful eye of Damian. I learned a lot then and I work with Vue until now, and I am in love with this technology.

Vue was new to you, and Monterail was one of the few early adopters.

I think the Vue conference is a good example: it was the first Vue Conference in the world, organized by Monterail. It says a lot about the knowledge and popularity of this technology back then. Large, popular frameworks had their established conferences and events, but not Vue— not yet. 

Vue is first and foremost open-source, created entirely by the community. No large company is behind it like React or Angular. This allows initiatives like Vue Conference to be entirely bottom-up.

Damian Dulisz is a passionate, enthusiastic evangelist of this technology and he put a lot of work into organizing this conference. On the other hand, our co-CEOs wanted to help organize this conference, big applause for them.

You had that first internal project as a junior. At what point did you get a promotion?

Moments after this internal project, and during my trial period, I got a second project that has been with me for a long time. That project was Extradom. We were creating a 3D interior builder based quite heavily on Vue and the Vue reactive system.

I liked the project a lot because the main problems to be solved were problems related to 3D graphics and rendering - that's a bit of my specialty, and I have some background from my studies. I was promoted to Regular Developer after 6 months of work.

How do you see the mentorship in Monterail?

My mentor helped me a lot at the beginning. Finding myself in the company, and what my role was, what I should and shouldn’t do, and how to develop in the company. Hubert Białęcki was my mentor until I became a leader myself.

Then for the past 2 years, I’ve had the opportunity to be a mentor.

It's a very interesting role. I have the opportunity to give something from myself, to help new people in the company, and to share my knowledge. It could be technical, general development, how various processes in the company work, or even simple things. 

To help provide new-joiners with some work-life balance, I explain that we don't want to work overtime, or if they want to take a vacation they can take it.People have different backgrounds, so they don't always know that this is how it works or what to expect at Monterail.

One of the factors that convinced you to work at Monterail was self-development time. Do you feel like you've taken advantage of it?

Yes, especially in the beginning. When I was a Junior Developer, I suddenly jumped into various technologies that I had no experience in.

At the beginning of my commercial career, there were a lot of different topics that I hadn't heard of. Self-development time was when I could catch up, read a bit about tools, find out which people to talk to, try stuff on my own, and feel more comfortable later on using these tools in projects.

Panel Discussion at Vuejs Amsterdam 2021, Featuring Artur Rosa

Your role as an Architect in Monterail - can you tell us more about it? 

The Architect role is a new role in the company that differs from Senior Developer. As an Architect, I have dedicated time for the project and implementation of tasks and responsibilities related to the role of the Architect. 

This means I'm no longer full-time in any project, I have limited time at this point in one project and apart from that, I have other responsibilities, or rather areas where I can contribute.

Some of these areas are strictly related to the company's development and team development, and others are project-related, but it's all outside of projects in which I work daily.

Could you give an example?

When we think about an Architect, often it's a software architect, a person in a given project or issue who designs the system. This is indeed part of my role as an Architect. If we have some non-standard or complicated project tasks or problems, I am the person who people can reach out to. I participate in such a project for some time, in a consultative role, or to help solve a complicated task when the team needs it.

As a development agency, we often have very different projects coming to us. Some time ago we diagnosed the need for a person with a more technical background to look at projects. To look at this entire sales process and assist in it, and also be able to easily answer the questions of potential clients, or advise on various issues so that this sales process is not detached from the actual technologies, we carry out in the company.

Sometimes I need to do additional research or proof of concept for the implementation of certain tasks to make sure that the given technologies will perform well in this role. It’s also part of my role to help choose and validate technologies. 

An Architect in Monterail also creates a culture of sharing knowledge. We have recurring meetings called dev meetings. We encourage people to share their knowledge at these meetings, but also to propose topics, or guide people to important topics that could be raised at such meetings.

Another aspect of knowledge sharing is sharing solutions and defining standardization. We are a development agency with a lot of different projects. It is often the case that we have already applied solutions somewhere and there used to be no exchange of this knowledge.

In a new project, people do not realize that in another project some solutions have already been created.It is my role to create appropriate places for this, where we describe these solutions or even create ready-made solutions that can be simply used in new projects retrospectives.

As Architects, we know various projects and the different problems that these teams face. We can look at it from a bird's eye view. In Monterail, successful or not, we have workshops after each project, called Lessons learned. We describe what lessons we learned, explain what went well, what didn’t, and what we could improve in the future.

The architects' role is to analyze such documents in order to actually learn from these lessons. Architects look for ways to avoid the problems described there, in future projects. And look for ways to apply solutions that could bring value to other projects.

All the things I mentioned are connected. They create a whole picture that could be simplified as: "we help with complex design solutions, support the sharing of knowledge within the company, and assist in sales processes." I’d be happy with that summary.

You also mentioned that something has changed in the structure, what? 

Monterail is growing, especially in terms of the number of employees. Restructuring concerns mainly the dev team, so let’s focus on them.

Until recently, the dev team had a fairly flat structure - there was the entire dev team, they had mentors who did not necessarily have any experience working in the same framework. So a front-end developer could have a mentor who was a back-end developer.

We found a few problematic things here. First, the Head of Technology, who is the direct supervisor of the entire dev team, was not able to get to know all these people.

Sometimes quite simple questions were not answered, i.e. how and where, in which areas we could develop. A mentor could help with these topics, however, they often did not have a technological or design context of the mentee. That was one thing we wanted to do within this new structure: shift leadership towards a technical side, so the mentees could talk to their mentors about technical problems as well.

There are two new roles in Monterail: Principal Engineer and Architect. When it comes to Architects, the idea was to create a position for a person so that they would have dedicated time for helping the sales or project team as an experienced person. Senior Developers are heavily involved in projects and they should focus on them. The idea behind the Architect was to create a place for people who may be less involved in projects, and have separate, dedicated time to get involved in other projects, be able to help people, and direct them to appropriate solutions. Whether it is in projects or our various internal departments, such as the Sales team, BA, or Growth.

And what is best for you in the role of an Architect? 

We’re still in the process of implementing this structure, especially concerning Principal Engineers. What I like about this role is that by working on the standardization or automation of various solutions, we can actually save a lot of work for teams, and thus affect the value we give to customers. 

As I said - this mainly translates into the work of teams. They can focus more on those less repetitive elements, i.e. those more interesting elements of the application, it also has a big impact on the value we give clients because we can be faster in accomplishing tasks.

Another thing that I like very much about the Architect role is that the responsibilities that come with it allow for quite a lot of flexibility of work. So that in many topics, at least the more high-level, long-term ones, you can do this work completely asynchronously. 

On the other hand, you can often work with us asynchronously anyway, but in contrast to such a managerial role, it doesn’t involve a lot of meetings with people. I have much more freedom when it comes to choosing working hours. Right now I have a small daughter and it is quite important for me and from my point of view that I could spend some time during the day with my wife and daughter.

Before you were a Senior Developer and now you are an Architect. What was the biggest challenge for you in this change of role? Or what still is?

Planning and prioritization. These two points.In projects, we often have a pre-imposed list of tasks that we will implement. These are technical solutions that we implement and without much preparation, we can get up in the morning, open this list and start completing tasks.

In this role we have a much greater influence on what tasks we carry out. As if planning is based on the fact that we define our tasks and we have different premises, such as our company's key initiatives, that tell us what goals we want to achieve but also tell us about priorities.We have to define how we want to implement it,and it is not always simple. This ability to plan and prioritize individual tasks, I think is important. 

Through consultations in projects or participation in the kick-off, i.e. at the very beginning of the project, we participate as Architects to see if everything is going well. Projects appear often, and you need to plan them in a way that you do not get lost in them.There is no such thing as true multitasking, so you have to organize this kind of context switching properly so that this work moves forward.

Is there something that you are most proud of or the most important thing you have done, as if in your career at Monterail?

What I value most about Monterail is the feedback after being a leader for the newcomers to the company. It is amazing that if you give a lot of yourself at the beginning and help people, you can get so much positive energy in return, not only during this early period but also after. Observing how a person develops, often very quickly. Sometimes they quickly catch up to you on many topics, technical and even work in the company, and I think this is someplace, in retrospect, where you can see that you had an impact on someone's development and career, it is very satisfying.