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?
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.
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.
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!
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.
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.
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.
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.
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.
(Edit) in case it’s edited: “Ask HN: I've been promoted to Architect. What do I need to learn/do to excel?”
* 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.
https://www.thoughtworks.com/radar/techniques/lightweight-ar...
I think it's a nice way of sharing with other engineers why and when decisions have been made about the use of a technique or technology.
- 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!
- 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.
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.
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.
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.
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.
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.
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.
In the other direction, coordinate the work on architecture and leave some of it to the developers.
Understand the domain(s), if you don't, find out who does, talk to them, write it down, read it back, until they say you've got it.
That way, you can take new ideas and new requirements and see how they fit into the domain, how it will need to stretch or flex to accommodate them. You will be able then to explain it to both the people wanting the new thing as well as the people that have to build and deploy it.
Making things flexible is the hardest thing, you don't want things to be too flexible, it makes it too hard to keep something running. But you also don't want it too rigid, it makes it too hard to adapt.
I’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.
https://blog.phuaxueyong.com/post/2020-03-24-how-to-improve-...
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.
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.
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!
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!
- 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!
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.
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.
I would like to recommend the recent book “Fundamentals of Software Architecture” https://www.oreilly.com/library/view/fundamentals-of-softwar...
It covers important foundations, walks through different architecture patterns. The last part of the book is about soft skills: communications, decision making, etc. In my experience, it is critical for such position. The book is different from piles of enterprise architecture books that talks a lot about UMLs, formal processes, ceremonies, and roles - things I found either irrelevant for my jobs or I can learn them better elsewhere.
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.
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.
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...
- 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.
In my view as an architect you need stay a top notch coder.
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.
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
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...).
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=...
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.
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!
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.
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
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?
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.
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.
* Learn to measure cross-cutting, high level technical metrics. Build up your own "fitness functions" and constantly ensure they are looking healthy. e.g. Incident metrics (https://www.atlassian.com/incident-management/kpis/common-me...), SLOs (https://landing.google.com/sre/resources/practicesandprocess...), Lighthouse scores, Time from raising a PR to deploying in production, etc. https://www.thoughtworks.com/insights/articles/fitness-funct... Don't be "abstract" when talking about maintainability, testability, observability, etc, but be able to support them with numbers.
* Draw yourself a line. Find out where you are the decision maker and where you are not. Example: don't make your entire judgement based on "how many people can be allocated", "what's the cost", "will users like this feature", etc. Budget, people & UX are not your decision making responsibility, there are Managers, Directors, Product owners for that. Give your recommendations, but let them do their job. It's easy to fall into the "I know everything better" trap.
* Don't be a "hired gun" working feature after feature, or a firefighter resolving issue after issue. Have an agenda for the technology itself that you work on 30% of the time. 6 months down the line, regardless of projects or firefighting missions – you should be in a position to prove that the technology is maturing, like: "In the last 6 months, our number of incidents/bugs has decreased from * 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.
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.
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.
(tip your waiter)
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.
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.
- 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.
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.