Skip to Content

Introduction

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:

  • Mentor/Coach
  • Coordinator/Moderator
  • Organizer/Communicator
  • Teammate/Peer
  • Leader/Multiplier

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 😉

Related Dilbert

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…

Related Dilbert

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.

Related Dilbert

Tips: Apply Outlook rules. Introduce catch words in email subject lists. Introduce abbreviations and ensure viral adaptation!

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.

Tips: Create Distribution Lists. Leverage multi-channel. Establish a WIKI. Use a single communication language in all written communication (you sure don’t want to add translation to your role!)

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!

Related Dilbert

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.

Conclusion

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. 🙂

To report this post you need to login first.

20 Comments

You must be Logged on to comment or reply to a post.

  1. Andreas Huppert
    I can only agree with every word you write. I like to add: fight for good architecture. Other people take care of budget and other restrictions. You usually have to do compromises, but if you do not fight for good architecture, nobody will.
    (0) 
    1. Murray Spork
      “Good architecture” takes into account things like budget. Architecture (and design for that matter [1]) is largely about understanding constraints. An architect that takes an adversarial and “purest” mentality to their role is rarely effective in my experience.

      [1] to quote from a Charles Eames interview http://redalyc.uaemex.mx/redalyc/pdf/375/37504907.pdf :

      Q. Does the creation of design admit constraint?

      A. Design depends largely on constraints.

      Q. What constraints?

      A. The sum of all constraints. Here is one of the few effective keys to the design problem – the ability of the designer to recognize as many of the constraints as possible – his willingness and enthusiasm for working within these constraints – the constraints of price, of size, of strength, balance, of surface, of time, etc.; each problem has its own particular list.

      (0) 
      1. Thorsten Franz
        I agree strongly with your point. The art of an experienced and gifted architect is to discover, correctly assess, weigh, and balance all the relevant constraints.
        I visualize the problem as a sort of spider’s web where each radial string represents one particular aspect of constraint or requirement, and the tension on each string represents the importance or force of this constraint. Together, they form a vector that defines the shape of the web and the position of its center.
        If the architect fails, important constraints will be left out of consideration in the building of the web. Later, when the constraint comes and exerts its pull on the web, the whole thing might be torn apart or be deformed beyond recognition. I think I should blog about this… 🙂
        Cheers,
        Thorsten
        (0) 
  2. Thorsten Franz
    Wow – that is an extremely strong blog post, full of valuable insights and things to strive for. I can’t say that I fulfill them all – not by a long shot. 🙂 But every aspect you mention is worth working on, learning and striving to become better.
    And I agree that it is especially gratifying when you’re able to make a difference and support someone who eventually spreads their wings like a fledgling and takes off to earn their own merits. 🙂
    Best regards,
    Thorsten
    (0) 
  3. Michelle Crapo
    This is a great blog!  It goes into a lot of interesting points.  Most of which I agree with.

    However, I do have a different opinion about this statement “Make sure they can concentrate on what they do best: development.”.

    I like to do a little bit more than just development.   (  Just a developer?! )

    But I may just be misunderstanding the statement.  “Development” isn’t just programming.  I tend to have strong feelings on that point.

    Michelle

    PS I love Dilbert too!

    (0) 
  4. Matthias Steiner Post author
    Many thanks for all the positive responses so far! Yes, Dilbert is really a legend – and the only way to cope with some situations at work 🙂

    @Michelle, I read your blog a while ago and I do agree to you. It’s just that my current team is facing though timelines (as usual), yet there’s a lot of stuff distracting them coming from the outside. From my experience the big picture is very important as you make your point – and a requirement to really empower the team to work on their own. So, what I meant is protect the team from outer distractions like politics, etc… it’s not about treating them as code-generating slaves – the opposite 😉

    (0) 
  5. Priyanka Porwal
    Hello,
    loved reading your article. More so because it uses humour in a very effective manner and at the same time conveying what is the essence.

    There are lot of things to learn from your article. Will try to pratice them as well.

    Thanks and Best Regards,
    Priyanka

    (0) 
  6. Claudine Lagerholm
    Thanks for posting this blog, Matthias!  It will be a good resource in the Career Center as well. We need more blogs like this one.  I like the fact that you talk about the value of improving one’s communication skills and coaching others. Nicely done!
    Claudine
    (0) 
  7. Matthias Steiner Post author
    Wow! I’m just very thrilled to see the amount of positive responses on the topic. Thanks to everyone who took the time to comment – there’s soo much value-add to the blog post!

    In general, yes – I outlined the perfect architect. I’m not saying I shine on all of them at any given time either… but I’m working on it. But that’s part of it… self-reflection and working on the weaknesses (e.g. patience :))

    @Murray: Great comment. Will definately check that interview out. Sounds like another set of insight 🙂

    @Thorsten: Yes, you should (as always) blog about it. 🙂

    PS: Wow… now it’s even featured on SAP SCN Career landing page: http://www.sdn.sap.com/irj/scn/careers

    (0) 
  8. David Hull
    I wish we could all come up with a consistent definition of Architect, it would many of us a lot of frustration. This is a good start to that!

    Cheers,
    David.

    (0) 
  9. Sebastien Locteau

    I just finished reading A Day in the Life being an Architect – modi operandi and really liked the writing and now this post is also very interesting.

    Thanks for sharing such experience

    (0) 
    1. Matthias Steiner Post author

      Many thanks for the feedback and taking the time for it! At the end of the day, blogging would be useless without readers so every feedback is truly appreciated!

      (0) 
  10. Matt Fraser

    Just came across this blog of yours, Matthias, for the first time, though it is now six years old. Yet still highly relevant. Oh, and I see it did make it to the Careers space back then, too.

    (0) 
  11. Jelena Perfiljeva

    …And I’ve just followed Matt’s “bread crumbs”. 🙂 2010? Wow!

    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 reminded me of an old (1990s) anecdote. A young lady of certain R-rated profession is sunbathing on a beach. A man approaches her and tries to chat her up. She gives him an annoyed look and asks what does he do for living. “I’m a factory worker” replies the man. The woman answers: “then imagine that you go to the beach and all you see are machines, machines, and machines…”. The man gets a hint and leaves.

    Another young man approaches and she also asks him what he does. “I’m a system administrator!” he replies. “Then imagine you go to the beach and there are only computers, computers, computers…”. Young man interrupts her excitedly: “Yes!!! And they are all Pentiums!!!” 🙂

    P.S. I guess the joke can be spruced up for the Millennials by replacing Pentiums with HANA or, dunno, iPhone7?

    P.P.S. Good blog, btw. 🙂

    (0) 

Leave a Reply