- Inventory management systems
- Employee records systems
- Health care records systems
- Etc.
Most of this work is about:
- Managing legacy tools and systems, much of which is diving into some complex mess for a few days to change one line of code
- Managing odd-ball one-off use-cases. If the customer has coupon code X, and is in Minnesota, do Y. If an employee was laid off on the last day in February in a leap year, do Z. Etc. These glum on and make spaghetti, and a lot of coding is just about getting stuff like this done.
- Long, boring meetings
- Documentation and, if you're lucky, test infrastructure
- ... and so on.
Technical performance matters a lot less than a whole bunch of other skills, and in most cases, hiring criteria are often "has a pulse." Most such systems use an "enterprise" stack (e.g. Java+Oracle or Microsoft tools).
I’ve worked on teams where there was a hood ornament manager and the real manager, usually carrying a Tech Lead semi-title.
Interestingly enough I’ve seen both be effective, but it’s a hell of a lot easier in the former case.
The rest of the time I just try to slog through the work and maybe take a moment here and there to be a 1.1x strategist.
I try to get all my mentees to be brilliant for a minute a day and just show up and complete all the work the rest of the time.
2) I've been at startups that need 10x engineers, and ones which don't. There are technically boring problems to be solved 10x engineers won't work on (and won't be 10x at). Many of those can be very lucrative. There are technically hard problems which will never be solved without a 10x'er.
I hate this kind of generalization and generic advice. If you're writing a medical patient record management system, the right toolkit, organizational structure, recruiting, etc. is very different than if you're doing build an autonomous robotics startup, which is in turn different from writing a mobile operating system, which is different from a mobile, social video game.