| First up: having total visibility of the org is really important. We have a hundred engineers and I see everyone’s changes at the point they make them public (in whatever form they are called today: pull requests, merge requests, diffs, eh.) Unless I engage then that’s the first and last time I see their stuff but it’s enough to stay on top of everything everyone is up to. It’s a surprisingly low volume / high value channel of information. Leave the code review to the experts in each codebase — most changes will be on point and need only a small or large amount of alignment before they can land. (By contrast, very few things need to have the brakes put on them.) Some changes though will correlate with other problems across the codebase and this is where you should be stepping in to spot future patterns or current anti patterns and providing solutions and directions forward, or at worst, road blocks. Once you have enough of these under your belt you can start
proactively spotting hot spots in the eng org that need focused effort. More mypy typing for a core library. Two libraries that should be one. One library that should be two. Vertical slices of functionality in two products that should be horizontal slices pulled into a separate service (or, my preference, library.) Processes are important too. You’ll see what people are repeating and or finding hard, and which could benefit from some love. Build infra. A testbed for debugging a process that is otherwise too heavyweight with production data. Teams that don’t talk enough pre-PR. Managers that need help managing consistent poor performers. I think many people wanting to go into an architect career think it is highbrow design work. In reality, I’ve found you end up doing much more support / boiler room / janitorial work. It’s very satisfying, and very much reminds me of my career sidetrack as a school teacher. Above all, you are there to help people and teams reach their potential and get the most from their jobs. |