Primary/Home Team for users with many teams (for accurate team capacity)
Vasil Enchev
When a person belongs to multiple teams, ClickUp should let them (or an admin) pick one Primary Team that acts as their default “home team”.
Make Workload capacity clear when grouping by team (count each person only once)
Make navigation from Personal Priorities / user pages consistent (default “Go to team” goes to the Primary Team)
Make it easier to understand org structure in Teams Hub / Org Chart (mark who is primary where)
Log In
Summer Aims
All of this screams, "We only thought about functional teams and highly structured org charts."
Where is the Enterprise or agency PMO thinking? Is there a separate thread I should be looking at?
J
Joseph Plaizier
Summer Aims, I unfortunately agree. It feels that most of the features in ClickUp are not thinking about enterprise level teams, projects, or user management including this one.
Vasil Enchev
@Summer Aims - sharp pushback, and totally fair. You're right that "primary team" leans on a clean hierarchy that doesn't match how PMOs (especially agencies like yours) actually work. A few directions we could go — would love your take:
- Weighted allocations- a user belongs to multiple teams with % capacity per team (e.g. 40% Team A / 60% Team B). Capacity reporting respects the weights.
- No "primary" at all- every view chooses its own team scope, and we just make multi-team membership feel native.
- Hybrid— admins can mark a primary forsomepeople (the structured org case) but it's never required.
Which of those (or something else) feels closest to how Driven Connection thinks about a person's "team"? Especially curious how you'd want capacity to roll up when one person is split across 5+ client teams.
Vasil Enchev
Joseph PlaizierJoseph - hearing this loud and clear. Want to make sure we get the enterprise angle right. Two specific Qs:
- Do you typically have an authoritative HRIS(Workday, BambooHR, etc.) that already knows primary team? If so, syncing from there beats asking admins to mark it again in ClickUp.
- For capacity reporting, is the unit you care about team headcountorindividual hours allocated to a team? Different solutions.
J
Joseph Plaizier
Vasil Enchev, thanks for the response back! 😊
- Short answer, no; long answer, we actually may have one that our HR team uses, but our organization is so large and our security policies are so strict that even if we did have one, the chances that we could integrate isn't great. Not impossible, but not great. As far as I know though, we don't have one and we're using a internally developed tool. It would be awesome if we could integrate into something like that though for this solution.
- Both, depending on the team. Some of our teams are dedicated teams for specific tasks - for them a headcount makes sense. Other teams are more like a pool of available people and when someone is available and has the proper skill sets they get assigned to a project (often multiple people from the pool get assigned). For them it may make more sense for it to be individual hours for the team and for each person in the pool.
I realize that every company does things differently so curating a software solution for everyone isn't possible. I appreciate you willing to listen, get feedback, and help improve the software.
Dave Montrose
We would mainly separate this out for teams by specialism, and teams by project. So in our case it would make far more sense to have Teams and Projects. Teams are Design, Dev, Motion, Copy, etc. That's Org-level stuff. Project teams really have nothing to do with Org charts, they're just who is on a project. The only thing there is setting who can do what – task setting, assigning people, timesheet approval. Anything else, and I'd be concerned you're really overcomplicating it.
As far as setting hours, it makes no sense to me that it would be anything other than setting the amount of hours available for all members globally – eg 40hrs – and being able to set them at an individual level too. Those hours would be usable across all teams they're part of, in total. Otherwise it's 40 hours in all project teams for one person, which essentially makes 100s of hours a week per person. If you want to see how much time someone has left on a project, you also need to see their overall utilisation – perhaps I'm misunderstanding the use case there?
Vasil Enchev
Dave MontroseDave — the specialism-vs-project-team distinction is a really useful frame. We've been thinking of teams as one concept but you're describing two different relationships:
skill membership
("I am a Designer") vs assignment
("I'm on Project Alpha for Q2"). Would it help if a user could have one primary skill team
but multiple project teams
without all of them counting toward "home"?On work hours: global + individual override sounds right. Would
per-day variation
(4 days × 6h / 1 day × 8h) matter for your use case, or is daily uniform enough?Dave Montrose
Vasil Enchev yes – especially in agencies, design and dev teams are just that – design and dev teams. But they'll be on multiple projects at any one time. Yes, the only important thing is that one person only has 8 hours in a day to use (or whatever is set for them). Time has to be attributed to a project, but you can _view_ capacity used at an individual a team level. That's also really important to understand individual and team utilisation rates. If a team is always running at 60% or 130%, then that'a a big issue.
Vasil Enchev
Dave Montrose yeah - looks more and more like we might need to set % allocation per team or per project at one point. But I imagine this would also be related with variables across time - effective from to date.
Dave Montrose
Vasil Enchev Project is less important for % imo: it would then be conflating two things there: utilisation – ie "are we using the team properly/enough/not enough", as that informs if we have a staffing issue, and project allocation – ie "are we working enough on this given the overall time allocated to it (which fundamentally should have a monetary hourly £ associated with it, which is another thing entirely that's missing). It also doesn't need an effective from date in the initial sense, as it's just daily volume. Eventually, yes – but thst shouldn't stop it starting smaller. I think it's really important with all of this that it relates to a job to be done. No-one needs to see timesheets. No-one needs to understand how much of team time has been used. what they're trying to understand is "have we got enough/too many team members relative to how much they're used" and "if we need more, we're not going to make a profit relative to the rate associated with what we're charging for the projects they're on – therefore we either need to put our rates up, reduce scope, etc". I think the big issue at the moment is clickup has a lot of features that don't relate to a job to be done. Timesheets as a thing in themselves are pretty useless unless they help inform some kind of insight and therefore decisions. Team capacity is pointless on it's own – it's about then trying to make more or less of what you have. That next layer on top is where clickup has to function. That's where SaaS starts to talk about "supercharging". At the moment, it's constantly hovering at the level below where it's full of features, but remains lacks decision-making weight. That level up is where it will become operationally meaningful. So tldr; yes, per person – how much of each 8 hours a day, per team – how much of all the 8 hour days combined, per project – how much of the allocated time has been used by what teams and within those, what people. But I think until cost rates and billing rates can be set per team/person/project, as above, none of this has any real business value. We're still in the realms of a really good to-do list rather than an opertational business tool.