Why All Engineers Must Understand Management: The View from Both Ladders

Photo credit: @yangmiao on Unsplash

Something interesting has been happening as I’ve been trying to write more about engineering management.

When I wrote advice about micromanaging for managers, a few friends asked me about how to deal with their (micro)manager, so I wrote about how to handle your manager. The latter piece seemed to be a lot more useful. I also wrote about how managers should avoid cognitive biases, and most questions I got were about engineers who felt their managers were victims of those biases. You see the pattern. I write for managers, I get interest from ICs.

It could be that I‘m reaching the wrong audience, but I think there’s something deeper going on.

Dual Ladders

If you work in tech, you’ve heard of the “dual career ladder”. As engineers grow, they can choose to climb the “technical ladder”, or they can climb the “management ladder”. In fact, companies you interview with will often brag about it so much, you’d think they were the ones who invented it! In reality, like most things modern Silicon Valley thinks it invented, the dual ladder has been around for decades. I found mentions that imply it was first made explicit by post-World War II DuPont (which, if true, would put the concept alongside other notable DuPont inventions like nylon, Kevlar, and the concept of ROI — more on the nylon part, in particular, later).

What’s the purpose of the dual ladder?

• Avoiding the Peter Principle. Engineering and management require different skill-sets, so if a technology company always “promotes” its best engineers to managers, it will end up converting great engineers to bad managers.
• Attracting, retaining and motivating engineers. If engineers feel like their only path to growth is management, and aren’t interested in it, they might not join, or they might leave, or just stay and not be that motivated.

It’s commonly said that managers of technical teams should understand technology so that they can be effective. It helps them build credibility, coach their staff, and make better technical decisions. I’d like to propose a broader claim: Regardless of which ladder you choose, you should understand the skills needed to ascend the other. Just like managers should understand technical issues, engineers should understand management issues to be effective. In the rest of this piece, I’ll mostly make a case for why this is important, but in future posts, I’ll go deeper on a few selected topics. But before that, let’s do a quick jump into the past.

Remember when we said we’d get back to DuPont and nylon? It’s hard to imagine how the world would be today if DuPont had not been able to offer a brilliant young scientist an opportunity to spend his time doing inventive research on polymers.

Wallace Carothers was teaching Chemistry at Harvard when DuPont approached him and offered him a job as a lab director. He initially declined. It wasn’t that Carothers, who was described as both brilliant and melancholy, enjoyed his teaching job. He actually seemed to dislike teaching. But he just wanted to do research, and had been dealing with bouts of paralyzing depression. He was worried about the industrial pressures of working at DuPont. Nevertheless, DuPont persisted, offering double his salary at Harvard, and explaining that at DuPont, while he would direct a lab, he could spend most of his time inventing. He would write of his days at DuPont:

“Nobody asks any questions as to how I am spending my time or what my plans are. Apparently it is all up to me.”

Carothers’ work led to the invention of both neoprene and nylon, which revolutionized plastic and were used in everything from clothing to military equipment. In fact, nylon became known as the “fiber that won the war” due to its contribution to the Allied victory of World War II.

Despite his success in the lab, Carothers continued to suffer from depression, and tragically took his own life at the age of 41, years before his inventions really took off. But his research was world-changing. It doesn’t seem like DuPont had formalized the “dual ladder” system yet in the 1930’s, and technically he was “director” of his lab, but if DuPont hadn’t offered him money, prestige, and a chance to spend his time doing research and solving technical problems, the world might be a very different place.

Let’s take another example. Meet Arthur Fry, credited with invention of the Post-It Note.

Rumor has it he also invented witty scientist photos

In 1974, Fry was a researcher at 3M, on the technical side of their dual ladder. Frustrated with trying to have bookmarks in his hymnal stay put, he used a unique adhesive developed by Spencer Silver, a fellow chemist at 3M to stick, unstick, and re-stick small pieces of paper, inventing the Post-It Note.

He would go on to get promoted to “corporate researcher”, the highest rung on 3M’s technical ladder, and stay with the company for many more decades. If it wasn’t for the dual ladder, he later said, he’d “have left the company and gone into business for [himself] as an inventor, or joined some small company where they give you a piece of the action.” Instead, he got to spend his time at 3M “staring at the wall or getting [himself] educated” while still “making as much money as a vice president”.

In other words, companies have been finding ways to attract and retain technical talent by providing them with opportunities that don’t force them to become managers or administrators. Of course, the “binary” dual-ladder is a little restrictive, so a lot of companies have more of a “wide ladder” (where there’s a spectrum of management vs. technical contribution) or a “jungle gym” (where mobility between the different types of roles is allowed or encouraged).

Most companies have realized that managers need some understanding of the technical side of things, lest you end up with pointy-haired Dilbert-style managers.

Dilbert.com

On the other hand, many individual contributors (ICs) don’t necessarily feel the need to understand things on the management side. ICs might feel like management is irrelevant to them, or they might have a cynical view on management. Here’s why I think that’s a big mistake.

Understand management because you need those skills

The software companies of today are a far cry from the industrial R&D labs of DuPont and 3M. Most current software development is more of an engineering discipline than it is a science. Sure, managers and ICs have very different day-to-day activities: managers spend more of their time in meetings and talking to people, and ICs spend more focus-time on technical issues. But, most ICs are not working in isolation in some lab in search of a moment of brilliance that will change the world. Modern software development is a heavily collaborative, cross-functional discipline. The brilliance comes in increments and iterations.

As you progress in your career as an IC, you will need skills like the ability to communicate with people on your team and outside your team, the ability to influence others, the ability to coach and mentor others, and so on. These are all skills that are required of managers, but are still very useful for ICs. A manager without these skills will probably fail — an IC without them might just have a stunted career. I’m not saying you need to spend all your time in meetings, or that you need to learn to play corporate politics. But I’ve seen many ICs who are so turned off from anything management-related that they throw the baby out with the bathwater. So don’t shy away from skills that might seem “managerial” just because you’ve decided to grow on the technical ladder — rather, invest in them!

Understand management because it shapes your system

By system, I mean the people processes in your company or team. You’re likely to be on the receiving end of processes designed primarily by managers. Recruiting and hiring? You’ll go through that process. Performance management? You’ll go through that process, too. You’ll witness good management and bad management. You’ll have to manage up. You should understand those processes, why they are designed the way they are, their strengths and weaknesses. And every process has weaknesses.

Let’s zoom in a little on a topic like performance management. Early on in a start-up’s life, the primary goals are execution and survival. Many start-ups don’t have the time, luxury, or experience to think deeply about performance management too deeply. As an engineer, you work on whatever needs to get done, and if you don’t know how to do it, you try to learn it, and through that, you become a better, more knowledgable engineer. If you’re not doing what the company needs you to do, it’s pretty obvious to you and everyone around you. If you continue to not do what the company needs you to do, you’ll probably be a victim of the “fire fast” mantra. Time horizons are short and feedback is swift but chaotic.

As the company grows and matures, things start to change. The company hires (or transitions) managers and “People Ops” folk, who have the experience (or at least the time and mandate) to think about performance management of people on their teams. The company’s time horizon stretches, which makes planning for the future easier. Someone might propose some structure: a 360-degree performance review process run at some regular cadence (once or twice a year). But how does the company evaluate people? Someone proposes a rubric (or “ladder”, maybe even a dual one). How do you reward people? Someone proposes a compensation policy.

Manager A notices that Manager B is a little more “generous” when evaluating members on his team. She proposes a calibration process, to try and maintain standards and fairness across different teams. After every performance, managers hole up in conference rooms to discuss their proposed evaluations and try to maintain consistency.

These processes differ from company to company, depending on the company’s size, maturity, culture, and overall philosophy. But as an engineer, you will be on the receiving end of one of these systems, with its pro’s and con’s. Even if your primary goal isn’t to get promoted, it’s still useful to understand why your company designed (or stumbled into) that particular process. What dimensions are being evaluated and why? Do managers have autonomy to make their own decisions, or are decisions made by impartial committees?

So how can you learn more about all this?

One way to do this is to just ask your manager. Why do we do “calibrations” as part of performance management? Who decides who gets promoted? What are the dimensions you evaluate people against? Sometimes those processes are well-designed and work as intended, but sometimes they’re not. In either case, you should try to understand them.

I actually love it when someone on my team show interest in these things, and value the feedback I get when I explain the reasoning behind some of the processes we’ve built.

I’m going to be writing more about each of these issues, but I’m going to try to do it a little differently. Firstly, I’m going to try to gather multiple perspectives from others, since different companies approach these issues differently and have learned various things about what works and what doesn’t. But more importantly, when I write, from now on, I’m going to try to write with a perspective from both ladders.

Let me know if you have specific topics you’d like to hear a “dual perspective” about.