A couple of weeks ago, I left my comfort zone (software development) and went to a conference for another “world”. The conference was hardware development-centric and for a specific business domain. I was very curious to find out what was going on in that context and wanted to learn. Quite unexpectedly, all they talked about was the need to increase the speed of going from idea to delivered product, and how that could be achieved.

An old friend who was also at the conference has spent his entire career in that business domain. He said there was an urgent need to think disruptively: “What if we did everything differently? Maybe be five in the design team rather than 200, maybe let all the designers collaborate every day. What else?”

Ah, another total surprise for me!

I instantly recognised his wild and crazy ideas regarding hardware development, as some of my favourite modus operandi for increasing the likelihood of achieving effective software development. This was yet another big surprise and good reason for re-learning. And for sharing some thoughts in my SDS-series. Therefore, here is my take on five superpowers from software development, which actually might be helpful to hardware development too, at least if speed is crucial.

Let’s start with the first suggestion, which is very much in line with my friend’s first idea…

1. Extremely few

Always start a team with as few members as you could possibly get away with for the tasks at hand. In fact, better too few than too many! Later on, when there is a real, urgent need to grow the team, do so. But delay it for as long as possible.

There are many reasons for this approach, but the first that springs to mind is that this way the team will have to focus on the absolutely most important things and nothing else. There is always a possibility of adding more things later on. With too many people, they will all start adding things. With some luck, some of those things will be useful and good. Most probably, it’s all guesswork and most guesses will prove to be wrong. But even before that, they’ll be in the way and cause friction. Which is actually much worse than being worthless. “Worseless”? :)

I do understand that people need to build things in the hardware world. However, in the software world, building things is an automated task performed by the build server, not the developers. (The build server takes instructions written by developers in source code as input and produces a program executable by a computer in machine code.)

If you build repetitive hardware things, you should go for automation in the hardware world too. That makes it possible to keep the number of people down to a bare minimum. A focus on automation leads to the possibility of focusing on quality over quantity, which is the subject of the next section.

It is, of course, important with redundancy so that everything doesn’t grind to a halt if a team member wins the lottery and quits. That could be a reason for growing more, but we have another, better way of dealing with that concern…

2. Only the right people

If possible, focus on finding expert generalists for your team (especially early on). Expert generalists have shallow knowledge about many things (and a few special areas with deeper knowledge). However, they are curious and quick to learn new things. They are also very collaboration-oriented and customer-focused making them effective bridges between different teams and functions.

If you manage to get people like that on board, you need fewer team members to cover everything since each person can take on several roles. That way, you’ll get redundancy built in without the normal overhead cost.

The right people are passionate about the result. It’s not just a job – accomplishing the outcome, is a mission for them. In the TV show “Australian Master Chef” a couple of years ago, a guest chef describe the importance of passion something like this:

If you work with your hands, you're a worker.

If you work with your hands and head, you're a craftsman.

If you work with your hands, head and heart, you're an artist.

It’s not only about finding people who will do stuff. Neither is it only about finding people who will do the right stuff. It’s about finding people to who will passionately do the right stuff.

Finally, you should take explicit care to mix people of diverse backgrounds, experiences, and characteristics in your team. Again they will cover a much larger spectrum together and think differently about challenges and solutions. Very powerful, as long as they work as a real team…

3. Great collaboration

With a tremendous amount of luck, you might be able to create a great product by having each person in the team work in total isolation. But we are not in the business of optimizing for luck, so we don’t even try. We aim to work closely together.

I’ve been fortunate to get many chances to help companies analyse and suggest ways to improve their software delivery performance. Overall, I think the most common problem has been challenges regarding collaboration. It’s not a margin problem, it seems to be ubiquitous.

As I understand it, in the hardware world, there is another possibility of friction to which I’m less accustomed nowadays: a big gap between development and production people. I would definitely try to bridge that gap or delete it completely. Not only to minimise friction but also to maximise opportunities for learning and improving!

This leads to a need to balance what I just said about tight collaboration and being extremely few. Sooner or later, a single team just won’t be enough (and a team should be tiny). One way to succeed with the collaboration outside your team is to keep your outside dependencies in control.

Domain-Driven Design (DDD) is a powerful philosophy, concept and toolbox often used in software development. It’s a big topic, but at its core is the idea that we succeed in developing software in complex situations by using effective collaboration between developers and domain experts, by speaking a shared language within a specific context, and by focusing on the most important subdomain.

One area of DDD, called Strategic Design, is about the big picture, for example, how different teams relate to each other. To take a simple example, which team should define something to be collaborated on? Both? No matter what you choose, there are pros and cons. However, if you don’t make explicit decisions, you risk mostly ending up with cons. Strategic Design is an excellent source of inspiration for designing your dependencies to keep them in control.

Talking about DDD…

4. Everything should start from the business needs

To some, it’s evident that everything should start with the business’s needs. Others consider this approach wrong. I’m definitely in the first camp.

So, how do you learn to start from the business’s needs if that’s not your usual approach? The above-mentioned DDD is an important source of inspiration in the software world, and I suspect it could work in the hardware world too. I haven’t tried, but the dynamics should be similar.

“Domain-Driven” means starting from the business perspective rather than the technical details. Ironically, the opposite is more common. But as software developers, we really shouldn’t worry too much about the development itself, we can typically manage that. The hard part is understanding the business and how to solve the business problems! DDD could probably be a source of inspiration in the hardware world too.

That said, even if you start from the right place with the right stakeholders, every single step you take risks leading you astray. It’s not just about the start, it’s about the entire journey. That needs to be dealt with…

5. Extreme feedback

We need early and frequent feedback. Not only so that we can learn when we are wrong but also so that others can come up with ideas and better solutions. Actually, it even helps us identify better needs. This is how breakthroughs happen!

For real feedback to flow effectively, we need continuous deliveries. Delivering early and often is the way to go. This happens to be a mantra of Extreme Programming, a way of thinking regarding software development. Essentially, it’s about using what is known to work and be effective, and then turning the knob up to ten on those things. For example, if it’s helpful to have automatic tests to check that you haven’t broken any assumptions after making a change, why not write those tests before you write the code? Or if it’s effective to integrate different people’s work often, why not do it after each change by every person? And so on.

Again, automation will be key to make sure the team doesn’t drown in overhead. This is also tightly connected to the focus on increasing the speed of going from idea to delivered product, which I started the text talking about.

I realise that “deliver early and often” is generally more challenging in the hardware world than in the software world. However, I see it as something to strive for rather than a requirement to deliver a fully functional product every working hour. It’s a direction, not an absolute. And many other things are easier to do, such as mockups, prototypes and simplified A/B Testing. The same goes for batch sizes of 1 and just-in-time (at least early on).

Another kind of feedback is regulation. It’s often said that certain businesses are so regulated that they require manual work. I believe the opposite is true. If it’s regulated, we must use automation.

Oh, finally something that is easy to overlook if you are used to it and take it for granted, but is super crucial and will stop everything if you don’t have it. Some fundamental things…

0. Fundamental things

Fundamental, as in “must be in place,” or there is no need to even try suggestion 1-5 above.

The fundamental things I’m thinking about are just that, the fundamentals:

Trust and psychological safety Alignment on values (here are factor10’s values as an example) Common purpose and goal (here is a short text about this as well, although in Swedish)

On the other hand, suggestions 0-5 are reinforcing each other. For example, being extremely few makes all the fundamental things much easier and more likely to succeed!

Thoughts?

Nine years ago, I wrote that hardware souls can’t become software souls, and that’s not what I’m suggesting we try now either. But I do think that we can learn from each other.

I imagine some of you who consider yourselves hardware souls think this now:

“Jimmy, you don’t understand. This is hardware! We are different and unique!”

And that may very well be true. But what if some of the ideas I presented above could provide some inspiration? It can’t hurt to try, can it?

Ironically, quite a few code bases aren’t soft at all. Some of them are so rigid that they are harder to change than hardware. Perhaps the two fields have more similarities than we think?

So, where did I go wrong? What should be number 6? Thoughts?

This article was originally published on LinkedIn. Join the discussion and read more here.

About the Series

Surprise-Driven Sharing (SDS) explores moments when established viewpoints are challenged, sparking reflection and learning. Read other parts of the series: