this post was submitted on 16 Apr 2026
35 points (97.3% liked)
Homelab
2137 readers
1 users here now
Rules
- Be Civil.
- Post about your homelab, discussion of your homelab, questions you may have, or general discussion about transition your skill from the homelab to the workplace.
- No memes or potato images.
- We love detailed homelab builds, especially network diagrams!
- Report any posts that you feel should be brought to our attention.
- Please no shitposting or blogspam.
- No Referral Linking.
- Keep piracy discussion off of this community
founded 2 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
Then I would absolutely share your concerns. If you can't share the value proposition clearly with the owner in your own words, then it will reflect poorly on you when this goes sideways with negative results. IMO you don't even need to say no. Just say, "there's no way I can explain this clearly to with what you've told me so far. I can't sell a plan I don't understand and I don't have enough details to understand the steps here. Let's write this down in a document that we can go back and forth on to get the details right that I can share with others." Then make some suggestions for them to do the leg work.
Before any hardware or software gets built or acquired it can be helpful to go through some exercises. Probably the most helpful here:
Business Requirements Document (BRD) - stakeholders, business constraints, goals. Should sell the idea "we need to do something here because it's important to the business for XYZ reasons".
Product Requirements Document (PRD) - Critical User Journies (CUJ), user stories, use case analysis. Should iron out how a solution should look like to achieve the stated goals of the business doc. Specify success criteria, what metrics are important for this to be a success "we saved staff X hours, we cut costs Y dollars, we brought in Z new clients".
Technical Specification or Technical Design Doc (TDD). Should explain how to achieve CUJs through a technical design. Focus should be both "why" to do it this way AND "why not" do it some other way. Tradeoff analysis.
Then there are a dozen related drill-downs exercises: legal review, security/privacy/compliance review, internationalization, launch review, UX review, on and on. They all serve a common goal: get everyone on the same page. You don't need to contort what your are doing into any of the above, but it's just kind of evolved into these aspects because it's so difficult to get everyone on the same page.
Again, I'm not saying adopt all of the above, but if you don't have the technical knowledge then your role is closer to a project manager and that is its own set of skills. It's very helpful when PMs have some technical background (so absolutely continue enjoying Homelab hobbies), but (from a random internet stranger's POV) here you need to wear a project manager hat.
Good luck!