I hope that some of the fellow readers can relate to when I say I have a hard time trying to explain what I do for a living. “Software Architect“… for a lot of people out there that means nothing at all and they just assume I’m sitting in front of a computer all day. But that’s about it… I usually try to map it to the job of a real estate construction architect, which I indeed find a good comparison. Yet, I leave that primer for another blog post – this time I would like to tell a few tales from school 🙂
So, what do I do as a Software Architect? Well, it’s indeed many-folded, which makes it that challenging and interesting at the same time. For me the following roles/responsibility make a good architect:
From my experience in all those distributed development projects I have worked in (India, Shanghai, Israel, Eastern Europe, Brazil, Americas…) I’ve came to realize that soft skills are at least as important as superior technical knowledge to successfully lead a team. The bigger the project, the truer the statement! Since almost a year, I have the privilege to lead an XL Composite development project in a distributed environment spreading multiple locations in India and Germany. At peak time, there are about ~40 people involved in the program – and they all need to talk to the architect. He’s the central node and needs to be able to speak both languages: tech talk to his team and management abbreviations… two different mind sets altogether sometimes 😉
No 1 Communication
Communication skills are absolutely required: fluent English in word and in writing, precise and adequate communication and Cultural Awareness. Efficient communication techniques and personal management are essential, which ultimately leads to…
No 2 – Time management
Yes.There are emails, phone calls, meetings, discussions, inquiries… plenty. Last year around December I had a throughput of around 100-150 emails per day. You need to be aware of timezones. Prepare smooth hand overs… DDPs can work around the clock, yes… they need to be coordinated/synced on a global level. So, you need ways to efficiently organize your time… especially if you want to preserve at least somewhat you can call a private life.
Time management and communication skills are really the basis. So, ensure to establish communication paths (and not only within your application, BUT also in real life)…maybe this is the social aspect of SOA ?!?
Exclusively communicate on these paths. Leverage all suitable channels (email, phone, messenger, twitter, ….) Decide on which ones to use to reach out to whom. Try to establish a living documentation… it requires a critical mass to see the platform of your choice manifest as the “single point of truth” for the entire development team.
No 3 – Coaching/Mentoring
That is the main part of the job. The inspiring one, the creative one. The rewarding one. See, looking back at school I can safely say there have been been good and bad teachers. Yet, there were a handful, that taught me something for live… they had an impact on my life, they gave me direction. I think that’s the rewarding part of coaching: the few students that actually listen and pick up on what you tried to teach them. The few you can really reach out to… where you can make a difference. The primary focus of a good architect is or at least should be the coaching and mentor role. Easy maths: If you teach people to work on their own, they take a share on the responsibility. Which is the ultimate goal. So, what makes a good coach, a good mentor? A good mentor/coach should…
- … aim to not only provide insight on technical topics, but also teach the reasoning behind it and the process of acquiring that insight – the mindset required to cope with a similar situation again. So to speak he acts as a knowledge multiplier.
- … should provide safe-guarding and assistance, yet empower the team to be able to execute on their own
- … should be close to the team; speak on behalf of the team, know the team… each team member, his/her background, his/her strengths, his/her weaknesses. In DDPs it is vital that the team really feels as one – periodic meetings face-to-face are important. A one-time kickoff meeting a must have.
- … clearly formulate his expectations and operation modes to the team – define a common playing ground, rules, interaction models
- … be a great leader. The ultimate way of leading is by example…. so, practice what you preach!
- … should never loose ground. Make sure to leave just a little bit of coding to yourself! Leave your footprint. It forces you to review code. You should know how your development team works. Network lags… working environments… privacy…
- … should look out for good students! Ultimately, every mentor should look for his apprentice, the one, to teach it all you’ve learned during your life-time in a nutshell to your successor. At the end, the apprentice will always be stronger than his master! 😉
No 4 – Empowerment
Listen to the needs of your dev team. Their concerns. If they complain about insufficient hardware, make the productivity loss transparent to management e.g. move to the cloud! Leverage new ways of thinking. If management tries to bail out… say the magic word: “lean!” … Play by the rules of the management. Let them make the ‘right decisions’! Clear, transparent communication and reporting is your ally and line of defense. Fight for your development team and its needs – that’s your primary objective: ensure they have a SMART target!
No 5 – Organization/Moderation
What’s the biggest asset of every team? Its members. Make sure they can concentrate on what they do best: development. If you succeed in the first four topics than your job should get easier and has reduced to organization and moderation. Once your team has the right knowledge, the empowerment to execute, the state of mind to analyze challenges and discuss on solutions… you’re almost there.
See, all the great architects I had the privilege to work with share a common characteristic: they all loooove technical discussions! Put five geeks in a room for a day, feed them and they come out completely stoked at the end of the day… 🙂
This is your ultimate goal… raise the next generation of architects. Make sure that you are aware of the chemistry within the team and that you leverage each team member best according to their individual strengths/weaknesses and skill set.
See, I learned all about leading a team from competitive team sport. If you want to win, you need a team that acts as one, which pushes each other and maintain a constant friendly competition about who is in the starting line-up. Identify your key players (who take the extra portion of responsibility), mix them up with the second tier so that they inspire/push/challenge each other… I’ve written about challenges already in my response to Thorsten Franz ‘s blog about coaching here.
This is where I’m at these days… the team just does its job! I mean, I knew this is the best team I ever had for a while now, as such my job is really not that much about coaching any longer. But moderating… I try to speak as little as possible these days… just providing questions and food for thoughts… (a little bit playing the devil’s advocate here and there…) So to speak it all comes down to a tweet I read the other day, which was containing the following quote:
“Judge a man by his questions rather than by his answers” – Voltaire
What I’m doing all day? Usually on the phone in the mornings to sync with my colleagues in India. Emails etc. at noon. Prepare the next steps in the afternoon. That’s it…
oh… and blogging at night. 🙂