Give Squads, Functions and Managers a Structure Everyone Can Read
Software companies usually run two structures at once: the delivery team a person works in daily, and the function that formally manages them. We help you decide which one owns the appraisal, the leave approval and the career, and write it down. We also design the manager and individual-contributor tracks, spans of control and approval limits, so decisions stop waiting for the founders.
Not sure what you need? Tell us about your business in six short steps and we will come to the first meeting prepared.
Share your requirementsThe starting point
Does Your Structure Still Match How You Build?
Squads, pods and project teams form quickly. The reporting line often stays in engineering, QA or design, and nobody has said how the two fit. People then get feedback from the person who sees the work and a rating from the person who does not.
We help you write down who owns what, so the structure can carry people the founders have never met.
You may be experiencing:
- Appraisals, leave approvals and promotion cases falling between the delivery lead and the line manager.
- Strong engineers handed a team with no written view of what a manager is expected to do.
- No individual-contributor route, so the only visible way up is into management.
- Engineering managers with very different numbers of reports, some too many to know their people.
- Hiring, expense and client-commitment approvals resting on the founders' habits.
- Nobody named to cover when a delivery head or architect is away or has left.
- Offices, entities and time zones each following their own reporting practice.
What we can help with
Our Organisation Design Services for Software Companies
Structure Review
Map the functions, squads, pods and project teams you actually run, including who each person takes day-to-day direction from and who holds the formal line. We mark overlaps and orphaned roles.
Dual Reporting Rule
Decide which line owns goal setting, appraisal, leave, promotion and discipline, and what the delivery lead contributes. The rule is written for a person in a shared team, not only for the chart.
Manager and Technical Track Design
Define what a team lead, engineering manager and head of engineering are accountable for, beside a parallel individual-contributor track that carries equal standing, so a good engineer can progress without managing people.
Span and Layer Review
Look at how many people report to each manager, how much of a manager's time is still hands-on delivery, and where an extra layer or a lighter one would help.
Role Accountability Definitions
Write short role definitions for the roles that cause confusion, such as product owner, tech lead, scrum master, delivery manager and support lead, covering decisions each may take.
Delegation of Authority
Build an approval matrix for hiring, offers, expenses, vendor spend, client commitments and exceptions, with limits by role and a named deputy for each approver.
Multi-location and Multi-entity Structure
Show how offices, remote staff, subsidiaries and client-site teams report, who approves for them and which decisions stay central.
Transition Planning
Plan the move from today's structure to the new one: who is told what, in which order, how titles and reporting lines change, and when the design is reviewed.
The deliverables
What You Receive
Depending on the agreed scope, deliverables can include:
- A map of your current structure showing delivery and reporting lines.
- A written dual-reporting rule.
- Role definitions for managers, leads and individual contributors.
- A proposed organisation chart with spans and layers.
- A delegation-of-authority matrix with deputies.
- A structure note for each location or entity.
- A communication and transition plan.
- A review date and the measures to check the structure against.
Step by step
How We Work
Listen to How Work Moves
We speak with founders, engineering and delivery heads, a few managers and some engineers, and trace how a recent decision or appraisal actually travelled.
Name the Problems
We list where responsibility is double, missing or held by a person who has outgrown it, and agree with you which ones matter most.
Design Options
We prepare two or three structure options and set out what each means for accountability, cost, supervision and speed of decision.
Write the Rules
With your leaders we settle the reporting rule, role definitions and approval limits, and test them against real cases from the past year.
Plan the Change
We help you sequence the announcement and the changes, and record the starting position so the structure can be reviewed against it.
The difference
Make Ownership Visible
A written structure helps your company:
We do not promise outcomes. We record a baseline before work starts, covering the spread of direct reports per manager, the time routine approvals take and the number of roles without a named deputy, and report against it, so you can see what changed and what did not.
- Settle who writes each person's appraisal and approves their leave.
- Offer engineers a route that does not require managing people.
- Give new managers a clear picture of the role before the first team.
- Spread manager load more evenly across teams.
- Move routine approvals away from the founders.
- Keep structure consistent across offices and entities.
Find your fit
Who This Service Is For
Founder-led Software Companies
Move everyday approvals out of the founders' inbox without losing control of what matters.
Scaling Product Teams
Introduce managers and technical tracks before the first wave of promotions creates accidental managers.
IT Services Firms with Matrix Delivery
Clarify how practice heads, project managers and account owners share people.
Companies with Several Offices or Entities
Give each location a clear line and a clear set of local decisions.
Firms After an Acquisition or Reorganisation
Reconcile two structures into one that people understand.
How it usually shows up in information technology and software
Technology organisations grow in squads, pods and project teams, while the formal reporting line sits in a function such as engineering, QA or design. A person may work daily for a delivery lead and be formally managed by someone who sees little of the work. Without a rule, appraisals, leave approvals and promotion cases fall between the two. Engineering management layers appear when a strong engineer is given a team, often without a written view of what the people manager track expects, and without an individual-contributor track beside it. Spans of control stretch as the company grows. Approval limits for hiring, expenses and client commitments are held in the founders' habits rather than in a document, which slows decisions as soon as the founders are not in the room.
Common challenges
Where it goes wrong in information technology and software
Two structures, no rule
Delivery lead and line manager each assume the other will write the review.
Managers appear by default
The best engineer becomes the team lead without a defined role or support.
Spans drift
Some managers carry far too many reports to hold real one-to-ones.
Approvals sit with founders
Hiring, spend and client commitments wait for people who are travelling or busy.
A better process
What a working version looks like
- 01
Name the reporting owner
State that each person has one line manager who owns the appraisal, leave and growth, and that delivery leads give structured input. The organisation structure shows both lines.
- 02
Define the manager role
Write what a first-time engineering manager owns, what they stop doing and what support they receive.
- 03
Keep a parallel individual track
Put senior technical roles on a track that carries equal standing, so that progression does not require managing people.
- 04
Set spans and deputies
Agree a sensible range of direct reports by role and name a deputy for every approval.
- 05
Write the approval matrix
Record who can approve hiring, compensation changes, tools and client commitments, up to what level.
What to check this week
- Pick five engineers and ask who writes each one's appraisal.
- Count direct reports for every engineering manager.
- Find a recent hiring approval and trace how long it took.
- List who can sign client commitments and who covers when they are away.
- Ask whether a senior engineer could progress without managing anyone.
What this looks like in information technology and software
The parts of organisation design that are specific to this sector, rather than general.
Organisation and Team Structure
Squads, functions and who actually does the review.
What this coversHide
Organisation and Team Structure
Squads, functions and who actually does the review.
What this coversHideTechnology organisations often run a delivery structure and a reporting structure at once. Problems start when nobody has said which one owns the appraisal.
- Organisation structure
- Function vs project reporting
- Squad and pod structure
- Engineering management layer
- Individual-contributor track
- People manager track
- Span of control
- Approval matrix
- Role ownership
Questions on this, in information technology and software
That choice is yours, but it should be written down. A common arrangement is that the line manager owns the rating and the delivery lead gives structured input. We help you settle it and apply it to every team.
Most software companies benefit from one, since progression otherwise means managing people whether or not an engineer wants to. We help you define the criteria so the track carries real standing and not a consolation title.
There is no single right figure. It depends on how much the manager still builds, how senior the team is and how distributed it is. We look at your teams and recommend spans you can test, then review them after a cycle.
Not necessarily. Many changes are about clarifying who does what, adding a deputy or changing a reporting line. Where a change touches an employee's terms, confirm the position with a qualified professional, since GullyHR does not give legal advice.
Often yes. We design the limits and the route first, then configure the workflows and approvals in your own HR or finance system, or on the GullyHR platform, so each approval has a visible owner and deputy.
Workforce planning says how many people and which skills are needed. Organisation design says how they are arranged and who decides. They work best off the same chart, and we can do the two together.
The line manager should own it and collect structured input from delivery leads. If the roles are split without a rule, appraisals become late and inconsistent.
It depends on how hands-on the manager remains and how senior the team is. The point is to set a range, so that one-to-ones and feedback remain possible.
When decisions queue behind them. Writing limits by role lets the business move while the founders keep control of the larger commitments.
Build a Structure That Does Not Need the Founders in the Room
If appraisals, approvals and career questions keep finding their way to the same few people, the structure is the place to start.
Prefer to talk first? Call +91 80958 58589 or write to hello@gullyhr.com.
Book an Organisation Design Consultation
Tell us how your teams are organised and where decisions get stuck.
The general method — what organisation design covers, the questions it answers and what an engagement produces — is the same whatever the sector, and is set out on the organisation design page. What is above is the part that differs for information technology and software.
Other HR topics for information technology and software
Where to start
Most engagements begin with a review of how this runs in your business today, then a written process and the sequence to implement it.
See all HR topics for information technology and software, or another industry.