Recruitment in IT: The Complete Guide From 250+ Hires a Year

I’ve spent 8 years in talent management, and the pattern I’ve seen repeat more than any other is this: organisations treat recruitment in IT like a faster version of what they do for every other function.

Post a JD.

Wait for applications.

Interview the shortlist.

That’s why most of them are still waiting.

IT recruitment isn’t a speed problem. It’s a methodology problem. The entire recruitment and selection funnel works differently when your target candidates are passive, technically specialised, and evaluating three competing offers simultaneously. Standard recruitment strategies don’t break here. They just never applied in the first place.

The cost of getting this wrong is not abstract. An unfilled senior IT role drains approximately $500 per day in operational productivity. At 60 days — a typical reactive cycle — that is $30,000 in lost output before a single hiring decision is made. McKinsey data shows only 16% of executives feel comfortable with their organisation’s technology talent pool. That gap is not a talent shortage problem. It is a process design problem.

Why most IT recruitment fails before sourcing begins

IT recruitment takes as long as it does because the problem is defined at the wrong stage. Most recruiters start diagnosing delays at the sourcing stage, but the problem is upstream. Broken requirement definition, technically imprecise JDs, and hiring managers who haven’t been properly calibrated are what create the backlog — before a single search has run.

Post a JD written by a hiring manager alone and you’re already sourcing against the wrong criteria. By the time you realise it, three weeks are gone.

The Broken Intake meeting

A JD written without recruiter input typically over-specifies some things (5 specific frameworks, 7+ years with a tool that has been commercially available for 4) and under-specifies what actually matters: what problem will this person solve in their first 90 days?

The result is a sourcing brief that eliminates your best candidates before they see the role, and attracts candidates who are good at writing CVs — not necessarily good at the job. And no recruitment assessment tools downstream can correct for a brief that was wrong at the source

A structured intake session should produce five things:

• The problem this person is hired to solve in their first 90 days
• Non-negotiable technical skills versus learnable ones, clearly separated
• The profile of the last strong hire in a similar role
• The hiring manager’s actual decision criteria (not what’s in the JD)
• A shared view on realistic market availability

This is where the Talent Market Pre-Alignment (TMPA) framework begins — before the JD is written, not after. TMPA maps the competitive talent landscape so the intake conversation is anchored in what the market can actually supply.

Calibrating the hiring manager before sourcing begins

Even structured intake fails if the recruiter walks in without data. A hiring manager who needs 5 specific technologies, fintech background, and 7 years of experience at a mid-market salary has described a candidate who exists — in their imagination.

Run a quick competitor talent map before the intake session. Who currently holds your target profile? Which companies are they at? What are they earning? What will they expect in return? Walk into the intake with data, not assumptions.

The Intelligence-Led Sourcing approach starts here: continuous market mapping before vacancies arise, so intake conversations are grounded in what the market can actually supply — not what the hiring manager wishes existed.

Real talk: The recruiter who brings competitive market data into an intake session is no longer a note-taker. They become the advisor. That shift changes every conversation that follows.

What IT professionals want in 2026 — not what you think

Competitor content on this topic reads like a benefits brochure: flexibility, competitive salary, career growth, strong culture. These are not wrong. They are just irrelevant to the conversation that actually converts a passive senior IT professional.

After running hundreds of technical hiring conversations — including sourcing niche engineering and IT roles — the same three motivators came up, over and over, from passive candidates. None of them appear in a typical job description.

The three motivators salary can’t buy

Autonomy. Senior engineers don’t want to inherit architectural decisions made by someone else three years ago. They want to make them. A role described as ‘implement this system’ loses to a role described as ‘design the architecture for this problem’ every time, at the same compensation level.

Problem complexity. The most persuadable passive candidates aren’t motivated by deliverables. They’re motivated by the nature of the problem. ‘Build and maintain the payments module’ closes far fewer conversations than ‘own the architectural challenge of processing 2 million daily transactions with sub-100ms latency.’ Same role. Different framing. Different candidate.

Scope of impact. In large tech companies, a senior engineer may own 0.01% of the product. At a mid-market company, they may own 40%. That difference changes the experience of work fundamentally — and it is a lever non-FAANG companies consistently fail to pull.

The JD restructure that follows from this is simple. Problem first. Ownership scope second. Requirements last. The candidate decides whether the challenge is worth engaging with before they read the requirements list.

I tested this framing directly in sourcing conversations for a manufacturing systems analyst role. The candidate who became our digital transformation lead wasn’t motivated by compensation. He was motivated by a problem complex enough to genuinely challenge him — and a company willing to let him solve it his way. He would never have applied to the traditional JD format.

The EVP differentiation problem for non-FAANG companies

Most IT recruitment guides assume you are competing with Google or Meta. You are not. And you should not try to. The attempt to match FAANG compensation packages at mid-market scale is a losing strategy.

There are four EVP levers non-FAANG companies can pull that FAANG cannot structurally offer: architectural ownership, domain complexity, visible individual impact, and speed of personal connection. The pitch isn’t ‘we can’t match Google.’ It’s ‘we offer what Google can’t.’

The hiring pitch for automation engineering roles was never compensation-first. It was problem-first, domain-first. Engineering problems in industrial IoT carry genuine technical depth. That is a real differentiator — but only if it is communicated as such in the role framing, not buried in bullet point 7 of a standard JD.

Build your IT talent pipeline before the role opens

The single biggest white space in IT recruitment is what happens between the previous hire and the next vacancy. Most teams do nothing. The vacancy opens, sourcing starts from zero, and the 45-day clock begins ticking.

The Talent Supply Chain model treats recruitment as a continuous, pre-vacancy mapping process. For IT roles, this isn’t aspirational — it’s operationally necessary.

Here’s how to build it:

The Intelligence-Led Sourcing system

Intelligence-Led Sourcing runs in four steps. First, identify the 8-12 companies your target IT candidates are currently employed at. These are your primary source companies — organisations with the technical environment that produces the profile you are hiring.

Second, map relevant teams within those companies using LinkedIn, GitHub, and professional community membership. Build a contact list with notes: what they are working on, how long they have been in their current role, any movement signals.

Third, track live signals. A GitHub contributor going quiet on a major project. A senior engineer presenting at an external conference — candidates who start making themselves publicly visible are often ready to hear from you. A company announcing a restructure or layoff round.

Fourth, when a vacancy opens, activate the pre-warmed list. Your first sourcing action is a personalised message to 8-12 people already identified and partially profiled — not a keyword search from scratch.

When we needed to scale the automation engineering team, I ran this process across 12 competitors in the industrial IoT space before a single JD was written. The result: 37 qualified candidates were pre-identified and partially profiled before the intake session. When the vacancy was confirmed, the first outreach went out the same day.

Time-to-Offer dropped from 68 days to 34 days. The process didn’t move faster. The pipeline was already warm when the vacancy arrived.

Signal-based passive candidate identification

The strongest IT candidates are not on job boards. They are visible through the work they have already done. Signal-based identification means looking beyond resumes to demonstrated capability.

For a backend engineer: GitHub commit history (frequency, language diversity, project complexity, contributions to open-source tools your stack uses).

For a data scientist: Kaggle competition performance, published papers, technical write-ups on Medium or Substack.

For a cloud architect: conference talk history on cloud-native infrastructure, contributions to Terraform or Kubernetes repositories.

Build a repeatable signal-scoring system for each role type. Different signals matter for a backend engineer versus a data scientist versus a cloud architect. Assign relative weights. Use the result to create a 15-20 person shortlist of high-signal candidates to approach.

When we needed a manufacturing systems analyst, traditional sourcing produced 14 qualified resumes. I switched to Inverted Sourcing Funnels — searching for ‘PLC programming projects’ and ‘lean manufacturing case studies’ rather than job title and years of experience. The result was 62 candidates. The best hire came from that pool: a former factory-floor supervisor who had taught himself Python, was documenting his automation work publicly, and would never have surfaced in any keyword search. He now leads the digital transformation function.

Signal-based sourcing doesn’t just expand the pool. It changes who’s in it.

| Anti-pattern: Confusing platform with strategy. ‘Use GitHub to find developers’ is not a sourcing method. The search logic — what signals you look for on a contributor profile, how you weight different indicators across role types, how you move from a signal-identified candidate to an outreach message — that is the strategy.

The Silver Medalist Re-Engagement Loop

Your second-best candidate from three months ago is often your best source for today’s vacancy. The Silver Medalist Re-Engagement Loop is a systematic process for re-engaging #2 and #3 candidates from recent hiring decisions at 3, 6, 9, and 12-month intervals.

For IT roles, this works for three reasons. Technology moves fast — a candidate who lacked one skill 6 months ago may have built it on a personal project since. Employment context changes — a candidate who wasn’t ready to move at 9 months may now be actively considering options. The pre-existing relationship removes all cold-outreach friction.

The system has three mechanics. First, tag all silver medalist candidates in your ATS with re-engagement trigger dates at each interval. Second, personalise the re-engagement — reference their specific project update, the conversation you had, what has changed in the role or team since. Third, track conversion rate from silver medalist re-engagement versus new sourcing.

In one of my company, 4 hires over two years came directly from silver medalist re-engagement. One became a team lead. Another referred 3 external hires after joining. The conversion rate from silver medalist outreach runs higher than cold sourcing — and the Time-to-Offer is a fraction.

| The honest downside: ATS tagging discipline is required from day one. If the tagging does not happen at the point of the original rejection, the system cannot trigger. This is an administrative commitment before it is a strategic one.

How to Source IT Talent using Inverted Sourcing Funnels

Traditional sourcing optimises for volume. The Inverted Sourcing Funnel optimises for signal quality. The difference in outcomes isn’t incremental. It’s structural.

A keyword search on LinkedIn for ‘Java developer, 5 years, financial services’ produces 200 CVs of highly variable quality. A capability-signal search produces 20 targeted candidates with demonstrated, verifiable expertise. Both approaches can produce the same number of final hires. The signal-based approach takes roughly half the time and produces a higher technical screen pass rate.

Start with capability signals, not keywords

The traditional approach filters for candidates who are good at writing CVs. The Inverted Sourcing Funnel starts with capability signals — what the candidate has actually built, written, deployed, or contributed to — and works backwards to contact information and fit assessment.

For a backend engineer: GitHub contributors to relevant frameworks, Stack Overflow reputation in the specific technology, technical blog authors writing about the same problems your codebase faces.

For a data scientist: Kaggle competition performance in relevant domains, published papers, open-source dataset contributions.

For a cloud architect: conference talk history, contributions to Terraform or Kubernetes repositories, certifications combined with visible practical application.

The data from the manufacturing systems analyst hire is instructive: traditional sourcing produced 14 qualified resumes. Signal-based sourcing produced 62 candidates — and the best hire was someone who would never have appeared in any keyword search. The 4.4x pool expansion wasn’t the most important outcome.

The quality of the #1 hire was.

Technical screen pass rates from signal-based sourcing run higher than keyword searches — because you are filtering for demonstrated ability before you send the first message, not after 30 CVs have been reviewed.

The 10/10 Rule for IT outreach

Most IT sourcing fails at the outreach stage. Not because the candidate is not open to moving — but because the message was generic. IT professionals receive 10+ recruiter messages per week. The ones that convert are the ones that demonstrate the recruiter actually looked at their work.

The 10/10 Rule: 10 minutes of research into the specific candidate, and a 10-line message that references something specific they have done.

The message structure:

• Specific reference to their work (one thing you noticed, named precisely — not ‘I saw your profile’)
• Connection to the problem this role solves (not the job description — the actual challenge)
• Why their background makes them the right person to consider for this specific challenge
• A question, not a request

Outreach that ends with a question converts better than outreach that ends with ‘would love to chat.’ ‘Given that you have been working on distributed systems at scale — I am curious how you would approach this problem at 10x volume. Is that a conversation worth having?’ That is a question that requires the candidate to think, not just respond.

| Anti-pattern: ‘Personalise your outreach’ as an instruction is meaningless without the method. The 10 minutes: read their most recent GitHub commits or blog post, note their tenure signals, assess their current company context. The 10 lines: open with what you noticed about their specific work. Close with a question about the problem, not a pitch about the role.

Where to Source IT Talent Beyond LinkedIn

LinkedIn Recruiter is still the most powerful professional sourcing platform for passive talent at mid-to-senior level. It is also expensive, increasingly competitive, and built for broad searches, not signal-based ones.

The non-obvious channels — and how to use them:

GitHub: Not job profiles, but contribution history. What are they building? What open-source tools do they contribute to? How recent and active? A contributor who has been quiet for 6 months on a major project is a different signal than one committing daily.

Stack Overflow: For backend engineers, DevOps, and security professionals. Reputation in a specific tag (kubernetes, postgresql, rust) is a direct capability signal, not a claimed one.

Kaggle: For data science and ML engineering. Leaderboard position and competition participation are demonstrated performance signals.

Technical conference speaker rosters: The most publicly visible practitioners in a domain. Search ‘[technology] conference speakers [year].’ These people are demonstrably expert and demonstrably interested in sharing knowledge.

Niche communities: Discord servers for specific technologies, Hacker News ‘Who wants to be hired?’ threads, domain-specific Slack communities.

Activated internal referrals: Not a passive ‘refer a friend’ programme. A deliberate programme where your top 5-10% of technical contributors are treated as talent scouts.

One senior engineer in the referral programme referred 11 people. 9 were hired. 8 are still with the company. The conversion rate: 82% versus the company-wide average of 31%. Estimated agency fee savings: approximately Rs. 40 lakhs from that single referral relationship alone.

Democratic referral programmes underperform. 5-10% of employees generate 60-70% of successful referrals. Activate the few, not the many. Give your top referrers talent scout status, recognition, and direct access to the Talent Acquisition team. The ROI on that investment is measurable within two hiring cycles.

| Anti-pattern: Listing channels without explaining the search logic. GitHub is not a strategy. What you look at when you open a contributor profile — commit frequency, project diversity, language distribution, contribution to tools your stack uses — that is the strategy.

How to structure IT screening and assessment

The most common assessment mistake in IT recruitment is applying the same process across every seniority level. HackerRank for everyone. Timed coding challenge regardless of role complexity. Then confusion when senior candidates withdraw without explanation.

The assessment design doesn’t just filter candidates. It tells candidates whether the organisation actually understands who it’s trying to hire.

Step 1: Design assessment by seniority tier, not role family

Junior (0-4 years): Coding assessments work. They are building proof-of-work, standardised tests are familiar, and the format is low-effort to score consistently. HackerRank and Codility are appropriate here — with calibrated benchmarks. Honest tool verdict: ‘Strong signal for core technical skills when used correctly; very damaging when overused or misaligned.’

Mid-level (4-7 years): Pair programming assessment — live, collaborative, 60-90 minutes, observed. This simulates the actual working environment more accurately than a solo timed challenge and provides meaningful signal without the candidate-alienation risk.

Senior and staff (7+ years): The technical conversation. A structured 45-60 minute session where the candidate walks through a past architectural or technical decision they made. You listen for reasoning depth, trade-off awareness, and communication clarity. A principal engineer with multiple offers will not spend 6 unpaid hours on a timed coding test. When they decline, that’s not arrogance. It’s a signal that the assessment is mismatched to the seniority level.

Step 2: Build a structured interview framework for all IT roles

Technical interviews without a structured framework produce wildly inconsistent results. Different interviewers evaluate completely different things. Comparison becomes impossible. Bias fills the gap.

A structured IT interview framework covers three things:

Technical depth questions: Role-specific, written with the hiring manager, evaluated against defined criteria. What does ‘strong’ versus ‘adequate’ look like for this specific question? Write it down before the interview, not during the debrief.

System thinking questions: ‘Walk me through a time you had to re-architect something under time pressure.’ The best IT professionals reason about trade-offs, not just solutions. This component assesses how the candidate thinks, not just what they know.

Collaboration and communication assessment: One question designed for this: ‘Describe a time you had to explain a technical constraint to a non-technical stakeholder who disagreed with your assessment.’ Translation ability is a multiplier skill in technical roles.

Interviewers score independently before calibrating. This prevents groupthink. The debrief is for comparing independent scores, not for the most senior voice in the room to anchor everyone else’s opinion.

| Anti-pattern: ‘Develop a consistent interview process’ is the instruction without the method. The three components, the pre-written scoring criteria, and the independent-scoring protocol — that is the process.

How to run IT Recruitment without a Technical Background

You don’t need to be a developer to recruit developers well. What you need is a minimum technical vocabulary — enough to ask the right questions, avoid the most common mismatch errors, and translate between the hiring manager’s technical spec and the candidate’s actual capability. Without it, you create avoidable upstream errors — sourcing the wrong profile, asking the wrong questions in screening, accepting a JD that was never fillable.

Here’s what you actually need

Seven concepts worth knowing:

Frontend vs. backend vs. full-stack. Frontend is the user-facing layer. Backend is the server, data, and logic layer. Full-stack means both. These describe completely different candidate profiles.

Cloud-native vs. hosted on cloud. These are not the same architectural approach and attract different candidate profiles. Conflating them produces wrong-fit sourcing from the first search.

Software engineer vs. data engineer. A software engineer builds applications and systems. A data engineer builds the pipelines and infrastructure that move and transform data. Sourcing one for the other produces wrong-fit candidates.

Legacy system. Any system built on outdated technology that is expensive to maintain and resistant to change. Candidates ask about this because it determines their day-to-day experience. ‘Lots of legacy’ is a retention risk signal.

Tech debt. The accumulated cost of past technical shortcuts. Candidates ask about it because high tech debt means slower development cycles, more maintenance work, and less opportunity to build new things.

Agile, kanban, scrum. These describe how teams organise and prioritise work. Candidates ask which framework the team uses because it affects the pace and structure of their daily environment.

How to read a GitHub profile at surface level. Commit frequency (how active is the contributor?), project diversity (are they building different things or maintaining one?), and language distribution (which technologies do they actually use day-to-day?).

None of this requires writing a single line of code. All of it prevents common sourcing and screening errors.

Using AI as a Recruiter’s Technical co-pilot

AI tools can cover some of the technical knowledge gap for non-technical recruiters. Here are five ways that actually work.

‘Explain this JD to me in plain English’ — paste a technical JD, ask the AI to translate it into what the role is actually asking for.

‘What questions would a strong backend engineer ask about this role?’ — AI generates the questions a technically-informed candidate would have, helping the recruiter prepare for and address them in outreach.

‘What is the difference between these two candidate profiles for this role?’ — AI can summarise technical differences when the recruiter cannot evaluate code quality independently.

‘Is this combination of skills commonly co-occurring?’ — knowing that a JD asking for both Kubernetes expertise and COBOL development is an unrealistic combination prevents sourcing against an impossible brief.

‘What does [technology] do, and why would someone with this background know it?’ — rapid technical context-building before a screening call.

The hard limit: never use AI to evaluate candidates or make screening decisions. That requires human judgment, contextual understanding, and accountability. Verdict on ChatGPT and Copilot for recruitment: ‘A genuine productivity multiplier — not a recruiter. Best used to augment thinking, not replace judgment.’

| The catch: AI tools used in hiring decisions are subject to emerging bias regulation in several jurisdictions, including the EU AI Act and New York City’s Local Law 144. Any AI-assisted screening workflow should be reviewed against applicable requirements before deployment.

The IT Recruitment Metrics that Actually Tell you what’s working

Generic TA metrics — time-to-fill and cost-per-hire — tell you very little about IT hiring. They don’t show where in the process delays are occurring, which sourcing channels are producing your highest-quality candidates, or whether your assessments are calibrated correctly for the seniority level you are targeting.

Here’s what to track instead.

Technical interview-to-offer ratio

For every 10 candidates who pass the technical assessment, how many progress to the offer stage? Below 40% signals either mis-calibrated assessment criteria or the wrong sourcing channel. The question to ask: are we screening the wrong candidates in, or screening the right candidates out? The answer comes from the data, not the debrief.

Source-to-technical-screen yield rate

For each sourcing channel — LinkedIn outreach, GitHub signal-based identification, referrals, ATS re-engagement — what percentage of candidates make it through to technical screen? This identifies where your highest-quality candidates actually come from, not where you spend the most time.

The data from the sourcing comparison: Inverted Sourcing Funnels produced 62 candidates versus 14 from traditional keyword sourcing — a 4.4x difference in raw yield. Referral power-users produced an 82% conversion rate versus the 31% company-wide average. Channel-level yield tracking makes this visible and actionable. Without it, you’re optimising effort, not output.

Time-to-Offer for IT roles (tracked separately)

IT roles typically run 30-45% longer than non-IT roles. Tracking separately from the overall TA metric sets accurate expectations with hiring managers and isolates where IT-specific process delays are occurring. Is the delay in sourcing, in assessment scheduling, or at the offer stage? Each has a different fix.

Candidate withdrawal rate by stage

Which stage are IT candidates leaving the process at? Pre-technical screen (process feels slow or opaque), post-technical assessment (offer-stage delays or compensation misalignment), or post-offer (competitive counter-offer or process-experience damage)? Each exit stage has a different root cause. Grouping all withdrawals into one metric obscures the diagnosis.

| Real talk: If Quality of Hire criteria are not defined at intake, measuring it at 12 months is a backward exercise. You cannot trace a quality problem to its source if you did not define quality before the hire was made.

Quality of Hire as the north star metric

Every IT recruitment metric should point back to one thing: Quality of Hire at 12 months. For IT roles, define it at intake against three criteria: technical capability verification (was the assessment predictive?), contribution velocity (how quickly did they work independently?), and retention signal (are they still engaged and growing a year in?)

Upstream process improvements — smarter sourcing, better intake design, tiered assessments — should show measurable Quality of Hire improvement within 2-3 hiring cycles if they are working. The benchmarks from implementing a skill-based talent pipeline combined with market analysis: Quality of Hire improved 30%. 12-month cohort retention rate: 89%. Offer acceptance rate: 90%. Those are the targets. Track backwards from them.

Internal mobility as your fastest IT talent source

Before any IT vacancy goes external, there is a 48-hour window that most recruiting functions waste completely.

The First Look Policy: when a technical role opens, it is posted internally to all employees for 48 hours before any external sourcing begins. This is not a passive job board announcement — the recruiter proactively reaches out to 3-5 internal candidates who match the Role Fit Profile.

Three types of hidden internal candidates surface through this process.

• IT talent who have grown laterally and want to move into a new technical domain.
• Employees with self-taught technical skills not captured in HR records — the operations analyst who codes on weekends, the kind of person Inverted Sourcing would find externally.
• And cross-functional employees with adjacent technical capability who want to formalise their transition.

In one of my company, the First Look Policy produced a 23% internal hire rate across all managed hires. Time-to-Productivity for internal hires: 28 days. For external hires: 67 days. That is a 58% reduction in ramp time. For IT roles, where codebase onboarding and team integration slow things down, the difference compounds.

The context: a global manufacturing organisation needed a senior systems analyst for a digital transformation project. Under the standard external-first process, the vacancy would have gone to market immediately. Instead, the First Look Policy surfaced an internal candidate from the operations team who had been quietly automating manual processes using Python for 18 months — skills that existed nowhere in the HR system. Offer extended in week 1 rather than week 6. Time-to-Productivity: 22 days. That hire is now two years into leading the automation function.

| The catch: The First Look Policy only works with proactive recruiter outreach. A passive internal job posting that nobody reads is not a pipeline strategy. The recruiter identifies 3-5 internal candidates who match the Role Fit Profile and contacts them directly. Without that step, it is just another announcement.

Internal hires onboard 40-50% faster. The First Look Policy costs nothing and is systematically underused.

Eight years of managing Talent Acquisition taught me one pattern more clearly than any other. Organisations that treat IT recruitment as a reactive event — vacancy opens, sourcing begins, offer made, repeat — pay for it consistently. In time. In cost. In candidates who were never in the pool, and senior talent who left the process before the assessment stage.

The results were predictable: 60-day vacancies, $30,000 in lost operational output, assessment processes that alienated the most experienced candidates, and sourcing cycles that started from zero every time.

The shift came from building the system before the vacancy arrives. The Intelligence-Led Sourcing engine running continuously. The Inverted Sourcing Funnel identifying candidates by what they have built, not what they have claimed. The Silver Medalist Re-Engagement Loop converting near-hires into hires. The First Look Policy finding your best IT candidate on payroll before you search externally.

IT recruitment isn’t a faster version of standard hiring. It is a different function built on proactive intelligence, capability-signal sourcing, and systems that put you ahead of the vacancy rather than behind it.

The IT recruiters who keep winning aren’t the ones with the biggest LinkedIn Recruiter budget. They built the pipeline before the vacancy opened, designed assessments for the talent they were actually trying to attract, and measured what predicts Quality of Hire — not just what’s easy to count.

Pick one framework from sourcing: Intelligence-Led Sourcing or Inverted Sourcing Funnels. Pick one from pipeline management: Silver Medalist Re-Engagement Loop or First Look Policy. Implement both over the next 90 days. Track your source yield and Time-to-Offer. The numbers will tell you what to scale.