Why All Engineers Must Understand Management: The View from Both Ladders
By: Osman, Ozzie
Tags: Engineering Management, Programming, Management, Leadership, Software Development

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.