Ask HN: I've been promoted to Architect. What do I need to learn/do to excel?

Thank you!

Honestly, I was just doing my job. In the end, I think I was providing valuable feedback that lead to decisions that, over longer periods of time, proved to be valuable. So I was asked to collaborate more on technical decisions and providing design ideas.

I'm in a country that puts a lot emphasis on "formal education", so having the certifications is relatively important but I do believe they were, in part, a waste of money, due to how/what was actually taught.

Actually, that's a skill he'll probably need to learn extremely well, depending on his workplace.

Yup. My advice was going to be “Delete it” .

    Clear goals that we widely communicated allow normal 
    people to make design decisions autonomously. It can 
    really remove the need for constant daily updates and 
    information overload (for you)

That one is so important and yet so rarely followed and also surprisingly difficult to do.

> Clear goals that we widely communicated allow normal people to make design decisions autonomously. It can really remove the need for constant daily updates and information overload (for you)

If you don't mind, could you provide some examples of this ?

Learning to love incremental change is great advice. The challenge that comes with that is being able to "sell" those changes.

Big Bang changes have obvious benefits but the individual incremental states often don't justify the change by themselves. You have to become really good at selling the overall vision while also keeping people focused on the short term objectives. Holding the two in balance is a really tricky thing to do but, I think, represents the core value of a good architect: they are the navigators who can describe the destination but can also describe the next turn to take to get us there.

To latch on to this comment, I found http://boringtechnology.club/ to be a really good resource; mostly the slides in the middle somewhere that explain that adding more technologies = cost. It's important to say no, to put a hold on people's enthusiasm for new tech in favor of sticking to a tech stack, and that adding more tech, or shifting tech, is very expensive. Rebuilding an application will likely cost more than the original application cost in the first place. Etc.

But I admit, it's a hard balance to find; you want to choose boring technology for your business, but for hiring you want to choose exciting, new technology because people generally don't want to work with boring tech when they're looking for a new job.

On that note, keep in mind that you will likely also be a project manager and responsible for hiring and / or indicating that your company needs to hire people. You have been empowered, it's up to you to push to your management to make investments in e.g. hiring, training, etc.

> Large changes almost always fail. smaller incremental changes always feel less thrilling, but when you look back over a year, they will accomplish a lot more. Plus its far easier to course correct.

Well, it all depends on the actual stack being used. If you are on dead-horse technologies or superseded dependencies with major breaking changes (e.g. JavaEE, OpenSSL 1.0.x -> 3.x), you can't avoid big changes.

Moving fast and breaking things is a way to force changes to legacy systems, where the tech wasn't ready for it (e.g. moving from monolith to microservices)

> 1) learn to say no

This is difficult for me. I think part of my success until now was a strong "can do" mindset. Thankfully, I have a superior who is extremely skilled, both technically and in professional cut-the-bs skills, so I'm trying to learn.

Regarding small incremental changes, one of my favorite quotes is from Michael Lopp (aka Rands): “Don’t underestimate the compounding awesomeness of fixing small broken things.”

If you’re working in sprints or iterations, try to include one thing like this in every sprint. Fix the logging that generates too many log entries. Improve the error handling in a problem area of the code. Add some retry logic to something that fails occasionally. I always try to keep a backlog of small things like this, and work them in wherever I can. Over time it makes a huge difference.

> Or you'll be asked to allow team x to use a new widget, instead of the old one. But then team z will want to use a different new widget to do the same thing.

THIS.

I'm a senior developer in a large org and this happens constantly. I was in one department who just about every few months was using a new JS framework to build medium sized, dynamic apps. After a year, we had four or five of these apps, all on different frameworks, and a huge technical debt because all of the framework knowledge was tied to a few individuals. It was great to build something the way you want to and test out new frameworks - but in a large org, all it did was create a ton of chaos down the road.

Now, the team has been tasked with transitioning the apps to a single framework - no simple feat when you have thousands of daily users and no one wants to give you the budget or time to re-work all of these applications.

Like OP said, stick to your guns and learn to say No. You might have to stand by your decision, but you have to really be thinking ahead and what's best for the org. Letting a dev team run wild and do what they want will kill you down the road.

In many environments instead of #1 "Say No", you may be better to say "I'd like to understand".

Then listen & ask questions, until you've fully heard their problem and can propose a preferable alternative and what design values it better aligns with.

(If you can't answer immediately, tell them you're really interested and will look into it & get back to them in eg. two days.)

In larger environments architecture can be like steering a vast river using a small wooden paddle.

A thousand times this: "Do not divorce yourself completely from code. Nobody likes ivory tower architects."

I haven't found this to be realistic: "Excel at one cloud provider services."

Oh I forgot one thing. It's ok to make mistakes and change your decisions. Sunk cost fallacy is a bitch and you have to be aware of that (sometimes it's cheaper to fail than do everything to be right)

I completely agree with the need to be a practitioner. In my experience, a good architect can create a POC project to demonstrate that their approach will work. It's not necessary to create a POC for every little thing, but it sure helps when the team is dealing with a new stack or large/complex project.

> - be realistic - most businesses don't need super-high-tech-microservices-based-kubernetes-mesh-powered architectures ;)

At my company, we developed a monolith that eventually reached the point where it couldn't scale anymore with the same design and was becoming more difficult to modify and update. Then over time migrated to a super-high-tech-microservices-based-kubernetes-mesh-powered architecture.

Which is to say, I agree with you. It is counter productive to start with the super-high-tech-microservices-based-kubernetes-mesh-powered architecture at the beginning. We certainly would not have came up with the specific microservices and technologies we ended up with, and never would have had a viable system to refactor at all as the microservices would have taken much longer to develop up front and iterate on than the monolith approach.

> attend both developer teams' demos, plannings and product teams' meetings

This is critically important. I try to cycle through my team's standups through the week so I know what's going on with them and what challenges they're dealing with. Often times I've found teams will raise issues during standup they won't raise at a big cross-team meeting.

As someone that has no experience with the role at all, but had to deal with some… special people, I feel the first three cannot be overstated.

Your job will be more one of herding people into doing things the right way, and it should never be one of you doing all the interesting decision making or prescribing the whole structure from the get go.

Talk with people, make sure they are invested in the overall architecture as well. And don't assume someone didn't think it through on their own until you discussed their ideas.

People who do all the architecture planning themselves, even if they aren't butting heads with anyone, can have a really negative impact on the team as a whole, because all other team members stop worrying about the topic and just let the other guy do it. I already had to deal with outcomes of this; code that has been written by "drones" is nothing you want to work with.

Thankfully there are no architects in Amazon: 99% of teams have SDEs and SEs.

Or putting in other words - keeping technical debt in check (as it comes mostly to non functional requirements)

Architecture is also really useful in another regard: making the right (or at least "good enough") decisions on things that will be really painful to change later.

Think for example the choice of programing language or the DB technology used.

Architecture must strike the correct balance between vague guidelines and over-specification upfront. It should provide a framework which ensure homogeneity between components without restricting the teams/developers excessively.

On this subject, I found this presentation (by Stefan Tilkov): https://www.youtube.com/watch?v=PzEox3szeRc

Also, I'm currently reading "Designing Data-Intensive Applications", which is quite interesting and full of insight on the architecture trade-offs for data management and querying.

Or if you can't minimize complexity - because the problems are irreducibly complex - try and contain and partition the complexity, so that there's a limit on the complexity that developers need to be aware of when working on any given area.

Complexity partitioning is fractal, from functions to objects to modules to services to deployments. The architectural focus is higher up the stack.

Avoiding complexity spillage, where distributed areas of a large application share global invariants, is a challenge, particularly when trying to scale up the development team, which will force one's hand on splitting out modules and services or service-like things (e.g. FaaS jobs).

I guess every company defines the architecture role differently. When I worked as an IT architect we never talked with developers or even looked at their code. There were 2000+ developers and less than a hundred architects. What it sounds like you are describing is a senior or lead developer role.

You are describing a good engineer.

> they make sure the code is organized in a meaningful way

> code conventions used in a project and help to enforce them with tooling (git hooks, generators, PR reviews, etc).

Finally, something where I can say "ha! that's exactly what I'm up to now". This right up my alley, and I'm hoping to make some good progress soon here.

Again, those aren't architectural activities. They're organizational, so the responsibility of a team/group leader, or an SDLC facilitator.

Architecture is about the function of the system and how it interacts with its environment. That requires understanding both of those elements, functionality, and environment.

That’s not architecture. The tasks you describe are those of a development lead or dev manager.

An architect might also be a dev team lead, in which case they might have such responsibilities, but the point remains that such detail oriented aspects of the development process are what the dev team lead does.

The job of a building architect isn’t to ensure the builders know how to use their tools and keep them neat, and to ensure they measure straight lines.

The role of the architect is to design the system at a high level to meet a myriad of business and other requirements such as performance security reliability interoperability extensibility etc etc

The architect is politician, diplomat, technical strategic planner, salesperson.

This.

These are how you appear to developers as a _useful_ architect. Sure, there is a lot of other tasks that they do involving design and planning for the future - but the only way as an architect to actually impact software development is to take a hand in building it.

Every architect that I have worked with (my title has been "architect" for awhile now) that didn't spend at least 50% of their time in code was more or less a pretty picture generator - whose documents were ignored by anybody actually building the application.

> The first designs how systems work internally, the other designs how systems work together

The lines are somewhat blurry over here. I've definitely been involved with both of those.

Awesome XD

A "lead architect" whose default is excel? Very convincing.

(edit: but I do get the joke now..)

Look into VBA too. Might be useful if you get in software one day

Many games do the opposite and have a "Excel screen" mode for that.

Just play Eve Online and you'll be in Excel anyway.