You are laying out certain facts well; if you are doing rare work on an expert subject its unlikely that anyone with the expertise will risk their time and career with your work.
But I have not anywhere suggested that I am not willing to do the hard work. In fact it's exactly the opposite. I am doing all the hard technical work that is sometimes too much. So what do you do? You look to transfer some of it to someone else. The fact is however, only the smallest bit of hard work requires so much that you might as well do it yourself by adding an extra 1 hour to it rather than wait for someone to do it, communicate, and get it done in a week. So you look for expertise.
And you don't have to know the details of a specific kernel or a TCP/IP stack. A very good C programmer in general will do well enough.
The other trait that is highly acceptable is not knowing a lot, but being hard working and enthusiastic. We have one engineer like this who knew nothing and in 1 year he is a wizard in linking, build systems, python, locking, drivers ... I am all up for teaching patiently, but finding someone who has that vigor and enthusiasm is also very hard.
To your do-it-yourself suggestion. You need to acknowledge the problem of scalability and look for ways to expand your team because you are then a scalability bottleneck. I am not saying I know how to do it, otherwise I wouldn't be doing the earlier post. But I am at least considering ways to fix it.
Now you are getting a little closer to reality: You paid a guy a year to learn.
For your "A very good C programmer in general will do well enough.", that sounds wrong: C is just Brian W. Kernighan and Dennis M. Ritchie; sorry 'bout that; for "C", it's just that one, thin, 'idiosyncratic' book where I still can't make sense, parse the syntax, out of an arbitrary 'declare' (I borrow from PL/I since C likely has no good terminology) statement.
C in Kernighan and Ritchie is a DIRT SIMPLE language. In particular, there is NOTHING, not a single line anywhere, in the language on concurrency.
Being a "very good C programmer" is a bit vague: To get very far in C, about have to dig into material definitely not in the book and likely not standard or even well documented.
In C one place I started screaming was all their talk about "the heap" and malloc(). Their 'heap' likely has nothing to do with the heap data structure in 'heap sort', and they never said what their heap was or how malloc() worked. I've done things in dynamic storage allocation, and not knowing the details, ANY of the details, of what C does was a BUMMER. I couldn't hope to design serious software, especially for an operating system with concurrency, without knowing in fine detail just how malloc() and free() worked. Not a chance.
Note that Microsoft just gave up: They know that their Visual Basic .NET, C#, common language runtime (CLR), etc. just MUST work for long running, serious, production applications. So, there, first-cut, it is CRUCIAL to let programmers not have to worry about memory leaks. Second, even worse, Microsoft had to find some dynamic memory allocation that didn't have the memory of the application just grow slowly over the days and after two months have the program slow to a crawl or just die. So, they went for the gold standard solution: MOVE the data in memory and do full 'garbage collection'. Some questions remain, but so far my timings indicate that it at least mostly works. Just dynamic memory allocation AIN'T easy, ESPECIALLY in an operating system that we want to run for months or years.
Next, for threading in C, maybe go to the Posix things. Again, that's not really just C, i.e., as in Kernighan and Ritchie.
Next, in C there's the 'stack': To get very far using C, very much need to know a LOT about the details of 'the stack', especially for anything with concurrency in an operating system, but the details are not easy to find and likely not even standard. Uh, do some moving of data in memory and totally mess up some stack pointers!
E.g., I could never find any decently clear details from C compiler or linkage editor documentation on just what the 'stack limitations' were or anything about 'stack overflows'. All clear as mud. The hope is that such things just won't happen, and for serious code that's DUMB. Special case of a general situation: For serious software, even just in applications, CERTAINLY in an operating system, C is DUMB.
Then there's the really big elephant in the room on using C for concurrency in an operating system: WTF does C do with an interrupt or an exceptional condition? The broad problem is freeing various 'resources' and popping back the 'stack' of 'dynamic descendancy' (another term from PL/I internals), but Kernighan and Ritchie provide no documentation about C to let one design how to do such things.
So, as a serious language for concurrency and serious work, say, in an operating system, C just SUCKS because of lack of solid features and documentation. Write trivial little word whacking 'filters' as in Kernighan and Ritchie, sure. The last C I did was as Microsoft .NET 'unmanaged' code called from Visual Basic .NET 'managed' code using 'platform invoke' -- what I did looks solid enough, but I want to avoid that subject like a barrel of poisonous snakes.
If I'd had to do much with C, then I'd have screamed myself hoarse.
Somehow I suspect that concurrency has made progress past, say, just
C. A. R. Hoare, 'Communicating Sequential Processes',
now in PDF near the top of a Google search. So, if you want some expertise in concurrency, then get someone who had a recent, solid course in the subject, did well in it, has applied it, and maybe has done some serious work with it.
Concurrency is now a newly, very hot topic due to many cores, Web sites with tens of thousands of user 'sessions' at once, corresponding loads on data bases, MemCache, etc. The latest I heard was that there are some fairly serious concurrency bugs in some of the most important 'frameworks'. Going forward, doing much with concurrency will be a challenge. Such work will just scream out for some totally rock solid 'proofs of correctness' -- and major applications of keep it simple, stupid -- since there is no hope even in heaven of duplicating failures from bugs. Zip, zilch, zero hope.
Mostly what people are trying to do is to get some better concurrency 'primitives' way above interrupts with save and restore registers, spin locks, Mutexes, even 'transactional' topics like deadlock detection and resolution, and give programmers some robust, easy to use tools that actually work.
For how to modify an operating system, looks like you should get with whoever owns the operating system and what their 'guidelines' e.g., on concurrency primitives, etc., are for modifications.
Again, part of success is good problem selection. So, if you can't do all the significant technical work yourself, then either you didn't pick a very good project or have one boatload of money and time to recruit, select, hire, relocate, train, and manage people.
C is just a thin wrapper around raw machine code, so naturally most of the details depend on the implementation. When a good C programmer wants to understand the stack, he leaps straight for the system documentation and source code for the target architecture. (A file named something like "crt0.s" or "fork.c" is a good place to learn how the stack works and where it comes from.) K&R is just background reading.
But I have not anywhere suggested that I am not willing to do the hard work. In fact it's exactly the opposite. I am doing all the hard technical work that is sometimes too much. So what do you do? You look to transfer some of it to someone else. The fact is however, only the smallest bit of hard work requires so much that you might as well do it yourself by adding an extra 1 hour to it rather than wait for someone to do it, communicate, and get it done in a week. So you look for expertise.
And you don't have to know the details of a specific kernel or a TCP/IP stack. A very good C programmer in general will do well enough.
The other trait that is highly acceptable is not knowing a lot, but being hard working and enthusiastic. We have one engineer like this who knew nothing and in 1 year he is a wizard in linking, build systems, python, locking, drivers ... I am all up for teaching patiently, but finding someone who has that vigor and enthusiasm is also very hard.
To your do-it-yourself suggestion. You need to acknowledge the problem of scalability and look for ways to expand your team because you are then a scalability bottleneck. I am not saying I know how to do it, otherwise I wouldn't be doing the earlier post. But I am at least considering ways to fix it.