When to Value Non-Technical Work

This presentation resonates:

Being Glue

It’s a pretty long read, but the high-level gist is that software engineers are, more often than not, evaluated primarily on hard technical chops. You know: the typical stuff that you find in technical interviews, to sit down and produce code and architecture that addresses some notion of scalability, modularity, reliability and whatever -ility attribute desirable for software systems. The acute observation is that successful software teams blend soft and hard skills, yet soft skills are routinely discounted.

The core issue is that this type of “glue” work—the logistical and operational minutiae necessary to drive a project to completion—is under-appreciated and often does not count towards leveling and promotions, particularly at the junior and mid-levels of most engineering career ladders. Somewhat paradoxically, this work gains more recognition at more senior engineering levels and on the people management track, where driving initiatives to completion and aligning multiple functions in the same direction are lauded as leadership qualities. Those who have worked with me have often heard this described as “herding sheep.”

That said, granting that industry norms are perhaps a bit unfair, two anti-patterns fall out from this bias.

One instance is pretty simple—sometimes engineers are interested in areas other than technical impact and prioritize their efforts toward other work instead. Sometimes, this is mentorship; other times, communication and project management cross-functionally; occasionally, boosting team morale via off-hours activities. These things are important to building enduring teams and shaping their culture, and folks who step into the roles often feel the gap in team cohesion, which is why they volunteer for these roles.

But the problem is that this work can distract from core coding responsibilities, that is, the technical output expected of software engineers. From personal experience, some folks can take their excitement here a few steps too far, and end up focusing on side projects in lieu of their main job, rationalizing it as complementary to the rest of the team’s skills since the rest of the team is coding anyway. The problem is that if these roles are truly that important to the team’s success, they should be owned by the engineering manager1, or performed by a more specialized role, e.g., Technical Program Managers or Executive Assistants2.

This phenomenon then leads to the other instance: some folks are intrinsically motivated by the activities around technical output that drive successful projects, so they optimize for getting themselves to those senior and management roles as soon as possible to leverage their interests for career progression. In sometimes interviewing and talking with these folks, I often advise against moving too fast into management, even if it looks like an obvious role ↔︎ personality match.

Here, the issue of fast-tracking to management and architectural roles presents problems of its own, perhaps not immediately but in the years to come. The cost is that without the experience of working through major technical projects, leveling up to senior or staff-level work, and encountering problems of heightened complexity with extended timeframes. Seeing a system through its initial build is one thing; releasing it, dealing with changing requirements that require rewriting parts, and doing so as the state of technology and frameworks and best practices3 evolve is another thing altogether. Particularly for aspiring managers, garnering sufficiently senior engineering experience before the role lifts the ceiling of how comfortable they’d be managing more senior engineers themselves.

So yes, the arc of software engineering careers goes something like:

1. Learning the industry, environment, systems (entry-level)
2. Producing technical output via hard skills (mid-level)
3. Driving technical output indirectly (senior/staff)
4. Enabling problem-solving via software with soft skills (management/architect)

But it’s ill-advised to skip steps in between, even if personal preferences suggest a straight jump to points (3) or (4). It’s less obvious written out like this, but akin to learning math, each step tangentially relies on experience in the previous step, and context about how software is produced at each level aids in the progression.