In a couple months, I’m going to switch to another division of my company, so I’m leaving my current project after 5+ years as an architect. The new architects of the project, the project leadership and I have thought about how to manage a successful transition. I’d like to share the measures we are currently implementing, and kindly ask for feedback on them and for new ideas, as well.

Prelude

If you have some basic elements in your project, they will help tremendously in the transition process.

A healthy distribution of architectural responsibility: the architect can have some deputies who back her up when she is absent or busy. Or subsystems can have architecture owners who can effectively manage these subsystems. Such setups will not only help the lead architect in focusing on the strategic topics, but also ensure a less bumpy transition when the lead architect is leaving the project.

A low level of technical debt means foremost a simpler architecture that takes less time to explain and understand. Availability of high quality design documentation means the architect doesn’t have to explain everything herself, as the new architect can just read them. Automated tests enable the new architects to change the system more safely without violating existing requirements. Static code analysis helps by showing the troubled parts and also by guiding the new architect while the software evolves now under her lead. On a conceptual level I could argue that a low level of technical debt functions like a layer of abstraction between the architect and her project, so it’s relatively easy to change the architect.

Of course, not everything can be abstracted, especially when it comes to people contributing to the project. The leaving architect will also have a vision, which she needs to convey to the new architect, but (a) this is much harder than explaining the design, and (b) the new architect doesn’t have to embrace this vision completely, anyway. As I mentioned in my previous post, the vision is also related to the personal taste of the architect. So the new architect will bring some fresh blood to the vision. Similarly, the architect’s skills, experience and influence in the project is also not transferable. The new architect will come with a new set of these. Influence, in particular, has to be built for each project almost from scratch.

Transition

The transition of architectural responsibility from the leaving architect to the new architect should follow some basic steps. Here I lay out our ideas, for every project they should be tailored to the specific context:

Inform the project leadership early on: Assuming it was the architect’s decision to leave the project, I think it is the duty of the architect to inform the project leadership early on, so there is enough time to execute a successful transition. The project leadership can consist of the project manager, scrummasters or subproject leads if present, maybe also product management, architects from neighbour projects, higher management etc. The notice time should be longer than when a developer leaves the project, the level of technical debt should also correlate positively with the notice time.

Find the new architect: Depending on project needs, this could also be a group of architects. For groups a lead should be designated, otherwise design by committee antipattern could occur. Promoting from inside compared to hiring from outside has the benefit of less need for transfer of technical and domain knowledge. The major downside would be a more limited talent pool. While searching for the architects, it is a good idea to request some architectural tasks from the candidates first, to assess abilities. Another very important point is to make sure that the candidate is willing to accept the new role. The leaving architect, being motivated by architecture work, could wrongly assume everybody is motivated by such work.

Make the transition plan: This would lay out how the notice period would be spent, how much time should be allocated by the leaving and the new architect, and this has to be balanced against the daily project needs. The leaving and and the new architect and the project leadership should agree on the plan.

General announcement: Informing the team too early will create some uncertainty, while informing them too late may result in unhealthy rumours. IMHO the sweet spot to inform the team is to do it when the new architect is identified, and the transition plan is ready. This way, the team is informed when an action plan is available, so there is little room for vacuum and uncertainty.

Execute the transition plan: The activities in the plan should be executed by the new and the leaving architect. Some ideas about these activities:

• Do not discuss only design: In a workweek, an architect does much more than design. Think also about additional activities: Driving initiatives, coordination with the test team, dealing with suppliers, providing input to planning such as work breakdown structure and estimations, assisting team building etc.
• Proceed document-based: For all major activities, the leaving architect should be able to show some documents related to the activities. These make the explanations much more concrete, and they will also serve as future reference when the leaving architect is not present anymore. For the activities without an existing document, short documents could be written as part of the transition process.
• Architecture documentation: Existing documentation should be referred to during the transition – and important gaps should be completed, which will provide long-term benefits to the project. Some portions could also be written by the new architect and reviewed by the leaving architect, providing a verification of correct mutual understanding.
• Transition journal: A journal to log important details that couldn’t be mentioned in separate documents is a good idea for future reference.
• Transfer immediately: Whenever a topic is discussed and clarified, the responsibility should immediately transfer to the new architect, so she will have the chance to fail gracefully while the leaving architect is still around.
• Allocate fixed slots: While the plan lays out how much time should be allocated by the new and leaving architects it can still be difficult to sync their schedules, so it would be good to dedicate some fixed slots in the work week. In case of urgent issues, it’s easier to nibble into these slots than trying to find a slot each time.

Test leave: At some not-too-late point during the transition, the leaving architect could go on a ~2 week “test leave”, in which she might focus on some long-term topics in isolation, prepare some documents for the transition or go on a real vacation leave. The important point is the isolation of the leaving architect from the team in this period, so that the new architect can test if she can handle the project load on her own. Occurred problems should be noted during the test leave, and be addressed during the rest of the transition process.

Conclusion: At the end of the transition, as with any kind of time-taking work, it’s good to have a clear conclusion. This could be a meeting with the new and leaving architects as well as other relevant stakeholders, where the planned activities are compared against the actually done activities; results are evaluated etc. An essential part of the conclusion should be the feedback among the new and leaving architects for multiple reasons: (1) it will help in planning some follow-up actions for the project if necessary, (2) it will keep a good rapport between the new and leaving architects so that a fruitful future consulting among the architects remains easily possible, and (3) it is a very valuable guidance for the future careers of the architects. A concisely written conclusion report capturing the results and the feedbacks would be useful for other stakeholders so that they can inform themselves about this important event in the project. The conclusion is also helpful in reminding the architects that the project is now fully in the hands of the new architect now. For the reason of having a clear architect role, it would be good to announce the conclusion of the transition to the whole team, as well.

Reflections

I’m not completely through with the transition process, so I lack the 20/20 hindsight at the moment. However I have some early observations that I can share.

I realize that every initiative I took based on my vision that was in-progress is completely garbage now. A work that is half-implemented is dramatically more complex to transfer than a finished one: there are too many loose ends, no documentation, a lot of clarifications left, unfinished code, maybe some people who still need some convincing etc. And the new architect may have a different vision, anyway. So, it’s key to refrain from engaging in too many initiatives in parallel, and realize the vision in small chunks implementable in short timeframes. Not just for an easy transition, but also for moving at a healthy pace towards the vision, as well.

Another observation is that as the leaving architect I should not start any new initiatives during the transition. Considering this together with the fact that in the initial phase of my new project I also won’t be able to drive any initiatives since I will first need to comprehend the new context, there is a period where I won’t be engaged in initiatives, and actively driving them. I was always used to chasing a target, so it’s a bit of an awkward time for me.

A final observation is that it is really hard to “abstract” an architect from his project. A project manager, in contrast, has a quite abstract relationship with the project: there will be a backlog, budget, scope and team to take over for the new project manager. All but the team are quite abstracted artifacts; and not nearly as complex as things such as design documentation and technical debt. That’s why we tend to have deputies for architects and not for project managers, and also why many architects tend to work on a single project until they retire, while project managers tend to change their projects more often.