It Doesn't Take Muscles to Use Your Strengths
But it does take a manager that understands how to leverage strengths. Many managers say they do this, but I'd question if they really think this way, if "leveraging peoples' strengths" is really part of their DNA. The reason I question this is because many companies have defined roles for people to do. They are specific roles with specific titles for everyone in that grouping. At Microsoft, we call them Disciplines. There's a Test Discipline, a Dev Discipline, and a PM Discipline. Those are the most common. There are other, less common ones specific to a division or organization, like roles in an operations team. But dev, test, and PM (program managers) are the main three that the company uses. To define those roles, there are diagrams and documentation to give you background and set expectations for people in those roles (disciplines). You can read about how you should be behaving if you are a new hire or if you are a seasoned engineer in the software industry. You don't have to do everything listed in these documents (also called career guides), but you should do quite a bit of it or should at least be doing your work in the spirit of the role you are in.
This process that many corporations have in order to organize their workforce into roles and show their employees that the company supports many career paths actually goes against the idea of leveraging peoples' strengths. What if your strengths fall across discipline boundaries? What if you like project managing Test-related initiatives? What if you like to Test our software and then talk to our customers about what they will be getting? What if you enjoy fixing problems in how we release our code into Production from both the hardware and software perspectives? What if you like to develop test tools, not write test cases or find bugs, but write code all day long, just code that helps the test team and never ships in products? What if you like to use customer data and bug data to understand the quality of the current product release? These are all roles I've seen people play in teams I have been in. They cross discipline boundaries (PM to Test, Dev to Test, etc.). What discipline should each of these people be in? Does it matter? Well, they have all been in the Test (SDET) discipline. Is that a problem? Maybe for the company when trying to follow documented roles, but it's not a problem when your main goal as a manager is to build a successful team that can show a ton of results quickly. The best way to do this is to leverage peoples' strengths and not adhere to documented disciplines.
This becomes a problem when the management chain expects people to be clones of everyone else in their discipline. Some managers want to know what they are getting so they assume all people in one discipline will act one way, the way the discipline dictates through its supporting documentation and career guide. Having people act like individuals would be too difficult to deal with, especially when it comes to review time when people get compared to one another. Although this happens rarely, I have seen cases where managers penalize someone for not fitting into their discipline properly. I think it is unfortunate.
I like to leverage peoples' strengths. And I don't mean that I want to just use their strengths to get the job done. I truly want to leverage them beyond just using their strengths, but enhancing them. I expect people to already know and use their strengths to get their job done. As a manager I want to suggest to them ways to push their strengths to the next level, to use them in more complex situations. The more I do this, the stronger the team gets and the stronger the individuals get, and potentially the farther away that individual gets from their corporate-defined role or discipline. When that happens, the best thing to do is show the significant value that this individual adds to the team, project, and/or company. Many times the value gained far outweighs the need to be aligned to a specific corporate discipline. And that's how you solve the issue at review time around "relative to one's peers".
I've also seen over time that even the work that happens cross-discipline by leveraging someone's strength actually is happening with many people in different teams, people who all tend to fall in between disciplines when it comes to the work they do, but together they themselves have similarities. Uncovering a larger mass of the population that fall between (or outside) a discipline in the work they do and the strengths they exhibit helps drive definitions of new roles within the company. That's also a great way to solve this problem.
No matter whether it's one person or many, as a manager, I favor leveraging peoples' strengths. It makes them happy and it allows us to get more done. The alternative would be to call out peoples' weaknesses and continue to push on them to grow those areas. Granted, that still needs to occur to some degree. But relying on people to do tasks that require them to exercise their weaknesses is a lose-lose situation for the individual, manager, team and project.
What kind of manager are you? Do you follow standard role definitions or uncover peoples' strengths irrelevant to the defined disciplines in your company? What kind of engineer are you? One that falls within defined roles or one that spans roles? If you fall outside your corporate-defined role, you should recognize this, discuss it with your boss, and make sure this only affects your career growth in a positive way.