
Ask HN: I've been promoted to Architect. What do I need to learn/do to excel? - dotdi
My company had some lateral movement which, somewhat surprisingly, resulted in me being promoted to &quot;Lead Architect&quot;. It&#x27;s just a fancy title because we don&#x27;t have any other designated software architects. There was, in any case, technical responsibility that needed to be redistributed, so that&#x27;s what happened, and titles shifted accordingly.<p>In the past, I had used my training budget for software architecture certifications, which was met positively by my team lead and management.<p>While I _wanted_ to take on that role _eventually_, I was surprised to have it happen so early. What are the things I need to learn ASAP? What things do I need to do? What should I study&#x2F;read?
======
squeed
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.

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

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

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

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

~~~
edraferi
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/](https://www.plainlanguage.gov/)

[http://www.hemingwayapp.com/](http://www.hemingwayapp.com/)

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

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

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

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

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

------
mateuszserafin
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!

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

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

~~~
dotdi
> 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 :)

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

~~~
eeZah7Ux
You are describing a good engineer.

~~~
mcv
I think I have three architects in my team.

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

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

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

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

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

~~~
kakwa_
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](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.

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

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

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

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

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

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

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

------
tilolebo
Maybe introduce lightweight architecture decision records in the design
process?

[https://www.thoughtworks.com/radar/techniques/lightweight-
ar...](https://www.thoughtworks.com/radar/techniques/lightweight-architecture-
decision-records)

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.

~~~
codetojoy
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...](http://thinkrelevance.com/blog/2011/11/15/documenting-architecture-
decisions) [2] -
[https://www.youtube.com/watch?v=LMBqGPLvonU](https://www.youtube.com/watch?v=LMBqGPLvonU)

------
mekoka
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!

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

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

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

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

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

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

~~~
dotdi
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](https://www.isaqb.org/certifications/?lang=en)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

------
xueyongg
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-...](https://blog.phuaxueyong.com/post/2020-03-24-how-to-improve-as-a-
sales-rep)

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

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

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

------
dandersh
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!

------
RickJWagner
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!

------
vegancap
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!

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

------
danilopopeye
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/](https://adr.github.io/)

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

------
playing_colours
Congratulations!

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

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.

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

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

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

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

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

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

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

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

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

------
qznc
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...](http://beza1e1.tuxen.de/definitions_software_architecture.html)

[1] [https://arc42.org/](https://arc42.org/)

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

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

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

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

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

------
rbirkby
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=...](https://books.google.co.uk/books?id=X-_bDwAAQBAJ&lpg=PP1&pg=PR9#v=onepage&q&f=false)

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

[https://dataintensive.net/](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.

------
tchaffee
Things that surprised me:

1\. Many IT architects use simple tools for diagrams. The most common in my
industry were PowerPoint and Google Slides. Even for very complex diagrams
that can cover an entire wall.

2\. Other architects will abuse diagramming standards and other standards. Ask
them to describe their diagram instead of assuming what it means. For example,
the vast majority of UML use case diagrams I have seen were used to describe
flow, which is technically wrong.

3\. Consider your role as one of advisor / mentor / coach. The best
architecture will not always win due to other constraints, and you need to be
able to compromise.

4\. Another of your primary roles is that of educator and communicator. Many
times people need to quickly understand the systems from a high level in order
to make decisions. And they will come to you for that understanding.

5\. Along with the above, you will likely be working a lot more with
management because you are participating in high level decisions that often
involve how money is spent. Learn how management prefers communication. Start
with the bottom line: "the preferred solution costs X and we have two other
solutions that cost less but come with some cons". And then drill down into
details as needed. A junior communicating with management always gives the
details and justification up front and that is the opposite of how management
thinks.

I hope that helps. Best of luck in your new role!

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

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

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

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

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

~~~
JoeAltmaier
That's clearly not how anybody gets to do any job the first time, ever. There
has to be a first time.

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

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

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

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

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

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

------
rdsubhas
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...](https://www.atlassian.com/incident-management/kpis/common-metrics)), SLOs ([https://landing.google.com/sre/resources/practicesandprocess...](https://landing.google.com/sre/resources/practicesandprocesses/art-of-slos/)), Lighthouse scores, Time from raising a PR to deploying in production, etc. [https://www.thoughtworks.com/insights/articles/fitness-funct...](https://www.thoughtworks.com/insights/articles/fitness-function-driven-development) 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.

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

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

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

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

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

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

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

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

(tip your waiter)

~~~
in9
what is this? (not an architect here btw)

~~~
detaro
A joke about "leads" = "cables".

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

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

------
exabrial
Empathetic listening, writing, and business accounting!

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

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

------
dandanio
You gotta learn Excel.

------
electrotype
Never stop coding.

------
dboreham
Learn Psychology.

------
29athrowaway
Read ISO 42010.

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

------
ineedausername
Excel

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

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

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

~~~
karatestomp
[https://en.wikipedia.org/wiki/Boss_key](https://en.wikipedia.org/wiki/Boss_key)

------
miblon
Excel

