

Ask HN: What helped you go from an indiv. contributor to a tech lead/manager? - allenc

I'd like to see those who have moved from being an individual contributor to more of a lead or a mgmt. role, the steps they took to get there or help and resources they've found to be helpful.&#60;p&#62;I ask since software engineering as a discipline usually does not emphasize the skills needed to lead or manage engineers. Some shops just award promotions based on seniority, but more often than not that turns out poorly - or disastrous, if that person has no interest in management to begin with.&#60;p&#62;For those who started out putting on headphones to pump out code to eventually inspiring a team to come together to create an awesome product and attract other top engineers, what's the secret?
======
cshipley
There is not one set formula, but IMO there are three attributes of engineers
who successfully move to technical leadership roles: knowledge, initiative and
communication skills.

The more knowledge you have, the more your opinion will be sought. Become an
expert in topics relevant to your company, introduce yourself to upcoming
technologies, and also know what is going on in your own company.

People who get shit done are the most important to a company. I've seen whole
teams paralyzed by differences of opinion, and all it took was one person to
create a adequate solution. Sometimes taking the initiative means doing grunge
work, like setting up the bug tracking system, or continuous integration
server. Help people out, including those outside of your own immediate team --
it gives you visibility and garners reciprocity.

Communication is the most important skill IMO. I noticed a general correlation
between people's position in the company and their ability to communicate
effectively. It is the topic I could write the most about, but I will relate
just the few important things.

* Learn to listen, and understand what people are saying tells you about their point of view and assumptions. Most disagreements IME are because people's underlying goals and assumptions are different, and a lot of times participants are unaware of it. They may be arguing apples and oranges, but think they are talking plums (If that makes sense?). Bring those things into alignment first, and building consensus will be much easier. Lastly, ask questions to resolve ambiguity, and test for false closure.

* Vocalize your thoughts concisely and understandably. Someone who rambles and doesn't get to a point, often gets interrupted or ignored. Also, as silly as it sounds, speak loudly, carefully, with conviction.

* Learn to write well. Aside from correct grammar and spelling, it means conveying information efficiently and understandably. Long gobs of text [like this diatribe ;)] often cause people to lose interest.

* Lastly, gather a bag of communication tricks. These can be general strategies for say building consensus in an unruly team meeting, or starting out a discussion with "Let me tell you the problem I'm trying to solve, and you can fix my thinking."

Well, that's my two cents worth. Feel free to message me if you have more
questions.

~~~
allenc
Great advice! I have the feeling that comm., like you say, is the most
important aspect and something that just doesn't come naturally for a lot of
engineers. Sometimes a simple email or ping can alleviate days of frustration
and head-wall smashing, but I know personally I can do a much better job and
perhaps it's a prereq to be noticed as "management material".

------
BenSS
Avoid just sitting down and 'pumping out code' to solve the problem. Make sure
what you're solving is really a problem, and is the right problem! This will
take tech skill, personal skills and a degree of relentlessness. Often the
person with the issue will not want to dig into what's really driving the
request.

