Directors and managers oversee team organization, ensuring their teams accomplish business and product goals. However, fallout can occur for several reasons.
This is where you end up with different frameworks and Scaled Agile, which can make things worse.
This is a people problem coupled with a lack of organization. Like your next holiday dinner with family… without software and hardware team integration, your IoT organization can go sideways.
This combined problem causes:
- Reiterating on things that waste time and company resources. This can be frustrating for everyone, on every team.
- Traditional problems with waterfall development (investing in something that doesn’t work).
- The production line can stop. How do you solve a problem when you don’t know whose fault it is?
Hardware & software engineers’ mindsets are different
Hardware engineers are used to less volatile requirements. The biggest hardware changes revolve around the efficiency of the hardware’s function versus cost. Minor tweaks here and there make hardware more efficient in design, but these small tweaks are limited by the scope of function the hardware is designed for. Hardware is harder to change and engineers know it.
Software engineers are used to changing rapidly and going with the flow. Software has to be adapted to changes or it becomes obsolete quickly. Operating System compatibility in software alone can cause any number of internal code changes just to reach the desired result. Do you bake a pie with a top crust? A crumble? Or does your pie end up more like a cobbler when it comes out of the oven? In the end, the result should be a repeatable process. But, small variations in ingredients can create massive changes to the internal structure and flavor of your pie.
As you can imagine, firmware engineers are somewhere in the middle of these two mindsets. The firmware places requirements/parameters the hardware functions within and the software reacts to this. It’s typically easier for firmware teams to work with both software and hardware teams.
The simple truth is you can’t treat the three disciplines the same way.
It’s important to know as a manager, if you’re going to constantly change the requirements, it may constantly affect your hardware. Thus, your hardware team needs to know when, what, and how to change to avoid derailing the process altogether.
How to integrate your software & hardware teams in IoT development
You ultimately decide the fate of the realm which you lead. If the farmers refuse to sell wheat to the baker because the baker refuses to talk to the brewer at the local pub to get the yeast they need to bake with, then no one eats. Soon, everyone revolts. If everyone revolts, leadership goes into a panic. Quickly, the realm falters and anarchy begins… and who wants that?
Here’s how to prevent an IoT disaster in your realm by properly integrating your software and hardware teams.
If you’re just beginning, start small
First, get a prototype going with a few people, where everyone is on the same team. You’ll have inherent trust built in because you’ve worked with these people and they work well together.
But what about issues or conflicts within the teams? The crux of the issue.
There is a stigma that hardware can’t be designed reiteratively. The attitude of “We’ll do this upfront and then pass it off” falls into this category, but isn’t necessarily true. If your team is developing something that needs to be iterable, a development kit can solve these issues! Dev kits are built exactly for this — to test and try out your IoT product.
Create, document, & distribute personas
All teams need to understand the basic premise: Who is going to use my product?
Understanding this will give your teams a clear vision of what your product is and how it’s going to be useful. You’ll probably have at least two main types of user. The “I have to understand every aspect of this.” super-user, and “I just want to make my coffee, where’s the on button?” user.
Ensure the team understands these personas. This will help create context for user-friendly development, inspire innovation, and help solve problems quicker.
Unified communication
What does your team prefer for communication?
Some teams use Slack, others Teams, while others still use Google Hangouts. The mass appeal of different communication apps means not everyone is always on the same one. Cross-team communication is key and different teams on different tools make that a hard prospect. Especially if another team member is blocked.
With no easy communication, blocked folks will save their hassles for standup, possibly wasting half a day in the process.
Companies should pride themselves on the ease-of-communication pathways they establish. If everyone uses the same tool, your entire team can communicate more freely and everything remains cohesive. This allows you to encourage small questions and combine interactions so things don’t bottleneck.
Have an IoT expert
Many companies think: “We need to make an IoT device. I have a software team. I have a hardware team. I’m good.”
IoT is strange, complex, and dare we say different. Therefore, having at least one IoT developer will speed up every aspect of development since they’ve probably worked with the complexities of hardware, firmware, and software integration.
Interface-driven design can help
When we say interface-driven design, we’re talking about Application Programming Interfaces (APIs).
With an API, you ask for particular data and then it gets sent. You don’t need to know how it happens on the backend. This is important because oftentimes, knowing the “how” can cause overthinking and general problems between teams. You just need to know that it happens and that cross-team communication problems won’t occur.
Develop your IoT product in the same country
This should be obvious, but we’ve seen companies try to save money in one function by offshoring. Offshoring engineering can work, but it can go sideways just as fast, and an IoT product is significantly more complex than a standard application.
Here’s an article that digs into offshoring vs nearshoring and how to strategize around both methods.
Host visiting members
Working inside bubbles does not a team make.
Branch out a bit. If team members can parlay the inner functions and issues of other teams, they can more easily understand the solutions that need to be made. Have a day each month where team members can work cross-functionally with other teams.
This is more than just an empathy exercise. It opens eyes, solves problems, allows for innovation, improves trust, and boosts everyone’s knowledge. With everything else, empathy is power.
Implementing the initiatives above, especially cross-team communication can help you integrate your software, firmware, and hardware teams. By achieving integration, you’ll help solve many problems before they start, and bring the rest of the product organization with you.
More Insights?
View all Insights
Questions?
Sr. Content Marketing Manager