What a Modern IoT Software Team Looks Like

A typical web software product has three layers: a front end, a back end, and a database. A connected industrial product has those three plus several more: firmware on the device, the connection between the device and the cloud, the pipeline that stores and processes device data, and integrations with the systems your customers already run.

Each layer needs people who know it, and all of them have to work together every time something changes. This post walks through what that team looks like, role by role, and how the work flows between them. It’s written for equipment makers deciding whether to build that team or use a platform that already has one.

The IoT stack, layer by layer

Before looking at roles, it helps to see what the team is responsible for:

Device and firmware. The code running on your controller, sensor board, or module. If embedded you are at a microcontroller level firmware. You may be at a PLC with built-in support or a Linux gateway that can run python applications, etc. (Note: Our customers and partners typically take this on but Exosite has embedded firmware experts.)
Connectivity. Network connectivity: Cellular, Wi-Fi, or Ethernet links. Local Connectivity - local wireless, gateways, and field protocols like Modbus.
Device cloud / IoT. Device identity, authentication, and the secure APIs devices use to send data and receive commands.
Data Pipeline and Management Time-series storage, retention, and processing, including rules and analytics. This can often mean millions of points a day being handled.
Applications. The web and mobile apps your team, your dealers, and your customers log into, with their own users and permissions.
Integrations. Connections to ERP, CMMS, and service systems.
Infrastructure and operations. Hosting, monitoring, backups, and the release pipeline.

A web SaaS team works across about three of these. An IoT team owns all seven or at least must understand and be aware of each layer, often for several hardware generations at the same time.

The IoT stack: six layers from device and firmware up to integrations, with infrastructure and operations and security running across all of them

The roles

Product manager

Owns the roadmap and decides what gets built next
Balances customer feature requests against bug fixes, security work, and new hardware revisions in one backlog
Decides how long each device model stays supported, which drives how long every other role has to maintain it

Engineering manager, tech lead, or architect

Owns technical direction and how the layers fit together.
Decides which parts of the pilot need to be rebuilt before they can handle a full product line
Tracks cloud services and dependencies the product relies on, and plans migrations when one is retired
Covers when others are unavailable.

Embedded and firmware engineers

Write the device software and the code that talks to the cloud
Build and maintain the over-the-air update process: signed images, staged rollouts, and rollback
Keep every hardware revision still in the field working, not just the current one

Backend and cloud engineers

Build the APIs and services devices connect to
Handle device identity, certificates, and authentication
Plan for traffic bursts, such as a whole region of devices reconnecting after an outage
Build and maintain integrations with customer systems

Front-end, web, and mobile engineers

Build the applications interacting with the other layers and admin tools, working with UX designers in some cases
Handle multi-tenant access, so each customer, dealer, and internal team sees only what it should
Keep the apps current as UI frameworks, browsers, and mobile operating systems change

Data engineers

Build the pipelines that clean, transform, and route device data, in real time and in batches
Design how that data is stored and kept, with retention policies that balance usefulness against storage cost
Keep queries and dashboards fast as the fleet and its history grow
Connect device data to the tools analysts and data scientists use, and to other business data like service records and warranty claims

Data scientists and analysts

Turn raw device data into answers: which features customers use, which parts fail first, how equipment is being run
Build and tune the models behind anomaly detection and predictive maintenance, and check that they keep working as equipment and conditions change
Work with product and service teams on what to measure, so the data collected supports real decisions
Often the role that shows the business value of the connected product, and the one most teams add after launch rather than before

DevOps, SRE, or platform engineers

Run the infrastructure: hosting, monitoring, alerting, backups, and tested restores
Own the CI/CD pipelines and the development, staging, and production environments
Automate certificate renewal and other routine operations
Run the on-call rotation

Security engineers

Review designs and code changes for security issues
Watch for new vulnerabilities across device, cloud, and web software, and drive the response
Handle vulnerability and incident reporting to customers and, where required, to regulators
Control who can change production systems and code

QA and test automation engineers

Build automated tests that cover the whole path from device to cloud to app
Maintain test devices and simulated fleets, including older hardware revisions
Keep test suites current as the product changes, so they keep catching problems

Support engineers

Take escalations from customers and field technicians
Reproduce problems that could be in firmware, connectivity, cloud, or the app
Answer “which customers are affected?” when something goes wrong

Smaller teams combine some of these roles, but the work doesn’t go away. Someone still has to do each of them.

Example: one line chart, every layer

Take something as ordinary as a line chart of a pump’s discharge pressure in your customer’s dashboard. For that chart to be correct, fast, and seen only by the right people, every layer has to do its part:

A line chart request travels down from the app, through the backend API, time-series database, and data pipeline, to the device API, connectivity, and firmware, with data flowing back up. Each step is labeled with its layer and the roles responsible for it.

The chart decides how much history to show and whether to downsample it. Thirty days of one-second readings is millions of points; the chart needs a few hundred.
The backend API checks that the user is signed in and allowed to see this asset, then rate-limits the request so one busy dashboard can’t slow the system for everyone else.
The time-series database returns aggregated values at timestamps quickly, even across months of history.
The data pipeline had to store each reading at the right timestamp. If it used the time the data arrived instead of the time the device recorded it, a device that was offline for an hour shows a gap and then a spike.
The device API accepted that data only over an authenticated connection from a known device.
Connectivity carried it over cellular, Wi-Fi, or a gateway, and the device held it while the link was down.
Firmware read the sensor, timestamped the value, and stored it until it could be sent.

That’s a simplified view, and it’s still seven steps and at least five roles for one chart. When the chart looks wrong, any one of those steps could be the cause, and someone has to know how to trace it.

How the work flows between them

A single change in an IoT product often touches several layers at once. A new sensor reading might need a firmware change, a new field in the device API, a storage change, and a new dashboard widget. The process that carries that change from idea to every device is its own body of work:

Source control and code review. Repositories for firmware, cloud, and web code, with review practices and access controls for everyone who can change production, including contractors.
Project management. One backlog and a regular cadence, so bugs, security work, and features are weighed against each other.
CI/CD. Automated build, test, and deploy pipelines for each layer, with separate development, staging, and production environments.
Release coordination. Firmware, backend, and app changes released in the right order, so a device never talks to a cloud that doesn’t understand it yet.
On-call and incident response. A rotation, runbooks, and a way to reach the right specialist at 2 a.m.

These tools are software too. Pipelines, test infrastructure, and issue trackers have their own updates, licenses, and failures, and each needs an owner.

Cloud services don’t replace the team

AWS and Azure as infrastructure providers offer building blocks: device connections, message routing, storage, and compute. They’re useful, and they take some infrastructure work off your plate. They don’t remove the roles above, and they can hide problems the team doesn’t know it has.

You still assemble the product. Cloud services cover parts of the device cloud, data, and infrastructure layers. Firmware, the applications your customers use, multi-tenant access, integrations, data schema, and the process that ties them together are still yours to build and run.
Someone has to configure them correctly. Each service has its own settings for identity, permissions, encryption, and networking. Under the shared responsibility model the major providers publish, they secure their infrastructure and you secure how you use it.
Managed services can hide how things work. When the product is a chain of managed services, it’s easy to lose track of how data actually moves, where it’s stored, who can reach it, and what happens when one piece fails. A team can believe a layer is secure without anyone having checked. These gaps tend to surface in production, not in the pilot.
They change on the provider’s schedule. Services get new versions, new pricing, and sometimes retirement dates, as with Google Cloud IoT Core in 2023 and AWS IoT Events in 2026.
The expertise moves; it doesn’t go away. Instead of running servers, your team needs people who understand each service well enough to spot when it’s misconfigured or not doing what everyone assumes.

What this adds up to

Some roles can’t be part time. Security, on-call coverage, and firmware for fielded hardware need people who are available when something happens, not when they have time.
Coverage matters. Vacations and turnover mean each critical area needs more than one person who understands it. When the one engineer who knows the provisioning code leaves, that knowledge often leaves with them.
It’s a long commitment. The team has to be funded for as long as the product is supported, which for industrial equipment is often ten years or more.
It competes with the equipment. Engineers pulled onto cloud and app work are engineers not working on the product itself.

For some companies, building this team is the right call. For many equipment makers, it’s a new department in a discipline they don’t otherwise need.

Where Exosite fits

Exosite’s team covers the platform layers of this stack: the device cloud, data storage and processing, the ExoSense application, infrastructure, and 24/7 operations, including platform upgrades and security. Your team keeps what’s specific to your product: the equipment, its firmware, and your customer relationships. We work alongside your engineers from the first connected device on.

Exosite maintains clear data schemas, formats, and definitions to ensure data can be carried throughout the solution. APIs and integrations are defined. Schemas, formats, and API definitions alone can be hard for organizations to standardardize on when starting a new connected project.

If you’re weighing a build against a platform, see why OEMs choose Exosite, or talk with our team.