Teamcentric Skills
Closed betaKnow whether your team can deliver the work in front of it.
Connect reviewed skills and available capacity to the roles and projects that need them — so staffing, training and hiring decisions start with evidence instead of recollection.
Teamcentric Skills is in closed-group testing. Access is invite-only.
Billing Platform
Project readiness
- Node.js covered
- PostgreSQL covered
- Kubernetes gap
- Threat modelling single owner
Kubernetes has the largest weighted impact on readiness. Two members are one level below requirement.
Fig. 1 — Weighted project readiness, decomposed into the skills that produced it. Sample data.
The questions it exists to answer
If your organisation can already answer all six from records rather than from memory, you do not need this product.
- Q01 What skills does your engineering organisation actually have?
- Q02 What do your roles and the projects in front of you require?
- Q03 Where are the gaps — by person, team, role and project?
- Q04 Do assigned people have enough available capacity to cover every project role?
- Q05 Where should the next investment go: training, hiring, mentoring or reassignment?
- Q06 Which records have gone stale, and how much does that weaken the answer?
The model
One connected model, from records to decisions
Readiness, role fit and coverage are calculated live from records you control, and every figure decomposes back into them.
The dependency order matters: a readiness score means nothing without project requirements, requirements mean nothing without a catalogue, and an assessment means nothing without a reviewer. The application walks an organisation through that order rather than presenting an empty dashboard.
From capability data to delivery decisions
One connected, explainable model
Define
Your capability model
Members & teams
Reviewed levels · allocation · recency
Roles
Seniority variants · weighted needs
Projects
Skill demand · staffing · complexity
Connect
Skills intelligence
capability × requirement × capacity
- Reviewed level
- The level a reviewer signed off, not a self-rating
- Requirement weight
- How much a role or project needs that skill
- Recency decay
- Older assessments count for less, on a published curve
- Allocation
- Committed capacity, spent once across every role
Reviewed evidence feeds every score. Activity statistics stay contextual and never infer a skill level.
Decide
Analytics & action
Project readiness
Role fit
Critical gaps
Kubernetes
2 members below requirement
Skill resilience
Threat modelling
Single-owner risk
Fig. 2 — The capability model, the factors that combine it, and the analytics that come out. Names and figures are illustrative.
Capabilities
See the delivery risk behind every skills gap
Nine things the product does. Repository activity may provide context, but it never decides what somebody is good at.
- One approved catalogue
- Keep technical and soft skills, proficiency levels and categories in one governed catalogue. Members can propose additions; leads and managers can approve, map, request changes or reject them.
- Assessment and review
- Keep self-assessment separate from reviewed evidence. Reporting-line reviewers maintain the levels used by analytics, and every change retains its date, author and history.
- Roles and role fit
- Define job roles with seniority variants and weighted technical and soft requirements. Role fit scores how closely a person matches, and shows precisely which skills close the distance.
- Project readiness
- Give each project weighted skill requirements, then compare them with the effective capability and committed capacity of directly assigned members and assigned teams.
- Role coverage and capacity
- Check whether a project has enough qualified capacity for every role it needs. When one person could fill several roles, their allocation is spent once rather than counted repeatedly.
- Coverage and resilience
- Find the skills held by exactly one person, and the coverage that is thinner than the organisation assumes, before a resignation turns it into an incident.
- Recency decay
- An assessment recorded three years ago is not evidence of today's capability. Technical skill levels decay with age on a published curve, and stale-skill reporting shows where confidence has quietly eroded.
- Reports built for decisions
- Move from project readiness and role coverage into the exact skills, people and capacity behind them. Critical gaps, stale evidence, resilience and data health show what to address first, with CSV export where it applies.
- Repository activity, as context
- Optional statistics from GitHub, GitLab, Bitbucket and Azure DevOps across member, project, team and role views. Presented as context only — activity never feeds a skill level or a readiness score.
The application
What it looks like in use
Readiness, gaps and data health on one screen, each figure opening into the records behind it.
Getting there
Build the evidence before asking for the answer
The guided checklist follows the model's dependencies, so each assessment and readiness score has roles, requirements and project demand behind it. Most organisations reach a first useful readiness figure with one project rather than the whole portfolio.
-
Step 01
Build the model
Type the skills that matter straight into the catalogue, then define the roles that need them and the weight of each requirement.
-
Step 02
Add teams and projects
Record what each project requires, so readiness has something concrete to be measured against.
-
Step 03
Bring in your people
Members self-assess; leads and managers review. Members come last on purpose — an assessment only means something once there is a model to assess against.
-
Step 04
Act on the analytics
Run readiness and gap reports, then make the staffing, training, hiring or risk call they point to.
Governance
Capability data describes people. It is treated that way.
Who can see what is a product decision here, not a configuration afterthought.
- Visibility follows the reporting line
- Managers and leads see their own reporting-tree descendants; tenant administrators see the whole workspace. This is enforced on the server for every member and analytics endpoint, not hidden in the interface.
- Changes are auditable
- Material data changes and sensitive exports write audit events, and every skill-level change is retained as history. Reviewed levels are maintained within the reporting line rather than shown back to the member.
- Multi-tenant from day one
- Workspaces are isolated at the data layer, not partitioned after the fact. Seniority labels, locale and currency are configurable per organisation.
What it deliberately does not do
The current release is focused on the capability model and the analytics it supports. These are listed so you can rule the product in or out quickly.
- Inferring skill levels from commits or code
- Forecasting and scenario simulation
- Learning-content recommendations
- Hiring pipeline and applicant tracking
- Single sign-on and two-factor authentication
- Scheduled reports and alerting
Bring one live project and test the assumptions behind it
Skills is in closed-group testing with a small number of engineering organisations. Tell us about a project, the roles it needs, and the capability question you cannot answer confidently today.