Transform a large-scale architecture: The first 30 days, and half year.
This blog is part of the series "Transform a Large-Scale Architecture Guide." Please see the links below for the other parts of the series:
- Before the Landing
- Create the Vision, the First 30 Days, and the First Half Year
- Get the First Project Started
- Execution and Delivery
- Promotion and Performance Evaluation
After careful consideration, you have decided to join the team. The first 30 days are key to making a good impression on your new colleagues. People will have expectations and judgments, so take the time to get to know them, create a positive impression, and present yourself as they expect. Keep a low profile and don't rush to make judgments.
First 30 Days
As an architect, people naturally expect you to bring new ideas and directions. Talk to your peers and managers to see what they expect. Your job is to transform, so they expect you to challenge them, but do so in a cooperative manner.
Don't judge. Bringing freshness to the team is good, but not everyone wants to be challenged. Be respectful, kind, and empathetic. Ask questions and help them understand that you are here to help them achieve success.
Try to start with something small. It takes time to create a thinking framework for a grand picture, and lots of research is required. This is the most important job of the transformation, but it takes lots of time. Meanwhile, find a peer who needs something from you and partner with them.
Be mindful of what you say. Don't talk about things that people are worried about. Transformation in architecture also means changes to the business and teams associated with it. If there are team changes, it will be an organizational change initiated by the leadership and driven by the transformation. The architect's role is to enable the organization to do that. Let people see it. It's too early for the first year to even talk about it. The organization will arrange things more appropriately and gently.
Try to make as many friends as possible. Attend the team's typical activities and be a part of them. Identify people who may have a similar background.
First Half Year
The most important thing is to create a workable vision and roadmap. But it takes time, so don't rush. Talk on a weekly basis and set up a routine to talk. Note things down with any notebook software. Talk with ideas, learn the ideas through research, keep track of industry trends, and check the reactions from peers, partners, customers, and other leaders. Identify what is doable and what is not.
While creating a grand vision and workable architecture, the first 30 days have already presented some low-hanging fruit to work on. Get the existing team members to do them. Understand what the team is good at, what the culture is, what the working standards are, what the quality is, what the process is, and so on.
Hiring
In my experience, transformation always comes along with hiring. During the first half year, you have a chance to change the culture by hiring key people.
Hiring is one of the most important things in transformation. People are hard to change. As an HRBP said before, 80% of things are settled once people are hired, and only up to 20% can change. The culture can be transformed by hiring, but you will need to know what kind of people you need to hire. The market is big, and you can always hire many people, but try to hire more experienced people rather than fresh graduates. The fresh graduates will be transformed by the team instead of transforming the existing.
Getting Things Done
Getting small things done creates credit among your peers and is one of the key supports you will need during the journey. Leverage the current team members to help deliver. Work with them, see through the work, see what they are qualified for, and see what they are not.
Coaching people is one of the ways to change. There will always be people who want to learn, especially passionate engineers. One of the best things about transformation is that there are tons of coaching opportunities. Coach through challenges, through various work, give space to everybody, let them do it, and then coach on cases.
Create the Vision
There are always plenty of things to do, but besides hiring and getting things done, spare a big part of the time focusing on the big roadmap.
First, you will need ideas, lots of ideas, lots of workable ideas. The ideas come from learnings on the industry, outside research, notes, talking with various leaders, and research on existing systems. Then, formulate the ideas into a workable solution that needs connections. The more connections, the more complex the whole solution becomes, and there will be a lot of moving pieces.
Second, after getting the ideas and connections, you need to know where to start and how to start. Creating a stable boundary will be critical. You will need to create domains and set up connections with each domain. There are books like Clean Architecture that talk about it and the elegance around it. Creating an architecture can also mean working with legacy systems, so Working Effectively with Legacy Code and Monolith to Microservices teach you how to work on that.
Finally, in my experience, it is often harder than technology itself. The books often tell you how to work from a technical perspective, but not from a product and organizational perspective, which the latter articles will cover.
