Selected work · Case studyFrom project silos to a shared capability system
Role
Test Manager, later Head of Quality Control
Context
Matrix organisation, long-term client portfolio
Sector
Quality-critical medical software
Period
Built from ~2014/2015, mature by ~2022
8 to 35
growth of the professional function
Direct management history
4 pathways
professional specialisation paths
Implemented capability model
4 to 5
concurrent projects typically supported
Operational portfolio
~10%
capacity buffer used as a planning threshold
Operating principle
01 · Executive summary
Growth required a shared operating system
Around 2014 or 2015, eight professionals were distributed across several software projects in a matrix organisation. Most served the same major client, but each project had its own product knowledge, terminology, daily workflow, leadership expectations and regulatory context. Although the people shared an employer, they did not yet operate as a transferable professional capability.
Moving someone between projects was difficult for two connected reasons. Product knowledge was deep and slow to acquire, with some complex systems requiring around six months before a newcomer became meaningfully useful. Local process knowledge was equally important; project terminology, team routines, quality practices and working habits differed enough to create a second onboarding barrier.
The inherited advancement model had another structural weakness. Client-side managers evaluated people using different standards. Some gave positive feedback easily, while others were more critical. Since feedback strongly influenced progression, people with similar capability could hold different levels and salaries.
I built the new function in connected layers: shared communication, reusable project knowledge, a common capability and progression model, specialisation mentors, resource planning and evidence-supported client proposals. By around 2022, the function had grown to approximately 35 people and supported four to five projects at a time.
02 · Business problem
The organisation had capable people, but limited shared capability
Knowledge trapped inside projects
People understood their own product and local workflow, but much of that knowledge was unavailable to the wider professional group.
Long domain ramp-up
Even an experienced specialist could require around six months to understand a complex product well enough to contribute meaningfully.
Different local processes
Terminology, daily routines, quality practices and regulatory expectations differed between projects.
Inconsistent progression
Different client-side managers assessed people according to different standards, producing uneven levels and compensation.
Capability was difficult to see
There was no common view of professional skills, product knowledge, certifications, interests or readiness for another assignment.
Demand changed quickly
Projects had hard delivery and submission milestones. The function needed enough flexibility to respond without maintaining an unsustainable bench.
03 · Building the shared function
Team identity, communication and reusable knowledge
The work began by creating a professional group that could communicate, learn from one another and understand why cross-project flexibility mattered. The measurement model developed alongside this shared foundation.
01
Understand the people
I held individual conversations to understand each person's motivation, interests, personality, preferred work and development goals. Allocation decisions later used this human context alongside capability and project demand.
02
Create a shared forum
A monthly team knowledge-sharing and product-demo session combined company updates, project milestones, future plans, product demonstrations, methods and new technology demos. Presenters volunteered where possible; when needed, I selected someone.
03
Turn demonstrations into reusable knowledge
Presentation materials, tools and demonstrated test environments were shared after each session. A short feedback questionnaire captured clarity, usefulness and requested future topics.
04
Record project knowledge
Projects were expected to document their terminology, workflows, quality and testing practices, local rules and practical onboarding knowledge. This reduced the need for every newcomer to reconstruct the work through informal conversations.
Capability transformation
From project silos to shared capability
Projects continued as distinct delivery units. The change was the professional layer sitting above them, holding shared identity, knowledge, capability and planning.
Swipe or scroll to explore the diagram →
04 · Capability architecture
One professional foundation, four development pathways
The capability model allowed people to develop in one or several specialisations, while all pathways rested on a shared manual and analytical foundation.
Manual and analytical testing
The professional foundation for understanding requirements, designing tests, identifying risk and analysing product behaviour.
Automation
Automation design, scripting, maintainability, tooling, infrastructure awareness and contribution to automated delivery.
Technical testing
Performance, hardware and selected security-related capability. Security testing stayed deliberately bounded, because the company chose not to build a dedicated security specialisation.
Test leadership and management
Planning, estimation, coordination, stakeholder communication, mentoring, interviewing and leading larger quality and testing assignments.
Progression levels
Level 0
Entry and potential
Interest, introductory learning and strong potential. Also supported hiring people with high potential but no previous testing background. They were not yet classified as junior professionals.
Level 1
Junior
Approximately six months of practical experience, selected tasks and regular guidance.
Level 2
Medior
Able to complete most normal tasks independently, with experience across different work or projects. Some highly technical tasks may still require support.
Level 3
Senior
Handles the hardest work, contributes to estimation and planning, works across several project contexts and supports colleagues.
Level 4
Mentor or expert
Advises clients, trains colleagues, contributes to interviews, develops methods and helps maintain the career path of the specialisation.
Capability pathways
Foundation, pathways and progression at a glance
Swipe or scroll to explore the diagram →
05 · Evidence and progression
A capability profile built from several evidence sources
The framework did not depend on a single manager's opinion or on self-assessment alone. Each person's profile combined several types of evidence and was reviewed through structured development conversations.
Self-assessment
Team members scored their knowledge against detailed capability statements using a ten-point scale.
Product knowledge
People recorded how deeply they understood each complex product and how independently they could work with or test it.
Allocation history
Historical assignments and the resource-planning system provided evidence of practical project and role experience.
Project feedback
Project managers, teammates and, where available, client stakeholders contributed feedback, especially on soft skills and working behaviour.
Training and certification
Relevant training and certifications formed part of progression. Some advancement levels included hard certification requirements.
Mentor review
The relevant specialisation mentor joined quarterly development conversations and could challenge, clarify or request evidence for unsupported scores.
Output
Capability profile
The profile informed career-path direction, next development steps, suitable training and certification, project allocation, mentor selection, salary and level calibration, hiring decisions, capability-gap analysis and client-facing aggregated capability evidence.
Scale note
- 01
Each specialisation contained approximately 40 to 80 capability indicators.
Evidence model
How evidence flowed into decisions
Swipe or scroll to explore the diagram →
06 · Resource and service planning
Capability data supported live management decisions
The value of the system came from applying it to real decisions. Professional capability showed what someone could do. Product knowledge showed where that person could become useful quickly.
Cross-project movement
Staffing options could be presented through structured comparisons of product knowledge, professional skills, certifications and relevant experience.
People-aware allocation
Assignments considered project demand, but also motivation, development goals, boredom, team fit and whether a person's skills were being used well.
Capacity planning
An approximate 10% bench threshold provided flexibility for sudden demand, internal training and service development while keeping unused capacity within a manageable range.
Evidence-supported staffing proposals
Historical tester-to-developer ratios, release scope and testing progress supported negotiations when a project had underestimated its quality and testing needs.
Experience before client demand
Internal pilot projects allowed people to gain practical experience with emerging tools and methods before a paying client requested them.
Service development
An internally prepared automation demonstration led a client project to request automation support.
Presenting staffing options to clients
When proposing a person for a new assignment or suggesting an exchange, I used clearly formatted comparison tables. These showed relevant professional capability, product knowledge, certifications and experience.
The proposal emphasised what the incoming person could contribute. For example, someone might already understand the product from an earlier assignment while also bringing automation capability that the project wanted to develop.
This helped move the discussion from attachment to a named individual towards the combination of capability the project needed next.
Illustrative example using synthetic data
| Candidate | Product knowledge | Automation capability | Relevant experience | Certification | Best-fit reason |
|---|---|---|---|---|---|
| Candidate A | High | Medium | Previous release on same product | Yes | Strong continuity option |
| Candidate B | Medium | High | Automation across two projects | Yes | Strongest fit for building automation |
| Candidate C | Low | High | Strong technical background | In progress | Longer onboarding requirement |
07 · Mature operating model
Central people leadership and distributed capability ownership
At its mature stage, the function included approximately 35 direct line reports and usually supported four to five concurrent projects. One large project commonly used more than 10 specialists. The remaining projects generally used smaller groups of around three to seven.
Specialisation mentors owned their professional area without being tied to a fixed management chain. A mentor could step into the role for a period, then step back to focus on delivery or deepen a different skill. This made the model flexible enough to accommodate changing projects, individual careers and the function's changing needs.
Because mentors were recognised as capability owners rather than operational project leaders, the team could distinguish between professional depth, management accountability and day-to-day project direction. This separation helped the function grow without forcing every senior specialist into a management track.
Specialisation mentors
- Manual and analytical testing
- Automation
- Technical testing
- Test leadership and management
Mentor responsibilities
- Maintain the specialisation pathway
- Identify relevant tools, methods and training
- Join quarterly development conversations
- Challenge unclear capability claims
- Support interviews
- Train and advise colleagues
- Track emerging professional practices
- Help prepare future services
The mentors generally welcomed the responsibility because it gave them time to shape their professional area and support others.
Recurring operating routines
Monthly
Team knowledge-sharing and product-demo sessions
Quarterly
Development conversations with mentor input
When changing projects
Capability and product-knowledge updates
Annually
Full capability review, development goals, budget planning and promotion planning
Continuously
Resource allocation, client negotiation, hiring decisions, capability-gap management and service development
The annual development conversation recorded the person's intended direction, planned learning and development goals for the following year. Quarterly conversations checked whether progress had started and whether the direction still matched the person's motivation. At year end, planned development items were reviewed using percentage completion.
Operating model
Three layers, one matrix
Swipe or scroll to explore the diagram →
08 · Technology and implementation stack
The systems behind the capability function
Sources and evidence
Self-assessment
ten-point capability scoring against detailed criteria
Product-knowledge profiles
depth of experience across complex software products
Allocation history
practical project and role experience
Manager, team and client feedback
behavioural and soft-skill evidence
Capability and progression model
Four specialisation pathways
manual and analytical, automation, technical, leadership
Five progression states
entry through mentor or expert
Certification requirements
hard gates at selected advancement levels
Documented management overrides
a reason recorded when judgement differed from the model
Decision support and planning
Spreadsheet-based capability model
individual and team-level calculated views
Product-knowledge model
depth of familiarity across complex products
Resource-planning spreadsheet
initial project demand and named allocation model
Power Apps planning application
later resource and allocation management
Operating routines and governance
Team knowledge-sharing and product-demo sessions
monthly knowledge and technology sharing
Quarterly development reviews
goals, motivation and mentor validation
Annual capability updates
career-path and training progress
Budget and promotion cycles
regular planning integrated with the capability model
Individual view
Calculated views helped each person understand:
- their strongest areas
- their likely specialisation fit
- development gaps
- recommended next steps
- progress along the career path
Management view
The management view supported questions such as:
- who had the strongest capability in a given area
- where product knowledge was concentrated
- who was furthest from the expected compensation or level
- where certification coverage was weak
- which people could support a new project or service
- how much experience the function could demonstrate to a client
Aggregated charts were also used in client presentations to show average years of experience, certification coverage, depth of professional capability and available specialist knowledge.
09 · Results
A function that could grow beyond its project silos
The function grew from eight people to approximately 35, primarily through expanding demand from a long-standing major client. Growth was supported by a more flexible knowledge model, clearer capability evidence, distributed professional ownership and stronger staffing and service proposals.
Growth from 8 to 35
The function grew from eight project-separated professionals to approximately 35 people supporting a portfolio of four to five concurrent projects.
Evidence · Direct management historyGreater cross-project flexibility
Knowledge-sharing routines, product profiles and documented project practices made it more practical to move people between assignments and explain staffing options to clients.
Evidence · Implemented operating modelClearer progression and compensation decisions
A common capability model gradually gave promotion and salary discussions a shared evidence base. Career pathways became clearer as inherited inconsistencies were reduced.
Evidence · Management and team adoptionDistributed professional ownership
Four specialisation mentors took responsibility for training, methods, interviewing and development reviews, reducing dependence on the function lead for professional capability building.
Evidence · Implemented role structureInternal capability became client-requested work
An automation capability developed through internal preparation and demonstration was subsequently requested by the client.
Evidence · Client-requested serviceThe model travelled beyond the original function
The development function later introduced its own related capability application and consulted me about the structure and operation of the earlier model. A former client stakeholder also requested me specifically to help establish a quality and testing function at another medical organisation, creating a new client engagement for my employer.
Evidence · Internal reuse and external advisory requestOperational confidence in the model
As the function matured, I received increasing decision authority over budget planning, hiring, promotions and allocation. My budget and promotion proposals were generally accepted. The client-side testing manager also contacted me directly when new people, staffing changes or clarification of individual capability were required.
When the client later prepared a broader training plan across its testing organisation and vendors, its testing manager was positively surprised that the supplier function already maintained a structured capability and development plan.
External engagement
A former stakeholder from the major client later moved to a medical company and specifically requested me through my employer. The organisation was preparing for European market access and needed to strengthen an inherited team whose members had strong clinical domain knowledge but limited formal software-testing experience.
I established the direction, assessed the situation, recommended roles, advised on tools and processes and proposed adding a mentor to support the team's professional development. A fuller account of that engagement may be published as a separate case study in future.
10 · Lessons learned
What I would carry into the next build
Shared identity comes before shared measurement
People contributed to a common capability model because they already felt like one professional group. A model imposed on strangers rarely lands.
Knowledge recording outlasts knowledge sharing
Sessions reduced immediate silos, but written project knowledge kept newcomers useful long after the original presenter had moved on.
Evidence-based progression needs several sources
Self-assessment, allocation history, feedback, certifications and mentor review together produced a picture no single view could match.
Judgement should be documented, not removed
The most useful control was recording why a decision differed from the model, not automating the decision away.
Transparency has to be phased
Publishing the full calibration model before inherited inconsistencies were reduced would have presented the past as the intended target state.
Distributed ownership scales the function
Mentors carried the professional pathway so the function lead could stay focused on portfolio, hiring and client conversations.
The Neurocroft method
The same six moves we apply to any organisational friction
Notice
A capable group could not yet act as a shared capability across projects.
Understand
Mapped how knowledge, terminology, progression and staffing actually worked, project by project.
Simplify
Reduced progression to four pathways and five clear states resting on a shared foundation.
Connect
Linked evidence sources, mentors, planning and client-facing proposals into one operating model.
Amplify
Distributed professional ownership through specialisation mentors and structured routines.
Evolve
The function grew from 8 to ~35 and the model was reused inside and beyond the original organisation.
Related services
Where this pattern fits in how we help
Primary service
Workflow & Decision Redesign
Redesigning how work, decisions and ownership move across a growing organisation so capability stops being trapped in individual projects.
Read the serviceRelated
Data & Decision Intelligence
Turning capability, allocation and delivery evidence into shared views leaders can actually run the business on.
Read the serviceRelated
Continuous Intelligence Partnership
An ongoing senior partner as the operating model, capability and portfolio keep growing.
Read the serviceTalk it throughA capable group that doesn't yet act as a shared capability?
Start with a short fit call. 20 to 30 minutes. You describe how work, knowledge and progression currently flow across your teams; we tell you honestly where a shared operating model would earn its place.
Get in touch