Lead the Work

1. 1Define the objective in terms of the work itself, not the workforce: name the tangible deliverable and the performance dimension that matters most (innovation, speed to market, quality, or cost). A leader's job is to achieve a mission through the work of others, so start from the work.
2. 2Deconstruct the assignment into components sized to their true performance requirement. Separate routine tasks that any capable worker can do from scarce, high-skill work — as with checking blueprints: split the routine check for clerks from the advanced analysis only engineers can do.
3. 3Route each component to the labor pool that best serves the target dimension. If innovation or creativity drives performance, shop the free-agent 'creatives' pool via talent platforms (Upwork, Tongal, Topcoder, MTurk); if cost drives it, engage the workforce that is likely cheaper.
4. 4Test effectiveness before scaling: segment a slice of work onto a platform, measure output quality, speed, and cost against your baseline, then move up the maturity curve as you learn the nuances.
5. 5Set the reward dials to the value curve. Where the value of higher performance is much greater than moderate performance, individualize toward top performers; where traditional individualization is optimum, hold there.
6. 6Build organizational form to support the routing: decide how permeable, interlinked, collaborative, and flexible (PICF) the organization must be to absorb external talent without losing coordination.
7. 7Re-measure organizational performance across all four dimensions after each reconfiguration — deconstruction that boosts speed or cost must not silently degrade quality of output.

Colgate-Palmolive produced ads for the Super Bowl through crowdsourcing rather than an in-house or single-agency team. The objective is a creative deliverable where innovation and quality of output drive performance, so the 'creatives' free-agent pool is the right place to shop. The work is deconstructed into a tangible deliverable — a finished ad concept — and dispersed to a global network rather than held inside employment. Compare this to IBM's Open Talent Marketplace, which optimizes work inside a single unit through an established internal infrastructure. Both raise organizational performance, but on different dimensions: crowdsourcing widens the creative input pool and can raise speed and innovation, while IBM's marketplace tightens deployment efficiency of existing talent. The choice turns on which performance dimension the specific work most needs, not on which model is fashionable.

• If creativity is critical to future business performance, then shop the free-agent 'creatives' labor pool rather than restricting the work to employees.
• If a large volume of work contains both routine and expert components, then deconstruct it so an army of cheaper workers clears the bulk and scarce specialists handle only what needs them.
• If the value of higher performance is much greater than moderate performance, then individualize rewards toward top performers; if not, keep traditional individualization.
• If the work could be done well remotely, then break it into manageable chunks first, because dispersion in time and space depends on prior deconstruction.
• If you are unsure a platform will deliver, then segment a small piece and test effectiveness before pushing many types of work onto it.

• Focusing on the Worker or the Client instead of the Work — the tell is that you collect bright-shiny examples (the coder in Bali, crowdsourced gamers) but can't see the pattern that connects them.
• Structuring by static jobs rather than deconstructable assignments — the tell is the organization cannot take change in stride and every shift requires reorganization (Lawler and Worley's warning).
• Deconstructing to cut cost while silently degrading quality of output — the tell is speed and cost metrics improve but rework, defects, or client complaints rise.
• Individualizing rewards for everyone when the value curve doesn't justify it — the tell is you're paying top-performer economics for moderate performance (Figure 9.2's non-optimal case).
• Adopting platforms without a learning-curve investment — the tell is a failed pilot on a harder platform (Topcoder needs real effort, MTurk needs programming) that you blame on the model rather than on skipping the ramp-up.

• ▸Tangible deliverable: name the concrete output, not the role.
• ▸Primary performance dimension: innovation / speed / quality / cost — pick the one that matters most.
• ▸Deconstruction split: list routine components vs. scarce-skill components.
• ▸Target labor pool: employees / talent platform (name it) / alliance — matched to the dimension above.
• ▸Dispersion plan: which chunks go remote or global, and the sizing that makes that possible.
• ▸Reward setting: standard individualization or top-performer individualization, justified by the value curve.
• ▸PICF supports needed: how permeable/interlinked/collaborative/flexible the org must be to absorb this.
• ▸Test slice: the small segment you pilot first and the baseline it's measured against.
• ▸Performance re-check: quality, speed, and cost readings taken after reconfiguration.

1. 1Identify the work that is pivotal to your strategic success, not just important. Ask: if this work is done superlatively rather than adequately, does it change whether you can compete at all? Software coding was pivotal for Ion Torrent; kid-focused marketing was pivotal for Siemens' children's hearing aid.
2. 2For each pivotal piece of work, reframe the sourcing question from 'which of our full-time employees can do this?' to 'who in the world really gets this?' Siemens asked the second question and the answer was Disney, not any internal hire.
3. 3Choose the model for getting the work done from the full menu: regular full-time employees, free agents via a platform (Topcoder), contractors (the European energy company), alliances (Siemens-Disney), or talent loans (Khazanah Nasional).
4. 4Run the total-cost-and-risk comparison. Contingent arrangements can be cheaper on total cost of employment (wages, benefits) and let the workforce shrink and grow; platform competition (Topcoder) means you pay only for the best end product.
5. 5Build the governance structure before you move the work outside your boundary. Agree the rules that make advantages outweigh costs — like the Premier League rule that loaned players cannot play against their loaning club.
6. 6Decide how far to permeate the organizational boundary, how strongly to interlink, how deeply to collaborate, and how extensively to flex — treat the boundary as permeable, not an impermeable barrier.
7. 7Assign a leader to lead through the work rather than manage the headcount: manage outcomes, quality, speed, and cost across employed and non-employed workers alike.
8. 8Reassess continuously, because the answer 'depends on your situation' — the same work may warrant employees in one context and free agents in another.

Siemens makes hearing aids, and among the end users are kids — a market its history, strategy, and culture had never faced. Instead of asking which full-time employee could market to children, its leaders reframed the question to 'who in the world really gets kids?' The answer was Disney. Rather than hiring and building the capability internally — which would be slow, would struggle to attract the best (Siemens is not an employer of choice for that talent), and would leave misfit employees once the project ended — Siemens formed an alliance where Disney employees were assigned to the project. Disney packaged the product with a Mickey Mouse toy and a comic book, treating the hearing aid like a toy, not a medical device. Siemens got Disney's world-class employees, reward structure, and culture faster, at higher quality, and lower cost. That is strategic advantage built from a superior model for getting the work done, not from owning the workers.

• If the work is pivotal to whether you can compete at all, then decide the sourcing model deliberately — do not default to full-time employment or delegate it to procurement.
• If the capability sits far outside your company's history and culture and you need it fast and world-class, then use an alliance (Siemens-Disney) rather than hiring permanent staff you can't attract or later reabsorb.
• If the deliverable can be judged purely on the best end product and you want competition to drive quality and price, then route it to a talent platform like Topcoder where you pay only for the winning output.
• If demand for a capability is variable or you need to add and shed skills cheaply, then use contractors so the workforce can shrink and grow with fewer hiring-and-firing costs.
• If you move work outside your boundary, then only proceed once a governance structure and agreed rules exist that make the advantages outweigh the costs for each party.

• Treating new work arrangements as mere cost-reduction extensions (outsourcing, temps, consultants). The tell: you delegate the decision to specialists in procurement or personnel instead of leading it strategically.
• Dismissing the shift as background noise while running 'business as usual' with only full-time employees. The tell: you're the taxi service ignoring Uber until it reshapes your industry.
• Reaching for permanent hiring to close a capability gap outside your comfort zone. The tell: long time-to-hire, the best candidates won't consider you an employer of choice, and new hires don't fit your core business after the project.
• Moving work across the boundary without governance. The tell: ambiguity over benefit plans, commitment, or whether loaned/contract talent competes against you — problems that surface only after the arrangement is live.
• Assuming one model wins universally — that free agents are inherently more efficient than employees, or vice versa. The tell: you seek a fixed rule instead of asking what the specific situation demands.

• ▸Work to be done: name the specific task or deliverable in one line
• ▸Pivotalness test: does superlative vs. adequate performance change whether you can compete? (yes/no + why)
• ▸Capability fit: is this inside your history, strategy, and culture, or outside your comfort zone?
• ▸Reframed sourcing question: 'who in the world really gets this?' — list candidate sources
• ▸Model choice: employee / platform / contractor / alliance / loan — and the reason
• ▸Total cost & risk note: cost of employment vs. alternative, and how demand varies
• ▸Governance rules: the agreed terms that make advantages outweigh costs for each party
• ▸Leader accountable: who leads through this work and on what outcomes (speed, quality, cost)
• ▸Review trigger: what change in situation would force you to re-decide the model

1. 1State the assignment as a problem to be solved, not a job to be filled. Reframe Siemens' question 'Which of our employees can take on this?' into 'Who in the world really gets this?' — the reframing exposes deconstruction and detachment options.
2. 2Set the deconstruction dial: break the assignment into the smallest components that can be independently pitched, judged, and delivered. Tongal shrinks the idea stage to a 140-character submission so hundreds of entries can be reviewed in the time it took to meet a few candidates.
3. 3Set the dispersion dial: decide how independent the work is of a fixed time and place. Min staffs a project with an American free agent for voice-over and a technical specialist in Egypt or the UK, using the global marketplace rather than on-staff talent.
4. 4Set the detachment dial: decide how far the work sits from a traditional employment relationship — regular employee, loaned employee via alliance, freelancer, contractor, or volunteer. Ask whether building 'a permanent structure based on employment' is warranted at all.
5. 5Test the employment default against the brick-house cost: if the capability is needed once, quickly, and won't fit the core business afterward, employment is expensive, slow to build, and hard to change — pick the pre-fab option.
6. 6Choose the platform/mechanism that matches the settings you dialed (Upwork, Tongal, Topcoder, MTurk, an alliance, or a crowdsourcing game) and confirm it delivers the top candidates the assignment requires.
7. 7Handle the operational residue the configuration creates — for loaned or dispersed talent, resolve whose benefit plan they sit on and any conflict-of-interest questions before the work starts.

Siemens makes hearing aids, including for kids, but needed to make the product feel cool to children and their classmates — a marketing challenge outside its history, strategy, and culture. Instead of asking which regular full-time employee could do it, leaders asked 'Who in the world really gets kids?' and the answer was Disney. They deconstructed the work into a discrete marketing assignment, dispersed it outside their own walls, and detached it from employment by using an alliance rather than hiring. Disney employees were assigned to the project and reframed the hearing aid as a toy — packaging it in a colorful case with a Mickey Mouse stuffed toy and a comic book telling an inspiring story about kids with hearing aids. Had Siemens hired employees to do this, hiring would have been slow, the best talent wouldn't have seen Siemens as an employer of choice, and those hires wouldn't have fit the core business once the project ended. The alliance captured a valuable application of Siemens' core capability without building a permanent structure to do it.

• If the capability is core, ongoing, and stable, then keep the work inside regular full-time employment (the brick house wins in stable environments).
• If the need is one-off, urgent, and will not fit your core business afterward, then detach from employment via alliance, contract, or crowdsourcing.
• If the best talent lives outside your walls or geography, then disperse widely and staff from the global free-agent marketplace rather than the talent you happen to have on staff.
• If the task can be judged from a small, cheap submission, then deconstruct hard so many candidates can be screened fast — and require heavy production only after the contract is awarded.
• If the work is a creative or research riddle people would do for passion, then consider volunteers or a crowdsourcing game (Foldit solved protein folding with no employees and no payment).

• Defaulting to 'which of our employees can do this?' — the tell is a candidate list full of remarkable workers, none with the actual expertise the assignment needs.
• Building a permanent employment structure for temporary work — the tell is new hires who don't fit the core business once the project ends and long hiring lead times.
• Under-deconstructing the pitch so candidates must do heavy work to be considered — the tell is few applicants and slow, costly screening that mirrors traditional selection.
• Treating beyond-employment arrangements as mere cost-cutting like old outsourcing — the tell is delegating the decision to procurement or personnel instead of the leader, and being blindsided like taxis were by Uber.
• Ignoring the operational residue of loaned or dispersed talent — the tell is unresolved questions about whose benefit plan a loaned employee is on or whether a loaned player competes against their original team.

• ▸Assignment reframed as a problem: rewrite 'which employee can do this' into 'who really gets this'
• ▸Deconstruction setting: smallest independently judgeable component (e.g., 140-char pitch, coding task, project)
• ▸Dispersion setting: what must be co-located vs. done anywhere/anytime, and by which global talent
• ▸Detachment setting: employee / loaned via alliance / freelancer / contractor / volunteer
• ▸Employment stress test: is this need one-off, urgent, and non-core? (yes = pre-fab, no = brick house)
• ▸Mechanism/platform match: Upwork, Tongal, Topcoder, MTurk, alliance, or crowdsourcing game
• ▸Pitch/selection design: how candidates apply and when heavy work is triggered (after award)
• ▸Operational residue: benefits, conflicts of interest, and post-project fit resolved before start

1. 1Start by defining your organization's current boundary honestly: list which work is done by regular full-time employees inside the boundary versus which flows across it (outsourcing, alliances, talent platforms). This baseline is the 'brick house' you are diagnosing.
2. 2Rate each dimension of PICF for the work in question. Permeate: how easily can talent and work cross your boundary? Interlink: how strongly are you connected to external entities (suppliers, partners, customers)? Collaborate: how deeply do relationships go — from arm's-length transaction to shared IP and shared employees? Flex: how readily can the structure reshape itself?
3. 3For each dimension, set it as a dial, not a switch. Ask how easily to permeate, how strongly to interlink, how deeply to collaborate, how extensively to flex — matching the setting to environmental stability. Stable environment favors the brick house (low settings); constantly changing environment favors the pre-fab structure (higher settings).
4. 4Test the depth of collaboration explicitly: decide whether a relationship shares only deliverables, or also shares intellectual property and people. Deeper collaboration (shared IP, shared employees) creates 'fuzzier' relationships — treat that fuzziness as both a challenge and an opportunity, not a defect to eliminate.
5. 5Design for reshaping over time, not a fixed end state. Plan the exit and absorption logic up front: an alliance may later be fully absorbed inside the boundary, or an outsourced function pulled back — build these transitions into governance so shape change is a planned move, not a failure.
6. 6Install the compensating controls that openness requires: a strong sense of purpose and shared beliefs to guide decisions when rigid controls loosen, tools that support collaboration at scale, and a reliable way to validate skills of people crossing the boundary.
7. 7Avoid over-relying on a single tactic. Match the mechanism (outsourcing, alliance, platform, in-house) to the situation rather than defaulting to the one you know best.

AstraZeneca's diabetes strategy shows all four PICF dials in motion. In 2007 it extended its organizational boundary to overlap with Bristol-Myers Squibb in diabetes research — a highly permeable, deeply collaborative arrangement that shared not just employees but intellectual property, producing a deliberately 'fuzzy' set of relationships. That fuzziness was the point: it let AstraZeneca move pieces available anywhere in the world rather than only pieces inside its own walls. When Bristol-Myers Squibb engulfed Amylin in 2012 and then began moving in a different direction, the shape no longer fit, so in 2014 AstraZeneca fully absorbed the alliance into its main corporate body, bringing formerly outside employees inside. Buying the alliance did not make the alliance a mistake; it was the flexibility dial being reset as conditions changed. Had AstraZeneca thought only in fixed structures and rigid boundaries, it would never have reached its current strength in diabetes treatment.

• If the environment is stable and the work is repeatable, then keep the dials low and build the 'brick house' of regular full-time employment — its stability and permanence are an advantage there.
• If the environment is constantly changing and you frequently need a bigger, smaller, or relocated capability, then raise Permeate and Flex — favor the fast, inexpensive, reconfigurable 'pre-fab' structure.
• If a relationship needs to share intellectual property or people (not just deliverables), then set Collaborate deep and accept fuzzier boundaries — but pair it with shared purpose and beliefs to guide decisions.
• If a partner starts moving in a different strategic direction, then reset the Flex dial: absorb, dissolve, or reshape the boundary rather than defending the existing structure.
• If you find yourself defaulting to one tactic for every situation, then stop and re-diagnose — leaning too heavily on one tool instead of matching solution to situation is the common failure.

• Treating boundaries as fixed. Tell: you evaluate options only by moving pieces already inside the organization and never consider talent available elsewhere in the world.
• Over-relying on one tactic. Tell: every problem gets the same answer (always outsource, always hire, always ally) regardless of situation.
• Opening up without compensating controls. Tell: rigid controls loosen but there is no strong sense of purpose, no way to validate skills, and no collaboration tooling — so risk rises with no guardrails.
• Reading a later reversal as proof of failure. Tell: when an alliance is bought or unwound, you conclude the original move was a mistake instead of recognizing planned reshaping.
• Forcing deep collaboration to be clean. Tell: you try to eliminate the fuzziness of shared IP and shared people instead of managing it as an opportunity.

• ▸Work/capability in scope: name the specific work being organized.
• ▸Environmental stability (stable / changing): drives whether to favor brick house or pre-fab.
• ▸Permeate setting (low-high): how easily talent and work cross the boundary today and target.
• ▸Interlink setting (low-high): strength of connection to suppliers, partners, customers.
• ▸Collaborate depth (deliverables only / shared IP / shared people): nature of the relationship.
• ▸Flex plan: the planned trigger and mechanism for reshaping (absorb, dissolve, extend).
• ▸Compensating controls: purpose/shared beliefs, skill-validation method, collaboration tooling in place.
• ▸Default-tactic check: the one tactic you overuse and why this situation may need a different one.

1. 1Set the time frame first. Decide how short the reward cycle is: tie pay to the deliverable when the work is discrete and detached (a Topcoder challenge, an Upwork project), and lengthen the exchange when you need commitment, development, and knowledge that only accrues over longer relationships.
2. 2Choose your individualization level deliberately rather than defaulting to top-performer bonuses. Map the value-of-performance curve for the role: if higher performance is worth far more than moderate performance (Figure 9.3), concentrate rewards on the few who deliver it; if the curve is flat, spread rewards more evenly.
3. 3Test whether steep individualization actually pays. Traditional individualization is optimum in some roles (Figure 9.1) but individualizing for top performers is not always optimal (Figure 9.2)—model the cost of the differentiated reward against the incremental value it produces before committing.
4. 4Add imaginative, non-monetary elements to the deal: reputation, purpose, autonomy, and development experience. For work you can crowdsource or gamify, design the reward around status and problem interest rather than cash.
5. 5Align the reward form to how far the work is detached from employment. Detached, project-based workers respond to short-term, deliverable-linked, reputation-driven rewards; embedded employees can carry longer, more purpose- and development-weighted deals.
6. 6For loaned or swapped talent, make development experience an explicit reward and codify governance rules so both sides know how value returns to them.
7. 7Run the reward as one of the 'few critical levers': set the three dials—time frame, individualization, imagination—explicitly for each work arrangement rather than applying one company-wide compensation policy.

Foldit shows the short-term, imaginative reward at its extreme: a game engaged volunteers to solve a protein-folding research riddle, and it 'achieved better and quicker results, with no employees, and with no payment whatsoever.' The reward here is entirely non-monetary—the interest of a challenging problem, the status of solving it, and the purpose of contributing to science. The time frame is compressed to the discrete deliverable (the solved puzzle), and there is no individualized pay curve at all. A leader facing an R&D problem should weigh this against the traditional path of hiring scientists and building laboratories, asking whether a crowdsourcing game could engage 'the best and brightest workers…for free.' The lesson is that reward composition can be re-engineered around reputation and purpose when the work is deconstructed and detached, delivering speed and cost advantages a brick-house employment model cannot match.

• If the work is discrete, detached, and project-based, then tie the reward to the deliverable on a short time frame; if you need sustained commitment and knowledge accrual, then lengthen the exchange because longer exchanges have greater impact.
• If higher performance is worth much more than moderate performance, then concentrate rewards on top performers; if the value curve is flat, then differentiating heavily for top performers is not optimal—spread the reward.
• If the problem is a creative or research riddle solvable by a crowd, then design the reward around reputation, purpose, and problem-interest before assuming you must pay salaries at all.
• If you are loaning or swapping talent, then treat development experience as a core reward and pre-agree governance rules so the lending side reaps a return.
• If the worker is a free agent crafting a portfolio, then weight autonomy and reputation in the deal, since employment-style security is not what they are optimizing for.

• Applying one company-wide compensation policy across detached, dispersed, and deconstructed work—tell: the same salary-and-benefit structure is proposed for a full-time role and a one-off crowdsourced challenge.
• Over-individualizing for top performers by reflex—tell: a large top-performer bonus exists even though the value of higher performance barely exceeds moderate performance (the Figure 9.2 trap).
• Defaulting to monetary rewards when reputation, purpose, or autonomy would engage better and cheaper—tell: leaders solve R&D riddles by hiring scientists and building labs when a game could do it for free.
• Forcing short-term, deliverable-linked pay onto work that needs long-horizon commitment—tell: knowledge and development that only accrue over long exchanges keep leaking out because the deal ends at each deliverable.
• Loaning talent with no governance—tell: no agreed rules for how value returns, so the lending side fears losing its best people and the arrangement collapses (contrast the Premier League loan rules that make it work).

• ▸Work arrangement: name the specific piece of work and how detached it is from employment.
• ▸Time-frame dial: short (deliverable-linked) / long (relationship-linked)—state which and why.
• ▸Value-of-performance curve: is higher performance worth much more than moderate, or roughly flat?
• ▸Individualization dial: even spread / traditional individualization / top-performer concentration—justify against the curve.
• ▸Monetary component: what cash reward, tied to what milestone or deliverable.
• ▸Imaginative components: which of reputation, purpose, autonomy, development experience you are offering.
• ▸Crowd/game test: could this be solved by volunteers for status/interest instead of pay? Yes/No.
• ▸Governance rules: for loaned or shared talent, the pre-agreed terms for how value returns to each side.
• ▸Fit check: does this reward form match the degree of deconstruction, dispersion, and detachment of the work?

1. 1Deconstruct the work before you source it: break each job into its component tasks and ask which parts must sit inside a regular full-time role and which can be handled by a specialist. Follow Chris Clegg's shift from seeking one generalist (coder who also does design and SEO) to hiring a designer, a programmer, and an SEO specialist separately.
2. 2Decide how far to detach each task from employment along the three dials — how small to deconstruct, how widely to disperse, how far to detach — before you touch a platform. Detachment ranges from regular employees to internal temporary assignments to external free agents.
3. 3Map the source options across the full ecosystem: build (develop internally), buy (external hire), borrow (secondment/alliance), and share (platforms, free agents). For each deconstructed task, name the source that best balances quality, cost, speed, and availability.
4. 4Match internal supply to internal demand first where scale allows: use an internal marketplace to route excess capacity in one unit to peaks in another before reaching outside, as IBM does with Blue Talent Cloud (2–12 month assignments, no relocation).
5. 5For external platform work, pick the platform to the task type — Upwork for broad internet-deliverable freelance tasks, Tongal for video/creative content, Topcoder for coding challenges, MTurk for micro-tasks — rather than forcing all work through one channel.
6. 6Where you assemble teams of free agents, appoint a free-agent wrangler to pull the specialists together and manage them beyond the organization's walls.
7. 7Run the sourcing through a single database that stores open opportunities and registered worker profiles (IBM combines its Global Opportunity Marketplace with an IBMer registration site), so matching is systematic, not ad hoc.
8. 8Treat the blend as ongoing optimization: the line between platform work and regular employment is blurring, so re-evaluate the mix per assignment rather than defaulting to one model.

Deloitte saw an opportunity to expand its software sales in Belgium, but the best-suited talent for that work sat inside IBM. Because Deloitte is an IBM business partner, the IBMer Assignment Agency arranged a secondment rather than treating IBM's own headcount as off-limits. The IBMer went to work at Deloitte and built ways to use deeper business analytics to support Deloitte's sales push. This sourced the right talent for the client's specific work while, coincidentally, extending Deloitte's use of IBM software and services. The example shows sourcing optimized across organizational boundaries: talent was borrowed, not hired, and the arrangement created value for the worker, the client, and IBM at once. It also illustrates IBM's assumption that seconded people return — but if they stay, IBM has placed an ally who deepens the client relationship.

• If a task can be cleanly separated and requires deep specialist skill, then deconstruct it and source a specialist rather than hiring a generalist to cover the whole job.
• If one internal unit has excess capacity and another has a short-term peak in demand, then route the work through an internal marketplace before sourcing externally.
• If the work can be delivered over the internet and the budget is limited, then test an external platform (Upwork-type) before assuming a full-time hire is required.
• If you are looking for authentic innovators and creative agents, then source among free agents worldwide who prefer free agency to employment — that is where they concentrate.
• If you are assembling multiple free agents into one deliverable, then assign a free-agent wrangler to coordinate them instead of managing each contract yourself.

• Sourcing the job instead of the work: hiring one person to do everything (coding, design, SEO) when specialists per task give better results — the tell is a job posting listing an unlikely mix of unrelated skills.
• Dismissing platforms as mere cost-cutting: treating nonemployment arrangements as simple extensions of outsourcing and consultants — the tell is delegating the decision to procurement or personnel rather than leading it.
• Overlooking the trend entirely, repeating the taxi industry's mistake of ignoring Uber — the tell is leaders who marvel at the change but keep defaulting to regular full-time hiring.
• Assuming workers must be onsite: failing to break the co-location habit blocks access to dispersed and remote talent — the tell is refusing arrangements where the worker doesn't relocate.
• Building or buying only, and never borrowing or sharing: ignoring alliances, secondments, and platforms leaves the best-suited talent inaccessible — the tell is a talent map with only two columns instead of four.

• ▸Task (deconstructed): the single component of work, isolated from the larger job
• ▸Skill required: the specific specialist capability this task needs
• ▸Best source (build/buy/borrow/share): pick one across internal dev, external hire, secondment/alliance, platform/free agent
• ▸Detachment level: regular employee / internal temporary assignment / external free agent
• ▸Platform or channel: name the specific route (Upwork, Tongal, Topcoder, MTurk, internal marketplace)
• ▸Quality-cost-speed-availability note: one line on the tradeoff driving the choice
• ▸Coordination owner: who manages it — hiring manager, free-agent wrangler, or assignment agency
• ▸Return/retention assumption: whether the worker returns, stays, or is one-off, and the relationship value if they leave

1. 1Deconstruct each assignment into tangible deliverables before you staff it. Split work into routine chunks (e.g., a check any clerk can do) and specialist chunks (analysis only an engineer can do), so you can staff each piece with the cheapest capable talent and reserve scarce experts for what needs them.
2. 2For each deconstructed chunk, decide the sourcing channel: regular employee, internal temporary redeployment (like IBM's Blue Talent Cloud), or external freelance marketplace (like IBM's Open Talent Marketplace). Match demand to the pool with excess supply.
3. 3Set the pricing and cost model per channel. On a marketplace, structure work as fixed-price outcomes billed only on successful delivery, so talent cost aligns to output and does not accrue between development cycles.
4. 4Build or use a searchable talent database where a leader can query the skills needed across units, described in a common language, with a broker/agency to reconcile employee desires and unit needs.
5. 5Choose the marketplace mechanism per event: tournament (many submit, best wins) or single-source (players propose, PM selects one). Segregate events by player channel — some earmarked for internal employees, others for certified external freelancers.
6. 6Decide the organization boundary for the work: permeate, interlink, collaborate, or flex. Dial each up or down based on whether a clean chunk can move outside, whether one partner or an ecosystem is involved, and how tightly the relationship can be legally defined.
7. 7Assign redeployment (2–12 month temporary assignments) to cover peaks and valleys, matching excess demand in one unit with excess capacity in another without requiring relocation.
8. 8Re-evaluate boundary choices continuously — be 'built to change' rather than staffing static jobs, and revisit which functions sit inside, outside, or partially in and out.

Before its Open Talent Marketplace, IBM staffed projects with dedicated teams — employees assigned solely to one project across its full lifecycle. Because development workload fluctuates but the cost of a dedicated team stays constant regardless of output, every project absorbed idle time, attrition, and retraining costs. With OTM, IBM deconstructs certain project work into defined outcomes and posts them as events — tournament-based (best submission wins) or single-sourced (one player selected from proposals) — segregated by channel between internal employees and certified freelancers. Work is developed at a fixed price and billed only on successful delivery, so no cost accrues between development cycles. The PM doesn't need to know who across IBM has the skill; OTM surfaces the right talent on demand. IBM reports 'up to 50 percent lower cost of delivery for equivalent outcomes,' with project costs aligning directly to deliverable output.

• If a chunk of work is clean and separable, then dial up permeability and consider outsourcing or a marketplace event; if it is entangled and needs constant collaboration, keep it inside and dial up collaboration instead.
• If one unit has an urgent short-term skill gap and another has excess capacity plus an employee with that skill, then redeploy temporarily (Blue Talent Cloud) rather than hiring — the existing IBMer already knows the culture and has passed entry requirements.
• If workload fluctuates across a project lifecycle, then structure the variable portion as fixed-price outcomes billed on delivery, not as dedicated headcount.
• If someone claims a function is 'core' and must stay inside, then treat that as a hypothesis to test — design firms move design work to platforms; nearly any function has a counterexample.
• If you are advising an individual on agility, then steer them toward general skills (manager, analyst, technologist) that move laterally, and away from narrow investment, because no single place is safe.

• Staffing work as intact jobs on the presumption the organization is static — the tell is paying full cost for dedicated people while output fluctuates and idle time accrues.
• Skipping deconstruction and dispersing whole assignments — the tell is that you can't hand work to home-based or freelance pools because it was never broken into manageable chunks.
• Detaching work from employment to escape labor laws rather than to improve effectiveness — the tell is that workers end up worse off (e.g., zero-hour contracts) with no gain in competitive advantage.
• Treating the freelance/marketplace shift as a technology or HR project alone — the tell is a stalled transformation because the CEO and executive team were never fully aligned.
• Relocating or redeploying talent without a broker or common language — the tell is that units describe similar jobs differently, can't see each other's workers, and can't reconcile employee desires with unit needs.

• ▸Assignment name — the whole task before splitting
• ▸Deconstructed deliverables — list tangible chunks (routine vs. specialist)
• ▸Skill required per chunk — the specific capability each deliverable needs
• ▸Sourcing channel — regular employee / internal redeployment / external marketplace
• ▸Marketplace mechanism — tournament (best wins) or single-source (PM selects)
• ▸Pricing model — fixed-price-on-delivery / hourly / dedicated headcount
• ▸Boundary dials — permeate / interlink / collaborate / flex, each rated up or down
• ▸Duration — one-off event, or temporary assignment window (2–12 months)
• ▸Broker/database owner — who maintains talent visibility and common-language matching