The Road to Engineering Management

Recently, I've seen some signals in a direct report of mine that they could potentially move into an Engineering Manager role in their future.  After I told him this, he asked why he had been noticed and what kind of experience, desires, and focus Engineering Managers should have before taking on the role to ensure they will enjoy and thrive at the job.  After some thought I have come to the answer below:

People
As talked about in previous posts, as a Manager,  your people are your bread and butter; the alpha and the omega.  You need to be interested in people, and building relationships with people, as this will be one of your more valuable assets.  This isn't a trait you see in the "stereotypical" engineer who is introverted and this is probably the biggest mistake companies make when promoting engineers to managers when they really should stay on a path of individual contributor.

I've always described coming to work like doing one of my favorite activities, playing multiplier co-op games.   When planning an event to play multiplier co-op games, I'll prepare by getting getting chips, soda, alcohol, setting up the game controllers around the TV, and separate the games we can play together on one screen from the games we cannot so we all know what selection we have to choose from.  Furthermore, I'll invite great people for good company.  We'll come together to cooperatively accomplish a goal together, and have a lot of fun along the way.  This isn't so different from Engineering Management at its core.  I setup the resources, get people together, and we accomplish something great as a team.  When I think about coming to work, I think about coming to hangout with some good company and accomplish a goal together.  The main point being, I think of work as people and accomplishing goals with those people, and that's my favorite activity.

Being focused on people, and having a passion to bring people together, develop relationships, and accomplish goals with those people is an important part of deciding if you are right to become and Engineering Manager.

"Done" with Coding
On some level, you need to be ok with coding not being the main focus of you job anymore to become an Engineering Manager.

Normally, you'll see management be between the ages of 35-60, and this is for good reason.  By this age, you have gained the experience needed for management (Breadth of Experience described later), and you may feel that you don't want to code anymore as you've done that for the past zillion years.  I would also argue that the older you become, you gain more responsibilities, and although managers should always keep learning, technology and fads in this industry come and go to quickly for people with high levels of responsibility to keep up on.  Although you must manage each individual differently, management philosophies and practices are timeless.  You don't have to be 35 to become a manager, but on some level, you need to be "Done" with coding.

You also need to be "Done" with Coding because, frankly, you won't be coding.  Remember, you are there to be in the meetings to keep your engineers out of them as much as possible, which means you are in a lot of meetings everyday, and that's your priority.   While not in meetings, you are still acting as the communicator to a lot of teams and people, keeping your engineers productive.  When you done talking in meetings, and done communicating externally, your communicating internally through 1-1s with your directs.  There is simply no time for coding anymore, and if you find the time, you might want to focus your efforts more strategically and answer such questions as "How can I grow/shrink a particular process to be more effective", "What resources can I offer the team or an individual that will pay off in the long term", "What new practice or activity can I facilitate to grow the Engineering culture?".  Let's even assume you've answered all of the strategic questions you can think of for your team, and look at what you should focus on next, which is "What can I do to help".  This is when you may get to help your team by coding, but remember the question is more vague than that.  You may be helping the art producer answer some of these strategic questions since the art pipeline is too slow in getting assets to your team; you may be helping designers come up with better ways to write specs since they often confuse your engineers; you may even be pounding buttons and running through acceptance tests to help out QA.  What ever you can do to add the most value at that time.

Personally, I actually enjoy not coding at work, if for no other reason, it give me the energy and the vigor needed to go home and code what I am actually interested in on a personal project.  When I was an engineering, after a 12 hour day at the office, the last thing I wanted to do was come home and continue thinking critically, problem solving, and code.

Self-Improvement and Improvement of Others
When playing multiplayer games with a class system, I always look for the class that can be described as a support class.  Let's take the Bard class as an example in Everquest.  The Bard was able to spin songs to buff the group.  The spin mechanic would allow you choose 3 buffs to help your entire group.  I always found that when playing the game as an individual contributor to a group (let's take a mage for instance), I didn't get as much satisfaction as I did when I played a bard and was helping others become stronger at the individual contributor role.  Even at this early age of 13, I was already exhibiting behavior that pointed toward myself becoming a Manager.

A Manager, eventually, has to derive some satisfaction from helping others, and feel a sense of accomplishment when others succeed with their support.  This sense of satisfaction will motive and drive managers to become better at their support role and helping other succeed.  But, as it is with any other practice, before you can help others, you need to travel the path of self-discovery and first help yourself.  If you have a constant desire to improve, have an unquenchable thirst for looking for knowledge on how you can improve, and are constantly practicing your improvements, you will have songs to spin to help others improve.  You are filling your toolbox of ideas to then hand out to other Engineers later.

Breadth of Experience
As mentioned above, you rarely see managers outside the age range of 35-60, because you need a breadth of experience before you can become a manager.  You can gain a breadth of experience more quickly, but you need to focus on acquiring it if you want to become an Engineering Manager sooner in your career, and I am living proof that you can become an engineering manager as a young professional (joined the Engineering Management ranks at age 27).  Some things I've found useful are listening to podcasts, reading management books, keeping up-to-date with management blogs and articles, experiencing many companies practices, offering suggestions to management and ask for opportunities to help start new initiatives, staying observant of all happenings in the company and asking questions about the business decisions when I necessarily didn't "need to know", gaining deep relationships with many people, and practice, practice, practice, everything you've learn.

Advice From a Lead Engineer

Recently, a lead engineer I work with was randomly poked on LinkedIn by someone looking for advice about how to advance their programming knowledge at the college level.  I thought the feedback was very good so I would like to share it with you in this post:

"

I think the best advice I can give you is to start doing projects that interest you, whether it's games, utilities, research projects or whatever; the important thing is to see them through until you can consider them "finished". Start building a portfolio of code - it'll be good for your learning and good for you to show off to potential employers.

Some more advice (I'm just going to go into stream-of-consciousness mode here)...

If you want to get into games, learn C++. It's still the lingua franca of the games industry and it will teach you a lot about how the machine works. Understand how the compiler/linker works and how to read the machine code/assembly language it produces.

Learn as many different-paradigm/feature languages as you can. Each one will teach you something and allow you to think in new ways, making you a better programmer and giving you more tools in your toolbox. eg. C++, Lisp, Haskell, Erlang, Smalltalk, Javascript.

For data structures, arrays and hash tables get you a long way. Graph algorithms are absurdly applicable to many problems (not least their obvious strength in this era of social everything).

Learn at least one scripting language well (eg Python), as a go-to language for whatever small task you need to do. Learn to use a unix shell. Learn a version control system (eg git). Learn to really use a decent programming editor (eg. emacs, vim, sublime). These are the non-programming things you don't really hear about much in academia; but they will multiply your productivity. Learn to be productive.

Find the area of programming that fires you up. In games, strategic areas that are always in demand are networking and graphics. Other possibilities are AI, physics, animation, gameplay, tools, audio, the list goes on. Try to develop breadth, real expertise in one area, and depth in a couple of areas.

Perhaps most important: learn to work in a team, get along with others, communicate well and conduct yourself professionally (eg. how to commit to things, and how to say no). People get hired for their technical ability. They usually get fired or plateau in a company because of their poorer soft skills.

"