Elanor

Your friend could walk you through their business processes and how they plan to use the third-party software. It would be a good chance to document all that knowledge.

You could also take a look on the documentation of Odoo.

Myspace has entered the chat.

Your company seem to have a significant technical debt in environments, tooling, test automation, CI/CD, that is slowing down releases. Is that a problem acknowledged in your org? Will you get support for continuing changes and is there an understanding of what is a good enough level?

Would a fixed weekly or bi-weekly schedule work? Both devs and QA can plan their work accordingly. For example: devs and QA agree on what to work on next on a Thursday and how to test (acceptance criterias). Dev start development, QA prepare tests (functional and regression). Dev work for a week, tests and feature freezes code next Thursday. QA starts acceptance test on Friday, they ping-pong Fri-Mon-Tue, regression test and full code freeze on Wednesday, release on Thursday. If quality of the code and tooling makes the process smooth enough, then a similar weekly cycle could also be possible.

Gradually increasing test automation could speed up the whole process. Devs and QA can write and maintain automated tests together.

Feature flags could help isolating bugs that are discovered late in the process.

If there are several rounds between devs and QA, then a root cause analysis can help there as well. Are devs and QA aligned on how to test? Are devs testing enough? Is QA giving enough info for devs on the bugs found? Etc.

First thing to figure out is if the new ship is stable:

• How were the customer numbers doing last 6 months? Churn vs new customers? Finance numbers (if possible to share)?
• How do you see the product of the company on the market? Who are the main competitors and how will the product win? Warning flags: not increasing customer base, people interviewing for dev roles have no clue about the product’s situation on the market

Next thing is to understand the team’s position within the company:

• what were the key deliveries of the team last 3 months, how are they connected to the success of the company
• what is the next top priority for the team Teams that are working on the key elements in the main product of the company are better for promotion for example. Teams that are working on side-projects or internal tooling could be better WLB.

Last, but not least, how does the team work:

• how is on-call? When was the last production incident and how was it handled?
• how does an idea get into development and to the users? Ask as an open ended question and listen carefully: – is there a backlog and prioritization, or ad-hoc pushing in new tasks – do they mention having different environments, code review, git or similar? – do they mention updating tests, test automation or manual QA? How are releases done? – where do they stop in the description of the process? Do they mention monitoring or logging? Smoke testing or post-launch checks? Is there someone checking if the release was a success for customers (usage/uptake or other key metrics)?
• how often do they release? Lead time for changes?
• how do they handle technical debt?

Keep practicing.

Read other people’s code, for example open source project. Contributing to open source can be good practice also.

Find a mentor.

Pick a team at work that has the skills and culture+capacity to mentor you.

Don’t leave a good place because of FOMO.

I have worked 5+ years at my first work place. Good WLB, growing skills, promotions, good people. Most people who left tried to come back.

Why do you think staying can cost you career advancement wise? What are your goals?

What is unusual about your current position? If your current position is very nieche or skills are not transferable, that could become a risk for your career.