Part 2: Delegation & Optimization

Every engineer has strengths and weaknesses. I can build awesome UIs and APIs for you, but if you want me to manage your AWS account I'll probably struggle a bit. Can I do it? Of course. Will I be efficient at it and enjoy it? Nope.

You can either be a specialist or a generalist, not both. A generalist runs the risk of being average across the board, while a specialist can only do so much, even if really well. As companies grow, the roles and hires typically become more specialized and instead rely on colleagues or even other departments to fill their knowledge gaps.

Shared Resources

Specialization works well in large companies, though does have some drawbacks, which is mostly rooted in relying and depending on others in the organization. Even if your colleagues are competent and helpful, you may have to compete with others for these shared resources and end up being blocked by them frequently.

As a fullstack engineer passionate about UX, with workable ops experience, I can interface well with an ops or design department, but if they're busy you don't want me messing with AWS, and you definitely don't want me to try to make something pretty. These cross-department dependencies can create bottlenecks and slow down engineering efforts company-wide, and also lead to frustration and even the 'blame game'.

Junior Engineers

There is tons of busy work a fullstack engineer can be responsible that isn't the best use of their time. HTML scaffolding and CSS, while not necessarily easy to do well, is not really the best use of a senior full-stack engineer's time and should be delegated out in order to free them up for more challenging or critical pieces of the system.

Some organizations may hire junior engineers to assist senior engineers with more mundane work, but younger companies may not have the luxury to pay someone six-figures to do HTML/CSS or mundane programming tasks. In fact, I'd argue that junior engineers should be looked at as investments rather than hires, much like interns. When hiring a junior engineer you should assume they are actually going to be a net loss and you should only be hiring them because of their long-term potential for the business.

For example, if it takes a junior engineer two years to become a mid-level engineer that can become a net gain to the organization, then you are investing 2 years of salary for them to become a cheaper mid-level engineer. If you get them at \$90k but can get a mid-level at \$110k, you just paid 2 years of salary (\$180k) to save \$20k/year, which will probably be even less because after 2 years and 'graduating' to mid-level they'll deserve market rates anyway, and if you won't pay them someone else will.

This is not to say you won't get value out of junior engineers, but they should not be relied on to build your company. Sometimes they'll give you a nice positive ROI, other times they may not, and sometimes you may break even. Regardless, they probably aren't a luxury you can afford until your company has grown its headcount significantly and actually has the support system to mentor junior engineers.

Alternative to Junior Engineers

1099/C2C contractors can be just like full-time W2 employees, with the distinction mostly just being tax/filing differences. However, I think there’s great untapped potential in what I’m going to call mini-corps. I don’t know if that’s a term already being used out there but I’ll give it my own definition here.

A mini-corp is an idea I’m playing with that really suits what I’d personally like to do with my career and business. Really it’s just a small agency that could be exclusive or not with a single client, but is ultimately more like a traditional partnership than a corporation.

In a traditional partnership, like a law firm, partners are largely independent but benefit from a formal working relationship with other partners. This is typically based on complementary skillsets that may strengthen any individual’s offering. These partners also benefit from sharing the expenses and responsibilities of forming and maintaining a business.

Engineering could be handled in a similar fashion via ‘mini-corps’. They could be partnerships between complementary skillsets (like a designer, front-end engineer and back-end engineer), or a group of experts in a specific niche (say Elixir or GraphQL, for example). They could even be as broad to become full-service product-management services, where an entire project, offering or product is delegated to the organization. This organization then handles everything from user research/UX, product roadmap and vision, technical management and engineering, design/branding & marketing etc., while having one or two 'point' people that interface with the client.

On a smaller scale, it could mean just hiring an individual who has a technical assistant that can handle some of the less complicated parts of the job, freeing up the more senior engineer to do the hard parts.

For some reason, companies are very cautious about this sort of thing. I'm not sure if they are scared about outsourcing, privacy/confidentiality, think they're gonna get ripped off, or if they just like the control and sense of 'ownership' that comes with a W2 employee, but I think a lot of companies could get much better results if they think outside of the box instead of trying to cram everyone into a W2.