Few years back I wrote about lessons learned while working as an architect, you can read them here. Since then my role changed from an architect who works on implementation projects for a single customer to an architect who consults teams from multiple customers spanning different industries. Here are some new lessons I learned external consultant/architect.
Accept the fact that efforts realization will be low
While working on a single project, all you care about is details, and make it work. It’s a fulfilling job with a high realization of efforts, the outcome benefits end users, sometimes you need course correction, but you learn as part of that process which is also fulfilling. Consulting on the other hand is very different, you are always on the move, switching context, effort realization is very low, you spend time on things like POC, RFP, and RFI which may get scrapped suddenly. This impacts your motivation, and you may feel out of action. By accepting the nature of consulting business you will be able to cope with low realization.
Use/suggest patterns/styles/practices without naming them
Using loaded terms like Microservices to explain proposed design invites unproductive debates. The discussion moves to advantages vs disadvantages of said practice, everyone starts throwing buzzwords, and it derails the focus from the actual problem. What I learned is to just use the underlying idea, for example instead of saying “Microservice Architecture”, I say “Modular services holding their own data, using asynchronous channels and crisp messages for communication”. This removes unnecessary resistance and bias. This advice looks contrary to practice of naming patterns to ease the communication, but I found it very effective.
Connect with real decision maker(s) and end users
As an external consultant, it takes time to get access to real decision makers within the customer organization. Sometimes the org structure does not reflect real flow of decision making and influence. Finding the key decision makers, opening a communication channel with them, and establishing trust is key for success. There is no formula for this, you have to observe, listen, and follow the memos (like follow the money). On the other hand, finding end users is easy, but getting access to them is very difficult for external consultants. Organization policies, politics, and culture builds multiple barriers between you and the end users. Connecting with end users, and understanding their needs helps you to distill the problem statement. It helps you to ensure that you are building the right thing for the right people, and deliver it incrementally.
Understand and pick your battles
As an architect providing appropriate technology solutions to a business problem is your primary battle. Defining the problem is also a battle, navigating a complex org structure for information is another one, and so is selling your solution. Each battle requires different skills, you can’t master them all. You have to pick your battles, work with your team to augment skills which you don’t have and support them for remaining battles.
Thanks for reading.
Top comments (0)