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