from Hacker News

Ask HN: Advice for a new Technical Architect?

by atsushin on 7/15/22, 3:53 AM with 4 comments

I've been at a very large firm / project for a little more than a year working as a backend developer. During that time I've accrued a decent amount of technical and domain knowledge about our system, enough that they've placed me as a technical architect working with two teams for an upcoming release whose deadline is about a year from now. Given most of HN consists of tech-oriented folks, I was hoping to get some advice on how to thrive in this new role both from a technical and leadership standpoint, as I feel I am still getting my footing in adjusting to this sudden change.

  • by ianpurton on 7/15/22, 9:11 AM

    A few tips

    - Some people don't want to be told how to build something. So give them space, you can make suggestions but they make the final decision. Developers will move heaven and earth to fix a problem caused by decisions they bought into.

    - Any decision you make without buy in from the dev team will be considered to be your problem by the dev team. So if they hit any issues they will down tools and expect you to fix it.

    - An architecture without a working proof of concept is not proven. Only when you hit real code can you be sure things work together. If you suggest a solution, make sure you did a PoC or it's something you did before.

    - Some times the dev teams wants to do the PoC. Give them that space to do that.

    - Part of you job is to turn sub standard requirements from non technical managers into a real system. Start thinking of UI/UX and clickable prototypes etc. Improve the quality of the input.

    - If no one is going to use the system, then it doesn't need to be built. Make sure project sponsors have an answer to the question of "how you will get users to use the product/feature?".

    - Follow best practices. It's quicker. So Pull Requests -> CI -> CD -> Infrastructure as Code.

    - Have the mind set that you work for the dev team, they don't work for you. So rather than have the mindset of "it would be good if we did this or that", open a pull request and do it yourself now and again.

    Hope this helps.

  • by jacarma on 7/15/22, 7:37 AM

    The bigger fails I've found in my dev career are over-architecture. Devs that though they were able to ideate quasi magical architectures that handle every single use case and adapt to any future changes. The result: very custom architectures that force devs to do things in weird and complex ways and get outdated as soon as the promoter leaves the company. Everything becomes slow and devs get frustrated. Many projects are already using the architecture and it turns very difficult to remove.

    My advice: choose between the existing architecture options and stick to the standard as much as possible. Use existing tools and keep them up to date. Innovate in architecture only if your company has a specific interest in the architecture itself and they want to invest in maintaining it as one of their products (documentation, maintainers...)

  • by cutthegrass2 on 7/15/22, 9:35 AM

    My personal approach, after a decade in such roles - "Everyone owns and is responsible for the Architecture" you're just "Accountable" for it.

    Let the team drive Architectural decisions - you just ensure the ship to steered towards the overall business goals.

  • by scioto on 7/15/22, 11:20 AM

    Where I work, the technical architect is mostly there to get in the developers' ways and tell them when they're using obsolete/vulnerable libraries. Then quarterly they put together a PowerPoint presentation to show which applications are red, yellow, and green based on the above. Now and then the TA will butt into a big project's kickoff to make sure they can bill hours to the project. Then the TA goes into hiding until the next quarter or big project kickoff. I still don't know the TA's name, but they don't get in my particular way, and that's important.

    Edit: clarification