I've been working in embedded software development for this small startup and our team is pretty small: about 3-4 people. We're responsible for all engineering which involves an RF device controlled by an embedded microcontroller that connects to a PC host which runs some sort of data collection and analysis software.

I have come to develop these two guidelines when I work with my colleagues:

  1. Define a clear separation of responsibilities and make sure each person's contribution to the final product doesn't overlap.
  2. Don't assume your colleagues know everything about their responsibilities. I assume there is some sort of technology that I will need to be competent at to properly interface with the work of my colleagues.

The first point is pretty easy for us. I do firmware, one guy does the RF, another does the PC software, and the last does the DSP work. Nothing overlaps in terms of two people's work being mixed into the final product. For that to happen, one guy has to hand off work to another guy who will vet it and integrate it himself.

The second point is the heart of my question. I've learned the hard way not to trust the knowledge of my colleagues absolutley no matter how many years experience they claim to have. At least not until they've demonstrated it to me a couple of times. So given that whenever I develop a piece of firmware, if it interfaces with some technology that I don't know then I'll try to learn it and develop a piece of test code that helps me understand what they're doing. That way if my piece of the product comes into conflict with another piece then I have some knowledge about possible causes.

For example, the PC guy has started implementing his GUI's in .NET WPF (C#) and using LibUSBdotNET for USB access. So I've been learning C# and the .NET USB library that he uses and I build a little console app to help me understand how that USB library works.

Now all this takes extra time and energy but I feel it's justified as it gives me a foothold to confront integration problems. Also I like learning this new stuff so I don't mind. On the other hand I can see how this can turn into a time synch for work that won't make it into the final product and may never turn into a problem.

So how much experience/skills overlap do you expect in your teammates relative to your own skills? Does this issue go away as the teams get bigger and more diverse?

3 Answers 3


In the early stages of a startup, each person usually does a work of several departments and there is no place for redundancy. However, in a team of programmers (3 or more), I'd ideally try to achieve total redundancy - that is, each team member should be at least temporarily replaceable. For example, one person might be full-time sysadmin, but one programmer should be able to jump in when sysadmin takes a vacation. People are good at different things, and it's not feasible to employ two Java programmers and two Javascript programmers just for the sake of redundancy. But, one Java programmer might be interested enough in Javascript, and Javascript programmer might be OK with handling communication with client when project manager is away. 100% overlap is usually not possible, but at least partial overlap in important parts of the job is not that hard to achieve in a well-balanced team.

I must emphasize that a professional should not try to be indispensable. While that might be a good position to negotiate better salary, if you do that you're screwing both your employer and yourself. I want to be able to switch off my mobile when on vacation. And especially as a project lead my job is among other things to make myself completely replaceable. I want to be able to leave my project and work on something else without someone calling me for help on a project five years after I've left the company. And as a manager, I owe the same to my team, which is why it's important to hire a balanced team.

There are also big benefits to redundancy. Programmers can choose/negotiate what part they get to program. You can do code reviews when you need. If everybody knows a bit about what other people are doing, the communication is usually better. Also, this allows people to grow and learn other things - for example, our beta tester who was initially not a programmer was able to get into JUnit and automated tests. At one point we had only one DBA who was on-call all the time, so one of the programmers expressed interest and the company sent him to Informix workshop and now he has something to show in his CV.

  • Have you ever been in a situation where redundancy was taken too far?
    – spade78
    Commented Mar 4, 2011 at 2:21
  • No. I believe it's rare if it ever happens - I guess budget constraints make it almost impossible.
    – Domchi
    Commented Mar 5, 2011 at 16:19
  • I'm not sure that it can even be taken too far - if it is, it's simply called growing, you have a larger team and can get more work done. If there's not enough work, you've probably been hiring too aggressively, and have to lay people off, and if not, large team can always be divided into smaller teams.
    – Domchi
    Commented Mar 5, 2011 at 16:25
  • I'd think it can be taken too far if there is bureaucratic overhead that comes with knowing who is the backup for each person to a rather unreasonably high degree,e.g. who is the 10th backup person for Bob just in case somehow the first 9 backups all are sick or too busy to help with something. While I can see how some redundancy can be useful, there is also the chance for management to do stupid things with it.
    – JB King
    Commented Apr 10, 2012 at 17:37

Some overlapping is healthy, exactly for the reason you describe: all of us are fallible humans, so it is useful if team members can double check each other's ideas and work results.

Another, at least as compelling reason is not to have indispensable people in the team. If such a guy ever quits / gets hit by a bus / ... your project can be doomed. See also bus factor.

  • +1 for the bus factor. Didn't think of that for a reason.
    – spade78
    Commented Mar 4, 2011 at 2:15
  • 1
    To avoid the bus factor you could create a RAID 5 array of developers. If any one developer gets hit by a bus the skills are evenly covered by the rest of the developers.
    – Nicole
    Commented Mar 4, 2011 at 6:05

As you are finding out there should be some overlap.

  1. You need to understand something of what the other members of your team are doing so you can appreciate when they are having difficulties with a particular problem.

  2. When you come to integrate your separate components into a working whole it's better that you have some idea of why your colleagues did things they way they did.

    You might ideally need coordinates in double precision (say) but they arrive as floats because of a limitation in the hardware. If you didn't know this it could cause problems.

  3. Hiring new team members becomes a joint effort as you all know (to some extent) what's required from a "firmware guy".

Not the answer you're looking for? Browse other questions tagged or ask your own question.