5 tips for system architects – how to collaborate with your team?
I gathered 5, in my opinion, the most important, tips on how to approach the topic of effective cooperation with the team. Developers team, business, CTO and … other architects. If you start your adventure as a systems architect, make sure you read it! If you’ve been working for a while, also take a look at it. You’ll probably read about situations from your backyard. You’ll find that others have them as well.
tip 1. put down the laptop
Am I crazy? Not yet. Laptops, phones. These are our basic tools. They help us with communication because they have many (too many) applications. And these applications are to serve this communication, not control it. It’s different when we find the time to meet and just talk about the staff. Meetings go better when there are no distractions.
Let me give you an example I heard some time ago. A certain company in order to successfully carry out the workshops invited its clients … underground, literally. In to the mine. Just kidding, in an adapted conference room – where there is no phone service. Thus, everyone could focus on work. Everyone was heard and the communication was not disturbed. Simple putting away equipment and focusing on interlocutors. I mean, such a little thing and so powerful effect.
tip 2. system architects, please keep your ego in check
Ha, ha. ha. like a chuckle in my throat. Cause that’s nothing to laugh at. Each of us, architects is a kind of visionary and there is nothing to argue with that. And like any visionary, you are probably charismatic and have your own opinion. And it’s very good! Your role is that people follow your vision, but … not uncritically.
“It is known that no one likes when one’s concept is overturned upside down. And here I don’t mean to win over your vision, but only a wise approach to the matter. Take a feedback and think about it.”
You don’t have to accept everything. After all, you are the architect and you are responsible for making your piece of the system workable.
And if you’ve got a team that will develop a vision with further details. Awesome. Your shared work can be more interesting and more effective. All in all, it’s probably the most important thing to work together. If you talk through the matter together, agree on what you’re doing and you give the team a free hand on how to do it … I guarantee you, it will be a fruitful cooperation.
Where is the architects’ ego mentioned in the headline? Probably every architect, every team leader, knows what I’m writing about. It is worth having your ego in check, especially if you work in a big team, with a big project. Where every architect is responsible for a piece of the system. And just as these pieces of the system have to “talk” with each other effectively, so do you.
tip 3. find time for analytics
If you’ll do a great job at the base, the harvest will be great as well. What does it actually mean? As an system architect, we have a lot of analytical work. We need to think through well about our piece of the system. First of all, transpose business requirements into work for the development teams.
It is also connected with many meetings and of course, indispensable documentation. However, if this analytical work is poorly done then problems may arise. And problems raise questions. For which no one else but you, must know the answer. What is more, when a developer doesn’t know what to do, he/she directly strikes the architect with a question. And these questions appear. However, you know that if there are so many of them that you do nothing else but answering. Something must have gone wrong.
And this is the aftermath of analytics and documentation made with lick and the promise. Therefore, to make it good – cut yourself off. Your brain must be offline. And sometimes you physically need to be offline. You must be unavailable for everyone. Otherwise, you know exactly what will happen next, if you don’t do this strategic part now.
tip 4. speak their language
The architect transposes the vision into technology. Most often, quite a general vision eg. CTO, tries to transpose into specifics. As the CTO trusts architects, he/she gives ideas of the system to architects hands/head. An architect is a person who communicates with development teams. He/ she processes this vision into specific technical requirements and thereby sets the work of the teams.
The essence of the communication understanding is in both cases speaking a common language. Business is often not technical. When in fact, CTO is usually technical but doesn’t go into details. They want to have a working system. All in one, the architect must understand the business requirements well, so there would be no disappointment. I think everyone knows this funny picture “what the client ordered and what the client received”. It’s a bit different, right? That’s why it’s up to you that the customer if he ordered a funfair, will get a funfair, not a tire hanging on a tree.
tip 5. when everything fails
- set communication standards
on their basis, verify the work of the team. Sometimes the human factor cannot be overcome and cannot be changed. People, who for years have worked out such and no other style of work and communication won’t change it, because we want it differently. However, this doesn’t mean that cooperation is impossible. Simply set together with the team/team leader, communication standards and stick to them.
- set acceptance criteria
As for the work of developers, set the acceptance criteria mentioned above, which must be met in order for the development goal be considered as delivered. But don’t be discouraged. This is possible to work that day.
If you stayed here up to this moment it probably means that you’ve met this kind of situations in your career, so…what are your proven ways for effective cooperation? So system architect, let me know about them!
Adam is a natural leader which is often evident during various it projects. Intuitive and visionary, he is skilled at designing software architecture and guiding the team in the right direction.