Mfcttrf

One year ago I got a job at a non technical company. Because I was a junior I quit after 4 months and went to a web-dev company and continued to work with them part-time.

Now I decided to go back to that company. I will be again on my own (one man team), but now I want to be more professional.

I was thinking to have meetings once per week with the product team and see what implementations we need. Beside that, maybe 1-2 extra meetings if there's anything new that we need to discuss.

Do you think that's a good idea? Have you been in a similar situation? If yes, do you have any suggestions for me?

As an alternative way of asking the question, I like to think about: "What can I do to make myself easy to work with, both for my current colleagues and future colleagues?"

Some major themes in answers are:

1. 
   Be transparent: Make it super-easy for others to understand what you're working on and why it is important. Check-in meetings are good, but use that time for problem solving. A blog on the company intranet, or a note on a share drive that is easily accessible could be good ways of helping individuals understand what you're doing and how it helps them.


2. 
   Know your stakeholders: Know the full suite of individuals who have a stake in the success of your projects and be thoughtful about how to engage them. Some will want occasional progress updates, others will only want to know when things are going poorly.


3. 
   Define work upfront: Even if you have the autonomy to be fully self-directed, be disciplined about writing charters for your work and discussing them with stakeholders. These force you to discuss resourcing, requirements, and timing before kicking off a project and giving you a chance to filter out unnecessary or unreasonable requests.


4. 
   Measure your own performance: Track some meaningful metrics about how well your function is performing (e.g., product modifications cleared per day, or issues resolved per day). Use these to challenge yourself and look for warning signs of getting bogged down or focusing too much on one part of your role.


5. 
   Document and log your work: Anticipate someone will take over your work in the future, but you won't have the opportunity to discuss your efforts with them. Leave a well-curated documentation trail behind explaining major decisions and issues.

Good luck in the new role!

The shortest answer is: We can't answer that.

The next shortest answer is: These are questions you should be asking your manager or some higher-up, not the internet.

All that said? You need to simply judge what's effective. I mean, there are some places where you'd need to have daily meetings; there are some places where a twice-a-month would suffice. Some positions demand rapid adaption and development; some are more concerned with stability and maturity of product. So failing any sort of direction from higher-up, you need to weigh after each meeting: Did it seem like we had too much to discuss in this meeting? Did it seem like we were having to reverse course from previous meetings at some points? (In those cases, you probably need more feedback.) Or did it seem like the meeting was basically just a time-waste that didn't impact anything (in that case, you probably need less of them.)