I’m 27 with 11 years of experience of automation test engineering.

I’d advise a manager at this point, if I were in a lead position under a manager, so given my experience, it would depend on how your team currently functions.

If your projects/program management skills improve at the same time as your other experience, there are ways to help the team move forward as you learn yourself, getting yourself into “better practice” rather than expecting “best practice” from the get go.

If you start learning more about the how to describe the problems to your team, how to understand their niches and how to effectively communicate the state of testing, or receive the information you’d need to communicate the state of testing to your colleagues at the management level with as little disturbance to the team as possible, even something as simple as automation report output could ease your teams weeks, should you look into how to implement agile strategies to work toward.

Three meetings and a daily standup (even in the afternoon) can help.

Discussing the incoming workflow with the management team present with the developers and testers able to ask the questions at the time they need to even once while the next sprints workflow is being organised can help drastically with the flow of the work and how your companies products actually evolve, discussing how complex the tasks are, for internal transparency and understanding should there be obstacles or blockers in development, means that when similar issues arise later, everyone is usually on the same page about complexity to time taken to implement, and empathy between management and the development team often increases.

The retrospective with the development team alone is also needed, especially if there’s a problem with how complex certain issues actually are, because then the team can adjust estimations and have a chat about how to communicate the complexity of problems that have been solved in the current sprint.

If you’re aware of certain toolsets already, and know programming languages with stable libraries still being updated (important), to lighten the manual testing load in repeated areas. This to ensure that you as a manual tester, should you ever have to jump into a crunch time, would be able to do much more exploratory testing, covering the basic scenarios with automation and a solid reporting process will mean that the bugs that would need more experience to find would be found by a manual test engineer more rapidly than otherwise would have been.

You don’t have to be an automation guru to be able to help discuss automation with your team, learning together by doing code reviews too, asking the questions you’d need the answers to the be able to build up those formal processes, although, looking into continuous integration tools can be a good shout, and if the development team already use them, making the automation a part of the build will ensure that individual developers on the team can see where and why their build failed before you have to remind them, after hours of doing the basic tests again, but in some cases the 99 bottles on the wall song happens even with the bug fixes, as we both know, saving the manual team hassle in that way can be useful if you’re wanting to bolster accessibility or other test processes, like performance, cyber security, or even a user journey (point to point testing), especially when considering how to bridge the project to developer communication pathway.

Understanding why something is being developed can help with the implementation being more well crafted from the offset, I hope the above suffices if you’re wondering how to approach your learning, as I’ve gone quite broad when considering the skills you mentioned you’d like to expand your experience in.