The number of buckets in a hash structure will almost always be on the order of the number of items in the hash structure.
The phrase "on the order of" is intentionally imprecise. That means you could have twice as many buckets as items. Or two times as many items as buckets. But the two values (bucket count and item count) are generally correlated in a linear (not exponential) manner, within a factor of 10.
If the hash function is fairly good, and the number of buckets is prime, then anywhere up to one item per one bucket will result in a median search depth of one and an average search depth just over one. Generally, because the relative cost of a bucket is small, it makes sense to maintain a ratio of buckets to items that is greater than 1, but only minimally so.
Your description of your solution is confusing, because you have 10,000 records identified by initials, but only 676 combinations of initials (26 x 26). It is likely that you are layering complexity onto complexity in a vain attempt to save clock cycles and RAM, both of which you are likely to waste as a result of the inherent complexity of your solution. A smart guy named Donald Knuth once said: "Premature optimization is the root of all evil (or at least most of it) in programming." I'm almost certain you are well down that path already, and I suggest that you back out of that choice.