JOB DESCRIPTION · ENGINEERING DELIVERY

Technical Project Manager .

Run delivery for 15–25 backend, frontend, and AI engineers building construction-tech and CAD drawing-automation software — with structural engineers on one side of you and the codebase on the other.

FULL-TIME BENGALURU · HYBRID MANAGER · 7+ YRS

DEPARTMENT

Engineering — Delivery & Program Management

REPORTS TO

Head of Engineering

TEAM YOU’LL RUN

15–25 engineers · Backend · Frontend · AI

LOCATION

Bengaluru, India · Hybrid

EXPERIENCE

6–7 yrs min · 4+ yrs managing engineers

DOMAIN

AEC · CAD / BIM automation · Multi-tenant SaaS

About Company

It is a multi-tenant SaaS platform that runs the day-to-day operations of construction and infrastructure companies — their workforce, projects, commercials, and documents — on a single system. Alongside it we build an AI drawing-automation platform that turns structured element data into production-ready technical drawings and exports them to PDF and DXF.

Both products are built by a small, senior engineering group in India: backend engineers on an AWS serverless platform, frontend engineers on Angular and React, and AI engineers working on drawing generation and data extraction. Sitting next to them — not in another building, not in another timezone — are the structural and detailing engineers who define what a correct drawing actually is.

That adjacency is our biggest advantage and our hardest coordination problem. This role exists to make it work.

02 Role overview

We are hiring one Technical Project Manager to own delivery across our engineering teams in Bengaluru. You will run 15–25 engineers across backend, frontend, and AI workstreams, and you will be the person who turns requirements originating with our structural and detailing engineers into scoped, sequenced, shipped software.

This is a technical role. You will not be handed a groomed backlog and asked to move cards across it. You will sit in the design discussion and have a view on how and when — you will push back on an approach that will not scale, ask why a trade-off was made, and know the difference between a two-day change and a two-sprint one. You are not expected to write production code. You are expected to read it, understand the system, and never be the least-informed person in a technical conversation you are chairing.

The centre of gravity of this job is the floor, not the calendar. Most of your day is spent with the people building and the people specifying — closing the gap between what a domain expert means and what an engineer can implement deterministically.



Status reporting is a by-product of doing that well, not the job itself.

03 Delivery ownership

Own the end-to-end delivery plan for every active workstream — scope, sequence, dependencies, capacity, and dates that actually hold.

Break large, ambiguous product intent into engineering-sized increments with explicit acceptance criteria, agreed with the people who will build them.

Run the operating cadence: planning, standups, refinement, demos, and retrospectives that change something the following week.

Maintain one honest view of status — on track, at risk, slipped, and why — visible to the founders and to the team at the same time.

Manage cross-team dependencies between backend, frontend, AI, and drawing-automation workstreams so no team idles waiting on another.

Surface risk early, quantify it, and arrive with options — never an escalation without a proposal.

Protect the team from thrash: absorb changing priorities, re-plan properly, and say no or not now when a plan cannot take more.

Drive releases to genuinely done — QA, UAT with domain experts, documentation, and post-release verification included.

Own and improve the delivery metrics that matter: cycle time, predictability of committed scope, defect escape rate, and rework.

Run the release calendar across two products so neither becomes the permanent second priority.

04 Technical partnership

Participate substantively in technical discussions on design, sequencing, and trade-offs — and hold your own with senior engineers.

Understand the architecture well enough to reason about blast radius: what a schema change touches, why a migration is risky, why an API contract must be agreed before two teams start.

Challenge estimates that look wrong in either direction, and recognise when an estimate is uncertain because the problem is still unclear.

Translate technical constraints into decisions leadership can act on, and business constraints into direction engineers can act on.

A working test for this role: when an engineer says “that will take three weeks because of the authorizer limit,” you should know roughly what they mean, be able to ask the next useful question, and decide whether that constraint changes the plan or the scope.

Keep testing, observability,



and debt-reduction work on the plan instead of losing to features every single quarter.

Insist that decisions get written down — architecture choices, drawing rules, API contracts, and the reasoning behind each.

Stay close to the artefacts: read the tickets, the design docs, the PR titles, and the incident write-ups.

Chair technical discussions where the outcome is a decision with an owner and a date, not a longer discussion.

05 Working with the engineering floor

Our requirements do not come from a product spec written in a vacuum. They come from structural and detailing engineers sitting on the floor with decades of practice behind them. Converting that into software is the defining skill of this job.

Partner with structural and detailing engineers to turn drawing standards, project practice, and domain expectation into unambiguous, implementable requirements.

Run requirement sessions whose output is a written spec — sample data, expected output, edge cases, and explicit non-goals — not a shared verbal understanding.

Arbitrate the constant gap between “how it has always been done on site” and “what can be deterministically automated.”

Set up validation loops so domain experts review generated output early and repeatedly, rather than at the end of a sprint.

Maintain a decision log for domain rules so the same question is not re-litigated three sprints later by different people.

Manage internal stakeholder expectations and, where relevant, commitments made to customers.

Spot when a “small clarification” is actually a scope change, and handle it as one.

Make sure engineers get access to the domain expert directly — your job is to structure that contact, not to become a relay in the middle of it.

06 Leading the team

Line-manage or matrix-manage 15–25 engineers across several pods: 1:1s, unblocking, growth conversations, and escalation of what you cannot fix yourself.

Know each engineer's strengths, current load, and trajectory — and allocate work with all three in mind.

Hold a high bar on craft: reviewable work, tested work, documented work. Address underperformance early, directly, and fairly.

Onboard new engineers so they are contributing inside two weeks, not two months.

Give feedback that is specific, timely, and practical. Receive it the same way.

Build a culture where people tell you what is actually happening with their work, including when it is going badly.

Partner with the Head of Engineering on hiring: screening, interview loops, and calibrating the bar.

Represent the team's reality upwards without softening it into uselessness.

📌 Technical Project Manager (Bengaluru)
🏢 Nexifyr Consulting
📍 Bengaluru