Umbrella tech department, thanks to company’s guidelines, is an environment where stress and conflicts are generally kept under control. This does not mean that there is no room for improvement. When we plan enhancements, we need to keep in mind a few facts: our relationship is not built on authority but on trust because developers report to line leaders and the ratio between front-end developers and front-end architect.
Real world examples
Here below few real world examples on how front-end architect help to manage stress and conflict:
A newly created
Team X is a newly created team and to help them meet deadlines in time, as architects, we are using a directing leadership style. This approach allows the group to get straight to the goal and get the job done because it reduces the chances of misunderstanding. Every task and decision are explained in long meetings or by working in pairs with team members. Micromanaging the team’s work has short-term benefits on a single team only and does not scale because it limits the time architects can dedicate to other teams. People involved can easily end up being frustrated or stressed. This way of working limits creativity and innovation. It is an approach that gives good results but has to be used with care and for short periods only.
Umbrella is committed to make sure all employees have the skills, knowledge and behaviors to deliver the best product as efficiently as they are able. All employees and directly employed consultants have access to Umbrella’s learning platform but there are not courses specific for frontend developers. As front-end architects we identified a training provider that offers first class online courses, proposed developer managers to buy them and make these training mandatory for developers. Already allocated yearly budget for talent development should be used for this purpose.
Collaboration between teams
To help the collaboration between team A and B we thought to organize a series of meetings with the aim to find a common ground between these two working groups. Immediately during the first meeting we all realized that the main source of conflicts was the unclear definition of responsibilities. Once these details were ironed out, finding an agreement between the two parties was fairly simple. Instead of waiting for the next project to try the agreed solution the teams decided to adjust their way of collaborating right away and benefits were noticed from the first week after the agreement.
Clash between team members
Agile leaders and product owners are two key roles in the teams we, as architects, work with. In the case we noticed that in a specific team there was an evident clash going on and the entire development team was suffering from it. We reported this situation to the responsible line managers and agreed how we could contribute to improving the situation. In this case the shy personality of one struggled to match the extrovert character of the other. As a united group of colleagues we supported these two to communicate more and adjust the tone of their communications to match each other’s nature. The process is still ongoing, but first results are promising.