Tech Lead (70% .NET, 30% React)

Job description:

Project info:

Next Generation Audit (NGA) is the audit platform. The work is split into value streams. Each stream is split into pods. A pod delivers a product area, such as admin and approvals, content search, audit-item templates, the data catalogue, test of details, or scoping and the test plan.

Delivery is agile. Pods use Kanban or sprints. The tech lead is the technical voice of one pod. The product owner sets priority. QA is part of the same delivery, not a step that starts after development.

The platform runs on Microsoft Azure. Services are .NET. The user interface is React and TypeScript. The exact libraries differ by stream. See the technology section below.

The role:

You lead the technical work of one pod and you still write production code. You are the person the pod asks when a design, a review, or a release decision is unclear.

You work with the product owner, QA, and leads in the US time zone. You explain a technical choice in plain language, including to people who do not write code. You also say when a request is not ready: the requirement is unclear, the deadline is not realistic, or the change has no proof that it works.

You listen, then offer options. You do not force a decision when the pod can reach it. You notice when someone is without work, or when work is landing on one person, and you spread it.

What you will do:

Design and build changes in the pod’s services and user interface. Review the design before a large change starts.

Keep the pod’s repositories consistent: API shape, Swagger, security checks, and pull-request descriptions.

Review pull requests yourself. Reject a change the author cannot explain. Do not approve generated code that nobody has read or tested.

Ask for proof with a delivery. That proof can be the user interface, a backend endpoint, or an integration test. It should show that the person understands the problem, the impact, and that the change works.

Bring QA in when the backlog item is written, not after the build reaches a test environment. Agree the acceptance checks early. Support developers who write the happy-path automated tests, so QA can review and cover the edge cases.

Set how the pod uses AI coding tools. Keep rules and skills in the repository. Share a useful skill through a pull request. Adapt a shared starter to this pod’s domain. Do not treat one setup as mandatory for every stream.

Use the tool with judgment. Give it context. Read the plan before implementation. Keep a human check on anything that leaves the repository, such as a push, a ticket comment, or a pull-request approval.

Join release work. Releases are coordinated across pods. You help make the pod’s part predictable: environment, configuration, and a check that the change is actually deployed.

Take a share of approved on-call when the pod needs it. On-call is rotated. It is not a standing weekend commitment for one person.

Help a new teammate become useful in the first weeks. Onboarding on this platform is slow because the system is large. Point people at the repository rules, the local domain, and the person who can unblock them.

Raise a risk early: QA capacity, a broken environment, a dependency on another pod, or a scope change that arrived too late to do well.

How the team works:

The backlog item is the unit of delivery. If the requirement is thin, you stop and clarify it before the pod starts.

Short-notice work happens. You still ask for a clear requirement and a deadline the pod can meet.

A weekly lead sync is where pod leads share the real state of the work. You keep your own pod informed.

AI coding is normal. Cursor is the usual IDE. GitHub Copilot reviews pull requests. Some people also use Claude or Claude Code. There is no single mandatory tool list. There is a shared expectation: the author understands the change.

A practical skill sequence already in use starts with a check that the feature is documented and ready, then a plan, then implementation, branch, pull request, code review, and a security pass. Pods change that sequence to fit their work.

Requirements:

You do not need every library on day one. You do need to be productive in the common stack, and able to learn the pod’s extras.

You need:

C# and .NET, including ASP.NET Core Web APIs

React and TypeScript

REST, Swagger / OpenAPI, and care with changes that break callers

Microservices, and a user interface split into micro-frontends

Microsoft Azure: at least App Service or Azure Kubernetes Service, Azure Functions, and Service Bus

A relational database and a document database. The platform uses SQL Server, Azure SQL, MongoDB, and Azure Cosmos DB in different services

Git, pull requests, and either Azure DevOps or GitHub. This programme uses both

Docker, for local runs and for service images

Automated tests that you can read and extend. Developers own small integration tests and happy-path UI tests. Playwright is the UI tool in use

Daily use of an AI coding assistant, with the habit of reviewing its output. Cursor is the tool the pods use now

Architecture you should be able to apply:

A thin backend-for-frontend in front of services

Clean architecture on the .NET services that already use it

Events through Service Bus, including an outbox when the service publishes a message

Feature flags. LaunchDarkly is in use. Some apps are moving to a shared feature-management library

API versioning, and contracts that stay stable for other pods

Repository rules that an agent will follow: security, Swagger, and the pod’s own domain

Useful on a specific stream, not required for every pod:

Squidex headless CMS, Azure Functions, content search

Ways of working:

English is the working language. You speak and write it clearly every day.

You can explain a trade-off, a risk, and a proposed change to engineers and to people who do not write code.

You take ownership of the pod’s technical result. You ask for help when the decision sits outside the pod.

You stay calm when a release or a late change puts pressure on the pod. You name the risk early.

You work overlapping hours with the US. A normal day runs to about 18:00 CET. A day of 09:00–18:00 or 10:00–19:00 CET fits. A wider overlap helps. The offset to US Eastern Time is about six hours.

You are comfortable in a remote team. In-person sessions in Prague are occasional, on the order of once a quarter.