The silver lining here is that the world has gained an extremely compelling argument for regulations.

Epics don’t have to be huge. And stories don’t need to be attached to epics in the first place.

An epic is just a way to organize features. There’s no hard and fast rule for how many features are needed to form an epic.

If the work is expected to make it into the deliverable product, then it should fall under a feature. Either add it to an existing feature or create a new one. I prefer the former because it results in less deceptive forecasts.

Don’t take too long trying to figure out a challenge by yourself. Ask questions. Unlike in school, you are allowed to ask for help with your work.

Learn how to write unit testable code as soon as possible (SOLID principles). Learn how to write concise and relevant unit tests. If it’s not in your team’s culture to write unit tests, then you go be that guy. It’s good for you and it’s good for the product. Unit tests are one of the few things in the programming community that everybody believes are a good thing.

Form a starting team based on skill sets and let them do the rest. Give them a project and they will tell you what they need if they feel assured that you have the capability and will to help them. You want the team to cater to the product, not to the manager because manager satisfaction does not bring value to the organization or the customer. You only need to manage more closely if for some reason you were only able to gather junior devs.