You have to learn to write, and get comfortable doing it.

When I was the (de-facto and later de-jure) architect, I was too reliant on in-person synchronous discussions. I neglected my e-mail and design-document skills.

The result: everything had to be synchronous. Chat was a wasteland. Decisions where one just had to Sit Down and Think wasted multiple people's time. I realized I was subconsciously avoiding writing long documents.

Part of the problem was - no kidding - I needed a new glasses prescription. But mostly I just needed to get used to the act of sitting down, drafting, and writing a design document. I also needed to encourage the team to have a bit of discipline and design before coding.

Later, as I transitioned out of a "move-fast-and-break-things" place to a large open-source project, my learned avoidance of writing definitely hurt me. I was not practiced at asynchronous design and development.

I've been an architect for a long time and have written a lot of tech documents and can say with confidence that no one ever reads them.

I like to Ha Ha Only Serious that the ask for documents is just a standard technique for getting out of having to care about whatever it is you're talking about. If they ask you for documentation, and you don't have it, you automatically lose and they get to ignore you.

If you always have it, eventually they stop asking you. (Until someone new joins and tries it on you.)

Cynicism aside, it's useful stuff anyhow. Rubber ducking is a well-known debugging technique where you describe your problem to someone who doesn't have your context, even if it's only a rubber duck, and the mere act of describing will often reveal the problem. Writing documentation for other people is the closest equivalent for rubber ducking at the architectural level. When you're sitting there writing the complicated things you have to do to do X, you get an outsider's view of the situation. Take that and use it as motivation to fix the problem. Try very hard not to be just cynical about it and let your sensitivity to that signal become calloused... it is incredibly useful!

>But mostly I just needed to get used to the act of sitting down, drafting, and writing a design document. I also needed to encourage the team to have a bit of discipline and design before coding.

In the architect role, I write a lot of documents as well, but mostly for the purposes of: 1) Organizing my own thoughts 2) Summarizing for the benefits of upper management 3) Influencing discussions with peers 4) To serve as a record that someone interested can refer to

The documents are generally higher-level and tailored to the audience that I intend to read it. In very rare (none?) cases am I ever getting detailed enough to get to this is exactly how we're doing it, since what I'm really trying to do is to set the overall direction and goals in pursuit of strategic objectives. I let the experts in individual domains handle the details. The entire process is also iterative. I build consensus through synchronous, high-level discussions ("wouldn't it be great if") and, through those, get a handle on the challenges faced by various orgs. I then try to coalesce that into something that benefits each org in some way, while still serving the overall objectives (developer velocity, flexible infra, performance, etc). My goal is to influence & inspire rather than dictate and own.

Worse, hardly anyone ever updates them.

But you still need to write, not necessary a speciation or tech document but all kind of notes and summaries for yourself. So that the you in two month can go back to a decision dinner two month before and reevaluate it with your new knowledge.

Also depending on the company they might give you the task of writing a less technical describing if the system for e.g. investors.

Lastly in my (little) experience asynchronous communication interleaved with small amounts of synchronous information discussions is king when it comes to the doing complex technical decisions (like which database or architecture to use for the next project).

But then I don't have too much experience in this area so take it with a grain of salt.

I'm on the ops-architect end and I read design docs and usually steal all of the plantuml and everything else I can find as nobody ever (aside from the developer of the feature) can help me track down or troubleshoot problems and I find most developers to be very disorganized (I was too until recently and it's still something I work on daily). So the documentation is appreciated. I also write a lot of ops-focused docs and tools, like stuff to lower MTTR and just generally help my ops teams relax and be lost less often when alerts come in. An ops person should never get an alert at 2am and be completely lost, no playbooks or guidance or anything because a lack of implementation documentation, I've been there, it sucks and will make you regret your employment.

I don't think most of that gets read either. But I still do it. I just assume most people are siloed in their own projects and barely have time to get those done so reading ancillary stuff is on the backburner. But if some emergency ever comes up at least it's there and if I'm on a mountain I got everything out of my head so you won't need me to walk you through how something works over the phone.

With that said, I face immense frustration when I go into a microservice repo that is scaffolded hoping that some golang developer updated the readme to actually be relevant and not the scaffold template and 99% of the time for internal stuff it's never, ever touched. Please do some documentation for Ops/new-devs, etc. That extra 30-2 hours of work will save half a day of some new person trying to launch your service in KIND or whatever, now compound that over every new person/outage/time you've had to explain something that you didn't document. The readme.MDs in every single one of your microservices should not be a base template with zero touching. It's not hard work to give someone who has never touched it some breadcrumbs on what your service does.

Half the time I go in there when something is already broken and the stress is high hoping for simple stuff to get me going, even just some basic UML of what apis its talking to, what kubernetes resources it needs, what RBAC permissions, etc. Think of yourself having never touched the service and leave some pointers/best-practices for someone who has never touched it or troubleshot it (like your ops people when you throw it over the fence for deployment).

Having to figure out your microservice architecture via container logs when SHTTF is miserable.

I've heard it said that a plan is rarely followed but the act of planning is invaluable. I wonder if writing documentation would fit similarly.

People should accept the fact that people are busy and often don't have/take time to read documents offline.

I really like how Amazon mitigates that, you hold a doc review meeting. Everyone gets together, reads the document (in silence for ~30 min, or however long it takes), and then discusses. Then you know everyone has the proper context and knowledge for a good discussion.

I think document is good for filling the details, but it will not solve all the problem . And I kind of hate Architect with an extreme authority from top to the bottom and just assume people know everything. From my experience, casual communication between developers is an important factor in software development.

The perfect role of architect I believe is an individual contributor. People just come to ask your idea and respect you to make the majority of design. And you need to help other to understand your idea.

This depends enormously on the culture of your organization. And in a high-level role like this you're in a strong position to shape that culture.

I honestly don't think it's even valuable to write them. It's a manifestation of BDUF. The more detail you put into a document up front, the more wrong assumptions you're committee to paper. It's basically a guess. Same reason we've adopted agile as a mindset, architecture needs to be agile too. Documenting a system as it's built is much more useful.

For context, I mostly work in consulting. So I don't have a lot of authority to impact culture as much as I try. Doing handoffs is a big part of my job and even if I hand off a detailed explanation of everything we've done, I'm still guaranteed to get asked about everything I've already written down.

I'd much rather have a clear record of the assumptions made & rational for them than have to discover them later when problems crop up.

Agree this is probably the most beneficial application. You can reference it almost like a contract.

How do you get people to read things? I've also written plenty into the void, and have no idea how to get people to actually read things (without being a jerk about it, which is not the culture I want to shape).

While I don't make people read things, but if the answer is in something that they should have already read, I do use their questions as a teachable moment. Instead of just giving them the answer, I tell them where to find it. Usually with a friendly note indicating that the docs are usually the quickest way to get an answer.

The old teach-a-man-to-fish adage, if you will. Some people never learn, but I'm still not unfriendly towards them. Although, I do start to silently de-prioritize their questions over time. Most people do learn though, and they're the ones that start asking for clarifications instead of complete answers.

Things I've found useful:

* Use a platform where it's very easy for people to give feedback. I've used Google Docs and Quip.

* Write documents when there's real disagreement about how something should work.

* Ask specific people for feedback on your documents.

* Ask other people to write things, read what they write, and leave good comments.

* Have a regularly scheduled meeting for reviewing team documents to get feedback. Anyone can sign up with a doc they want reviewed.

Also:

* Write clearly & concisely

* Use good headers and provide a table of contents

Here are some useful resources for writing better:

https://www.plainlanguage.gov/

http://www.hemingwayapp.com/

I frequently write architectural documents and as a team we find it a very useful way to collaborate. We structure them as RFCs (meant literally, in that the document is designed to solicit comments, and so are often proposals). I've never had an engagement problem with them.

I, on the other hand, try to write technical document to not have to answer the same questions twice. When some one ask me anything that I have a doc cover it, I give them the link. If I don't, I answer, then check and update my doc. That works well for me so far.

Me too.

I have colleagues who do the opposite. They often complain that they don't have the time to write documentation because they have to explain stuff to people all the time. Thus, I believe writing saves time eventually.

On the other hand, everyone reviews the figures in detail. Therefore I’ve always used the text as a way to document the decisions behind the figure, mostly for myself, and to clarify any ambiguity in the figure itself.

Write an overview in narrative, and the rest in headings and bullet points.

Keep the substance to 1-2 A4 pages. Nobody sane wants to parse more than a tiny bit of narration.

Try to use Wiki, Google Docs, or shared docs in Office 365 if at all possible. Email chains are a collaboration fail, and Word docs are where information goes to die.

As someone currently migrating a rusty old Oracle enterprise system, please write documents. Migrations always blow up in complexity because someone didn't realise that there were 20 feeds from X DB and that a decade of hacking lived under the skin of their simple workflow system.

Same. I Always talk and discuss with diagrams, the more colourful the better (like AWS components).

Agree. Usually when I write a document, it's usually centered around a few "hero" diagrams, with most of the text explaining it. Afterward it's always the pictures that are the most useful for me, but maybe we're just visual learners!

It's ok if he didn't, comment was positive way to say what he does instead of saying that was crap.

> avoiding writing long documents.

Just to pick on this bit: You should still avoid writing "long documents". Spend the time to make your documentation as concise as possible. And make no mistake, making it shorter is much more effort and takes longer:

    "I would have written a shorter letter, but I 
    did not have the time." -Blaise Pascal, 1656

Nobody reads big, long wall-of-text documents. Break things into smaller sections, and be sure each section has a clear audience in mind (developer implementing initially? support debugging a production problem? QA building test cases? tech writer making user-facing docs? PM?).

Good rule to retroactively build up your docs: When someone asks a question, answer it with a link to the docs. Sometimes this means writing new documentation.

I fear this is great advice. I too avoid writing documents. Or even reading them. I want to have my hands in the code, but it's increasingly clear to me that I need to write more stuff down.

I don't fear writing documents, but i do work with a lot of people who do fear reading! I've found a really good trick is to highlight key figures or a few standout grabs in the early paragraphs of the text and then to have more substantial higlights towards the meaty parts of the document.

Essentially it's like having the bullet points and full document in one. It;s resulted in a lot of people getting interested up top and being tricked into reading down the bottom.

Give it a try sometime.

For sure. Part of being a successful writer is communicating in a way that is most effective for your audience.

Rarely is a wall-of-text the right answer. Bullet points, flow diagrams, and examples are all helpful techniques when writing for engineers.

I had/have the same problem, what helped me a lot was to write down what I've learned (roughly bi-weekly). Another booster was to stick to the same document structure for example NABC for proposals and ideas.

NABC: https://nielschrist.wordpress.com/2012/07/13/the-nabc-method...

Writing would be valuable to me even if nobody else ever read the documents. I find that writing helps me think through a problem much better, and in the end I have a better solution.

Learning how to make concise, effective infographics is a part of learning technical writing.

A picture may not always be worth exactly 1000 words, but images with high cognitive density are usually worth putting into your document.

I can't stress how important it is to get good at writing design documents and producing effective diagrams. If you do not produce these artifacts, it is very difficult for your developers to do what you want them to do. You end up spend way more time re-explaining yourself than you would have spent documenting.

Do you have any advice or tools for diagrams? That's one area I struggle with, and usually have to pull in our designer.

PlantUML if you want to maintain the diagram in version control.

yEd for interactive use because of its auto-layout function. Not unintuitive to use though. It takes some effort to learn.

Enterprise Architect if your company pays the money and you really need its features (e.g. SysML diagrams).

Whatever is close by. For example, we use Confluence for our wikis. It has a Gliffy plugin, so I often use that for embedding diagrams.

I've seen photos of whiteboards, drawings in MS Paint, and other stuff. The tool rarely matters. What matters more is the content. A few tips for that:

Have clear meaning what a box means and what an arrow means. Don't make it inconsistent like "this box is a server, this box is a software component, and this box a message". If you need multiple types, then draw them differently (colors, rounded corners, dotted, etc).

One statement, one diagram. Don't make multiple statements in one diagram like "Here you see we send do more messages then necessary and you also see the undesirable coupling between Foo and Bar". Ok, there is also value in overview diagrams to show "everything" but those are for live use in discussions and not for documentation which should be understandable on its own.

Thanks!

draw.io (which is now app.diagrams.net) is all I've ever needed. I got my company to buy the Confluence plugin for it too. It's free to use by itself.

This is a great advice. Do you know of any publicly accessible design documents that you would consider good (to serve as An example)?

Thanks, I feel this is great advice!

I used to insist on writing down the things that were just floating around in the heads of the more experienced team members, and it went really well for a time. I was part of the effort that pushed for better infrastructure for documentation, and we did get it in the end.

But, alas, this stalled and so did the excitement about having documents.

> Part of the problem was - no kidding - I needed a new glasses prescription.

Huh, what did the glasses have to do with it? Old prescription making it hard to read text for long periods of time?

Yes I've suffered the same - farsightedness making it hard to focus literally and a slight astigmatism where one eye focuses a little better than the other combine to increase fatigue and make prolonged writing very difficult

With glasses my whole mind relaxes and I can settle right into the zone

Yeah, same here. It turns out I could focus, but it took a lot of brain power to actually and understand text.

Getting new glasses lowered the cognitive load.

Yes, and in my case, it's still hard to read text off a backlit screen, even with the right prescription. I have to use e-ink or paper if I'm going to be reading for a while.

Congrats!

1) learn to say no

2) learn to make simple enforcable short, medium and longterm goals (ie, everyone must be on platform x by november)

3) learn to listen

4) learn to love small incremental changes rather than big bang

why say no? because you'll be bombarded by brilliant solutions. On their own will be great, but in your environment will be tech debt. 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.

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)

Some of the best insight into a product or thing will come from a junior whos only just joined. Make sure you have regular contact with all the teams, if only to steal ideas.

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.

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?

Congratulations. I've been in exactly the same position many years ago so I can share with you some of my insights.

I've proceeded with my career keeping those on mind:

- listen to what people say, you can't and won't be an expert on everything

- when you listen to them - verify and deepen your knowledge on topic, it's good to be able to connect dots

- be a practitioner - there's nothing worse than an architect that doesn't know how to code/configure server etc ;)

- attend both developer teams' demos, plannings and product teams' meetings - context is king and as an architect you have to see things both broad and narrow connecting technology with business needs

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

- remember that architecture is about structure, guidelines, policies and order that aligns with business needs (so this is the starting point - understanding what business tries to achieve). Technologies really don't matter - they are just a tool

- always assume that you don't know everything - challenge your own assumptions

- be authentic and polite - people don't like super-star-asshole-know-it-all-architects (been one, don't recommend that :))

Good luck!

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)

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

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.

Also not great. An "architect" once threw a POC at my team like "hey, look at how easy it is to do this!", then other people started adding requirements and then wondered why it took us that long if the "architect" can throw something together in an afternoon. The POC was completely unusable for the end product.

> The POC was completely unusable for the end product.

That's why it was called a proof-of-concept, and not an end product, I think. But if it was unusable, then it probably tried to prove the wrong concept :)

Just want to agree fully! I've been known to say that an "Architect" who doesn't code is no better than a bullshit artist. Architects don't necessarily write production code (they won't have the time/bandwidth) but they should be (at least involved in) coding up PoCs and key abstractions that have impact across a range of systems (in existence or to-be-built).

Architecture is a process not a product.

I think that it's both actually as architecture as a process produces some artefacts (diagrams, decisions, PoCs, guidelines, policies, structure, knowledge, roadmaps, etc)

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.

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

I have worked with only 2 architects who have made me understand what it means to be a good architect. 1 they make sure the code is organized in a meaningful way - consistently, and using places and patterns which make it feel easy and obvious. 2, they determine the code conventions used in a project and help to enforce them with tooling (git hooks, generators, PR reviews etc).

This helps scale a team, and build a cohesive lightning fast unit.

I’ve worked with fantastic devs in the past who had no real understanding of this kind of “architecture”, and as a team the difference was clear.

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.

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.

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.

You are describing a good engineer.

I think I have three architects in my team.

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.

I think the big point is that developers should trust you. One of the best ways to achieve that is to participate in coding a little. My experience says the architect should avoid the critical coding and focus an quality topics. For example, style unification or linter fixes.

A corollary is that you also need the trust of other stakeholders.

For managers I'd say you need to communicate confidently and deliver. The trick with delivering is to lower expectations early.

It depends on the organization what other stakeholders there are. That is a good separate point actually: Know your stakeholders. Make a list and ask them about their expectations.

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

Independent of being an architect, it will make sense to clarify what your authorities/responsibilities are. What are the expectations from your colleagues and bosses?

Is your role more a consulting one, because the teams should have a high degree of autonomy? Or are you held personally responsible for the (architectural) decisions, and therefor should have the authority to take the decision (which doesn't mean, you should not consult others).

What is/should the "border" of your personal responsibility starts, and where is it more consulting?

Do you only define (or facilitate to define) the top-level architecture, or are you responsible for a complete top-down design of the software?

Are they hoping for a detailed structured approach going even into the teams? Or "only" someone keeping an eye on the big-picture / having a long-term vision? Or all of the above and more?

So, in a way, the same steps to take as an architect in software. First find all the stakeholders involved (bosses & colleagues), gather their requirements (what do they _really_ want from you), facilitate an agreement between the stakeholders about the outcome (chances are, they too many and even conflicting things). Then you should also be closer to know, what you need to learn.

Number one: don’t get hung up on it being a ‘promotion’. You’re playing another, more specialized position, but you’re just one player on the team - not the boss, and you can’t make every decision about how the software gets built (that won’t scale, and if you’re doing that, why do we need all these other developers anyway?)

It’s not your job to tell everyone what to do. It is your job to take the time which developers typically aren’t afforded to learn more about the relevant context of the problem than they can, think, plan, and prototype and bring back and share that additional information you have learned with the team.

The job is, at its heart, to help software developers be able to make smarter decisions.

So the core skill winds up being communication - learning how to understand what the developers on the team are thinking, how to explain constraints and opportunities to them, how to collaboratively problem solve, and how to resolve disagreements among devs about what trade offs to prioritize.

> The job is, at its heart, to help software developers be able to make smarter decisions.

If anything, I've found that it strongly resembles Confucius' mentor/subordinate writings. The mentor is frequently below their subordinate. Code quality/mechanical sympathy is a constant struggle, but my teams are slowly improving. Decision making is less of a hill, my teams are rapidly learning to make really strong decisions (sometimes better than my initial decisions).

An architect should aim to teach their way out of a job.

Learn what everybody should know and then tell everybody.

In larger organizations (multiple teams on the same product) this might already be enough. Once you have a broad knowledge people will start asking you stuff and then involve you in decision making.

I would say the two most important things are to learn to simplify and to not be a yes man (and actually, to learn to be a no man).

This is something all developers experience, of course, but it's of utmost importance when you're responsible for the architecture. For every problem your company will face, business side will come to you asking with the idea of a solution rather than with a problem. You have to extract the problem from the suggested solution, then ask yourself how you can do simpler, not to overload the architecture with adhoc solutions.

And sometimes, you have to just say "no". Business side always have tons of ideas that they will insist on being high priority, then forget about it a week later or never use the feature if you release it. A nice trick is to make them prioritize the todo list themselves, so they feel the importance of each requirement compared to the others. Just forbid they put their last idea on top of the todo list, no matter how loud they're crying for it, or it will always be the last ones that are on top. If they put it somewhere lower, they will put it to the higher position they can, then they will re-evaluate its position correctly when looking at the todo list again later.

A lot of technical architecture comes down to minimizing complexity. When considering an approach, ask "how can we make this simpler?"

As a matter of process it is important to consider many different approaches together with the team, and weigh benefits and drawbacks of each approach in order to make the best decision.

Another big part of the job is to build and promote a shared technical vision among the team. This can involve establishing a technical roadmap, and principles/ethos which will be most effective if arrived at in a collaborative manner.

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.

Note that sometimes the right DB is one specific one. Other times it is enforcing everyone use a DB abstraction so that you can switch DB. If you choose the later make sure you have 3 databases at all times to enforce using the abstraction. Ideally one isn't sql.

Likewise sometimes you choose the language (or maybe two), sometimes you choose an inter language communication protocol and allow any language. Either can be good or bad. The right answer for you is important.

Some choices above are hard to undo if you are wrong. However the hardest to undo often have significant advantages if it all works out.

I agree with the idea that you should take most seriously the decisions that will be hardest to undo.

However, using a database abstraction layer in this way is counter to optimizing for simplicity, and in a way is not making a decision at all.

If you are using a database abstraction layer so thoroughly that you really can switch between different database implementations, then you are almost certainly not leveraging the strengths of any underlying database engine to begin with. So you are limiting your performance, at the same time as introducing complexity.

That is exactly the trade off. Which is why sometimes it is wrong despite the obvious advantages of being able to change

Moving from a DB engine to another, even if technically possible (right abstractions and everything), is often extremely painful once you have a few years of data.

(I'm currently involved in migrating quite a few large DBs, and it's a pain for everyone: SREs, support teams and the customers).

But yes, there is no "one size fits all", it depends pretty much on how your org is operating.

That isn't the only reason to support more than one engine. Sometimes you don't need to move data to change the engine.

If you sell a product that needs a database you probably want an abstraction so you can use the customer's database and schema.

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

Did anyone else misread the title as "learn/to do Excel", as in Microsoft Office?

(Edit) in case it’s edited: “Ask HN: I've been promoted to Architect. What do I need to learn/do to excel?”

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

Don't forget PowerPoint. As Michael Cote likes to say "I used to be good at my job, now I'm good at PowerPoint".

But in all honesty, being able to convey your ideas and vision to a variety of people and levels is key to being an architect, whether that is PPT, documents, charts, whiteboards, or just plain old conversations.

The best architects I have worked with were able to reach and convince senior business and IT leadership as well as the IT staff. Understand the why things are done the way they are done before proposing some new change, take time to listen. Status quo isn't always ideal, but it's important to understand the motivations and reasons before proposing your company or organization embarks on a new path. I've found frequently understanding the details end up being the key to a successful shift in strategy since that's the stuff that tends to bite you at the last minute and scuttle projects.

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

Real programmers run sed on csv files

You need to learn/improve

* Persuasion

* Negotiation

* Planning

Besides hard skills these seems the most important ones. I have seen good technical architects being bad architects because:

* They can't convince anyone that the ToBe architecture is worth it so any change has to be forced. This leads to a bad environment and overall lesser results.

* They can't negotiate other teams'/business' goals with the ToBe architecture goal so, again, the ToBe architecture can be only forced to the teams.

* They can't plan what is required to go from AsIs to the ToBe architecture. They can't tell you what's the most important change to be made, what should be done first and should be done in what order. This usually leads to an NobodyWanted architecture because random changes are being done.

Maybe introduce lightweight architecture decision records in the design process?

https://www.thoughtworks.com/radar/techniques/lightweight-ar...

I think it's a nice way of sharing with other engineers why and when decisions have been made about the use of a technique or technology.

I second the motion for ADRs (resources below). A side-benefit is that they use Markdown: plain and simple. Try to use Markdown (or similar) as much as possible. Once you are used to it, it is hard to go back to the insane formatting friction in a word processor.

[1] - http://thinkrelevance.com/blog/2011/11/15/documenting-archit... [2] - https://www.youtube.com/watch?v=LMBqGPLvonU

Congrats!

- strive for simplicity.

- when diagramming, don't force your audience to learn a new language made of weird shapes. Simple boxes, clouds, and arrows, go a long way, but clear labels and descriptive text are like a superpower.

- when a solution is proposed, ask what problems it actually solves, whether you have that problem, and if there's no simpler way to solve it in your case.

- anything you add to your development workflow has a cost. Always ask "do we really need it?"

- many architects/managers tend to forget that metrics are not produced in a vacuum and not all metrics matter. Anything you decide to track has a cost.

- if you ask your devs to measure it for you, you're removing time they should be spending doing dev stuff. Make sure it's worthwhile (e.g. it incidentally benefits their own practice).

- every new rule costs a freedom. Less freedom may lead to less agility. More freedom should come with more responsibilities.

Good luck!

- You need to learn to decide and consider when you need to be on the top of things, and when you need to be at the bottom of things (Donald Knuth).

- Helicopter perspective

- What are the capabilities of each component

- Functional capabilities (post correct financial figures to ERP system) Versus - Technical capabilities (upload transactions as exported from db flat files over SSH/sftp to dumpsite)

- Learn to summarize and distill information about your domains, as you now are working from a helicopter perspective in a greater degree.

- Learn to understand and be inquisitive about the entire value chain of your business and solution. Understand it end to end.

- There is going to be Powerpoint, at least exeutive summaries, 1 pagers et cetera

- SIPOC is a good way to analyse left to right architectures, both for analysing solution architectures and processes.

Don't stop building. You won't have as much time to write code so pick your battles wisely. I would focus on making sure that the code you write makes everyone else on the team more productive. Focus on tooling and frameworks that remove boilerplate and make writing systems that are correct by construction easier.

Learn to write then learn to write well. You will need to communicate complex ideas in ways that even the newest member of your team can understand. Aim to be concise and precise.

A bonus would be to learn formal methods. Being able to model a complex system with many moving parts in an abstract way and check that your requirements and every invariant holds will help you manage complexity. Pick up TLA+ or Alloy. It pays for itself in dividends.

The "Architect" role varies from business to business. If you don't understand exactly how to be successful in your current role it sounds like you have some work to do. Find out who will make the determination about whether or not you are successful(spoilers it may not be your direct manager). After finding out who they are you need to find out what they consider success. Before you let that person go you have to setup a system for validating their expectations. "If we do this do you think we're headed in the correct direction? Can we meet on this regularly until you are convinced?"

Generally speaking one thing you can do in any technology leadership role is to understand your space. Take the space in which you are working and distill each major technology component into a one-pager. You should know from a high level how it works, what purpose it serves in the business, some basic cost/return metrics, what it interfaces with, what projects/initiatives are currently in flight etc. Basically a crib sheet.

Once you understand your space and what your organization considers success you are ready to get started. You need to build a plan to take the pieces of that space and manipulate them to make your handler's expectations a reality.

easy peasy.

Congratulations!

Perhaps you could share with us, how you brought about being promoted on the basis that even yourself recognise you were not ready for it. Surely your certifications impressed your management even though you are yet to gain practical experience.

If you have gained certifications, then surely they would have provided with knowledge that you could apply. Is there a chance that you are being too modest? If not, then I would suggest that the courses were a waste of money.

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.

What certifications did you get? I have been interested in getting some myself but am unsure what certifications are best.

I did the foundation and some advanced courses offered by the iSAQB[0].

My experience was mixed. The foundation course was good, some advanced courses were excellent, while others were way too basic to be called "advanced" courses.

[0]: https://www.isaqb.org/certifications/?lang=en

Architects often coordinate work that happens over multiple organizational units.

I found it to be very helpful to spend a week or two full time with the org units involved in the projects or software systems.

Ask if you can be an intern in there teams for a while, get an introduction and feeling for how they work, and after a few days, ask them (informally) about their challenges.

Why? Because the architect is at least half a people person, working with the constraints and pressures felt by all the people and org units involved.

Finally, I've learned that software architecture and business processes are very tightly linked. You already know about Conway's Law, I assume; the processes often define how different org units collaborate, and that greatly influences possible software architecture. So, try to learn about the processes as well, and get to know the people who define the processes.

I found myself in a similar position a couple of years back. One of the big things that changed for me is that I had to widen my field of view on a project. I had already worked the "full stack" through previous jobs, but now I was responsible for designing how everything connected: APIs, CDNs, servers (or "less"), storage options, security, CI/CD, etc. It's not unlike how we grew from single lines of code to functions to modules to applications. Now, you move to assembling all of the mechanisms into complex systems. Based on your training, I imagine you already know a good amount about the various tools at your disposal, and it is time to apply all of that together.

Your days of learning new things is not over. You don't need to know the minutiae of everything, but you need to know what can and will work together, what may cause pain in integrating, and where your risks are. Oh, and you'll have less time to tinker your way through the new things.

There are things that you may not be used to doing though. You'll spend more time in meetings trying to figure out what you're actually supposed to be building. You'll spend time investigating new tools to use (replace libraries and packages with services in your mind). You'll probably be expected to do even more project planning and estimating.

And one of the most difficult for some people: you'll have to delegate. I still struggle with this one sometimes. You cannot possibly build it all, and now the people you have to rely on to build it will probably lack your experience, and on top of that, it's up to you to make sure that the requirements are crystal clear to them. And that's not their fault. We were all junior devs at one point. Crawl, walk, run. On the flip side, remember that some people WILL have experience in things you don't. Identify those strengths and leverage them!

Oh, and there's a decent chance you'll need to manage how much all of this crap costs... Brilliant solutions aren't so brilliant when they cost more to run than they generate in revenue.

Do not divorce yourself completely from code. Nobody likes ivory tower architects. Also, lean towards getting things done over getting things perfect. Read a lot of architecture types. Hexagonal, Microservices etc. Excel at one cloud provider services.

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

You need to liaison differing personalities to communicate and come to consensus. First are your customers, presumably business types, to your development team, stereotypically introverted nerds. Second is the interaction amongst your team. Those introverted nerds will have opinions and you need to drawn them out to civil debate. Best case scenario in the latter is they arrive at a design themselves with you coaching, otherwise you end the debate and select for them. For the former, you need to jokingly tell the customers about the golden triangle... good, fast, cheap... pick two and only two. Then make sure they know you aren't joking any more.

Learn your weaknesses, learn to delegate and to trust others.

Once, I have worked with an "architect team". They were brillant, talentuous, very creative. One of them has lead the development of a software component. He has been in charge of a small team of developpers for this component. As he was very creative, he has "improved" the architecture many times during development. At the beginning, he was loved for his ideas, but at the end, the developper team hated him. Later, he was tasked to change the organisation of the source directories (and makefiles) to adapt to in house software management tooling. I have been asked to replace this guy because the team did not want to see him anymore. I have followed his ideas with as few changes as possible. It was a success. I think a good architect must be creative, but a good project leader must also be able to keep direction (limit changes). The creative guy should initiate projects, build prototypes, show roadmap, them find an accountant to replace him (someone who monitors planning, risks and costs). Either you are able to change your mindset according to project phases, or you learn to delegate.

Will you be a 'technical architect' or 'enterprise architect'? The first designs how systems work internally, the other designs how systems work together.

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

Keep coding, prototyping, benchmarking. Do not just draw stuff. Eat your own dog food.

In the other direction, coordinate the work on architecture and leave some of it to the developers.

Communicate ideas clearly, concentrate on the Nouns, not the Verbs, particular technologies, frameworks, languages are important, but not that important.

Understand the domain(s), if you don't, find out who does, talk to them, write it down, read it back, until they say you've got it.

That way, you can take new ideas and new requirements and see how they fit into the domain, how it will need to stretch or flex to accommodate them. You will be able then to explain it to both the people wanting the new thing as well as the people that have to build and deploy it.

Making things flexible is the hardest thing, you don't want things to be too flexible, it makes it too hard to keep something running. But you also don't want it too rigid, it makes it too hard to adapt.

I would strongly recommend the Strategy pattern, over modeling fixed concrete configuration structure.

At least the first time or couple of times you encounter a complex configuration requirement, in a new domain.

Spring XML or similar can offer pretty much a gold standard for being able to instantiate & parameterize strategies or simple executable ASTs.

As someone who has had to deal with a few architects - the number one thing I’ll say is - listen. Really listen. Listen and credit. Don’t take everyone else’s ideas as your own work. You’ll see the employees you cheated leave and then you’re gonna run dry on ideas.

I’ve stopped thinking of the architect role as one where a person gets creative freedom to figure out the best solution (on their own or with another similar person or some consultant). Instead, I’d think of an architect as someone who just has good enough taste to determine what will be most effective.

As usual, as soon as you have poor taste - you lose all respect from peers. So, be aware.

> I’ve stopped thinking of the architect role as one where a person gets creative freedom to figure out the best solution (on their own or with another similar person or some consultant). Instead, I’d think of an architect as someone who just has good enough taste to determine what will be most effective.

Well said. This also applies to any kind of leadership.

Congrats! What a great follow-up to your previous Ask HN! https://news.ycombinator.com/item?id=17808874

Write write write! Agree with the mass! Writing provides the alignment needed for a team to move together in a project! I personally have started writing as a software engineer to allow myself to develop my writing skills to articulate my ideas and thoughts coherently. Just wanted to share my post on that as well. Hope it encourages my readers!!

https://blog.phuaxueyong.com/post/2020-03-24-how-to-improve-...

#1: ask whoever's evaluating your success or failure in this role what they want you to do. Exactly what they want. What should a week for you look like? Is there anything they're doing that they want you to do now, or anything that someone else is doing that they want you doing now? Have them show you exactly how to do those things.

If that leaves you any room and you're not expected to fill it with crushin' Jira tickets, ask the rest of the team—PMs, developers, designers—what they want or need from you.

You should probably ask the person who promoted you, that what are their expectations from you.

didn't quite see this in other comments:

its not about you anymore

your job is to make the product and the team successful. the worst way to go about that is to use your new bully pulpit to make everyone follow your process

i agree with the people who say you need to keep your hands in the code. absolutely. but maybe instead of picking out the hardest and sexiest problems for yourself...maybe acknowledge that you have alot going on, and that you might not have enough bandwidth. i've find it works better if I keep a wider eye on everything thats going on rather than swapping out my architect hat for a developer hat and working privately on something. its also a good idea to think about tracing/debugging/operational levers that help the team as a second order (but aren't in the critical path). assume you're going to be parachuting in all sorts of places and leave time for that

get to know your people/teams. you're going to deliberately be invoking conway's law. know strengths and weaknesses and help to set up the overall development structure so maximize success. if that means not using a language or tool you think would be the best choice, then suck it up.

i don't find it at all helpful to consider yourself in charge. your role is to try to guide people to the right decision. to talk to everyone and understand whats going on and connect the right people together. to continuously translate the business needs to tactical action. but really, you're a support person now.

i guess for some people i've blurred technical team lead and architect. thats fine - let me know where you think that line is.

First of all, congrats!

One of the most important things I've found is to know exactly what is expected of you. Everyone has different ideas about what an architect is, and an architect's responsibility in one role can differ from another role. For example, how much coding are you expected to do, and in what capacity?

You're going to have to be able to stand up for yourself. It might be a senior dev that thinks they should be in your role, or a BA/PM that tries to push through a feature/change. You're going to have to explain why you made certain choices and took certain paths.

Your communication skills will need to improve. Now previous in person conversations might be better off documented. You're going to need to be clearer while also being concise. This is where knowing the expectations really helps: how much should be documented and how thoroughly? You may end up speaking to business more or less than you did previously and must adjust accordingly.

Good luck and I hope this helps!

Congratulations. It's been my experience that a business-savvy, technically capable architect can be absolutely essential.

It's also true that architects can sometimes be jerks, if they lack the above qualities they can be tremendous liabilities.

To achieve your promotion, you must have done some very good things. Keep up the good work, vow to be a 'good' architect.

Good luck!

As a recently appointed architect myself:

- Learn to get good at Lucid Charts, or Draw.io, something like that if you haven't already. You're about to get asked for a lot of diagrams... - Don't expect to change everything over night, expect a lot of frustration. You'll suggest changes, design things, then you'll realise people didn't listen or understand. What you actually end up with, will likely end up looking completely different, it's easy to get demotivated by this. I'm still working on this myself, but I guess try to be empathetic. What might be obvious to you, might be more obscure to engineers, especially junior engineers. Focus on trying to inculcate good practices and approaches into everyone, try to get on the same page. If you design something, or request something's done a certain way, and people don't quite understand it, they'll likely fall back to what they know already. Just be patient, accept things won't always go the way you planned it and work on knowledge sharing where needed most.

- Come up with a common dictionary of shared terms and concepts within the business, it will be your role to act as a mediator at times, between engineers and the business. Find a common tongue.

- Make sure you have the fundamentals down, it's easy to get moved into an architect role because you demonstrate certain qualities, but this means you might be missing some of the basic architect stuff. I've been in my role nearly a year and I still feel like an engineer who can do some architect stuff at times. So just keep reading.

- Practice spotting abstractions and opportunities. Try to look for ways in which your code can enable more opportunities further down the line, and safeguard those. All code has untold, unknown potential, try to get engineers thinking along those lines.

- Be an enabler - try to find improvements that speed up future changes.

These have been the key things for me so far! Good luck!

Study The Mythical Man Month. It's a short read.

Take people in the trenches out to lunch/coffee 1-1 and take notes. Say "I can't promise anything but I'm listening". Find neglected low hanging fruit.

Under promise and over deliver to both your bosses and people below you. Don't oversell yourself or your work.

A while back we started doing ADR[0] for most of our projects and now they’re helping us to provide context for new developers and to help us stay in the path defined for medium/long goals.

[0] https://adr.github.io/

Communicating in writing is THE core skill for a systems architect, just like drawings are the core skill for construction architects.

Review, carefully, stuff written by other people on your team. Do it promptly, and avoid developing a backlog of stuff to review.

Work on writing clearly. It's like coding; you can improve your writing by reading good writers (and bad ones). Becoming a good writer takes a lifetime.

Don't use the passive voice unless you must. It almost always reflects sloppy thinking.

Always answer the question "why?" in your written work.

If you can help from a technical editor, use it. Pretty much all writers except university students have editors.

To go all Yoda on you, in a job like yours "the only way you can do enough is by doing nothing." Avoid getting bogged down if you can.

Congratulations!

I would like to recommend the recent book “Fundamentals of Software Architecture” https://www.oreilly.com/library/view/fundamentals-of-softwar...

It covers important foundations, walks through different architecture patterns. The last part of the book is about soft skills: communications, decision making, etc. In my experience, it is critical for such position. The book is different from piles of enterprise architecture books that talks a lot about UMLs, formal processes, ceremonies, and roles - things I found either irrelevant for my jobs or I can learn them better elsewhere.

> the book is different from piles of enterprise architecture books that talks a lot about UMLs, formal processes, ceremonies, and roles

Thank you. I generally hated every book on the subject that I got my hands on. I'll order this.

More generally, search for works by the authors: Neal Ford, Mark Richards. Similarly, follow Martin Fowler. They all have many articles, videos, on architecture.

I’ll assume you’re landing in an Enterprise Architect role rather than a software architect role. So:

Don’t be surprised if you don’t write much if any code any more.

Your non technical colleagues will look to you to be accountable for all things technology, and they won’t understand any division of responsibilities between yourself and your technical colleagues. You’ll be front of house for engineering. You will be the link between the business objectives of the organization and the technical roadmap which supports those objectives.

Say goodbye to having clear requirements. More often than not you’ll be helping shape those requirements rather than being handed them. Software project estimates are an impossible dark art, but you need to do it anyway and communicate your cost modelling and assumptions. Your colleagues will rely on those estimates regardless of the caveats you attach, and no degree of Agile will save you from needing to make hard-landscape decisions based on imperfect information.

Get comfortable with sticking your neck out and being a little bit wrong. Just a little bit though!

You will rarely make decisions. You will frequently facilitate achieving consensus on decisions.

People will complain bitterly when things go wrong, so make sure you can justify the reasoning behind your recommendations.

Grow a thick skin. Finance people will tell you your to-be solution is too heavy on capex. Finance people will tell you the as-is solution is too heavy on opex. Project delivery people will tell you your solutions can’t be built and they’ll want you to hold their hand every step of the way. Engineers will accuse you of being an impragmatic dinosaur and of living in an ivory tower and of not understanding the details (and if you’ve any hope of going home at a reasonable hour, they’ll be right on that last one). Your job is to soak up the criticism, learn from it, adapt to it, and broker something that best fits all those competing objectives.

There will be times when what’s globally optimal is locally suboptimal, and you’ll have to deliver that message to the locals.

Curate corporate memory - you’ll be consulted regularly by people who will expect you to act like a wise sage who can explain the deep history of how your architecture came to be, what forces shaped it, and where it is going.

Your role delivers long-term value for your organization and will be viewed as a hindrance in the short-term. Get yourself aligned to people who share those long-term responsibilities - Risk and Policy people would be good choices, Sales and Service people would be bad choices.

Find a business architect who can collaborate with you on delivering the non-technical change (people and process) that goes with your technical change.

Learn to spot the difference between a fad that the industry wastes $$$ on and genuine innovation that could unlock $$$$$ of genuine value (hint: you’ll be lucky to do this once in your career).

Prepare for the money to run out. What does your solution look like if only half gets built? Think about how to break up big work into small packages of deliverables and transition states. Your engineers will want to deliver continuously. You need to get on top of the risks of doing that.

Learn to speak plainly and simply. Your role isn’t about being a master of all the complexities of everything. You need to identify themes and patterns, and communicate those in a way that your colleagues will be able to internalise. You need to train them to instinctively do the right thing rather than do the wrong thing or come to you for validation of everything they do.

You need to exude clarity and purpose and vision.

Learn to trust your engineers to do what they do best - solve technical problems. You probably love doing this, so it will be hard to let go. But your role is now to enable them and give them architectural runway by unblocking non-technical impasses.

Wow ... thanks for this, but a lot of this reads like daunting and sobering JD of people constantly knocking at your door with problems.

What are some of the positives? Besides a higher salary?

OK, very good point! My view of the upside is:

Yes, typically this is a well paid position that is acquired based on a track record of success in the organization, as it’s predicated on being finely in-tune with that organization’s specific needs more so than generic industry expertise or certification (though those help!). You tend to earn the position more often than be hired into it.

The above lends to the role having higher job security than rank-and-file engineers.

Similarly, your skills deepen and mature over time and are less at risk of becoming obsoleted by a new technology trend.

If you do it right you’ll be treated with a great deal of respect and admiration.

You get to take genuine credit for the success of the organization.

You are likely to have a great degree of autonomy in how you work.

It’s a challenge no doubt, but if you can do it, you are in Maslow’s self-actualization zone.

can you recommend ways to recognize companies like this during a job interview?

Any organization with >50k employees.

If security isn't someone else responsibility I would start there. Job zero as Amazon puts it.

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

Good job!

I recommend that you learn how to speak slowly.

This not only makes you easier to understand, but also makes it easier for people to interrupt and ask questions.

And as others have said, listen carefully to questions and suggestions and try to answer them at length.

Bonus points if you can carry this over into writing, too.

Not useful to OP now, but I really hate companies that do “leading promotions”: promote you to a level without you actually showing, or in this case even understanding what it means. It’s a recipe for broken expectations and very hard for engs. The alternative, “lagging promotion” is where you have a clear idea of the responsibilities and skills you need to develop for the next level, prove that you can do it consistently and get promoted. As a manager, having worked on companies that do one or the other, I really prefer lagging promotions: it’s so much better for engs and managers as well, because it prepares you to grow and it naturally encourages support and guidance.

I have been given “leading” promotions and I have grown into the roles. It took a little time to figure it out though. Problem is that often your own leadership doesn’t give you any training or mentorship about what’s expected from the role.

I think the whole field would be well advised to do more mentorship. It seems most of tech works with a “sink or swim” mentality. This works well for the development work but once you get into leadership a lot of people fail. Not because they are not capable but because nobody helps them understand their new role.

There is no definitive answer because there is not even a good definition what software architecture actually is [0]. So you need to find an answer fitting your organization yourself.

One idea could be that you start a document with the Arc42 [1] template.

Figure out how to communicate the essential structure of your software to everybody.

Document why certain big decisions were made. E.g. why did you pick that programming language/framework?

[0] http://beza1e1.tuxen.de/definitions_software_architecture.ht...

[1] https://arc42.org/

What are the the company's expectations of your new role? Do you have the tools to implement your mandate? Biggest issue I've seen over the years:

- Unclear role: so you interpretation might not match upper management's expectations.

- Super results with no powers: Sometime you are expected to do X, but have no control or 'power' to enforce your vision. Persuasion only goes so far, employees will ultimately go with the person who signs their paychecks...

Best case is when everything is clear for all the stakeholders and you feel you are truly overseeing the technical horizon and steering your team in a way that is a force multiplier.

I an addition to having to communicate with a lot of stakeholders, keep coding. I have seen plenty of architects that lost touch with the technical side after a while and turned into major obstacles. If they are politically savvy they are the go to guys for management but their actual contribution is negative because they often push the wrong designs and suppress ideas from people who work on the code and have a handle on how things really work.

In my view as an architect you need stay a top notch coder.

When I transitioned to architect 1) I had already been designing services for years and slid into the position naturally. 2) We had an entire department for architecture and development.

So in other words I just continued doing what I was already doing, except now I had a direct line of communication to other architects and developers within the org.

I can't imagine just being dropped into this position. So what I'm telling you is that you use whatever experience it is that got you there to a further extent.

For starters- do you even know whats expected from the role or it's more of a fancy title for Lead / Principal Engineer?

My $0.02 on SW architecture is that it's not as much about SW or architecture as about people and their needs and you being able to be effective channel for everything between end-users and engineering.

If there's one thing- learn as much about your business domain from end-users and "business persons" at your company as much as possible!

ps. basically You're screwed! :D

After many years of being an architect I would suggest getting really familiar with two concepts: Separation of concern and (reduction of) Technical Debt.

Both are important concepts that you will need to promote as an architect and the whole point of it is to reduce the total complexity that is facing developers during their daily work (so they can focus on the important stuff and not be bogged down with irrelevant stuff...).

As suggested by the previous comments here, there are different types of architect in technology.

The software architect elevator is a new O’Reilly book that explores this.

I have no connection with the author or publisher.

https://books.google.co.uk/books?id=X-_bDwAAQBAJ&lpg=PP1&pg=...

One of the best books I've read about software architecture is Designing Data-Intensive Applications:

https://dataintensive.net/

Almost no fluff, very concrete explanations of various algorithms and system properties, how various real world systems embody them, and how to put those systems together to get effective real world solutions.

For your #1 point our team has had great success using PlantUML for our diagrams. They can be easily output for slides or wiki pages, but it's all written in code so we can keep them in our git repo for tracking.

Two of the teams I worked on supported a couple thousand devs each. So going in I thought it would be everyone using specialized diagramming tools. But the majority did not. I don't do much architecture these days, but I've bookmarked PlantUML just in case and will check it out if the need arises.

Well done!

Two of biggest lessons learn over the time are

1. Always have a Plan B in case Plan A does not work out.

2. Always be ready to defend Plan A to make it work.

Good luck on the journey.

As the only person doing that role within an company, you’ve probably been promoted as an acknowledgement of what you’re already doing what your superiors expect.

Keep learning always but the only person who can tell you how to be a success in this role is your boss and the stakeholders who pressure him

How can you get to be lead architect if you don’t already know how to do the job incredibly well?

Like how could someone design/architect a skyscraper if they didn’t already know how to do it?

Why would you accept such a job if you didn’t know that you were passionate about it, skilled and experienced?

Precisely my point.

An architect is someone who has been designing and building software architectures for years as a developer and or team lead and has accumulated the skills of an architect until eventually they get do take a job solely focused on the architecture aspect of development.

Crazy to make someone lead architect who hasn’t got this behind them.

Architecture certifications? What the?

Never been in a small company I guess...

? Don’t understand your point.

Is your point that small companies appoint unsuitable people to architect systems? Why because they know no better?

FYI many years in small and startups also large and medium.

Then how can you not know, that founders/early employees wear lots of hats? No small company has everyone it needs. So you do the job, learning as you go, and the company moves along.

> What are the things I need to learn ASAP?

Basically to consider the bigger picture.

What do you need now? What do you need later? What do you not need at all?

Think about how you're using your people's time, and your budget.

Think about how you'll survive without key people.

How you'll rebuild when things break.

Read the articles posted on https://staffeng.com/. A collection of very insightful articles from folks that moved up from a senior role and onto the next level.

How to handle poisonous and toxic people. The higher you get, the more there are.

Make sure that higher up people have your back, and keep them in the loop. Nothing worse than thinking you have new powers and people start treating you like a busybody because the title was just a name and not a role.

this depends on the type of organization you are in and what type of architect. At a small startup i was an engineer who coded a lot but also did what would be considered architecture, devops, db administration, project management and client relationships.

when i joined a fortune 100 as a solution architect, i mostly made power point and worked to translate unclear business objectives into architectures, work breakdowns, estimation and multi-year planning. it was expected i could code, understand db choices and trade offs but truly never had to do anything hands on technical.

Congratulations. Everyone have good suggestions in threads. Few other things:

* Learn to measure cross-cutting, high level technical metrics. Build up your own "fitness functions" and constantly ensure they are looking healthy. e.g. Incident metrics (https://www.atlassian.com/incident-management/kpis/common-me...), SLOs (https://landing.google.com/sre/resources/practicesandprocess...), Lighthouse scores, Time from raising a PR to deploying in production, etc. https://www.thoughtworks.com/insights/articles/fitness-funct... Don't be "abstract" when talking about maintainability, testability, observability, etc, but be able to support them with numbers.

* Draw yourself a line. Find out where you are the decision maker and where you are not. Example: don't make your entire judgement based on "how many people can be allocated", "what's the cost", "will users like this feature", etc. Budget, people & UX are not your decision making responsibility, there are Managers, Directors, Product owners for that. Give your recommendations, but let them do their job. It's easy to fall into the "I know everything better" trap.

* Don't be a "hired gun" working feature after feature, or a firefighter resolving issue after issue. Have an agenda for the technology itself that you work on 30% of the time. 6 months down the line, regardless of projects or firefighting missions – you should be in a position to prove that the technology is maturing, like: "In the last 6 months, our number of incidents/bugs has decreased from <X> to <Y>", "our time to ship features has decreased from <X> to <Y>", etc.

* Don't – just don't – ever give abstract advice. A major difference between experienced and novice engineers is – giving concrete examples, facts or metrics to back up. If you don't have an example or use case, and if you just have a hunch, just keep it to yourself and move on. Remember that what you do is what other engineers will indirectly follow. You have to set engineering culture by example. If you talk abstract stuff or behave opinionated, engineers will reflect it right back.

I'd focus on things like how to write good documentation, diplomacy, negotiation, mentoring, presentation skills, etc. Non-tech stuff. You're basically a city planner now.

Which "software architecture certifications" did you get and which do you think were the most useful?

To me, an architect is also a good programmer that is able to get work done - learn good coding practices (DRY comes up a lot), be up to date on your stack (latest language features). Practice Clean Code (e.g. some of what Bob Martin writes about, some of it is a bit...special).

Learn about pipelines, version control schemes, and the "best" way to implement it given your constraints. Specifically, how code gets merged, when it gets built, in what environment. I can answer questions about details here. Edit: You will also need to know how to organize your board in Jira, Rally, Azure DevOps, or whatever, especially if you don't have a Scrum master.

Understand how to decouple code into micro-services (and why it's mostly unnecessary to do so). Have a solid understanding of testing principles, and what you want your TDD to look like (if at all) - mocks of everything or small units of functionality.

Understand database performance, modern authentication (JWT, OAuth2, intercepting requests).

This was all specific to Line of Business web apps btw..so may not relate to you.

When I play "architect", I also need to draw diagrams and clearly split up work, so you need to learn to do that. I found it super helpful to have a high-level vision (as pretentious as that word is) for the software. Usually, no one has that.

I have also found that a lot of architects irl are just career bsers, so I might be going about it the wrong way, and I don't have the title.

80% of the architects I know just say random stuff that makes no sense like "Everything will go through an API", "Use attributes everywhere", "everything will be a microservice" and tell you to implement their high level goals, but could never do it themselves. I have zero respect for them.

Since I am just ranting - some of the best advice I have heard (from the Python docs, though I don't use Python). Have one, and ideally only one, way of doing certain things. Clarity is king.

To me, being an architect (not by title, but while leading fairly large teams) always meant being an example (at least in terms of code quality) and always being able to pick up a story from another dev if I dictated something - e.g. not asking devs to do what I am not willing to. This, combined with the vision of the whole product, often means refactoring and helping resolve merge conflicts for others - whether it's in code, Entity Framework migrations, etc.

thinking linearly, as developing require you to think about all the networked intricacies of software but that would make communicating goals harder.

you're no longer putting together lego pieces, so to say, you're writing the instruction manual.

figuring out integration point between responsibilities, identifying inter-dependencies and avoiding every interface to become a nimby turf war all rely on your communication skills way before on your technical prowess.

I read that as "what do I need to do to learn Excel" and I thought "yep, seems like a good question".

Learn to write convincing and pleasant to read documents and learn to sell your ideas. You are now in a sales role.

Seek to understand from the ones that promoted you what expectations they have of you and from the new role.

Listen carefully to your peers, don't be a dictator, find out what the business actually needs.

If you're a Lead Architect you need to know the different between CAT6, CAT6a and Cat 7.

(tip your waiter)

what is this? (not an architect here btw)

A joke about "leads" = "cables".

System or software architect ? As the product grows the two diverge rather fast.

Normally architects are at the top of the technology decisions along with principles. The focus of architecture is generally two fold:

1) Satisfying decisions that please many opposing masters.

2) Deciding how the company will build software from its current talent and the expected talent in the marketplace.

Consider the architects as the practical application and technical planners that represent the technical things a CTO might bundle together from a senior managerial perspective.

—-

Things an architects will need to do:

1. Make decisions. Know your various competing stakeholders and master written documentation. Be good with influence and always have supporting evidence. Never propose ad hoc decisions or use data that is either invented by you or poorly estimated. This is the essence of your reputation. Push back on decisions that are poorly qualified.

2. Place the product first. This means the most principal interest is a balance of generating revenue and pleasing the customer. Everything else be damned. That also means telling people no and putting developer interests as a far lower priority. From a business perspective people understand the answer “no” when there are competing priorities and when their pet priority isn’t fully qualified.

3. Account for talent. Temper that previous point against talent availability. For example if there is some giant JavaScript framework out there that there is giant slow, both in development time and execution time, trash and yet the only JavaScript you can find require that framework this must be factor in your proposals and technical planning.

4. Plan. Your ideas and proposals must be feasible. Are they things that can actually be built in a given timeframe, with the given talent, and the given resources? How long will it take to build? What are the risks? Will more assets be required? Will more time be required? In what stages and order will it be put together? Your plan should be communicated in two ways: a high level summary for stakeholders and a supporting specification that provides technical details and evidence.

—-

Things to learn:

1. Leadership. Stand behind your decisions. Own them with confidence and yet be willing to accept changes in the face of better evidence. Openly accept fault when your decisions fail in practice.

2. Administration. Learn to document data points across a variety of subjects and build knowledge cases.

3. Management. Management is a hybrid of leadership and administration. Even if you are not in management yourself you need to empathize with those that are in order to solve for their concerns and influence them.

4. Expenses. You need to estimate how much a given technology costs before adding it to a technical proposal. Expenses refer to asset consumption which is much more than money and free software comes with expenses.

5. Behavior and motives. You cannot influence people if you have no idea what they want. What people claim to want versus what they actually seek out are often two different things and nobody will tell you that.

Empathetic listening, writing, and business accounting!

Be aware of TOGAF, even if you don't use it.

#1 Put your absolute focus on getting things finished.

That can be much harder than it sounds because first you have to master the skill of defining what 'finished' means. Speak with the stakeholders and, without judgement or resistance, find out what it would mean to them to be 'done' with this project, phase, milestone, whatever.

Let them tell you. The business people should make decisions about the business. They set em up, you knock em down.

#2 Strategize on how to get it finished. Once you have an agreement on what 'done' looks like, then talk with your team in a casual environment with a whiteboard present. Ask your team: Here is our task, what is the best way to get this done? Call on the members of your team who are quiet. Do not mistake being quiet for being out of ideas. Those guys just need a little encouragement to speak up. People say 'there are no bad ideas' that's not true, of course there are bad ideas. However, the environment and tone that you want to set for this meeting is: There is no NEGATIVE JUDGEMENT for your ideas. Get your guys to feel comfortable to spill out everything. Your job is to collect the gems.

#3 Assemble the document. Get those gems into some sort of order that ends with you being done (see step 1). This is the 'architecture' phase. You have the task defined, you have the 'how' defined, now you assemble it into a document that you give back to both the stakeholders and your team for corrections. Repeat as necessary. Group the tasks into phases/sprints. Show your work to the stakeholders on a regular basis. If they change course because of that, go back to #1. It'll be faster this time.

#4 Delegate Do your absolute best to give away as much of that work as possible. This will free you up to both help and coach the development team and to update the management team. If you are heads down in code for 50 hours/wk every week, you are not leading, you are coding.

If you are going to code, abstract up the hardest part of the project and code that only.

--

TL/DR: Train yourself to find the shortest path to done, which often means not using your favorite technology. Part of being a mature leader means to know when to be non-biased and to follow the natural flow of project requirements and staff acumen. Don't force that, listen more than you talk at first. Gather information and then produce a document that echos your decisions.

You gotta learn Excel.

Never stop coding.

Learn Psychology.

Read ISO 42010.

This is just my very personal and subjective experience, which may or may not apply to your working environment since I've no idea how many developers or teams you have or how your responsibilities are defined. This is at least what I've learnt so far in my environment:

- Be transparent about your decisions, motivations and opinions. People will come to you for advice or suggestions for what to do, and if they don't understand your thought process that causes unnecessary friction.

- Document everything in writing publicly (except confidential/sensitive info, naturally) - decisions, designs, ideas, proof-of-concepts. This will be helpful both to your fellow engineers since they can access this information on their own without you having to explain it to them every time they ask, and also helpful to you to recall the context in which you did something. I find myself often going back to notes I wrote months or even weeks ago, to remind myself of e.g. the motivation for why a decision was taken. Having it public also forces you to write in a clear, structured and professional manner since you're writing for a broader audience.

- In terms of studying, formulate a vision for where you think your software should be within 1, 2 or 3 years, and spend time researching what options can take you there, learning how they work, and so on. I've found InfoQ to be a pretty good resource for keeping tabs on what others are doing in the field.

- Be patient. Be prepared to repeat yourself multiple times, sometimes to different people, sometimes to the same people. Be prepared to communicate a lot, and keep in mind to tailor your message depending on who you're communicating with.

- Learn to let go of details. You will see code and solutions pushed out that you perhaps don't fully agree with. Take a step back and consider if it's really that important or if it's good enough. If something gets pushed that really isn't up-to-par, be humble and consider that you might not have communicated the requirements clearly enough.

- Make sure to understand the business side of the company, and always take that perspective into account when making decisions. You might from a technical perspective think a piece of software is in desperate need of refactoring, but from a business value perspective it might not make any sense. Be sure that you agree yourself with those kinds of decisions (i.e. don't blame "the business") because you'll likely find yourself having to explain and champion them to others who disagree with them.

- I realized now that all of the above is mostly "soft skills" and have very little to do with technical skills or training. Which I suppose is the biggest learning I've had so far - for me the biggest gap by far was (and still is) mostly about communicating, working with others, and taking the broader needs of the company into account and not just the technical aspects.

Just my 2c - hope it can be helpful to someone.

> What do I need to learn/do to excel?

You need to turn off tool tips immediately. It makes you look like a newbie.

You should setup a hot key to open excel at any time. This allows you a "panic button" to hit whenever you are playing games or planning vacations and hear someone about to enter your cubicle.

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

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

Let's hope Elite Dangerous introduces a complicated menu system for their carrier system to compete!

Oh wait

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

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

A lot more convincing than Visio or MS Project or some UML.

Yeah, a lead software-architect who uses UML, ridiculous!

Much better is a excel table .. where all of the used technologies are listed? Seriously, why and for what would a software architect needs excel for his main work?

Maybe for hand-tuning a deep neural network to detect sarcasm.

I think the best answer around here is a careful explanation that can be summed up as "it depends". It depends on what is expected of that role at any given organization. And whatever the answer to that, the likelihood that the role highly depends on efficient communication, mediation between parties (multi-stakeholder approach and so on), the best tool is probably Thunderbird, or Office, or whatever floats one's boat.

Of course, at some point said Architect usually have to manage technological aspects, decisions, problems, projects - and for that the best tool is again "it depends", just like in any engineering endeavor. And yes, it might include a few sleepless nights doing low-level R&D, looking over code, fiddling with components, getting to the bottom of bugs, coming up with workarounds, strategy, proposals - or evaluating them, soliciting feedback, reviewing it et cetera.

And so, it depends, I might have been.

(But seriously, I usually found, that those high level tech decision makers/influencers who are not communicating enough, who are not organizing information enough, but are too lost in some specialized tool, to be completely useless. I use Google Docs and Spreadsheets to track things, because it can be easily and kind of "safely" shared with the required folks. Whereas every other tool is too slow. JIRA? Oh, that only works on the internal network, better wait months for VPN access. Oh here's a .xlsx attached to an email, fuck the actual devs that don't live on Office, and so on.

And on top of all that an "architect" is - at least in my experience - is a thankless job. Not high-profile enough to actually have authority to effect change, but usually sufficiently high on the ladder to get flak for any and all problems.

Finally, in large orgs it's not rare that the Architect role is the last line that has at least some connection to the actual tech/development, and up from there it's all about costs, headcount, opex/capex, schedules, compliance, governance, PR, and internal/external politics/sales/optics. And this makes it neigh impossible to execute well.)

Draw.io?

PowerPoint baby!

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

"Hey, Bob, it's great to see that you're keeping busy, but why are you still running Excel '95?"

The Ribbon sucks, I ain't payin for Office365, and when it comes to doing basic adding, subtraction, and division in a table, I don't need high end software. Plus it integrates really well with the Unreal Engine...

really? i've never heard of a single game with something like this. do you have any examples? or am i just missing a joke here haha??

well, web version of Tinder has it. That counts as a game too?

Awesome XD

Excel