First Step for a New Architect: Join Development and Build Small Modules

Understanding the business and talking to the existing development team are important, but the author’s personal recommendation for a newly hired architect is to start participating in development work, beginning with small modules, then moving to medium and large ones.

The reasoning is that without deep, concrete knowledge of the system’s details, an architect cannot produce high‑quality software designs that fit the current company’s needs. Although architects may have a set of so‑called universal design principles and experience from previous jobs, these are often impractical in the specific context of a new organization.

In many codebases, small changes can have complex and unpredictable consequences. For example, ensuring consistency in a complex system may require a comprehensive understanding of the entire codebase; without that, any design proposal is likely to be flawed and could “pit” the team.

The author emphasizes that only developers who work on the code daily and know the system intimately can create reliable designs. He recounts experiences where architects blamed implementation teams when their proposals were not followed, highlighting the risk of relying on abstract principles without hands‑on insight.

Consequently, the author advises architects to set aside generic design doctrines and best‑practice checklists, focus first on the most concrete details, gradually collect knowledge, and then select the most appropriate design from their mental toolbox.