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.

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

+1 for this. We've been struggling for a while with backfilling roles, and it's killing projects. But only one person was clamoring for more bodies and specific skilsets -- and they didn't have the budget for it. Once another PM and an Architect started on the "we need new blood" chorus we finally got some extra hires and contractors (that is, 1 hire, and 3 contractors -- but that was enough).

As an architect you're going to have to foresee that kind of stuff, and then advocate for it. "We might be able to get by without [X]" means we don't need that to accountants, so you're going to have to pick battles.

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.

    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.

I'm a big proponent of this thought, though I wish it worked better in my day-to-day.

There were many times where I spend considerable effort into communicating goals and the background of why they are important but with sub-par results.

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.

> 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)

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

> 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 ?

Some examples:

- Because 5 out of 6 outages the last month were related to simple regressions, we have decided to improve automated test coverage. Every service must have at least 90% unit test coverage and at least 1 integration test for every happy path before the end of the year.

- We will turn off supporting system XYZ at date ABC because of reason DEF (say, it violates GDPR and we don't want that liability). The recommended replacement is system GHI. All teams that use system XYZ must migrate off it before ABC - 1 month and provide a clear plan before ABC - 4 months.

- Market research indicates that potential customers recognize that we have a lot of features, but they perceive us to be slower and this is causing them to prefer competitor X. We want to win this customer group and therefore: 1. Every new feature from any team must be benchmarked to ensure it does not impact speed-related metrics A and B (time to first paint, for example) 2. Teams X, Y and Z should spend about 50% of time this quarter identifying and fixing performance issues.

- Example from the navy: We know based on intelligence reports that the enemy has no submarines and has recently acquired a big batch of air-to-surface missiles. Therefore, when choosing priorities for repair, anti-air system have priority over anti-submarine systems.

Important for autonomous decision making is not just communicating the priorities, but also WHY those priorities were set. In the navy example above for example, knowing why anti-air is more important can further guide personnel into choosing properly, since there might be systems officially classified "anti-air" that are not useful against air-to-surface missiles but only against helicopter or whatnot. The military calls this extra communication "commanders intent". Of course, letting people make decisions autonomously requires trust on both sides. It is worthwhile to invest in this.

How are these goals the responsibility of an architect. These are operational requirements that might need changes in a system's architecture, or adaption of interfaces.

All of these are requirements, not architecture. Architecture is about satisfying those requirements along with all the others in a cohesive and structured way.

My guiding quote is "Design is about constraints" from Charles Eames. Find and explore those constraints and you will be able to determine the architecture.

They're intended as "Clear goals that we widely communicated allow normal people to make design decisions autonomously" as per the parent post. In any case, architecture can be just as much about setting the constraints as it is about discovering them.

These goals should really be unique the company.

But as the head architect, its your job to figure out where the company is going and design goals to get them there.

A standard problem is monitoring, or more than one way to host/deploy something so good long term goals might be:

All services must be on platform p

All services must use <<CI system of choice >>

All systems must emit metrics according to spec 1.0

system z will be turned off by march 2021, migrate to new system y

These goals are clear, measurable and only have one instruction. They are not prescriptive.

These goals can be given to the team leads to figure out how to do. You then have to watch them and try and gently steer them away from making new legacy/snowflakes.

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.

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

You can and should keep the "can do" mindset while learning to say "no". Key is to say "no" by saying "Yes, this is what I need to do it".

Doing it wrong #1: Boss: Hey, can you be the architect for system X? You: Yes, sure, my schedule is full but I'll just work weekends and screw up work-life-balance.

Doing it wrong #2: Boss: Hey, can you be the architect for system X? You: No, I don't have time. Boss: Your attitude sucks. I'll replace you.

Doing it right #1: Boss: Hey, can you be the architect for system X? You: Yes, I'd love the challenge My schedule is full, can you assign some of these tasks to someone else?

Doing it right #2: Boss: Hey, can you be the architect for system X? You: Yes, I'd love the challenge. I'm fully booked until Novemver, how about I schedule this for December?