Why We Updated the Dev Team Structure and How It Improved Our Workflow

Long story short, we have a new Development Team structure with distinguished roles of Principal Engineers and Architects. Since its introduction in Q3 2021, it has proved to work well and we’re more than happy to be sharing the story behind it. 

Read on to see how these roles differ, why we decided to start the evolution in the first place and how introducing the new development structure has improved plenty of areas at Monterail in just six months since implementation.

Why Change Something?

Last year Monterail reached the number of over 140 employees with almost 100 people in the delivery team. It means more projects, processes, and internal operations to handle. 

“We’ve come to a point where handlingprojects, proposing new solutions, and ensuring smooth communication within teams has become difficult to handle by our Head of Delivery and me solely. We also wanted to organize the team technology-wise and take care of the personal growth of people.”-Tomasz Kania-Orzeł, Head of Technology 

With the planned growth for 2022, it was clear that changes were inevitable and we could all feel it. One of the most important things about the approach to change at Monterail is that pretty much everyone can have a say and direct impact on the organization's shape and initiatives. We listen to our employees really closely, draw conclusions from feedback and apply changes if needed. It wasn’t any different when it comes to the dev team structure. 

The Evolution Step by Step

The answer to our most burning problems was relieving our Heads of Delivery and Technology. But how to share the workload between the leaders in the most effective way? 

Testing and staying Agile I would say. As it makes much more sense to act on a small scale than changing the whole organization (and then turning it around in case of failure), we started the experiment. In Q4 three “test” Solution Architect roles were introduced. 

Six months later, we gathered feedback from people involved in the experiment but also from many of the team members in day-to-day cooperation. The next step was to analyze what works, what doesn’t, and what the needs are.

Based on that, we managed to define and plan the way we should go next. It became clear that as our Dev Team grows, it is a natural thing that there is evolution needed. During the Organizational Workshops our Head of Technology, Head of Delivery, and Solution Architects decided that based on the feedback from the Dev Team, there are a couple of areas that need to be improved: 

• Knowledge sharing within the team
• Technology-focused support and guidance in personal development
• Technological standardization in projects and the company 

What is more, during the workshops we decided that the Solutions Architect role splits into two new ones:

• Principal Engineer
• Architect

"The more experienced you are, the more impact on the surrounding environment you want to have. The new role gives us more space to use our experience for comprehensive work on our processes, standardization of good practices, finding organization bottlenecks, and ways to fix them. I like to think that our main responsibility is to help - other devs as well as PMs, sales, and People team in removing obstacles or pushing things forward, so we can create the best dev team possible." -Jan Dudulski, Backend Principal Engineer

The New Development Team Structure

And finally, on the verge of Q2 and Q3 2021 - we implemented the plan we had worked out!

We added a Principal Engineers’ and Architects’ layer between leaders and the Head of Technology. 

We ran the implementation with baby steps. Starting with the Mobile Team only, then, after checking how it works (worked well!) and gathering feedback, we implemented the structure for the Backend Team. Another phase concerned the implementation of the Frontend Team. 

So now we have 4 Principal Engineers on the team: Hubert Białęcki in the Mobile Team, Wojciech Maciejak and Jan Dudulski in the Backend Team, and Szymon Licau in the Frontend Team.

Looking at this diagram you can see what the Monterail Dev Team structure currently looks like.Basically, there is only one adjustment made in contrast to the structure we had before: between leaders and the Head of Technology role, there is a Principal Engineers’ and Architects’ layer. 

Principal Engineer vs Architect

Do these roles seem pretty much the same to you? Well, there are some crucial differences.

We consider Architects as satellites. They work mostly with our Head of Technology and focus on research and development. The architect role is focused on R&D and working closely with Business Analysts and the Sales team. 

The Principal Engineers’ cooperation range is a little bit wider. They work closely with the Head of Technology, Head of Delivery, leaders, People Team, Project Managers, and Sales Team. The Principal Engineer role is focused on leadership and team management. PE is closer to the team members and projects, working on cross-project knowledge sharing and technical standardization. They work on improving communication with the PM and People team and constantly help team members to grow. 

“Principal Engineer is a leadership-managerial role that embraces taking care of the Mobile Team, its' development, and supporting leaders.I am responsible for ensuring that people have time and space to grow and develop. I organize meetings related to sharing knowledge, encouraging people to get involved in writing articles or making presentations, so that we all share our ideas, comments, or questions.” - Hubert Białęcki, Mobile Principal Engineer 

The Benefits of The New Structure

There are a bunch of advantages we noticed on all levels of the organization that stems from this change. Here are the most important ones:

• Improved efficiency of the whole delivery team (Dev, QA, Design, PM).
• Technical standardization in projects. 
• Faster projects’ kick-off with the support of Principal Engineers who suggest good practices and new solutions for development. 
• Better cooperation between leaders and mentees.
• More discussions in the Business Analyst Team about technologies for future projects.
• A valuable knowledge-sharing flow within and between technical teams.
• Creating a virtual place for discussion, experience & inspiration sharing for enthusiasts of a given technology.
• Greater clarity - every person knows exactly to whom to go for an answer or help in a given technology.

Currently, we are also on a good track to plan development paths for every developer at Monterail with a stronger focus on technologies in each developer’s main area.

"As a Principal Engineer, I have the pleasure to lead and take care of the Frontend team - its' growth, encouraging knowledge-sharing between developers, supporting the leaders and their mentees, and ensuring best practices in our frontend projects. For me, the biggest challenge of the frontend is overcoming the framework silos - extracting the important knowledge beyond just what's commonly used within one of the popular frameworks. What excites me in this role is the real impact I can have on a larger scale within the company and the challenges it entails." - Szymon Licau, Frontend Principal Engineer

Influence on Mentorship and Peer Review Process

That evolution was essential to help all Dev Team members grow as developers and give them more support from the company in their daily work. After only six months since implementing the new team structure, we noticed positive changes in the following areas:

• 1 on 1 meeting is now focused not only on general satisfaction and well-being but also on technical skills development. Mentors can help their mentees with technical issues in projects, and support them with their knowledge and experience.
• Technical guidance. Mentors, as they usually work with the same technology and framework their mentees do, help with creating a roadmap for mentees’ skills development which is useful for employees on any level of seniority.
• The whole peer-review process that we conduct for every person at Monterail every 6 months, is now more precise when it comes to the value of feedback. It includes more details as mentors have more context on mentees’ skills development, especially technical ones.

Summary 

The whole process of reshaping the development structure was not a quick and easy change but the results show it was all worth it. Besides improving many processes in the organization, I think it showed something important, too.

It's a clear sign that Monterail implements its' core value "Figure it out" into practice, that we're willing to adapt and learn. Also, I hope it provides any senior developer with some hope that reaching seniority does not have to be the end of the career path but might be a new beginning. Development and growth are always possible, you just need to find the right place to uncover your potential.