Ten lessons from leading IoT projects

The photo above: an antenna mast we installed ourselves for a Herd-itt customer in South Africa. That is part of an IoT project too. Make sure the connectivity survives: no connectivity means no product.

Building an IoT product is rarely a technical problem alone. Over the years I learned that a project succeeds or fails on people, communication and decisions as much as on the hardware or the software architecture.

So I put these ten lessons in that order: people first, process second, technology third. Five come straight from the lessons in my stories. The other five are lessons the embedded world keeps learning again, project after project.

People

1. Align the agendas

Everyone around the table has their own agenda, strengths, worries and blind spots. Engineering cares about a sound design, purchasing about the cost, and suppliers about a predictable planning. The customer needs a system that works, on time, and management needs business results. Each of those priorities is legitimate.

A solution only holds when every party can live with it, technically and humanly. That goes for employees, suppliers, customers and partners alike.

As CTO, leading the meetings came with the role. But even where I was not in charge, I soon ended up leading them. At Connext, for example, I was the project manager, not the boss, and still I quickly ended up leading the meetings with industrial customers. Not because I was the loudest voice in the room, but because I tried to understand what drove each person at the table, and looked for the solution with the least friction.

Trust plays a big role here. In a team, I value trust as much as talent. Skills can be developed. Trust takes much longer to build.

2. Influence without authority

Many of the people you coordinate do not report to you. They are volunteers, customers, suppliers, subcontractors or colleagues from another department. And even when you do have formal authority, it is rarely the best tool.

At Solergie most of the people I worked with were volunteers. Volunteers do not work on orders. They give their time because they believe in the cause, so a clear goal and real collaboration matter even more.

What holds a team like that together is a shared goal. Personalities, backgrounds and working styles differ, and that matters much less once everyone knows what success looks like. So one of the most important jobs of a project manager is repeating the goal, and showing every contributor how their part gets the team there.

3. Teach until they can carry it alone

Training people takes time. Explaining a task takes longer than doing it yourself, so the temptation is to keep it. In the short term that is faster. In the long term you become the bottleneck.

Good leadership is not about becoming indispensable. It is about making yourself less necessary.

4. Bridge the hardware and firmware cultures

In IoT, the hardware and software teams often live in different worlds. Hardware engineers think in manufacturing constraints, component availability, certification and board revisions. Firmware and backend developers think in iterations, deployments and bug fixes.

The two work to different timelines and look at risk from different angles, and both views are needed. The projects that go well build a shared vocabulary. Cross-training, joint design reviews and early integration sessions catch the misunderstandings before they turn into delays.

As an IoT software engineer who owned the whole chain, from the electronics to the platform, I was often that bridge myself. Bridging these cultures is often worth more than solving the next technical problem.

Process

5. The slowest part sets the calendar

A platform update takes a day. A firmware release takes a week. A board revision takes six weeks or more.

Teams tend to plan around the work they control and underestimate the lead times outside it. At Herd-itt the hardware, the firmware and the platform had to land together, and the hardware set the calendar. The firmware had to be ready for the next board, and the platform followed.

So plan from the slowest part of the chain, and spend your attention on the bottlenecks, not on the work that already moves fast.

6. Decide on what cannot be undone

Some decisions can be reversed tomorrow. Others are expensive to change. The platform can be updated any day. The firmware on a tracker around a cow’s neck, in a field without coverage, is much harder to update, and the hardware itself cannot be updated at all.

So the biggest risks deserve the most attention and the most budget. At Herd-itt that meant: when budgets are tight, cut costs on the platform, never on the trackers.

Just as important is saying those risks out loud. A risk nobody names gets ignored until it becomes a problem. Decide consciously, and make sure everyone around the table knows why.

7. Be agile where it fits, use gates where it must

Agile works very well for firmware and platform development. Hardware follows a different reality. At some point the design is frozen, the components are ordered and the production slot is booked.

The IoT projects that work combine both:

• short iterations for the firmware and the platform;
• clear decision gates for the hardware;
• fixed milestones for manufacturing readiness.

Flexibility where you can afford it, discipline where you cannot.

8. Integrate on real hardware early

Many embedded projects postpone integration until late in the schedule. That is usually when the unpleasant surprises show up.

Simulations, development boards and virtual environments are useful, but they are never the final product. Only the real board shows the timing issues, the power problems, the radio interference, the manufacturing limits and the unexpected interactions between subsystems.

That is why I make “first firmware on the first prototype” an early milestone, not the last step. The earlier a problem shows up, the cheaper it is to fix.

9. Think about certification from day one

Certification is often treated as something for the end of the project. That is a mistake.

EMC, radio compliance and the other regulatory requirements should shape the design from the start. Pre-compliance tests on early prototypes are cheap, and they catch problems while a change is still manageable. A failure at the final test can mean a new board, another round of prototypes and months of delay.

I learned the same thing on a medical device at Verhaert: a sensor nobody can show to be compliant is not finished, however well it works. And at Connext, the hard part of an indoor radio system was not the design but proving that it would never disturb the other users of the same frequencies. Certification belongs on the roadmap, not in the last month.

Technology

10. Design for security and updates over the product’s whole life

An IoT product is not finished when it leaves the factory. It stays connected, exposed and responsible for data for years. Security and updates therefore belong in the architecture from the start. Secure over-the-air updates, vulnerability management and long-term maintenance are not optional extras.

Regulation now says the same. Under the EU Cyber Resilience Act, manufacturers have had to report actively exploited vulnerabilities since 11 September 2026, and most of the other obligations apply from 11 December 2027. A device that cannot be maintained securely becomes a liability rather than an asset.

This is where lesson 6 comes back. The hardware you cannot change, and the update mechanism itself, have to be right before the device leaves the factory. Design for launch day, and for every day after it.

Final thought

When people talk about IoT projects, they mostly talk about technology. Technology matters, of course. But the longer I work in this field, the more convinced I am that success comes from connecting people, aligning interests, communicating clearly and making the right decision at the right moment.

Products are built from hardware and software. Projects are built from trust.

If you are leading an IoT project and recognise some of this, let’s discuss your project.