| This is... kind of precisely the distinction between technical leadership in a medium sized team vs in a really large team. It's one of the hardest challenges I work with senior devs to overcome as they move up to larger and larger scoped roles, up to principal engineer positions. Because what they have learned that got them that far stops working as they develop into more expansive roles and responsibilities. Basically, the problem solving approach of 'I'll go away and work out how we're going to do this, then bring back a masterplan', while it offers a good path to successful project delivery early in your career, does not scale. What worked for you when you were building a system with one or two teams working on it for three to six months is not a viable approach for systems which will have five to ten teams working on them, over multiple years. You have to adopt approaches that decentralize decisionmaking - else you'll become a bottleneck; you have to adopt approaches that are adaptable to information that will be uncovered later and to requirements that will shift; you have to adopt approaches that acknowledge that you are never going to be 'full stack' enough to be able to make smart decisions about every single part of the solution - the mobile apps, the backends, the financial system integrations, the frontend caching, the analytics and reporting... and you need the expertise of different teams to deliver that. You basically have to unlearn the pattern of 'let an experienced person set out the whole plan' that has been successful for you so far as you move to higher level leadership roles. As a principal/staff/whatever in a big engineering org, your role is much more about making sure that the right people are having the right conversations and negotiating the right boundaries and not getting caught up on artificial constructs they think are being imposed by you from above. You need to leverage all the intellectual capabilities of the senior engineers on every team, not tie their hands by thinking you know more than them. Same as as you become more senior, you shouldn't be writing critical code - eventually you also get too senior to be making critical architectural decisions. |