Ask HN: I've been promoted to Architect. What do I need to learn/do to excel? - <AUTHOR> My company had some lateral movement which, somewhat surprisingly, resulted in me being promoted to "Lead Architect". It's just a fancy title because we don't have any other designated software architects. There was, in any case, technical responsibility that needed to be redistributed, so that's what happened, and titles shifted accordingly.
In the past, I had used my training budget for software architecture certifications, which was met positively by my team lead and management.
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/read? <comment><USER2> 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.

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

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

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

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

<comment><USER6> 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/)

</comment></comment></comment></comment></comment></comment><comment><USER7> 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.

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

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

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

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

</comment></comment></comment></comment></comment><comment><USER11> 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!

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

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

<comment><AUTHOR> > 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 :)

</comment></comment></comment></comment><comment><USER14> 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.

<comment><USER15> You are describing a good engineer.

<comment><USER16> I think I have three architects in my team.

</comment></comment></comment><comment><USER17> 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.

</comment><comment><USER18> 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.

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

</comment></comment><comment><USER20> 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.

</comment><comment><USER21> 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.

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

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

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

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

</comment></comment></comment></comment></comment><comment><USER24> 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?"

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

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

</comment></comment></comment><comment><USER27> 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.

</comment><comment><USER28> 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.

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

</comment></comment><comment><USER30> 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!

</comment><comment><USER31> \- 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.

</comment><comment><USER32> 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.

</comment><comment><USER33> 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.

</comment><comment><USER34> 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.

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

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

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

</comment></comment></comment></comment><comment><USER36> 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.

</comment><comment><USER37> 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.

</comment><comment><USER38> 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.

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

</comment></comment><comment><USER40> 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.

</comment><comment><USER41> 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.

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

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

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

</comment><comment><USER10> 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.

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

</comment></comment><comment><USER44> 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.

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

</comment></comment><comment><USER46> 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)

</comment><comment><USER47> 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)

</comment><comment><USER48> #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.

</comment><comment><USER49> You should probably ask the person who promoted you, that what are their expectations from you.

</comment><comment><USER50> 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.

</comment><comment><USER51> 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!

</comment><comment><USER52> 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!

</comment><comment><USER53> 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!

</comment><comment><USER54> 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.

</comment><comment><USER55> 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/)

</comment><comment><USER56> 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.

</comment><comment><USER57> 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.

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

</comment></comment><comment><USER58> 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.

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

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

</comment></comment></comment><comment><USER60> If security isn't someone else responsibility I would start there. Job zero as Amazon puts it.

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

</comment></comment><comment><USER62> 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.

</comment><comment><USER63> 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.

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

</comment></comment><comment><USER65> 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/)

</comment><comment><USER66> 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.

</comment><comment><USER64> 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.

</comment><comment><USER67> 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.

</comment><comment><USER68> 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

</comment><comment><USER69> 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...).

</comment><comment><USER70> 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)

</comment><comment><USER71> 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.

</comment><comment><USER72> 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!

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

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

</comment></comment></comment><comment><USER74> 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.

</comment><comment><USER75> 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

</comment><comment><USER76> 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?

<comment><USER77> That's clearly not how anybody gets to do any job the first time, ever. There has to be a first time.

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

</comment></comment></comment><comment><USER78> > 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.

</comment><comment><USER79> 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.

</comment><comment><USER80> How to handle poisonous and toxic people. The higher you get, the more there are.

</comment><comment><USER81> 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.

</comment><comment><USER82> 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.

</comment><comment><USER83> 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.

</comment><comment><USER84> 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.

</comment><comment><USER39> 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.

</comment><comment><USER85> 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.

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

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

</comment><comment><USER88> Seek to understand from the ones that promoted you what expectations they have of you and from the new role.

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

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

(tip your waiter)

<comment><USER91> what is this? (not an architect here btw)

<comment><USER92> A joke about "leads" = "cables".

</comment></comment></comment><comment><USER93> System or software architect ? As the product grows the two diverge rather fast.

</comment><comment><USER94> 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.

</comment><comment><USER95> Empathetic listening, writing, and business accounting!

</comment><comment><USER96> Be aware of TOGAF, even if you don't use it.

</comment><comment><USER97> #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.

</comment><comment><USER98> You gotta learn Excel.

</comment><comment><USER99> Never stop coding.

</comment><comment><USER100> Learn Psychology.

</comment><comment><USER101> Read ISO 42010.

</comment><comment><USER102> 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.

</comment><comment><USER103> Excel

</comment><comment><USER104> > 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.

<comment><USER105> Many games do the opposite and have a "Excel screen" mode for that.

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

<comment><USER48> [https://en.wikipedia.org/wiki/Boss_key](https://en.wikipedia.org/wiki/Boss_key)

</comment></comment></comment></comment><comment><USER107> Excel</comment>


Artificial intelligence to decide who to email next - <AUTHOR> http://getseer.com/landing?utm_source=hackernews&utm_medium=newspost&utm_campaign=hackernews

<comment><AUTHOR> Joe and I just submitted the app to iTunes -- been a long few months coding & designing, looking forward to feedback.</comment>


Boy Lifts Book; Librarian Changes Boy's Life - <AUTHOR> http://www.npr.org/templates/story/story.php?storyId=113357239&ft=1&f=4516989

<comment><USER2> The story unwittingly demonstrates a case where zero-tolerance policies could have created frighteningly different results.

In some alternate universe, the story reads:

 _The librarian noticed Olly tucking the book under his jacket. Following school policy, she called the police. Olly spent the night in jail and was suspended from his school. Bitter and vengeful, he never went back. His street cred soared, and soon Olly was accepted into the local gang...._

<comment><USER3> I'm not saying they're a good idea, but countering an anecdote with another isn't a very good way to affirm your point. I doubt letting everyone go who tries to shoplift a book from the library in hopes of them becoming characters more fit for a movie plot will do much good either.

That said, you still received my up-vote since it made me think more of zero- tolerance policies and reading books in general. I remember reading a story on the Kindle's popularity with women. A lot of women it interviewed said they enjoyed the literary anonymity the Kindle afforded them in public places, as they generally didn't feel comfortable reading romance and pulp novels in public places like the subway.

The article felt to be in similar vein; someone discovers something that catches their eye but feels shame in seeking it out. I guess what we really need to test are programs that expose youth to a wide variety of material and the freedom and anonymity to pursue those interests :).

<comment><USER2> The problem with zero-tolerance is that it too often equates to zero-thought. It drives out space for humans to exercise _good judgment_. And since rules often replace judgment, I think they should be evaluated in the same way we evaluate judgment -- how do the rules fare at their worst [1]?

In any case, I edited to make the anecdotal nature clear. Better?

[1] It feels somehow more 'scientific' to point out that some rule works 99.9% of the time, and to thereby dismiss anecdotes as non-evidence (not that zero- tolerance even comes close to meeting this standard). But if a rule unjustly destroys the lives of 0.1% of people who interface with it, I still consider that a lousy rule.

<comment><USER3> You're totally right. Now that I think about it, zero-tolerance _always_ equates to zero-thought, as the point of zero-tolerance to create a shortcut through judgment and rules.

<comment><USER4> Zero-tolerance, in schools anyway, is zero-thought for the administration and principles, having to deal with the grey cases, setting exceptions when they're education administrators not lawyers. I doubt a student who did a similar action (stealing and returning a library book) would perceive themselves as morally wrong even with a zero-tolerance policy in place on 'stealing'.

</comment></comment></comment></comment></comment><comment><USER5> Cover of the book he originally lifted:

[http://www.fantasticfiction.co.uk/y/frank-yerby/treasure- of-...](http://www.fantasticfiction.co.uk/y/frank-yerby/treasure-of-pleasant- valley.htm)

<comment> jim-greer Another version, a little more risque, as he described it:

<http://www.coverbrowser.com/image/pocket-books/180-1.jpg>

</comment></comment><comment><USER6> The 8 levels of good deeds, as organized by Maimonides:

      1. Giving begrudgingly.
      2. Giving less that you should, but giving it cheerfully.
      3. Giving after being asked.
      4. Giving before being asked.
      5. Giving when you do not know the recipient's identity, but the recipient knows your identity.
      6. Giving when you know the recipient's identity, but the recipient doesn't know your identity.
      7. Giving when neither party knows the other's identity.
      8. Enabling the recipient to become self-reliant.

By continually adding books, Mildred Grady fulfilled both numbers 6 & 8\. May her memory live on through her good deeds and the good deeds they spawned.

<comment><USER7> if you want to achieve 6 & 8 _now_ , sign up for <http://kiva.org> anonymously and lend money to entrepreneurs.

</comment></comment><comment><USER8> I am quite amazed that reading was considered uncool...even in the 50's

<comment><USER9> There was an article recently about John Ogbu, either on HN or reddit. Can't find the same source, but from a bit of googling: <http://www.ogbu.com/>. Main point: black children tend to be behind at school because the home and peer culture is at least not supportive, and at worst against education.

</comment></comment><comment><USER10> That's one hell of a story.</comment>


Samsung Launches Galaxy Note 10.1 With Impressive Features - <AUTHOR> http://techpp.com/2012/08/06/samsung-galaxy-note-10-1/

<comment><USER2> Good on Samsung for continuing the trend Lenovo seems to have started of bringing the digitizer pen back. The fact that people are buying aftermarket styli for devices that don't have pens is an indicator that there should be more devices with them, since nothing really beats an actual digitizer pen. To me it seemed like a step backward when Steve Jobs first asked "Who wants a stylus?" at the iPhone keynote.

<comment><USER3> > The fact that people are buying aftermarket styli for devices that don't > have pens

Are you sure about that? My completely unscientific anecdote is that people buy the galaxy note for it's size, but end up never using the stylus at all. I see a _lot_ of galaxy notes in the wild, but never seen someone who actually used the pen. People usually tell me they tried, found it terrible and gave up.

Are my anecdotes too off? Are you guys seeing something different? Maybe someone has some good data on this?

<comment><USER4> People are buying styli. The Kagi Stylus is popular on the train I ride to work. I saw someone using one on their ipad with Notable and I asked her where she got it (it has a clear disk on the end so it feels more precise) and she said ebay. Right from China to your mailbox. But it turns out that this type of styli is hard to come by otherwise. In my email exchanges with the vendor they claimed they were selling thousands of them, but I would not expect them to say 'hardly any' so its not solid data, Ebay's 'how many are left' on their buy it now auctions were starting at 100 and working their way down to 0 pretty quickly (a few days).

That said, one of the things I really liked about the iREX Illiad (RIP) is that it used an honest to god Wacom stylus digitizer. That can capture tilt, pressure, and doesn't require a conductive connection between your finger and the tip. I've argued for a while that blending the two would provide a really useful combination.

The Wacom only allowed single touch so using capacitive touch as 'modifier' keys would allow for combined intent+action type things.

</comment></comment></comment><comment><USER5> Looking at the "note taking" screenshot, their virtual keyboard style is shameless.

Screenshot: [http://cdn.techpp.com/wp- content/uploads/2012/08/Capture1.jp...](http://cdn.techpp.com/wp- content/uploads/2012/08/Capture1.jpg)

<comment><AUTHOR> what do you mean by that?

<comment><USER6> They ripped off Apple's significantly contrasting, virtually elevated, rounded-corner button invention.</sarcasm>

<comment><USER7> Well, they did. And I say that as someone who really dislikes Apple.

That keyboard looks like someone took the iPad keyboard and beat it with an ugly stick a little bit. What makes this especially sad is that the default Android keyboard is really good and they should have just used that, but in an attempt to "differentiate" they basically just badly copied the iPad.

As much as I dislike Apple for the current lawsuit mess, I'm starting to dislike Samsung just as much because unlike most of the rest of the Android ecosystem Samsung clearly DO have a problem with badly copying Apple's design elements to a confusingly similar degree which gives an unfortunate truth to at least some of Apple's claims which then makes it harder for the layman to see when Apple is overstepping.

Fix your shit, Samsung. Hire a couple of real designers.

<comment><USER6> Nah, I think it looks and functions as much like iOS keyboards as it does my G1's physical keys: [http://mossblog.allthingsd.com/files/2008/09/android- open.jp...](http://mossblog.allthingsd.com/files/2008/09/android-open.jpg)

Maybe even the G1 took hints from iOS, but I'd be dubious to believe Apple created or holds any merits over much of their design(s). Does Samsung lift Apple designs? I think so. Does Apple own much of the designs they have legal documents over? I think not.

I don't believe this is about confusing customers; I think it is about closing the gap with customer awareness. I'd love for most of these interfaces to share common grounds; I think it is a large reason to why Windows, OSX, and GNU/Linux <insert GUI> are so fragmented and unfamiliar to those that have to or are looking to move between platforms.

</comment></comment></comment></comment></comment><comment><USER8> Really interesting that the resolution is only 1280x800. This is just a little more than the 1280x720 resolution of my Samsung Galaxy S III phone.

<comment><USER9> It's also identical to the 5.3" Galaxy Note phone.

</comment></comment><comment><USER10> It's odd to me that no one seems to be noting that the video doesn't show a single second of actual use. It's all mockups and pre-rendered scenes. Is that not extremely concerning to the commenters saying that they already want to buy one?

<comment><USER11> Speaking as someone who does want to buy one, I am concerned that the video didn't include any actual use. That being said, I've tried out the original Galaxy Note several times. As long as the new one is a step up in terms of responsiveness and pen performance (which seems likely, though not guaranteed) I will be more than satisfied. On the other hand, I'm also not buying one until I can try it out for myself.

</comment></comment><comment><USER12> I understand strategically why Steve Jobs stood on stage and slammed the stylus, but I never really understood the practicality of being against a stylus. For many people, quickly jotting notes is natural, quick and easy.

I've spent a lot of time with Windows Tablet PCs and latency issues aside, they have excellent recognition capabilities, even reading my slop. Aside from latency, it would also help to get the digitizer physically closed to the actual display elements.

I'd kill for an iPad with a truly high-resolution digitizer. It would finally replace carrying a thin stack of index cards everywhere.

</comment><comment><USER13> The pinch-shrink keyboard might even top the different-sized keyboards built into webOS. Samsung has some innovative UI stuff going on in that video.

</comment><comment><USER14> Love the stylus. I remember being able to enter text onto my iPaq about 10 years ago much faster than I can on my phone or tablet today. This brings tablets a step closer to being devices of creation as much as consumption. Call me a nerd, but I want to write code on this.

</comment><comment><USER15> I wont buy Samsung again. I still feel burnt by my purchase of a 7" GTP1000. The hardware is great but the software feels unpolished, laggy and really ugly in places.

At the time I was expecting Samsung would follow Apples lead and ship updates for years to come. Instead... nothing.

I'm going to stick with Apple from now on.

</comment><comment><USER16> Has a price been released yet?

<comment><USER11> Not just a price... [http://negrielectronics.com/samsung-gt-n8000-galaxy- note-10-...](http://negrielectronics.com/samsung-gt-n8000-galaxy- note-10-1-16gb-unlocked-white.html)

$750 (list $800) for a 16 GB 3G version.</comment></comment>


Facebook begins global rollout of "Find Wi-Fi" feature for its mobile apps - <AUTHOR> https://newsroom.fb.com/news/2017/06/expanding-find-wi-fi-globally/ <comment><USER2> "Find Wi-Fi will turn on Location History. This allows Facebook to build a history of precise locations received through your device. You can see or delete this information in your activity log."

I think it's kind of ridiculous that just to use a search database, I have to enable 24/7 location tracking of my phone...

<comment><USER3> Well, you have to pay for all this (Facebook stuff) somehow. It's not free.

</comment></comment><comment><USER4> Hmm. Neat trick to incentivize more businesses to share their information, while also tracking more end users.

</comment><comment><USER5> Interesting how it's only for companies that have it shared on their page. FB will have the same info as Google as to where all the free Wifi is located, they're either being cautious or they're trying to drive companies to setup a page.

<comment><USER6> Or, you know, they want companies to opt in to sharing. It's a kind of free advertising, but not every coffee shop wants to advertise it has wifi...</comment></comment>