|
I found myself in a similar position a couple of years back. One of the big things that changed for me is that I had to widen my field of view on a project. I had already worked the "full stack" through previous jobs, but now I was responsible for designing how everything connected: APIs, CDNs, servers (or "less"), storage options, security, CI/CD, etc. It's not unlike how we grew from single lines of code to functions to modules to applications. Now, you move to assembling all of the mechanisms into complex systems. Based on your training, I imagine you already know a good amount about the various tools at your disposal, and it is time to apply all of that together. Your days of learning new things is not over. You don't need to know the minutiae of everything, but you need to know what can and will work together, what may cause pain in integrating, and where your risks are. Oh, and you'll have less time to tinker your way through the new things. There are things that you may not be used to doing though. You'll spend more time in meetings trying to figure out what you're actually supposed to be building. You'll spend time investigating new tools to use (replace libraries and packages with services in your mind). You'll probably be expected to do even more project planning and estimating. And one of the most difficult for some people: you'll have to delegate. I still struggle with this one sometimes. You cannot possibly build it all, and now the people you have to rely on to build it will probably lack your experience, and on top of that, it's up to you to make sure that the requirements are crystal clear to them. And that's not their fault. We were all junior devs at one point. Crawl, walk, run. On the flip side, remember that some people WILL have experience in things you don't. Identify those strengths and leverage them! Oh, and there's a decent chance you'll need to manage how much all of this crap costs... Brilliant solutions aren't so brilliant when they cost more to run than they generate in revenue. |