Behind the scenes, this has been a big boon for CDNs, my work is powering Amazon, and it is interestingly derived from work from Netflix on FreeBSD TCP. Together we are making TCP work much better on these largely wireless networks.
I'll give this simple example as a call to action. Schedulers of any kind, say the one that puts threads on to CPUs, are open-ended problems. If you co-design a system with hardware and software, it is highly likely you can get a 20% speedup in a system by manually emplacing different workloads (i.e. NIC interrupt handlers, application threads). In TCP, this same kind of thing applies. If you run Linux, there are a lot of things in the Documentation/ directory of the kernel that are worth reading and tuning. Selecting a congestion control, and tuning buffer sizes is very much "working on TCP" and could benefit any company using TCP. It's also something anyone with a few years of general development experience shouldn't feel intimidated to do! The most critical skill isn't any particular technology but learning to measure and confidently make and deploy changes. Likewise, there are very few things on computers that can't be improved. This can range from tuning general settings to a particular workload or change of underlying hardware, to algorithmic advances.
A good first level manager in my opinion should remain a strong individual contributor to the team. It's important to have prudent knowledge of the system and continuously develop your decision making basis. On top of this, a good manager should be directly recruiting and hiring talent (i.e. talent agencies and recrutiers are not good ways to build a team). And you should finally and most importantly be an advocate for the individuals on your team (compensation, basic empathy around life events etc) and the output of the team (vendors, other teams, etc will eventually try to undercut you knowingly or not. If the work is meaningful, and you are doing well, you must generate positive news about it). Done well, it's not an easy job.