
Ask HN: I just got my first team lead. What should I do? - endymi0n
Dear Community,<p>Lucky me (29, Software Engineer from Berlin, Germany) recently got a new job as a Lead Architect for a startup.<p>Now I'd say I'm not a bad engineer, but I've never been much of a "people person" or a natural leader. Although my colleagues treat me with a lot of respect, I still feel a little awkward. I'm a total newcomer to the "business" of managing, regularly keeping up with people and doing hiring/firing decisions, but I think I'm worst at delegating. Since the company is still pretty small, there's no choice for me than to get my hands dirty on coding and sysadmin stuff as well. Unfortunately, I'd rather do it all myself than entrusting and encouraging others with it, so I'm kind of playing my old role. Also, I'm having a hard time being a good listener, since I'm always coming up with my own ideas and notice that I'm mostly talking about myself which doesn't exactly make me more likeable, but it's hard to stop.<p>Reading "How to win friends and influence people" already helped me a lot with my people's skills, but I'm still struggling to get it all into practice.<p>Have you ever been in a similar situation? Do you know of any great resources, tips, tricks, hacks, communities or seminars short of doing an MBA (which I definitely wouldn't do due to time constraints and the bullshit factor)?<p>I'd really appreciate your help, especially from the engineer-turned-manager folks!<p>Best,<p>Dom
======
tkiley
Three years ago, I was the sole employee/founder of my startup. Today, I'm CTO
of a 21-person company with a 6-person dev team.

As an individual developer, my default loop is "Find something to do. Do it.
Repeat."

As a CTO, my default loop is "First, cycle through all my employees and make
sure that I have equipped them to be happy and productive in their jobs.
Second, find something to do. If possible, delegate it; if not, do it.
Repeat."

~~~
nekojima
"First, cycle through all my employees and make sure that I have equipped them
to be happy and productive in their jobs. Second, find something to do. If
possible, delegate it; if not, do it. Repeat."

This is what I did in my role as team leader and earned the equivalent of
Employee of the Year at a large firm. Its quite simple to say, more difficult
to successfully implement and often even harder to quantify during a
subsequent job interview, because when you do it well, to you its common sense
or straight forward doing your job. As a result, its not necessarily easy to
train into the behaviour of others. But it is quite easy to undersell (its
easy for you) or oversell (can sound arrogant) how you did it and doesn't have
the impact it should or could have on a hiring manager. Obviously referrals
from those you worked with can be a much better testament to the impact you
provided.

------
jbob24
I made a similar transition myself and have one piece of advice for you.

Forget about all that "leadership" and "management" bullshit. Seriously. When
you have direct reports your primary function is to serve them. I'm not
kidding - I know it sounds all squishy and kumbaya-ish but if you think about
what it means to serve somebody else you'll have a really good compass to
guide you through your day.

Everybody seems to throw around bits of advice around what to do and even how
to do it. The problem is every person is different and since people make up
teams, every team is different. Plus, they change. Don't get lost in the what
and the how until you understand the why. Everybody on your team has different
needs and serving those people means understanding their needs. Some people
need to be micro-managed and some people need to be given tons of space. Don't
let their needs/situation effect your respect for them and always remember
that people change.

Your to "why" will be different than anybody else's answer to that question
and will give you immense insight into which "what" and "how" things you pick
up from all that advice that is out there. It will also determine what kind of
a leader/manager you are. This is important.

Identify what makes you and others around you happy and you will probably find
yourself asking "what should I do?" a lot less often. Oh, and in case it's not
clear, don't be so naive to think that "happy" is all fun and games and wine
and roses and group hugs. And don't forget that you serve the "team" too -
it's an entity with its own needs and challenges.

~~~
bane
Absolutely agreed.

There's a saying, "shit rolls downhill." I'd argue that a surprising amount of
your job will be to keep that from happening to your people. Providing top-
cover is one of the most important ways you can serve your team. Keep the crap
off of them so they can concentrate on doing there jobs.

~~~
jbob24
Yup. It's all about crap reduction. Nobody wants to deal with stupid shit.
Most grown-ups understand life involves the occasional bit of excrement and
can deal with it.

One of the biggest mistakes I see managers make is failing to view people as
people. The shit flowing downhill is a symptom and not a given fact of life.

------
kls
_I think I'm worst at delegating_

 _I'm having a hard time being a good listener_

Wow that is a description of me 10 years ago to the T. I was always the guy
that people turn to and the guy that pulled the project out. It can and does
go to ones head. Be very careful to not become arrogant, I really wish someone
gave me that advice 10 years ago.

As for your case specifically, the delegation is going to be the hardest one
and the one that you have to cross the chasm on. Given your nature (I know
from experience) it will be hard but you just have to trust in your people.
Hire people that you believe are smarter than you, this will help in
delegation because you will perceive their opinions higher than your own. Also
try to remember, you design systems the way you do because it worked for you,
they will design it their different way because they are drawing on what
worked for them, look at it as an opportunity to learn a different way of
doing things. Many times when people like you and I enter this type of role we
believe that we are the authority, it can make working with our personality
type unbearable when you are a subordinate. Instead take it as an opportunity
to learn. Help them make their solutions better, not make your solutions
better. Just because you are the lead does not mean you are the best at every
situation, be humble and try to be an eternal student, that is the best advice
I can give you.

------
scottm01
Shortly before I started managing engineers I read "Managing Humans" (I'd
already been following <http://www.randsinrepose.com/>) and found it helpful.
One of the best resources I found was (luckily) my own boss. Find others in a
similar (or higher) position and talk with them regularly, openly, and
candidly about any challenges you're facing.

I wish I had better advice, but what you'll find is that being a good
manager/team lead is at least as hard as your old job (and probably harder).
Continuing to do your old job alongside it, while probably a good idea for
your own job satisfaction/sanity, will only make it harder.

Random bits of advice I find helpful:

* Your primary job is to shield your direct reports from management BS (false priorities, unrealistic deadlines, company drama); while this is less of a problem at a small startup, don't ignore it. Your secondary job is to make your direct reports look good; promote what they're doing and make sure what they're doing is aligned with the company's goals.

* Schedule 1:1 meetings. See Rands' advice on how to structure and run them, but basically keep them short, informal, and regular. Start with a softball and use it as a time for your direct reports to warn you about any upcoming problems that may be bubbling. Avoid the temptation for status reports, one larger team meeting instead, etc. Sit down with each individual direct report and get to know them better.

* Set clear goals and priorities for everyone.

* Avoid the temptation to micro-manage. You may eventually find you have an employee who has to be micromanaged, but most people hate it and will find it counter-productive. While this sounds obvious, it's hard for someone who likely got to their new management position because they were the best at the job they're now managing. Let people make mistakes and then let them recover from them.

------
bmelton
The first thing you need to do is learn the capabilities of your team.

Who are the best programmers? Who are the best programmers for the given types
of problems you have to solve? Who are the most creative thinkers? Who is good
at meeting deadlines?

If somebody is bad at meeting deadlines, why?

One of the best programmers I've ever worked with was always missing
deadlines. Turns out, it was only because he was really bad at estimating
time. Once I learned that, and started handling some of his estimates for him,
he was the best programmer on paper too.

As for managing, I try not to micro-manage, but it's easier to get a sense of
who does and doesn't need it once you understand, from a manager's
perspective, who is capable of what, and to what degree of consistency.

For the actual management, most of the time, I would just periodically see if
anybody needed any assistance, and let them know that I was always happy to
help where needed.

~~~
endymi0n
Great advice, thanks! On a sidenote, that guy:

"One of the best programmers I've ever worked with was always missing
deadlines. Turns out, it was only because he was really bad at estimating
time. Once I learned that, and started handling some of his estimates for him,
he was the best programmer on paper too."

...was most probably me =D

------
gmantastic
The best advice I could give is, whenever someone you manage brings you a
problem, resist taking it away and solving it for them. Instead, give them
some pointers on how they might solve it, but leave ownership of the solution
with them. This is hard to do consistently, particularly when it would take
you less time to do the work yourself, but the long-term effect is that you
grow a team of self-sufficient people, who only bring you problems when they
have tried hard to solve them themselves and genuinely need your help. This in
turn means your time is freed up to work on the most important things.

~~~
elliottcarlson
This is very important imho - the temptation to just do it yourself is for me
personally a hard thing to resist, but you will definitely strengthen your
team this way and gain more respect from your developers. You obviously want
to be there for them for any help and advice, but allow them to be the ones to
solve it in the end.

------
ThereRNoDumbQs
Congratulations on the new job!

It sounds like you've already identified your weaknesses, and they are
EXTREMELY COMMON - especially for really great engineers.

You used the word entrust, and this is key. It demonstrates that you have a
great sense of ownership over the work, and feel personally responsible for
the team's output. This is great, but now that you are the team leader and not
the team itself, you need to get three additional ideas burned into your
brain.

1: The members of your team are working with you toward a common goal, but
they are not performing brain surgery on your first-born child. A little
imperfection and inefficiency is OK. In fact, it's good business.

2: It is your job to set that common goal - which must be based on a business
goal - and get the team to buy into it. Getting buy-in is, ironically, more a
function of how well the individuals on your team believe you hear their
opinions than how well they hear yours, so this is a great opportunity to
practice your listening skills. But once you are all focused on the goal, the
fact that someone solved a problem differently or more slowly than you would
have will bother you less, because you will know you were doing other
important stuff at the time and together you got closer to the goal than you
would have alone.

3: Innovation means trying things and learning from them. The more people on
your team try things, the more you all get to learn, so give them the space to
try and celebrate the process as a team. Yes, sometimes that means people will
try things you already know won't work, but sometimes you will learn a better
way, or fail in a new way that leads to a new success. None of it will be a
waste of time.

Finally, remember that these apply to your own performance on the team as
well. Allow yourself the time to experiment and learn as a manager. Listening,
delegating, and coaching are all learnable skills that require practice more
than study, so just work at it and know that you'll get better at it.

------
DanielRibeiro
Agile Coaching helped quite a lot (even if you don't use Agile)[1].

A CTO of a very successful startup on the valley recommended me _Difficult
Conversations_ [2].

As long as you remember that empowering other people to do great work is very
valuable in itself (as it is a multiplier), you can motivate yourself into
getting to understand this side of software development.

It is not only important for tech leads, but for CTOs, and open source project
leads.

Good luck on your new job!

[1] <http://pragprog.com/book/sdcoach/agile-coaching>

[2] [http://www.amazon.com/Difficult-Conversations-Discuss-
What-M...](http://www.amazon.com/Difficult-Conversations-Discuss-What-
Matters/dp/0143118447)

------
j_baker
I generally think of it this way: a manager tells you what you _have_ to do. A
tech lead tells you what you'd be stupid not to do. You won't have much formal
authority. At the same time, you hopefully won't _be under_ much formal
authority if you chose the right startup.

At the same time, you earn a significant amount of "political capital". People
will probably give you a certain amount of deference. And you earn the unique
benefit of having a unique perspective on something.

Don't think this can't all be taken away from you, because it can, either due
to political or technical considerations. You can get marginalized by someone
with an agenda, or you can lose the respect of your peers with a few wrong
decisions.

The good news is that you really don't need great leadership or people skills.
You just need to convince people that the benefit of having worked with you is
greater than the cost of having to put up with you. People are willing to
forgive the occasional foot-in-mouth incident or the occasional screw up. You
just have to make sure people know what benefits you're providing them in
return. And having been objectively right or gotten great results will more
than make up for having _accidentally_ hurt a couple of feelings in the
process.

------
akg_67
Congratulations on becoming the lead. You already got some excellent advise in
this thread.

I found some good advice about managing and leading teams in books:

"The Wisdom of Teams: Creating the High-Performance Organization" by Jon R.
Katzenbach, Douglas K. Smith

"Leading at the Edge : Leadership Lessons from the Extraordinary Saga of
Shackleton's Antarctic Expedition" by Dennis N. T. Perkins, Margaret P.
Holtman, Paul R. Kessler, Catherine McCarthy.

Few suggestions from personal experiences:

About not delegating, getting your hands dirty can play to your benefit if
positioned right as trying to understand what team members goes through in
their activities so that you can make better decisions that are in best
interests of team members.

Consider your team lead role as mentoring role and not as a "manager" role.
Allow people to make mistakes and do lesson learnt type sessions.

Depending on the size of team, have lunch/ informal gathering as a team and
also meet with individual team members informally at regular basis.

Watch patterns and signs in how team behaves around you. If they are quiet
around you or always agreeing with you, you have a problem.

------
devs1010
Some of the comments below are a bit scary to me, it seems everyone things
architect = manager and I work in a company where this is also the prevailing
thought and I just can't agree with this line of thinking. There are a lot of
nuances to developing a complex application and the longer someone gets away
from coding on a daily basis the more they forget these things, they forget
how to "think like a programmer", they overly abstract things and trivialize
things. I can't help but realize that the "architects" who I have dealt with
who no longer write code always seem to be stuck in the past, they want to use
older libraries, patterns, etc that they used back when they were programming
even if the prevailing wisdom of the platform currently differs. I guess the
only advice is to be aware of this and don't become like this, you still
should be at the code level, at least part of the time, if you are truly an
architect and not just a manager.

------
spacecowboy
Accept that being a lead is going to be challenging. That whatever tasks you
have taken on for yourself, you may or may not get to them when you want to.
Accept that you will be the bridge between upper management and the technical
folks and that you will be dealing with any number of issues.

Also, keep in mind that there are lots of resources out there about how to
lead people and be a better leader. Look to the Harvard Business Review (
<http://hbr.org> ) for some good resources on how to be a better leader.

At the end of the day, as a lead, there is a process that you can follow to
help you along. The process includes the following: 1) Meet with your team and
work out what tasks are assigned, follow up with each team member and confirm
that they understand the assignment by asking them to describe to you what
they think they are doing, follow up with each team member on their assignment
and measure their progress, and finally, check in with them to review their
work and let them know when they are done or have completed their assignment -
then start again. Use this process no matter how small or big the assignment
is.

Some folks use an agile like approach to management of projects and one of the
nice things out of this world is SCRUM and the concept of daily stand up
meetings. One of the things I would recommend is to get into the rhythm of
meeting with your team for about 15 minutes every day to check progress, see
what they have accomplished and see what they are working on for the next day
and to see if there are any things keeping them from meeting their goals. If
you ever hear a complaint, that is a red flag and try to use whatever
resources you have to remove those obstacles.

At the end of the day, you only have so much time and energy. Do the best you
can and never loose your cool no matter what the situation is.

Best wishes and a great new year!

------
five18pm
Do you like your team members? If not, find out why and find a reason to like
them. Once you develop that basis to like your team members, everything else
will fall in to place. You will take interest in their activities, not just in
terms of getting your work done, but in terms of what they are trying to
achieve.

Talk to your team members on an individual basis frequently and in an informal
setting - people are much more open in an informal setting. Keep these
meetings to 5 mins. If there are more topics than can be covered in 5 mins,
increase the frequency of meetings, not the length.

Never do your team member's work. Help them in every way for them to do their
work, but just don't do it for them.

(Break every rule / advice that people are giving out. Finding what works for
you is one of best parts of management)

------
hkarthik
The fact that you're even asking how to be good at this is a really good sign.
I wish some of the folks that I've worked under in the past would have done
the same. There's lots of good advice in this thread.

My advice is to find a way to handle the pressure from above without letting
it affect how you treat your team. Technical teams are built on a tremendous
amount of trust and understanding.

If you're constantly getting hammered on by your non-technical boss, try not
to pass the buck and hammer your team in turn. You may find yourself in very
combative situations with the nontechnical leadership, and you certainly
wouldn't want your teammates to feel the same way about you. That makes for a
very ugly environment, and most smart people won't stick around for too long
if that happens.

------
sriramk
Set up weekly 1:1 meetings. Never miss them. And whenever possible, do the
meetings outside, even if it is just taking a walk.

~~~
martininmelb
I came here to say exactly the same thing... so, here's my other piece of
advice: Think about very good managers that you've had; what was it that made
them good managers? Try to emulate that (for me it was the weekly 1:1).

------
martininmelb
Don't express appreciation, show appreciation. What do I mean?

Express appreciation: Hi Jane, I really appreciate that you worked until
midnight to get rid of that bug.

Show appreciation: Hi Jane, I looked through the code - and you've really
improved it by replacing that buggy lookup with a hash function.

Anybody can do the first and it does not take time or effort. The second shows
that you've taken some interest and taken the trouble to understand what
they've done.

------
ct
An MBA probably won't help you and may even make it worse.

The first step is recognizing there's a problem and seek help, which you've
done and I congratulate you for that. I think you just have to be more patient
and humble.

Even if you think you're the smartest person in the company, you have to learn
that others can bring something to the table also. Just setup what the goals
are of the meeting at the start then give people a chance to speak and
withhold your own opinion until after you've heard everyone else talk at the
end. Again don't try to interrupt too much and give everyone a chance to voice
their opinion, and use it as an opportunity to try to learn something from
others (ie. respect that others have something to teach you as well). And
sometimes you'd be surprised at learning something you didn't expect or know
beforehand that would change what you thought should happen.

------
felideon
You might want to simply look into reading some leadership books. _Leadership
101_ [1] is one you can read in probably an afternoon, to get you started.
From there John Maxwell as a few more books on Leadership as well.

As I haven't been in a team lead position myself, I'm not sure if any of these
books can help you learn how to delegate as that seems something that would
take time and practice.

I have however, worked under a few engineer-become-leaders that are simply
horrible leaders, and I -wish- they would read a book like this some day and
have it click. Your success as a leader can possibly be measured with how
successful you are at raising leaders under your wing.

[1] [http://www.amazon.com/Leadership-101-John-C-
Maxwell/dp/15964...](http://www.amazon.com/Leadership-101-John-C-
Maxwell/dp/1596448318/ref=sr_1_1?ie=UTF8&qid=1325257380&sr=8-1)

------
DyumanBhatt
I tend to be of the mind to learn by doing. As many of the others have
mentioned, have conversations with your team members and spend time with them.
A common practice is to grab lunch with them. This will help you get to know
them and become more comfortable talking and listening to them.

I would also recommend regular work oriented meetings with them. Some may
disagree, but I think regular meetings to review work, and go over tasks has a
lot of value. You will see when they are finishing up their work and be able
to hand off tasks more readily. Also do what you can to get feedback from them
on you, and don't take it personally when they are critical and learn from it.

Ultimately there is no one answer and you have to find your own style as well
as a style that works for your team. A conscious effort and trial and error
will be better than books.

------
dudeguy999
Make lists. That's 90% of the job of a manager. Always have an answer to "what
should I do next?"

------
colorado_hacker
Well...I've been in the software engineering biz for a while now and go
between being an engineer, an architect, and manager depending on the company
and group. I don't have any formal management training and don't even have a
post-high school degree. But I love building software (I started writing
assembly on an Apple II+ way back when) and working with people and am in a
constant state of learning.

The quick answer is that there's no easy path if you want to be good at this.
You need to be aware of your natural strengths and weaknesses, and what you've
built up over the years to compensate. If you can, find a mentor, or at the
very least have regular lunches or coffee with folks with more experience.

It sounds like you are a technical leader with management responsibilities,
which is a very tough position. A lead/architect position without management
duties usually means that you are involved with all technical decisions in the
group but don't have direct reports. When I'm an architect, I expect the
majority of my time will be writing code with maybe 30%-40% of my time split
between formal meetings and hallway conversations. I will not take an
architect position that has no hands on coding - it's a recipe for failure. An
architect/lead will need to understand the business and technical needs and
help drive things forward so both sides are happy. Look for quick wins here to
keep things moving and 80/20 solutions. Also know when to stand your ground on
things that you know are wrong - be able to communicate your reasoning for
both engineers and non-technical folks. That role will also need to have
strong technical vision and the ability to communicate that vision so other
engineers will be able to follow the path. Figure out the types of engineers
and what they need to get their jobs done - some like diagrams, some like
talks, some like code examples, some just need a few lines in an email.
Conversely, you'll need to be able to help the business side understand the
technical side. You'll also have to know your team and help with things like
pushing things through to avoid engineer navel gazing, balancing NIH
attitudes, breaking ties on proposed solutions, slotting in engineering driven
changes that destabilize things, helping the engineers understand why they
can't rewrite a key component of the system without showing the business
value, helping the business understand why adding a fifth story to their
building won't work because really have a bicycle, etc.

Architects are expected to be "big dawgs" in terms of technical skills, so
it's ok to be opinionated and try to out-think others. Your own style will
come into play and you need to recognize it and be ok with how you work - you
might be the type who doesn't suffer fools lightly and because you see the
solution before anyone else, you just make your vision happen and ram it
through. Or maybe you have a high end team and you need to listen to the other
ungodly smart people around you and do more consideration. You do need to pay
attention to other engineers and business folks, and listen to them.

A good manager requires an addition set of skills. Management is really a
career restart because you're really going down a whole new path. The things
that got you to the management position aren't the things that will make you a
good manager. Being the smartest person in the room does not a good manager
make. A good manager creates an environment for others to succeed. A good
manager listens a lot and doesn't try to come up with the solutions. A good
manager recognizes that the right idea will present itself because the team is
awesome. Try to come up with as many options at possible decisions points. If
a tiebreaker is needed, a manager should be able to argue both sides
convincingly and not take sides (unless one side is just flat out wrong, but
hopefully it won't come to that). A good manager will let problems and
solutions come up from the team. Managers need to be aware that each person is
different and adjusts to each person. Depending on the group, they also need
to have a slightly more balanced view of the business then an architect. It
does require some politiking as well - you shouldn't go into a meeting for a
big decision without knowing where people stand ahead of time. Managers also
have to deal with the 'kindergarten' issues like ruffled feathers,
misunderstandings, bruised egos, etc. You'll need to know when someone is just
venting versus needing your action. And people have lives that impact the team
as well - people get divorced, have kids, get sick, have people die on them,
switch genders, come out of the closet, find Jesus, etc. A good manager makes
a personal connection and gets to know each person's story. This lets you
figure out where each team member is coming from and then how you can make
sure their needs and values are met at work. People are happy when what they
want out of life lines up with what the company needs. Managers need to know
when someone on the team is causing issues and maybe isn't working out.
Letting someone go is tough, but usually it should be obvious to everyone
involved that things aren't working out. It also involves bearing bad news to
both your team and other teams. Telling the CEO that your team fucked up and
caused customer level issues is rough.

Let's see...what else...hiring the wrong person is orders of magnitude more
difficult than delaying a hire. Be super picky when hiring, even if the
executive staff is pushing you hard to fill those reqs.

Engineers like to solve problems, so presenting things in the form of a
problem can be a useful approach.

Even if you have a solution in mind, start from the top and lead people
through. Let them come to the same conclusions you did and when they do, them
tell them the pros/cons of each decision.

Sometimes you have to be the alpha dog and make a decision that someone
heartily disagrees with - you need to understand their position, be able to
echo it, and stay the course.

You cannot take on other's emotional issues - you can be aware and offer help,
but you can't internalize them.

Try not to play favorites - this is tough because you'll find people that you
connect with easier.

Put yourself out there, let the team get to know you as a person so that
connection is better.

You need to keep in mind that you might have to fire anyone on your team at
some point, or give them feedback they don't want to hear, etc. So there's a
fine line between becoming friends with folks and being their boss.

Have fun with it, I try to keep a sense of play with me because that's part of
who I am.

I dunno - that's it for me - this was kind of a lot of stuff without much
structure, but I wish you the best of luck. This is a tough change for an
engineer but the fact that you're asking these types of questions shows that
you care and are willing to change to be better.

~~~
div
This sounds like great advice, and your post would make for a good blog entry.

------
dotBen
When I first landed this kind of role, I was given a copy of "Peopleware:
Productive Projects and Teams ". In some circles it is considered a bit of a
bible for this topic.

It's kind of an old book, but then the principles have remained the same. It
also means this book isn't then laced with specific methodologies of the day
or what not.

Downside is its a tad expensive on paperback, but reasonable on Kindle:

[http://www.amazon.com/Peopleware-Productive-Projects-
Teams-S...](http://www.amazon.com/Peopleware-Productive-Projects-Teams-
Second/dp/0932633439)

------
narag
One little piece of advice: your priority is giving work to your reports.
Avoid at all costs that they're idle. To achieve that, you must plan to be
idle yourself half of the time, so you can attend them when they need it (they
will.)

The other half of the time is to explain your bosses what your team is doing,
so if you're thinking of programming yourself, think again.

Edit: for both halves you absolutely need to know at all times what
everybody's doing, how they progress, what obstacles they're finding.

------
benawabe896
For me, I was only able to learn through experience, but hopefully my
experiences can help you avoid my mistakes. My first lead opportunity at my
first company was about 2 years in. It was a 12 or so person company, and all
positions were flat except for the owner. When I was promoted, I considered my
new main goal in life was to improve efficiency. While true to a point, I
decided that the way I was to improve efficiency was to start tracking every
piece of work performed. I created elaborate tools to allow everyone to check-
in their time, and built amazing executive reports to interpret this data.
However, efficiency (or rather actual work being done) was dropping.
Identifying this as a failure on the team's part, over the period of a year, I
implemented a series of changes ranging from good cop stuff (take the guys out
for team-building) to bad cop stuff (threaten pay-cuts, firings etc..)

Later at a new company, the opportunity presented itself, and I was sure I had
figured it out this time. Around this same time, I was really into design
patterns and diagramming. In fact, I felt as though every problem in life
could be distilled down to a pattern. Every member of my team could fit into
nice little diagrams as boxes, and the work would get done like magic. A
designer was a designer, and programmer was a programmer. Everyone and
everything was interchangeable. We could outsource work when we needed it, and
get rid of people when we didn't.

A bit later at a different company, I was able to give leading a third try.
Around this time, I was reading a lot of joelonsoftware, and randsinrepose.
Instead of implementing anything, I decided to just try to eliminate obstacles
for my team. I started weekly 1 on 1 meetings with my guys, allowing them to
talk about anything they wanted for as long as needed. Lastly, I just tried to
be the guy that I wanted my guys to be. I made a conscious effort to keep my
morale up, not let things get to me, and lead by example.

Looking back, I see that in the first two, I was trying to implement things
that motivated me. I love analytics and treating tasks as games. I love seeing
charts go upward. However, management is about your people, not you. People
are emotional and complex. This sounds pretty cliche as I write it, but try to
improve yourself as a person, encourage that in your team, and the
productivity / efficiency / whatever will take care of itself.

Good luck!

------
burnstek
Leadership revolves around having respect for your colleagues and believing in
them. This component is very similar to an ability to maintain healthy
relationships with family and friends.

Don't be just another software developer destined for a career in middle
management. Spend quality time with your team and get to know them as people.
Find out where they excel and assign responsibilities accordingly. The
listening part will then come naturally.

------
hn_philipp
I found this book very helpful in understanding of my role as manager:
[http://www.amazon.de/F%C3%BChren-Leisten-Leben-Wirksames-
Man...](http://www.amazon.de/F%C3%BChren-Leisten-Leben-Wirksames-
Management/dp/3593382318/ref=sr_1_1?ie=UTF8&qid=1325257860&sr=8-1) (German).
Malik's style is probably not to everyones liking - I enjoy it, though.

------
zorkerman
manager-tools has a nice website of podcasts about some basics of management.
I find these guys to be really sharp. Here is a link to their basics page:
<http://manager-tools.com/manager-tools-basics>

one on ones, coaching, feedback and delegation. They make a great logical case
delegation.

------
hodbby
Hard to answer but: 1\. know the design better then anyone else. 2\. Be ready
with any question that may come up. 3\. Know what your guys do at any time.
4\. Plan a good gantt. 5\. Be a friend with your team until it comes to work
decisions. 6\. Backup your team against anyone outside the team.

------
damoncali
_I'm having a hard time being a good listener_

Fix this first. It's a prerequisite for leadership.

~~~
endymi0n
Hard but honest... any specific advice on how to do it?

~~~
hluska
I hate to say it, my friend, but learning to listen is largely about changing
your attitude towards the people around you. It is very difficult to listen
when you perceive that you're miles above everyone around you. Consequently,
the first step is to learn to see how wonderful, competent and intelligent
every single person around you is. If the people who surround you are (in
actuality) neither competent, intelligent or even remotely wonderful, run
(don't walk) away and find new people!!! :)

Once you have built a genuine interest in the people around you, good
listening skills naturally develop. When you're interested in the people
around you, you will hang on their words, ask probing questions and reflect
back what you heard to make sure that you understood it.

If you can't engender a natural interest in the people you surround yourself
with, you can fake an interest. To do so, I recommend getting in the habit of
repeating back things that you hear, nodding in agreement when the person says
something you agree with, not interrupting when they say something you
disagree with, and asking probing questions when you don't understand/agree
with something.

Have you ever considered Toastmasters? It sounds silly to join a public
speaking group to become a better listener, but I can't tell you how much
Toastmasters helped me!

------
TYPE_FASTER
You don't need an MBA. You already know what you need to do. For every
conversation you have, concentrate on one thing: being an active listener.
Focus on that like you would focus on a technical problem.

------
known
[http://www.jamesaltucher.com/2010/11/how-to-exploit-your-
emp...](http://www.jamesaltucher.com/2010/11/how-to-exploit-your-employer/)

------
justinlilly
I'd recommend reading "Being Geek" by rands. Its great.

<http://beinggeek.com/>

------
kross
Lead by asking questions. It will force you to change your style, and it will
grow others at the same time.

------
renmarksky
Congratulation first.

Managing people is easy—but being a manager is not about managing people.

You have to be aware that managing is not as satisfying as coding and your
goals have totally changed from now on.

\- Learn to listen—that's so crucial—they're tons of techniques to get a
better listener. Listening can be boring but these techniques enable you to
listen hours (even with a smile on your face) without getting bored. It's so
damn important that I stress it again: you should listen 95% and talk just 5%
(from now on meetings aren't fun or a relaxing break, they become hard, boring
work).

\- Always 1-to-1 meetings—always. Every meeting with more than two people is
worthless, try to avoid them, if you can't just keep them short and full of
small-talk, fun and non-sense but without decisions. Harsh words, but leading
is not anymore about cookie-cutting talks with colleagues. That's one of the
big downsides of leading.

\- Don't focus too much on your staff—look that they are happy and motivated
(most important) and they have always challenging work, that's it. Don't try
to be all the time around them—if they need help be there. Don't change your
communication, just be yourself, but don't think they are your friends. Focus
now on next steps within the company—you are now doing first steps in
management and your work changed from working yourself to networking, to give
and take and last but not least to power politics (if your startup is >100
employees). Look that you spend more time with peers from other departments
and higher level peers in your company. If you can't progress or your company
sucks in less than 12 months, look that you spend a lot time outside your
company (there're lots of ways) and move on.

\- Don't use tactics or manipulative techniques even if you are good in it.
People always feels there's something wrong. Be yourself but keep distance.

\- Get a mentor or coach with leadership experience in highly volatile
environments, preferably outside the company

\- Because working oneself is still most fun, look that you keep coding on
private projects, even while in office (there're lots of ways). That's good
for your own motivation and keeps your coding skills fresh. Otherwise you
burnout after 6 months of all the meetings, mails and bullshit. That's
important because from now on you will slowly loose close relationships within
the corporation, upcoming relations are different, more political and it's
important to stay grounded, meet lot of people (again leave your company
often, go to meetups, because there you can just be yourself and that makes
you happy; if you don't do this you'll quickly degenerate and get isolated
because the working contacts are less and less true relationships). To
officially code yourself is not an option anymore (which is sad) because after
the first bigger mistake your management will tell your that you are not able
to lead your folks when they see you coding with them (which would be better
but non-technical management and c-level just don't get it)

These are all only very small hints without giving you the big picture which
would take more time and there is no book giving a really deep understanding
(I've seen many books before I had my first leadership position, none of them
is written by real leaders).

If you want more advice: renmarksky at live.com

~~~
quanticle
I like your advice, except for the insistence on 1:1 meetings only. When
there's a dispute on the team, the best option is often to grab a meeting room
with a whiteboard and hash it out right then and there. Trying to mediate via
1:1 meetings or e-mail threads often just lets the dispute fester and poisons
interpersonal relationships among team members.

~~~
renmarksky
Meetings aren't easy. Sure it can help to grab a room, gather and talk and
calm down but an existing dispute can also further escalate in a larger
meeting—it's gambling. One does always loose after a dispute (in his point of
view) and that's much harder to accept in front of many than in front of one.
If two have already a dispute, sure then you should talk with them both at the
same time and act as a moderator. But still it's a very complex dynamic
process which is harder to control with more participants.

Moreover, you can often clear/avoid a dispute when you had lots of
1-to-1-meetings beforehand where you got a good understanding of peoples
thoughts, fears, etc.

------
kamaal
Firstly Congratulations,

Now coming to how might probably go about this is awesome opportunity.
Remember a very important thing about software today. Its extremely difficult
to do anything big without a team these days. Even giants need teams. There
fore I will first start out with both the Technical and Managerial areas you
need to be aware of.

Technical:

As a manager, you might not have to know and understand each and every line of
code that is out there in your code base. But you definitely need to
understand enough technical details to consciously solve problems, take
decisions and assign and referee things among team mates when needed. This
means you have to on a day to day basis keep track of the developments. To me
this can addressed by separately planning a part of the day, this can achieved
in a stand up or status call, where everybody quickly reports three things
"What they did yesterday", "What they are doing today" and "blockers". Your
job is to first get sufficient perspective and context about he work your team
is doing, incrementally know their progress every day and remove any thing
that is coming in their way of achieving those tasks.

In turn you will have your own updates. Its not difficult with a little
discipline. You can take strides.

Management:

Here, you need to take a little care. Planning, Prioritizing, tracking and
course correction are crucial. They say, a true appraisal in any company is
when the junior and manager know exactly where they both stand. A good
appraisal has no surprises.

Talk to your team mates and be friendly with them as much as you can. Develop
their trust as a friend. Most people will do work for your just out of
politeness and courtesy. Never use provocation or threat as a means of
motivation(Often geeks make this mistake). Try to take things as easy as you
can, but be serious and stand up and make the person understand the
seriousness of their mistakes. Stop there, no further. Basically they must
respect you.

Trust them, or at least make them feel you trust them. Even if you don't
internally. The reason being once they realize you don't trust them, they will
loose all respect for you. They will fail to replicate the same feeling back.
Work, productivity will dry out and ultimately lead to a separation.

No invisible assumptions. Neither assume, nor allow others to assume. Make
plans, and prioritize, execute, track and course correct in iterations
frequently.

Your job must be to inculcate this agile discipline, with as little
distractions, more trust, friendship, higher productivity and aligned towards
goals.

P.S :

I am not a manager, But I would like my manager to be like the one I
mentioned. I admire some of my managers who truly were like that.

------
codeonfire
Here's a good tip. When you write something find the ratio of the number of
times you refer to yourself in what you wrote to the number of sentences. It's
a good indicator that others will find you self obsessed. Well experienced
leaders I've known almost never referred to themselves except in telling a
joke.

