didn't quite see this in other comments: its not about you anymore your job is to make the product and the team successful. the worst way to go about that is

didn't quite see this in other comments: its not about you anymore your job is to make the product and the team successful. the worst way to go about that is to use your new bully pulpit to make everyone follow your process i agree with the people who say you need to keep your hands in the code. absolutely. but maybe instead of picking out the hardest and sexiest problems for yourself...maybe acknowledge that you have alot going on, and that you might not have enough bandwidth. i've find it works better if I keep a wider eye on everything thats going on rather than swapping out my architect hat for a developer hat and working privately on something. its also a good idea to think about tracing/debugging/operational levers that help the team as a second order (but aren't in the critical path). assume you're going to be parachuting in all sorts of places and leave time for that get to know your people/teams. you're going to deliberately be invoking conway's law. know strengths and weaknesses and help to set up the overall development structure so maximize success. if that means not using a language or tool you think would be the best choice, then suck it up. i don't find it at all helpful to consider yourself in charge. your role is to try to guide people to the right decision. to talk to everyone and understand whats going on and connect the right people together. to continuously translate the business needs to tactical action. but really, you're a support person now. i guess for some people i've blurred technical team lead and architect. thats fine - let me know where you think that line is.