As others also commented above, it is a mix of both. I have functioned as a manager by doing hands on work as well as guiding and managing projects and teams. I firmly believe doing one or the other wouldn't have been as effective.
One also needs to look at this from another perspective -that of the game theory. A project team or a corporation needs to be viewed as a cooperative game where all team members declare their intentions upfront and do not change their intentions after others have. It has been mathematically proven that unselfish players lead to the most optimum cooperative game and a similar analogy applies to the project team. Just my two cents!
Certain things at work which I love to do (and obviously I should be good at doing those), I would like to apply "lead by doing" for those. For certain things which I won't like to do repeatedly but they need to be done, I would prefer to apply "lead by doing" initially and then gradually change over ro "lead by managing".
Jim, ostensibly, yes, made pointier. In actual fact, the management course was excellent since the focus was on creating positive motivation, team spirit, and comraderie. It greatly helped fill in the interpersonal void that us techie types often exhibit, and it balanced my perspective of what my role was about. That clearly took some of the pointiness away, as it helped me develop a sense that I was serving my team as much as they were serving me.
BV certainly has it right regarding the blame sink aspect, and it requires high quality upper management to understand the value of that function. Unfortunately, the company I was at got hung up on inflicting "pressure points" at the line managment level without addressing issues at the root cause, which eventually led me to resign.
Frank, I agree that Bob sounds like a guy we'd all want to work for!
My own experience over my 20+ year engineering career is that I've never had any interest in becoming a manager until now. I think the reason is because this is the first chip design company I've worked for, and I'm not a chip designer, so to accomplish my goals I'd need chip designers working for me. That and/or because I realize that my interests and goals exceed what 1 person can do. Being a manager allows a person to get into more stuff, as I see it (correct me if I'm wrong).
Now, how to get from point A, hardware engineer in RF DVT where I am now, to point B, manager of R&D for a broad range of products where I'd like to be, is not obvious at all, but I'm figuring it out. Unfortunately, it's probably going to take a long time.
Rick, I like your story about getting the pointiness smoothed out, although to be more accurate to Dilbert, you got your hair made pointier! That is, you became more of a manager than "just" a techie. Unfortunately, Dilbert's pointy-haired manager has neither the technical nor the people management skills! Having both has got to be very valuable.
On career structurees and all tha.... a long time ago the solution was seen as 'the dual career structure'. Engineers and indeed scientists could be rewarded for their work so that they can be are paid more than managers. Leadership for these staff means both innovation, and learning for team members. Combining the management and technical leadership runs the risk of the team becoming dependent on the 'manager/engineer 'leader' who can 'solve' everyones problems 'Genius' Manager/engineers are very high risk as no one can stop their 'runaway' projects. They always have the answer.
Bob, I think you just wrote the perfect job description for front line and mid-level managers: Protect the development team from upper management and bureaucratic nonsense, and be prepared to take blame for failures, but reward the team for the successes.
You sound like an excellent manager!
I think part of the problem may be structural within many companys' philosophy around career path and salary scales. If traditional staff engineer salaries top out at or below the median manager salary, an outstanding engineer is forced to enter the management path to make the "big bucks". As BV points out, a star player may make a poor coach, so it is with engineers. Companies should define a path for designer salaries that values their capability more than their title.
In my own experience, I've had the pleasure of reporting to a non-technical "people manager" who understood and respected the skills of his direct reports. I've also had the less-than-pleasant experience of reporting to a highly technical manager with virtually no people skills. I, regretfully, have to also admit to the latter situation in my early line managment career. The company finally took some action and sent us newbies for line management training. That smoothed a lot of "pointiness" out of my boss hair.
The real time situation only can decide to lead by doing,lead by managing,or both together.The highly winning managers do both.Technical managers need to guide and contibute towards the projects apart from managing the team. Similarly the marketing mangers need to meet their customers and project them with their products and also make his team to meet the customers. So seeing in any way i feel that both are must.
Not too many sports all-stars become great coaches. I was never a stellar developer, but I can manage people. My role as a line manager is to protect my developers from upper management and the bureaucratic nonsense. I make sure that they have a clear understanding of goals of the project and that they have the tools they need.
Several of the developers who report to me have higher salaries and they do not want to manage; they want to develop. Become a manager and you stop doing the things you love.
I happen to like managing projects and bringing them to conclusion. My team gets the credit for all successes, I take the blame for all the failures.
Companies should let people so what they do best and value their contributions. There should a career path for developers and managers.
What are the engineering and design challenges in creating successful IoT devices? These devices are usually small, resource-constrained electronics designed to sense, collect, send, and/or interpret data. Some of the devices need to be smart enough to act upon data in real time, 24/7. Are the design challenges the same as with embedded systems, but with a little developer- and IT-skills added in? What do engineers need to know? Rick Merritt talks with two experts about the tools and best options for designing IoT devices in 2016. Specifically the guests will discuss sensors, security, and lessons from IoT deployments.