December 13, 2021
Artur started his path at Monterail right after graduating University. He is now a Frontend Architect and in the interview he goes into more details about what that means.
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 have been working at Monterail since 2017. It will be over 4 years now. I started working right after finishing studying IT at the University of Wrocław.
There are a lot of choices, why Monterail?
I was looking for my first full-time job. I considered several companies. The main deciding factor was the external audibility of the company.
I knew Monterail from attending meet.js meetings organized in their office. I had the opportunity to meet some people who worked here. We talked about different aspects of the job. I remember one thing I liked was that Monterail had time dedicated to personal development.
What was your first role in Monterail?
I applied for Junior Frontend Developer. I dealt with frontend before 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 working at Monterail was my first full-time CV job in the profession.
You started as a Junior and got a project right away? What was it?
My first project was an internal project, it changed my career a lot. It was the website for Vue Conference, created by Damian Dulisz, now 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. It was a page with a presentation plan, general description, and a landing page for this event. It was also written in Vue, which I had no experience with. I was making it under the watchful eye of Damian. I learned a lot then and I work with Vue until now, and I am still 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, and this has not been the case with Vue yet.
Vue is first and foremost open-source, created entirely by the community. No large company is behind it, unlike 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 the trial period, I got a second project that has been with me for a long time. That project was Extradom where we were creating a 3D interior builder based quite heavily on Vue and the Vue reactive system.
I liked the project a lot as the main problems to be solved were problems related to 3D graphics and rendering - that's bit of my specialty, something that I like to deal with, I also had some background from 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.
For the past 2 years, I’ve had the opportunity to be a mentor.
This is 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 do not 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.
You mentioned that one of the factors that also convinced you to work at Monterail was self-development time. In retrospect, do you feel you have taken advantage of it?
Yes, especially in the beginning. When I was a Junior Developer, I suddenly jumped into various technologies with which I had no experience before.
At the beginning of my commercial career, there were a lot of different topics that I hadn't heard of. Self-development time was where 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
Your role as an Architect in Monterail - what is it about?
The Architect role is one of two new roles in the company that differ from the Senior Developer role. As an Architect, I have a dedicated time for the project and the implementation of tasks and responsibilities related to the role of the Architect.
This means that I am no longer full-time in any project, I have limited time at this point in one project and apart from this project work, 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 matters, but not in projects in which I work daily.
Could you give an example?
When we think about an Architect, we often think about a software architect, a person in a given project or issue, who designs the system. This is indeed a 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.
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 there is a 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 the Architect's 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 the 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 our 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, as well as look for ways to apply good solutions that were developed in projects and 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 it 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 about 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.