
Ask HN: How to manage developers who aren't very good? - marktangotango
	Before becoming a team lead, I was the type of developer who, when given a task, would dig into the application api&#x27;s, the database schema, the configuration, whatever it took to fill in the gaps to accomplish the task. Sure I&#x27;d get stumped sometimes, but I&#x27;d always try to ask for help sooner rather than later.<p>Now, I&#x27;m a lead of 4 developers. Two are like I was, I can give them a task, they&#x27;ll go do it with minimal guidance. The other two will spend hugely more time on tasks. I&#x27;ve notice they tend to go off on tangents, spending time things that aren&#x27;t relevant, like setting up vm envirnoments they don&#x27;t need when they can develop and test locally. There have been occassions when they have asked me for help, and then a week later come back with the same question as though we had never talked about it.<p>It&#x27;s baffling to me, it&#x27;s like they&#x27;re &quot;scatterbrained&quot;, ie not focused or concentrated. How does one manage people like this?
======
jonstewart
Presumably this is your first time managing programmers. Without ill will, you
are most likely a very poor manager right now. Management is a separate skill
and, like programming, it takes a long time before you're proficient. So, the
first step is to acknowledge that, right now, you are a total newb and to tell
yourself that a few times every day.

From your description, it sounds like these programmers are not as efficient
in their work, or as task/goal-oriented as you'd like them to be, but not that
they're completely incapable. Sometimes you will find programmers who can't
program; they're hopeless, you have to fire them. But otherwise good
programmers can be awful at managing themselves... and you're the manager,
after all, so it's your problem to solve. Of course, you don't want to micro-
manage them every hour of the day; that's not scalable.

Not every aspect of Extreme Programming is applicable to every situation. But
a quick morning standup meeting can be a very effective tool. First, you will
find out when people get off track and are having problems. Second, it creates
some accountability to advance the ball every day. Third, while you must
actively work to have the team cooperate instead of compete, it will naturally
create some competitive and evolutionary pressure, where the more focused
members of your team provide a good example and, over time, can share some of
their secrets. Finally, the standup helps reinforce teamwork. If someone is
having a hard time with a task, you can respond and say, "hey, you know, Bob's
in a good place with what he's working on, why doesn't he help you out today,
see whether a fresh perspective can help?"

~~~
jmulho
Excellent answer up until paragraph three. Nothing will drive your developers
(good and bad) away quicker than an a "quick morning standup", aka daily
interrogation. Were you productive yesterday? Will you be productive today?
What are your excuses? This innocent attempt to keep everyone on track has all
manner of unintended consequences. Here is what happens to your developers
calendars: Draw a box around the hour before standup. In that box write "Don't
start on anything hard." Draw a box around the half hour after stand up. In
that box write "Try to regain focus." Draw a box around the last hour of the
day. In that box write "Do meaningless things I can mention tomorrow in
standup, if necessary." Difficult tasks are rarely accomplished as a series of
daily successes.

As a manager, the most important thing to remember about the meetings you
schedule is that they are for your benefit. If you are the type of person who
needs to know what is going on every minute, you will hold a meeting every
minute. When developers need to know what is going on they simply turn around
and ask, exactly as often as necessary. One way managers could minimize
disruption is to walk up and ask developers what is going on as often as
necessary on a per developer basis.

~~~
joesmo
"Excellent answer up until paragraph three. Nothing will drive your developers
(good and bad) away quicker than an a "quick morning standup", aka daily
interrogation."

While it's far from the worst thing to drive developers away, I do agree a
standup/scrum meeting every day is stupid, counterproductive, and just plain
useless.

For the managers, they should be able to look at your ticketing/project system
and know instantly what everyone is working on. Keeping tickets up to date is
part of the job and really, it's not that hard.

For the programmers, they are now tasked with figuring out what to say in the
standup and how to make sure that they are not perceived as not working when
they really are. Programmers who need to know what other people are working on
in the team can also look at the ticketing/project system and when they need
more information (as in cases where their work depends on someone else), they
will ask directly.

I've been to standup meetings in close to a dozen different companies, ranging
from the smallest startup to some of the biggest tech companies and never have
I ever seen a standup meeting end on time. NEVER. I don't think it actually
happens. What I have seen is the meeting go on for half an hour to an hour,
boring everyone out of their minds. Sometimes this even involved multiple
teams whose work barely intersected at all. The other team's work status was a
pure waste of time for anyone not on that team.

Yes, it is absolutely an interrogation. A daily standup shows that the manager
doesn't trust his employees. He doesn't trust them to keep the
ticketing/project system updated. He doesn't trust them to do work without the
threat of being shamed and/or seen as lazy if the work done doesn't sound
impressive in a standup. He doesn't trust them to seek help on their own.
Basically, a daily standup is the sign of an incompetent manager.

Scrum is for rugby.

~~~
jonstewart
A standup is for communication. "Here's what I'm working on, here's something
cool I found out, Oh hey I have some code related to what you're working on, I
need help, That sounds awesome, What a pain in the ass setting up VMs is",
etc. I've actually found it's also a good way for the manager to communicate
what s/he is doing, by participating as an equal. The standup should not
devolve into the manager pointing a figure at each team member and asking them
when they'll be done with a certain task.

~~~
jmccree
In my personal opinion, if you need to set aside 15 minutes per day, killing
at least 45 mins of productivity, for people to communicate, then your
communication processes are broken. All of the things you mention could be
communicated throughout the day in a team chat room. If someone needs help,
they should send up a flare immediately via email or chat and get assistance
as soon as someone is free.

In my personal experience, standups are practically useless if you have a team
that has good communication practices. You know what people are working on
from the ticket system, things are shared throughout the day as people work on
chat, and if you do need some level of daily status report, having everyone
email one in directly to the manager is the most efficient route.

~~~
jonstewart
That's funny. Right now my colleagues and I are remote, and I really miss
having a standup and often despair at using chat all day long. For me, it
feels like an interruption throughout the day and frustratingly low bandwidth.

------
jkaunisv1
I see a lot of comments here about having a daily standup. As somebody who has
been the weakest developer in a team of stars, standups can be really
intimidating and not a place I'd like to own up to the fact that I'm stalled
on something.

A daily meeting/checkin is super valuable but don't expect your junior devs to
pipe up with what's actually important. You may have to check in with them
one-on-one, in private, to hear what's actually on their minds. And ask
specific questions, not just "how's it going?"

~~~
mrharrison
If you are stalled on something, AKA blocked in agile terms., then its the job
of the scrum master to have people unblock you. Stand ups and agile are put in
place to help people. Its sounds like the people in comment thread have had
poor scrum masters/managers. I'm an engineer and scrum master and love the
process of helping and being helped. Thats the whole point, not
accountability.

~~~
jkaunisv1
I think a lot of companies heard about "that agile thing" and implemented
stand-ups because that's the stand-out thing they can emulate from whatever
blog article they read. Or they don't even associate it with agile.

I don't think any of the places I've worked that did stand-ups were trying to
do agile, it's just an attempt by the manager to know what's up without
devoting much time to it. I haven't seen it work well in that context.

------
wballard
What works for me having managed 20 years now:

-accept that different folks work at different speeds, measure success on dollars made or saved -- real business metrics -- not are they fast vs your expectations -share the end goal and business metrics, don't 'task' people, give the a mental stake in the real problem -- otherwise you are not getting their brains, just their hands -if you have a strong preference for hands off and not guiding, hire for that, which is a longer chat but I can share how I do it -if you are willing to have 'dependent' developers, personally pair with them and see the real problem in real time, not a weekly or daily vignette

------
Jemaclus
Someone already mentioned Situational Leadership, but I'll just expand on that
a little. There are four main methods of management in this paradigm, and it
depends on how your team members work.

* Low competence, high commitment -- these guys don't know wtf they're doing, but they're happy to be there. They need direction and guidance, very hands-on. The strategy here is "I talk, I decide."

* Low competence, low commitment -- these guys don't know enough to work on their own (but maybe aren't totally incompetent), and they're discouraged. They need direction AND encouragement. The strategy here is "We talk, I decide."

* High competence, low commitment -- these guys know what they're doing and can work on their own, but maybe they're bored or intimidated or not confident enough to really take charge of their own schedules. They need encouragement and advice. The strategy here is "We talk, you decide."

* High competence, high commitment -- these are the ones where you say "Here's a problem, go solve it". The risk here is that they'll leave -- they don't need you anymore, right? The strategy here is "I trust you, you decide, but I'm here for advice if you need it."

That's just a really rough overview, but I suggest picking up some management
books. Like my boss tells me, "if you're trying, you're one step ahead of the
game."

Good luck.

~~~
brational
> * High competence, low commitment... The strategy here is "We talk, you
> decide."

Can you elaborate on this one? What do you talk about and how do you steer
them to their own decisions?

~~~
Jemaclus
With the first two low-competence groups, you tend to start off the
conversation with "I think we should do X," because you don't trust them to
come up with a good plan from the start. You can talk about it with them, but
at the end of the day, you get to decide what's going to happen.

With the high competence/low commitment group, you probably want to start the
conversation off with "Here's the problem. What do you think we should do?"
Then you both discuss is and come to an agreement as to the best course of
action -- but you make it so that the decision ultimately rests with them. If
you do it right, they wind up doing what you want anyway (because you've
talked about it together, right?).

If they're highly competent, then that means they should be able to accomplish
the goal, so you don't want to necessarily override their decision. You're
demonstrating that you trust them, so you're letting them make the final call.

Contrast with the 4th group, where you basically say "Here's the problem, let
me know when it's solved" and don't even have to talk about anything at all.

That make sense?

------
matt_s
They might be bored. They might be in over their heads and see two co-workers
knocking stuff out and not want to appear like they don't know what they are
doing.

Do you have regular one on ones with them to shoot the breeze about what
they're working on? Find out what motivates them. Maybe they don't believe in
the work going on and think the lead/manager (aka you) is just giving them
busy work. Explain the broader picture of what their contributions mean to the
organization. Did they get "passed over" for the role you now have?

If you work in a big company, maybe they have seen where getting work done
quickly doesn't get them ahead. Maybe there isn't any room for them to grow.
What do they want to be when they grow up?

When assigning work, ask them about their approach to the task. Ask them to
ask their coworkers or bounce ideas off them. Maybe they think building VM's
will help with testing for future work.

You may not be their HR manager (hire, fire, raises, etc.) but talking with
them about non-task related stuff may enlighten you with how to better work
together.

------
acjohnson55
It's going to be a process, but you have to break down the problem, and attack
it piece by piece. I can identify a couple issues in your short description:

\- _Untimely completion of core tasks_. There may need to be more frequent
check-ins with more granular goals, along with accountability or at least
retrospection for missed checkpoints. If a checkpoint is missed, the dev and
you have to figure out the why of it and how the process can be improved in
the next iteration.

\- _Lack of resourcefulness /grit_. This can be taught. This is where it helps
to pair someone with a strong developer or yourself. As a teacher, we modeled
the learning process as I-do, we-do, you-do. It may be enlightening for an
unproductive dev to see better habits in action. But you can't just show a
skill and hope it will be replicated. You have to gradually shift more
responsibility to the other party to transfer the knowledge.

\- _Misspent time_. Not every subproject is useful for its own sake. Hold your
team members accountable for demonstrating the value of tangential work
beforehand, and put your foot down if you're not convinced. Everyone loves a
side-project, but it's not a substitute for progress on the core goals.

Most people want to improve, but everyone has some mixture of compentencies
where they will naturally self-improve and ones for which they will need
mentorship. This isn't the sort of thing where you can make one exasperated
speech and see overnight improvement. The goal should be gradual, consistent
increases in productivity.

And don't forget, since just became a team lead, _you_ also need guidance and
continuous feedback. Be proactive in seeking it. Good luck!

~~~
mreiland
> Not every subproject is useful for its own sake. Hold your team members
> accountable for demonstrating the value of tangential work beforehand, and
> put your foot down if you're not convinced. Everyone loves a side-project,
> but it's not a substitute for progress on the core goals.

Disagree with that. Sometimes they're working on improving things you don't
want to be improved and they should be.

As long as they're getting the work done, who cares what else they do.

~~~
acjohnson55
I'm not saying side projects aren't important. I do plenty of them. Maybe too
many. But as a team lead, you can't let everybody do their own thing willy
nilly all over the place.

My interpretation of the original post is that these side projects are
impeding scheduled work. That's not acceptable. Either a) this side project
work is crucial and team lead is deficient for not recognizing this or b) it's
not and the devs aren't being held accountable for the work the stakeholders
have prioritized. This discrepancy needs to be resolved.

------
kappaloris
Either you follow them more closely or let them go.

As a lead is your job to put them on the right track, so you should try to
understand their way of thinking and weak points.

If even after trying hard you still can't get them to perform properly, let
them go. It might be that they're too "scatterbrained" or that you weren't
able to find the right way to approach them, but, either way, if you've been
through, it doesn't really matter.

YMMV, but the point is: you're the one supposed to 'bend' more to make the
collaboration work. If you can't, you still should try to solve the situation
(for the sake of all parties involved, not only yours) by letting them go,
having them reassigned, or something else.

~~~
madez
There is a third option that is you leave.

It's arrogant and unfair to just consider the option to let them go if things
in the end don't work. It might be that another lead could make things work.

~~~
sosborn
> It might be that another lead could make things work.

It might also be that another developer would get the work done. Unfortunately
is it not easy to know which option is correct.

------
markbnj
You can debate different ways of applying management theory and practices, but
in the end there really are great differences in the ability of individuals to
think clearly and work toward a goal. I have worked with and led many
different kinds of programmers over the years, and I've run into this time and
again. Some people will accept a goal, dig into every relevant aspect of the
requirements, overcome the issues that arise, and create a solution that works
and is robust. You learn to trust these people and their judgement because
they produce good results. Others may have just as strong a grasp of syntax
and tools. They are "programmers" too, but they simply don't think clearly,
proceed logically, or arrive reliably at good solutions. This is always going
to be the case. If you want to build a world class team then one of the things
you need to do is identify the first type of person, rely on them more, and
try to duplicate them as often as necessary. You also identify the second type
of person and move them out. It may sound harsh, but you can't change the fact
that humans are different, and that some perform better than others. There is
a place for that person, but it doesn't have to be on your team.

------
thirdtruck
Let me emphasize the importance of patience and positive reinforcement.

I've worked with someone who had a reputation (previously unbeknownst to me)
of being terrible to work with and inadequate to the task. However, I both
enjoyed working with then and saw them make significant strides in
understanding in less than a year. What was the difference?

Multiple factors:

* I made a point of working with them until they understood the problem at hand (easier to do as a fellow developer than as a manager, though, I suspect). This had the side benefit of often increasing my own depth of explicit understanding.

* I would rewrite code that they found confusing until it made sense to them. I _also_ emphasized (sincerely) that their lack of understanding was an asset we could leverage to engineer more inherently clear code.

* Every bug of theirs was a learning opportunity.

* Praise for accomplishments, even small, was liberal.

All of the above might sound excessive and like "hand-holding," but it's
things that everyone needs. A lot of us just lucked into receiving such
reinforcement earlier in life, or were spared the negative reinforcement that
can only be undone with larger doses of the positive. The more you invest in
the "problem" developers now, the higher the dividends later.

Hoping that advice helps, and let me know if it does!

------
edw519
1\. Give direction with appropriate detail. Be prepared to give _very detailed
direction_ to junior people. I sometimes ever go as far as putting lines of
code right into the technical specs. Most technical leads hate to do this.
They say, "I might as well write it myself." That's because they look at it as
an expense. I consider it as an investment because people learn from it. This
should make things run much smoother. Important: the level of detail should
decrease over time. In fact, your junior person should start pushing back: "I
don't need that much detail anymore!" If this doesn't happen, then they're not
learning fast enough. This is not normal.

2\. You must have your finger on the pulse of everything going on all the
time. Not every little detail, but you must know where each project is, plus
or minus 10%. Don't let yourself lose track of anything; that's when problems
start.

3\. Reviews must be daily, not weekly. You don't need status meetings, emails,
or project updates, just one minute reviews. 3 day old problems are 2 days too
old.

4\. Peer review everything your people do until you're absolutely certain you
can let someone else do it. And even then, continue to peer review _something_
they do every week. You are responsible for their work; peer review is one of
the best ways to stay one top of it, insure quality, and teach. And always be
brutally honest with peer review, never bashful. Tell them what's not good
enough, what you want, and why. It may be uncomfortable at first, but it will
save everyone headaches later.

5\. Read "The One Minute Manager". Then do it.

6\. Be nice, have fun, and get shit done.

~~~
hyperpape
Regarding 1, I'll link to a comment downthread
([https://news.ycombinator.com/item?id=9009056](https://news.ycombinator.com/item?id=9009056)):
you're in tricky territory if you're giving direction that detailed.

Giving a level of guidance that's appropriate is good. Treating a junior dev
as incapable of working except as a puppet is soul-crushing.

~~~
edw519
Thanks for the interesting feedback, hyperpape. I agree that this is tricky,
or "delicate" as I prefer to call it.

What you cite is a classic example of academia vs. the real world. I am
currently responsible for 19 offshore programmers of varying skill levels and
work habits and this is _exactly_ how I've been handling their assignments for
5 years. I have gotten better results this way than any other technical lead I
know.

At first, they love the extra detail. Then over time, they push back. And
without exception, they all want to be in my group.

Grandparent was my own heavy experience getting great results with issues
similar to OP's. I know there are academic studies for just about everything,
but remember, it's my ass on the line if the work doesn't get done, not the
professors.

------
joedrew
Read this paper ("Set up to fail: How managers create their own poor
performers"):
[http://www.insead.edu/facultyresearch/research/doc.cfm?did=4...](http://www.insead.edu/facultyresearch/research/doc.cfm?did=46698)

The paper's basic tenet is that managers, by over-focusing on "poor
performers", actually cause their poor performance by interfering with their
work and putting them on performance improvement plans. Are there measurable
differences between these people and your high performers in terms of output,
or are you simply observing that to be so?

And listen to jonstewart. Being a manager is very different from being a
programmer. Be humble and introspective, and work on becoming better at your
craft.

------
jleonard
Setting up a vm may sound 'scatterbrained' to you but depending on the
complexity of the environment they might see it as an essential task.
Repeating what's been said: you need to consider that they are finding flaws
in your DevOps/Engineering practices.

~~~
eurekin
That was my immediate thought as well. I can see few scenarios which could
justify having the VM's. I'm also very wary about those "super productive" two
other guys. One should at least consider that they unwillingly make the
quality bad (and thus maintenance harder).

Unfortunately, some really bad technical solutions blow up very late.

~~~
mreiland
yep. dealing with one of those solutions now.

The guy who wrote it is "faster than me", no doubt. The difference is the
system I wrote for the company works and the system he rewrote is currently
being rewritten (by me) because we couldn't get it to work for more than day
without blowing up in some manner.

Maybe that isn't what's happening here, but speed isn't always the most
important goal.

------
ghettoCoder
As others have already stated, you're new. Most new managers try evaluating
staff using their own personal measuring stick. Doesn't work that way. Never
as, never will. Comparing others to what you believe your performance would be
leads to frustrations for all. I have two personal rules I apply to any
management situation.

1\. The circle of trust starts big and shrinks every time you fuck me. All of
my staff are aware of this. Aware of my expectations and it rarely requires a
personnel meeting. I don't micro-manage unless I'm forced into it by someone's
behaviour or performance.

2\. Managing a team of devs is no different than coaching a sports team. You
have varying levels of talent, ambition and inter-personal skills. The trick
is to find the best fit for "players" where they feel they're contributing and
others don't resent them for "messing up". Once you do that you can develop
them.

As a team lead it is your responsibility to your staff, and the company, to
develop those individuals. I guarantee treating staff like people instead of
widgets pays in the long run. With that being said, sometimes a team member
doesn't see acknowledge a lack of skill, etc... and they have to be let go.

------
brucehart
Develop a process that adds more openness and accountability. Hold a 15 minute
daily standup meeting where each developer shares what they accomplished the
previous day and what they plan on accomplish that day. Spend some time
creating very distinct tasks for each developer that are 2-4 hours long. Tell
the developers which tasks you expect to get completed that day and not to get
sidetracked. They are providing the engine power, but you are steering the
boat.

Many developers get sidetracked because they are afraid to confront the fact
that they don't know how to do something. Make it clear that it's okay not to
know something but it's not okay to just avoid a task in front of them. Find
roles for them where they can excel. Imagine being a coach of a basketball
team. Some players are good shooters while others might be good at defense and
rebounding. It's up to you to find these strengths and use them together. A
fast developer may get excited about doing new development but hate doing
things they consider grudge work. These slower developers might like doing
work like testing and documentation (and actually be better at it).

~~~
mattmanser
Daily standups, especially with 2-4 hour long "tasks you expect to get
completed that day" is simply thinly disguised micro-management. It is the
antithesis of all the advice on how to make people more productive and
excellent at their jobs, which is to make them autonomous. Sounds like a
nightmare environment.

~~~
brucehart
Some people work better with daily accountability and need help breaking up
tasks so they don't get overwhelmed. I worked for a boss that managed this way
and no one felt micromanaged. Having clear objectives and giving a 1-2 minute
daily verbal update didn't seem like a "nightmare environment" at all.

We had some members on our team that were similar to those the poster is
describing. For those the team lead was more explicit about setting tasks and
for others he gave more autonomy. The daily standups were a chance to discover
what's holding people back from making the progress needed to complete larger
team goals on time. I was also skeptical of the process when I started the
job, but it actually works very well.

------
gokhan
A week is a long time for feedback loop, especially for juniors (assuming the
two lagging are juniors). Scrum's daily standup meeting is a nice way to
shorten the feedback loop and eliminate blockers. A similar meeting in your
schedule, even if you don't implement Scrum, might be helpful.

You may try pair programming. Might decrease productivity but increase
quality. Or you can find another way of getting help from the two good guys
like you on keeping an eye on them.

Whatever you do, a team of five is quite small. Just keep close to your team,
move to a single room together, share a long desk with them etc. You may also
want to divide work into smaller chunks so you can keep a better and timely
track.

------
cronin101
Pair the "junior" developers with the ones that you are more happy with and
have them learn productive habits through collaboration and observation?

~~~
DanBC
Kill the productivity of the good workers?

EDIT: People mention the need for continuous development. That's lovely, but
it's wrong to think that putting unproductive workers with productive workers
will somehow transform the productive workers into effective trainers or help
the unproductive workers become productive.

What you've done in added distraction to your productive worker's flow. It's
not their role to train other staff and they are possibly going to resent this
new -unpaid- addition to their workload.

~~~
johnatwork
It's a long term investment. Of course the worst case scenario is that the
developers leave afterwards.

~~~
sarciszewski
If you train them, the risk is that they leave. If you don't, the risk is that
they stay.

------
UK-AL
They might have different values, maybe they come from environment where they
do everything by the book, and "correctly"?

Your environment is get things out the door fast sort of environment? Doesn't
mean their bad, just different values.

Should have worked out their values at interview stage.

In a different company they could be the stars, and your the guy close to
being fired.

~~~
quonn
I don't like how you reduce a possible difference in efficiency to different
"values". Like in all other jobs, some developers are less efficient. The OP
asked for advice how to _manage_ them, not how to fire them, so there's no
need to defend someone you don't even know. He wants to work with the people
he has and the situation he is in, not be told how these guys should not have
been hired or that they supposedly have different values.

~~~
UK-AL
Its not efficiency its a trade off.

If your writing tests, setting up environments, and writing specs, your going
to be slower than developers who just codes by the edge of his seat.

If you writing software thats needs to be correct, or maintained for many
years, you might value that.

If you writing a quick prototype, you won't.

This is why star performers at one company, turn out to be duds in another and
vice versa. Its quite a common thing. Switching companies can be a culture
shock.

I like being a contrarian, because I force people outside of their preset
view, and to see it from other side.

How many times do i see bosses calling their employees lazy, making then work
over time? Yet whens its their kids, or wife having to work over time or being
heavily worked, so they never see them, they think differently. A different
viewing angle, thats why.

~~~
beachstartup
> This is why star performers at one company, turn out to be duds in another
> and vice versa

in my experience this is nonsense. a good developer will be able to produce
anywhere except _the_ most fucked up of workplaces. if they can't, then
they're not good.

in fact, this is a moot point, because good developers don't stick around to
try to produce work in fucked up companies.

and a bad developer is going to suck no matter what. it's not a question of
finding the magical company for him to magically become good at.

~~~
_delirium
In my experience this isn't the case at all. There might be some developers
who are good everywhere, but most excel in a subset of all possible
roles/cultures. For example compare the environment of a "ship it now" web
startup to that of an engineering company focused on safety and product
support cycles. Some people can do well in both, but many programmers used to
one environment will be frustrated and less effective in the other one, at
least without quite some time to adjust.

------
brudgers
Forget about focusing on what people can't do effectively and focus on what
they can _and_ will do effectively. Then work your ass off to make them even
more effective.

Recognize that you're new to management. As a new manager the overwhelming
odds are that you suck at it in ways that make the dictionary definition of
"suck" say, "No really bro, that's not me."

Nothing personal. And even if I am totally incorrect and you are the
immaculately conceived management prodigy, the best attitude you can have is
that you totally suck and that the team goes home after work and tells their
spouse dogs children and parents about the idiocy they deal with because of
you.

If people are coming back a week later and demonstrating that they didn't
understand last week's conversation that's an indication of less than
effective communication on your part. [1] Never mind getting people to do what
needs to be done, they're not even getting the what of it. A lost week means
you haven't followed up.

To put it another way, how you would do it doesn't matter. You're just another
snowflake. What matters is getting it done in the ways the people who you want
to get it done will do it.

Favoring your doppelgangers means that other people's diversity prohibits them
from ever being any good as far as you're concerned. You're the new boss and
you're broadcasting closed mindedness. To the degree it's about who will tow
the line and who won't.

It happens all the time. The PHB is a latent talent in everyone.

Good luck.

[1] And very effective communication to. You are effective at communicating "I
don't think you are very good." And It flows as naturally as the title of this
Ask HN. It's disrespectful and counterproductive.

------
qvikr
Your definition of "good" and "bad" is probably off tangent. As a manager, you
take up a new role of being the "coach". It's your job to help your team play
at the best performance they possibly can.

Letting go of someone is the simplest thing anyone can do... but if you look
back at your own career, chances are you'll find more than a couple of
instances when your peers put up, tolerated, and coached you to where you are
today - just don't close the doors you walked through.

~~~
smackfu
Yeah, if "good" means they manage themselves, and "bad" means he has to work
at managing, that's not a great expectation.

------
moron4hire
Fire them. If you don't have the authority to fire them, tell the person who
does have the authority that you can't use them. Quit wasting your time on bad
employees. Bad employees don't just fail to get work done, they make more work
for everyone else. They are _negatively_ productive.

~~~
slantyyz
>> Quit wasting your time on bad employees.

It isn't just time. It's money. When you work for a company with a lot of
money, it's quite easy to lose sight how much money gets burned on bad
employees.

Also, people who are working with what they perceive as bad employees who are
basically making the same money as them get demotivated, so keeping them
around is risky for morale.

Having said that, managers should make the effort to know if people are
genuinely bad or an ill-fit culture-wise before firing.

------
DanBC
You introduce regular feedback. During those feedback sessions you tell them
that you noticed they sometimes repeat questions, and ask them if there's
something you need to do differently to help them. Or you just tell them that
they lack focus and that they need to knuckle-down.

You also introduce targets for them to achieve. Tell them what you want them
to do, and ask them to focus on which-ever bit you think they need to focus
on.

------
leading_who_
This could be a problem of communicating expectations and a poor feedback loop
from you.

Do they know that you aren't happy with their performance? How early in the
process do you catch it and correct the action? It doesn't sound like it's
very early at all if it's a week later and they are coming back at with the
same questions.

I'm not saying to micro manage or even tell them that they are poor employees
-- I believe both approaches lead to hostile work environments. The best
managers I ever had largely followed the principles laid out in How to Win
Friends and Influence People, and now that I'm transitioning to leading small
teams I find that approach leads to far better results than the alternative.

------
icedchai
This is normal.

I managed to fix this by getting a new job where I didn't have to manage. ;)

~~~
lafar6502
Heh, i'm in similar situation and considering such a solution. I have two
quite poor and messy programmers, but they have been with the company since
the beginning and probably nobody will consider letting them go. Besides, i'm
not really interested in firing anybody - would prefer to concentrate on
cooperation and getting the work done as a team. But with such people i can't
guarantee anything will be done on time, and they tend to keep themselves busy
just trying to fix the mess they created so far (and inevitably creating some
more mess in the process). Sometimes i can't stop thinking the project is
doomed and i can't really do anything about it.

------
gumby
Many years ago I was given a great explanation of (good) management: "the
purpose of a manager is to eliminate uncertainty". Clearly for the good
programmers you can do so: "we need to drain this swamp".

The less good programmers probably don't know how to evaluate what's important
and so waste time. For them you'll need to dive down one level: "we need to
drain this swamp, so go evaluate pumps and if you find one with X
liters/minute for less than $Y, go install it on the north side." For the
other you might need even more detail. Part of the art is picking the right
level of detail so you aren't wasting a lot of time and so hopefully the
recipient can learn from it.

If you have to dive down TOO low you have the wrong people.

And your managers: I hope they are eliminating uncertainty too: We need to get
rid of the "mosquitos so get this swamp drained by the end of the month. You
have $Z to spend on it."

------
bonn1
Most of answers here focus around management as a general topic and ways to
handle the two weaker devs. Nobody recommends to fire them. I am also not
giving this advice because I am not aware about the entire company and team
situation and can't oversee all implications. And maybe _you_ might be the
problem for the two weaker devs.

I just know that the most important management skill is 1) to make the
decision to fire somebody and to do this not too late and 2) then to execute
it smooth and fast. And most managers are neither good at 1 or at 2 because of
lacking practice.

It's a though decision, it doesn't feel good to fire somebody and often
managers ask themselves if they made mistakes in their leadership.

But if you say that you just don't feel good how they do their work and if you
don't see any potential for improvement then why don't you spend the budget
for better engineers?

~~~
sukilot
Presumably if OP could find better engineers, he would. In the mean time,
_make_ better developers.

------
estava
Maybe you need to pick your battles. Your question reminded me of this video:
John Maxwell The 5 Levels of Leadership
[https://www.youtube.com/watch?v=aPwXeg8ThWI](https://www.youtube.com/watch?v=aPwXeg8ThWI)

See also this oldie article: Don't Let Architecture Astronauts Scare You
[http://www.joelonsoftware.com/articles/fog0000000018.html](http://www.joelonsoftware.com/articles/fog0000000018.html)

Sometimes people have good ideas that may be a little overkill for your
project. Running a VM could help with creating test environments. Although
there may be alternatives to that. So maybe they just want to test more. Maybe
they are more QA types.

Try to understand where they are coming from and give them some guidance. :-)

Cheers.

~~~
th3iedkid
i once worked with a remote(with a 12+hour time-difference) team and i was the
least experienced(both effectively and in the code base) in the team. It was
hard for me to both learn and work in that constraint and both of us found it
difficult to continue for a brief period.But then after a while we knew the
intersection of my strengths with what the project needed.Until that phase , i
would often digress on things , esp Unit-tests .I was often singled out for
focus(in those tough times) but these eventually played out as good learning
points for me in the long run as i mastered their system that way.The manager
understood my strengths early on and today we both are happy we went that
path.

------
jules
Before you can solve this issue you need to figure out _why_ they are doing
this. Here are three example possibilities:

1\. Maybe they are not in the mindset of getting to the goal, but rather they
are in the mindset that work is work. Or maybe they are doing it simply
because it's a habit or because it's fashionable and they heard some celebrity
say you should use a VM. Then explain to them that not all work is equal, and
that it's important to do work that moves you in the direction of the goal,
rather than busywork that will not pay off such as setting up a VM
envirnoment.

2\. Maybe they actually think that setting up a VM environment is worth it in
the long term. If you don't think that is the case, explain why.

3\. Maybe they don't know how to solve the problems that they are tasked to
solve, and setting up elaborate dev environments is a way to procrastinate.
Then make sure that they have enough guidance so that they know what concrete
bit of work they can do _right now_ to make actual progress. Ex: if they don't
know how to make progress because they do not understand the database schema,
then the next step should be to familiarize themselves with the database
schema. You could even task them with writing documentation for the database
schema to get this started. Or perhaps they procrastinate because they don't
like the work that is assigned to them.

There could be many other reasons, but once you figure out _why_ they are
doing this, it's likely that the solution will be relatively obvious. Try to
not fall into the trap of micromanaging them. If you don't understand why they
are doing this you could simply instruct them not to set up a VM dev
environment. That won't solve anything in the long term because they will just
find something else. It's much better if they know _why_ they should do or
should not do a that, rather than simply following orders. Following orders
kills motivation and orders don't generalize to new situations, but the right
mindset does.

On the other hand, in some cases the issue isn't that a developer is not doing
the right kind of work, but rather that the developer is doing the right kind
of work but he is simply not very good at it. This can be improved to some
degree with training but you have to make a business trade off here: is this
developer making a net positive contribution to the business or not. Keep in
mind that a developer does not have to be super productive in order to make a
positive contribution. Otherwise it's time to move him to a different role or
fire him.

------
endeavor
This might be totally obvious to you, but it wasn't obvious to some junior
managers that I manage. When you're an entry-level programmer and you get
stuck on a tough programming problem for a while, you're supposed to go to
your boss/lead for help. Now that you're an entry-level manager, don't feel
like you have to solve this on your own. Go to your manager for help. They
should have more experience dealing with this.

I think smart, experienced engineers who have been figuring everything out on
their own for a while start a totally new role, then forget how to ask for
help when needed.

------
eurekin
Hey, I won't add anything relevant to the discussion.

Only wanted to say, that I've learned a lot from the answers presented here...
Some of them made me really upset (as in my blood boiled), because I
recognized some patterns as ones used by my old managers. The "make them do
estimates" and "Make the penalty for missing their own deadline big" part is
what I immediately recognized as the most often occurring one.

Nevertheless, there are some very fine tips which I will try to use in my
personal time & task management. I see immediate benefits, even tough I have
nothing to do with management role at all.

Thanks!

------
sukilot
I bet you'll get great advice about making employees more productive, from
people slacking off on HN on a work day.

~~~
brational
If my boss would just let me devote 3 hours a week to whatever I want then I
would never checked HN the other 37...

------
Panamfrank
Daily development logs can replace alot of the what have you done? What are
you struggling on? conversations that happen in standups. Given that
development can be very reductive and introspective having to retell the
problem post-fact when your understanding isn't fully formed is a major
challenge for some. Create a shared Google drive folder and give each dev a
log to prepend what they're doing each day as they do it. Then review and
discuss solutions adhoc or in the stand-up.

------
throwawayx
The reality is that you need to micromanage the shitty ones. They need to be
kept on track so that they were productive.

I'm a lead as well and one of our developers is a smart but scatterbrained
programmer. She is a mess in terms of running a project and communicating with
the rest of the company but if I give her a specific task, she does well.

So what I did was insert myself in any meeting she was a part of, and talked
with her several times a day to check in. When I see her going off course in a
meeting, I will correct it, and if she says anything incomprehensible in a
meeting, I will translate for the others.

The good thing about this programmer is that she really wants to improve, so I
give her very frank feedback. The feedbsck I orovide is along the lines of
"you need to increase people's confidence in you, because right now it is low,
we don't know if you can run a project on your own". She has gotten much
better and a lot more productive, which I honestly believe is due to me. I
don't take any credit for the work she does, and I constantly praise her in
front of others, but I do know that without my micromanagement, she would not
be nearly as productive as she is right now.

If her productivity didn't imorove with my micromanagement, I would have fired
her because the last thing we need is a drag on the team due to an
unproductive member.

------
Thetawaves
Firstly, I would be hesitant to label these developers 'scatterbrained'
because you simply can not follow their thought pattern. I am likely to place
blame with you if you can not understand the value in tangential tasks. This
shouldn't really be an issue anyway because you should be in a position to
veto efforts you deem unnecessary.

Secondly, I see a bunch of people suggesting you micromanage these people and
I must advise you that nothing good can come from this. You need speak with
and make your self available to people daily or several times a day but you
MUST give them space to accomplish something on their own.

Thirdly, you must set expectations and required outcomes. You can only set
expectations if you know the clear path from A to Z and if that isn't the
case, you need to trust your employees when deadlines slip. You need to manage
the expectations of your customers so that there is a wide buffer between when
you expect employees to get it done, and when you expect to deliver to your
customers.

Your inefficient employees aren't dumb. They know their peers are
outperforming them. It is your job to provide a safe stable work environment
where employees can relax when there is a lul, and strive for greatness when
there is a deadline. You can not work your employees to death.

------
wallflower
I constantly like this comment from an AskHN from jlcfly from a while ago. I
hope most of us embrace this philosophy as the reality is programming as an
art is much more important than programming as a rote skill. And teaching
programming as an art is much more about understanding the individual than it
is about teaching them like a soldier (Andersen Consulting bootcamps - are an
outlier).

"Teach them to be better than you. That may seem counterproductive. I have a
type A personality, and I have decent coding skills. I've been in your
situation a number of times. I also know there's these mythical expert
developers out there that I can't seem to find (or afford). So, what to do? A
few years ago I realized that if I continue down this path, I'll end up with
some serious health issues due to the stresses that come along with having a
reputation for being a really good developer.

So, I decided that instead of searching for developers better than me, I would
teach developers I work with how to BE better. It's taken a lot of patience.
And it's taken me quite a bit to LET GO of my way of doing things. I had to
take my ego out of the picture. (VERY hard to do.)

Nowadays, I realize that developers don't have to BE better than me. I simply
have to ALLOW them to do what they do without being so obsessive about it.
Turns out, even junior developers really CAN do good work. They just need a
little guidance that only comes with experience, and then they need me to get
out of their way."

[https://news.ycombinator.com/item?id=8649415](https://news.ycombinator.com/item?id=8649415)

------
Simp
The link lifebeyondlife submitted is actually quite a good read:

Set up to fail: How bosses create their own poor performers
[http://www.insead.edu/facultyresearch/research/doc.cfm?did=4...](http://www.insead.edu/facultyresearch/research/doc.cfm?did=46698)

"I like how it describes the negatively reinforcing cycle of closer scrunity
which results in worse performance etc. " -lifebeyondlife

------
ap22213
I recommend looking at it as a system problem. Think of your team as a whole
body. Your job as the 'head' is to achieve the high-level goals. You make the
best use of your team when they work together to multiply the effects of the
others. Then, you achieve your goals more efficiently.

They're all individuals with their own interests, motivations, self-purpose.
You have to understand who each of them are and how they all work together.
Then, you must question if the issues are innate or only symptoms of something
else.

Most likely (since they're hired and not fired) they're all able. So, are they
bored, burned out, tired? Are they not being rewarded for their work? Do they
not understand the high-level goals? Are you micromanaging? Do they not
understand their roles? Roles are important - it must be completely clear that
they have a singular set of roles and responsibilities.

Sometimes it's ok to have inefficiencies with one or more staff if it benefits
the whole system. For instance, I kept a guy on my team simply because he was
funny. He made the other teammates laugh and have a good time.

------
fsk
You aren't someone's bosd if you don't have authority to fire them.

I've dealt with people like that. You explain something to them 5 times and
they still don't get it. Some people just don't have the talent. The previous
lead probably didn't notice or care.

Did you speak with your bosses about replacing them?

Even if the team lead is just being narrowminded, those two devs would be
better off working with someone else.

------
bane
It's ultimately about making them make the right decisions, and building up a
non-broken mental model of how to do things. Lots of their actions are likely
just from ignorance of alternatives, but it could also just be a broken
decision making process.

The idea is to make them part of their own reformation:

\- Don't set deadlines, make them set deadlines, document it, then hold them
to it. Make the penalty for missing their own deadline big. Because you've
documented it, if they make a pattern of missing their deadlines, work with
them on learning to better gauge and estimate their level of effort. Review
the cases where they miss the deadline, find out why, build up a pattern. It
could be they just don't understand how some library works, or how the build
tools work etc. It could be an external dependency they have no control over.
Either data-point gives you tools to help them learn how to do this most basic
of tasks.

\- If you tell them something once, and they come back again, the second time
make them write it down in a binder of notes, if they come back again, make
them refer to their own notes. If they come back yet again, make them do a
full report on the topic, put it on an internal wiki, and treat it like a High
School writing assignment. It sucks for them so they'll never want to do that
again, but it produces useful information for other people.

\- Don't tell them what to do. But make them describe their strategy to tackle
the task. When it sounds like they're doing something wrongheaded, ask them
why they're doing it that way instead of the obviously better way. Maybe they
have a good reason, maybe it's out of ignorance. Take it as an opportunity to
make better ways available to them. But the decision for which way to go is up
to them, so long as they hit their self-imposed deadline.

~~~
jnbiche
> Don't set deadlines, make them set deadlines, document it, then hold them to
> it. Make the penalty for missing their own deadline big.

Software time estimates are a legendarily hard problem. Experienced developers
get better at it, but still _frequently_ miss deadlines, often by large
margins. And you're somehow not only expecting beginner-intermediate
programmers to be able to set accurate estimates, but enact "big" penalties if
they miss them?

And if your argument is that these are small tasks, and they should be able to
figure out estimates for them, then I'd point you to the all the studies on
software estimations that suggest that major project overruns are usually not
due to lots of little tasks being 20% or 30% late, but rather on 1 or 2 tasks
on the critical path being 1000% late. We're all familiar with this problem.
If you've been programming long enough you've run into quite a few of these
"gotcha" tasks, not matter how good you are.

I think your other ideas are very good. Actually, I'd take some of the ideas
from your last two points, and apply to the first. Instead of penalizing the
developer for overruns, have them write up brief case studies that outline why
there was an overrun, and put it on the company wiki. I think having to write
up a case study is probably an appropriate "penalty" for something that may
have been out of their control (although I really wouldn't suggest portraying
this activity as punishment, but rather as a critical response to overruns).

But "big" penalties for missed deadlines is just pointy-hair boss territory.
Given the quality of your other advice, I have to believe you weren't
referring to an actual big penalty, like docking pay or missing a promotion.

~~~
bane
Sorry yeah, I communicated that poorly. "big penalties" is meant to mean
exactly what you wrote. Spend some time studying why they went over and do a
write-up on it.

I've found most developers hate documentation more than anything, and making
them do work like this is a "big penalty".

I agree that software estimation is hard, but that's usually at the macro-
level. Micro-level estimation, within a few percent is usually pretty
reliable. What happens at the macro level is that those tiny percent
uncertainties compound up and interact in all sorts of horrible ways.

But "do you think you can build the database connector and load the data by
next Friday?" is not too hard of a problem, even at the junior level.

I think more importantly, if they come back and it's not done, but it's not
their fault, they'll get comfortable coming to give you bad news, which is
super-critical for macro-planning.

------
protonfish
No group of developers will ever be all at the exact same level of
performance, there is no reason to freak out. Demanding that everyone work in
the exact same way as you will probably do more harm than good. The important
thing is how your team functions overall. Get to know the strengths and
weaknesses of your team so you can better assign tasks and responsibilities.

------
rglover
Don't look at them as incompetent, look at them as needing to be taught how to
do it correctly. As their leader, it's your responsibility to give them the
resources (and environment) to learn what they need to do. What's more, it's
also important to give them a process to follow. If you don't explicitly state
your process and give them a means for learning and following it, you'll
always be disappointed.

Accept that developers are a diverse set, mostly self-taught, and all have
varying degrees of expertise. In order to find the people you'd like, sit down
and define what an "ideal developer" looks like (irrespective of whether
you're actively hiring). That way you can either hire people that match that
description, or work to build up your existing team to match that.

It sounds like your first step is to document your process and to educate your
development team on how to do things "your way," and _why_ you do it that way.

------
kyled
Have them create a todo list. Make them write it down.

I was like them. I've been programming for over 15 years. I started when I was
a kid. When I started programming as a profession, I kept the same habits I
had when I was doing it for fun. Ie, find hard new stuff I've never done and
learn how to do it! I was inventing new problems to solve because I enjoyed
learning new things. Unfortunately this isn't a good model for generating
money for a smaller company, you don't yet a lot done if you keep task jumping
around. When I started to make a list of things to do I could refer to it and
ask myself If the task I Wanted to work on was actually necessary.

Also, don't overload them with stuff to do. Before I if someone had a request
for a change I would switch in the middle of a task and try and complete it.
This goes back to the todo list, you learn to focus on one thing at a time.

------
zpool
Your application has huge untested areas, which standard testing techniques
can not adequately cover. You need integration tests, and you need to be able
to run them locally so as not to trip up testers. In short you need a VM,
since some of the dependencies can not be installed on your host OS.

When you are repeatedly asked the same question, ask yourself why? It is
probably because you failed to answer adequately the question that was asked.

If they have less domain knowledge, they will be slower on technical tasks
regardless of ability.

You as the lead should be providing the information your developers need to
get the job down. Sounds to me like you are acting like and egotistical
developer IC, rather than a team lead. You could probably find a way to help
them if you tried...

------
dugfresh
Is it just me or are there a lot of excuses made for these two developers? In
every profession you have to do what your boss tells you. If you don't know
how to do it you should speak to someone - a peer if not your boss. If you
don't want to do your job (pass over for a promotion, the work is
uninteresting, etc) then TS! It's irresponsible to slack off because you don't
like some aspect of your job or work. If you're paid to do a job, then you
should do it. These developers have the luxury of finding another job because
the market is so red hot. A lot of other professions don't have this luxury.

~~~
sukilot
Good management means developing talent. As you say, the market is hot, so
managers can't sit around hoping a pile of perfect professionals show up at
their door. If you hire people cheap and teach them, you spend way less than
you would by recruiting superstars.

------
cubano
It is quite possible that they are simply milking the job and really don't
know how to complete the tasks you are giving them, and default to "hey, let's
set up a unnecessary vm because we know how to do that easily and it will show
we are not slacking" or something of that sort.

Or perhaps not; idk...no one here can, but it is your job to figure it out,
quick. Use the same tenacity you showed as a developer to start learning
management.

The daily stand-ups are a no brainer...accountability and progress need to be
applied and shown, respectively, with consequences attached, unless you are
happy to let things ride along as they are currently.

------
tenpoundhammer
I have had this exact same problem, I mean exactly the same. I found out a few
things:

1\. It takes time, be patient

2\. Get under people and push them up. Instead of standing over them and
pulling them up. What's the difference ? In the first you are saying "I'm not
too good too grab someones foot and boost them up", in the second you are
saying " I have arrived now I'm going to drag up to my level of greatness".

3\. Sometimes people are distracted and slow because they are a square peg
being jammed into a round hole. Not every programmer thrives in the same
environment, you have to tailor your management and help style for each
individual.

------
jpswade
Letting them have free reign to solve a problem clearly isn't working for you.

It sounds like you need to manage them by breaking their tasks down into more
bite sized chunks if you don't want them to go off task.

------
ScotterC
Introduce them to Pomodoro techniques [1]. I've seen this same problem with
junior devs and they're not fully aware of it themselves. When you get them to
track themselves using a tool like Vitamin-R [2], they'll be more aware of it
and also want to fix it.

1\.
[http://en.wikipedia.org/wiki/Pomodoro_Technique](http://en.wikipedia.org/wiki/Pomodoro_Technique)

2\.
[http://www.publicspace.net/Vitamin-R/](http://www.publicspace.net/Vitamin-R/)

------
vpeters25
Maybe you could try an agile approach where instead of assigning tasks you put
them in a board and allow each team member pick the one they like to do.

Our experience is this makes each team member pick tasks that fit their
strengths, or challenge themselves. You, as a team lead, can leave them along
to handle it. They will ask for help, or mention they are stuck in the daily
stand-up.

EDIT: I guess I didn't need to be that blunt, thanks downvoters for pointing
that out.

~~~
emodendroket
So what do you do about the perma-tasks that are on the board forever because
no one wants them?

~~~
vpeters25
There are many ways to deal with that if it becomes an issue.

One way that has worked well for us is to nominate a rotating "support guy"
who handles the interruptions, attend meetings, etc.

------
unfamiliar
I'm one of those "scatterbrained" people. Whatever I'm doing always seems
important when I start it, but then I end up spending ages on it and once it's
done I can't really remember why I did it. The end of the week comes and I'm
exhausted and have to make up excuses about my poor performance.

How can I stop this behaviour? It's like I'm not in control, I just get
carried along by the current.

~~~
jmagoon
Personally I (and a few others on my team) have found mindfulness meditation
to be enormously helpful in developing focus and not being 'carried along' by
thoughts. It's really helpful to observe your thoughts, which begins to allow
you to classify, organize, and prioritize them. They become a toolset rather
than a slavedriver. My manager started relatively recently and the difference
has already been very noticeable in true productivity, not just excitability
without any real traction.

------
TeeWEE
Firstly, asses the skills of the developers. If they are not on the skill
level you demand of them (as junior), then you should think why they are
hired. If they are on the right skill level, you should ensure to find the
reasons why they are stalled.

One big problem of big companies, is hiring developers who actually cant even
write a simple algorithm. Cranck up your hiring process to ensure only the
good developers are hired.

------
mjv
How can anyone say anything definitive from this little information? Some
manager dislikes a few of his employees. Scatterbrained appearances can be
indicative of so many things: a poor work environment, terrible communication,
lack of culture, or no team gelling. There's also just people unqualified for
their job, but a 50% miss rate in hiring? That sounds unlikely. Or like your
biggest problem.

------
rbosinger
Maybe you can somehow make them envious and inspired by how much work the
other two developers are getting done. I've never managed developers myself
but as a more senior developer I have definitely inspired junior ones to want
to step up their game. It seemed to work well for the most part.

------
agounaris
I tend to say there are no bad developers...only devs with no motivation. It's
not only you who have to do something. Do they like the product? Do they enjoy
the tools they/you use? Are they happy with the compensation? There are a lot
of such questions you as a lead must figure out.

------
vishalzone2002
Actually,you are in an ideal situation. Encourage the better developers to
spend time mentoring the other developers. Developers appreciate managers who
help them getting better. Work on actionable and measurable goals for the
developers to improve. I am pretty sure they will catch up. ATB

------
ProAm
This is the sole reason why I have turned down every management and team lead
position I have been offered. I have no idea how I'd deal with or handle
people who work slow, or output what I would deem as low quality. Management
is tough.

------
PaulHoule
Development environments should be a team function.

It makes sense to use virtualization, but you should also have a standard
build that uses tools like Vagrant.

If a developer has to spend more than an hour to set up a development your
process is broken by modern standards.

------
spot
give the weaker developers tasks in smaller chunks. instead of just a goal,
give them each step of the way. meet with them every day, or even twice a day,
to confirm they are on the program and to answer any questions they have.

------
jackgavigan
How about pairing the the "other two" developers with the two first two
(deliberately avoiding being judgemental here) with the aim of getting the
other two to learn from the first two?

------
franze
that book is a good starting point [https://pragprog.com/book/rdbcd/behind-
closed-doors](https://pragprog.com/book/rdbcd/behind-closed-doors)

------
reacweb
Some developers have difficulties with environment or novelties, but are not
so bad for routine tasks. If you can not fire him, you can try to give him
simpler tasks.

------
musgrove
Team each one up with the producing, independent ones. See what they think. If
it's a matter of anything other than needing to be more challenged, replace
them.

------
kyllo
Go read Peopleware and then come back to this thread.

------
kendallpark
I guess I thought I put my two cents in as a smart but "scatterbrained" type
of programmer. Prioritizing and focus has been my private war during my
programming career. Here are some points I'd like to make.

1\. Concrete, quantifiable goals. The first time I really ran into a wall with
my issues prioritizing was during summer CS research after my sophomore year
of college. I was given vague tasks that were basically "make the program
better." This doesn't help someone that is prone to tangents. In the process
of working on some part of the program I might discover a new thing that
needed fixing, switch to working on that, and then down the crazy refactor
rabbit hole.

2\. Deadlines. Deadlines help a lot (as annoying as they are). I always did
well in school because of deadlines. At my work we have a goal of completing
X% of Q1's weekly sprints on time. It's a team goal, so if I don't get my
tasks finished for the week, the whole team doesn't get clear the sprint for
that week. I find the team aspect helpful. It also facilitates communication
between team members. People that finish early often look at the sprint and
check on members that aren't done yet, offering assistance.

3\. Boredom. Boredom is a real issue for me. I do better on harder tasks than
easy ones because they're interesting. This isn't something I think a manager
can solve because I think it's on the programmer's end to learn how to do work
when it's less-than-engaging. But you might find some of your scatterbrained
programmers actually tackle hard problems better than easy ones. It really
depends on the programmer.

4\. Communication. I was pretty upfront with my manager about prioritization
and focus issues. It's something we discuss every time we have a one-on-one
meeting. How things are going, what strategies I'm using, etc. He's also great
at pruning down my conceptions of tasks. I'll read a task and think, "Oh I
need to get X, Y, and Z done" and he'll say, "No, you just need X, the task
doesn't actually call for Y and Z."

5\. The optimization struggle. This is probably the single largest
contributing factor to my prioritization issues. I don't like doing things a
way, I like doing them The Best Way. A lot of time is spent figuring out which
way is The Best Way. I might waste several hours working out a linear time
solution to something I could easily write polynomially all the while n is
small and it doesn't really matter. Inelegant code bothers the hell out of me
so I might start a small refactor which snowballs into a larger and larger
refactor. This is something that your programmers will have to get a grip on--
saying no to refactors in order to better focus on a task. But as a manager
you can help by watching out for tangental refactors and putting a stop to
them.

~~~
RogerL
This is by far the best comment on the page; too bad it is so far down. It is
very specific, mirrors what I have seen with 'scatterbrained' programmers, and
maps out how to improve the situation.

~~~
kendallpark
Thank you! Didn't get to posting it until later on because I had to focus on
finishing up a ticket. ;)

------
codecrazy
Fire the two losers and ask the two good ones for friend references. Time is
too valuable to have to deal with unqualified help.

------
codecrazy
Fire the two losers and get resumes of the two good developers' friends. Time
is too precious to deal with poor help.

------
mariusz79
Well, maybe it's not that they aren't very good but that you suck as a team
leader? :)

------
IgorPartola
Congratulations and condolences. You are about to embark on a journey that is
fraught with frustrating experiences. Having done something similar, here's
what I can tell you, though I consider my experience at best a mixed success.

First, focus on fundamentals. Spend time with the guys who are having trouble
getting stuff done. Pair program with them, letting them drive. Or pair them
up with one of the people who do work well.

Second, create effort estimates. No, really. Sit down and have these guys
explain to you what they will do and estimate the amount of time. Tally it up
as you go, then double it, telling them you want a margin of error (make sure
to double it again when speaking to your boss, but don't tell the developers
that). Encourage them to speak with you immediately if they run into problems
that will derail the estimate. This exercise will help a lot in terms of
getting them to understand what they really should be doing.

Third, don't be a micromanager. Assign a task, support them and check in
periodically, but don't push them to do things a certain way. I am really not
a fan of the standing morning meeting. Instead, talk to them individually for
5 minutes every morning. It's more of a pain, but it's less stressful on them,
which is good. At the same time, encourage them to talk to each other and do
have an occasional team meeting (a quick one) explaining where you are
heading.

Fourth, forget about programming. Sadly, you won't have time for it. With a
team this size, you might still have some time, but it's best to lower your
expectations dramatically. You'll be doing quite a bit more thrashing between
different tasks aimed at supporting your team. You know work for them, and
your job is to keep them focused and productive. This really means two things:
(a) don't take on large or important projects or projects with major
deadlines, and (b) don't seize control of the system architecture. Why?
Because you won't have time for it, and will block the rest of the team while
you do the research.

Fifth, and this is somewhat in conflict with #4, the buck stops with you.
Example: my team wanted to switch from using Django's built-in template system
for Jinja2 without any real need to do so (we made very light use of the
templates anyways; their argument was more of a preference). I listened, but
ultimately said no. We had much bigger fish to fry, and this would have been a
costly distraction with no upside. This was not a popular move, but the issue
was let go after a few weeks.

Sixth, be honest with everyone about how things are going. If the devs are not
pulling their weight, encourage them to get better. Offer help, guidance, etc.
If they don't improve, consider letting them go. If you are a team lead,
chances are you don't have that power, but surely your boss will want to know
that the company is paying good money to the people who don't do the work
required.

Lastly, remember, as the lead, it's your job to move the furniture out of the
way for your team to get shit done. Your priorities have shifted, and now you
are in a different role. The sooner you adapt to that mode, the better.

P.S.: Take vacations, and often. Burnout sets in twice as fast for team leads.

------
cphoover
fire them?

~~~
spacecowboy_lon
Thats a bit brutal but not that deserving of down votes

if "and then a week later come back with the same question as though we had
never talked about it" is actualy whats ocuring. That is a bit of a red flag
that you have employed "cheap" people who have gone into the biz becuse its a
good "professional" job for familiy or social reasons.

Fireing is a last resort but if they are not willing to learn sometimes that
its the best solution.

~~~
mangamadaiyan
Keep in mind, you only know the manager's side of the story. Maybe they go
back to him every week with the same questions because they didn't get good
answers the first time around, and didn't know where to look! It's not too
hard to fire a dev, it's harder (and more frustrating) to figure out the real
problem in situations like these and fix it.

~~~
emodendroket
On the other hand, one I see a lot is "I don't agree with your decision, so
I'm going to keep asking this question over and over again."

------
wojt_eu
Give everyone in the team copies of the book "The Healthy Programmer".
Problems focusing could be anything from blood sugar level or thyroid to food
allergies.

------
monroepe
That kind of dev drives me nuts.

------
datashovel
Programming is an interesting thing to manage. It's not like you're managing a
warehouse where you can tell the guy "You see that box over there? Pick it up,
and take it over to the other side of the warehouse". Or a restaurant where
you say "You see that pasta? Put it in the boiling water for X amount of time
and when it's done take it out".

My feeling, especially when starting with a new group of people, is the amount
of time you should allow them to struggle is inversely proportional to their
years of experience.

In the end productivity is important, but not at the expense of creating a
hostile work environment. Programmers need to be ok with creating imperfect
things. Sometimes it's the only way they'll successfully iterate toward
creating less imperfect things.

Another interesting thing about managing programmers is it's difficult to
create objective metrics by which to assess performance, which you can then
easily compare to other members of the team. In other words, I can't go find
the box and say "why is that box still over here? I thought I told you to put
it on the other side of the warehouse?". or "Why is that pasta not in the
boiling water?" At best I've only ever had a clear "sense" of where each
member of the team is. Nothing I can put on a chart that shows definitively
that Team Member A is performing at a higher standard than Team Member B. In
this case it's critical to give the slower guys the easier tasks, and the more
ambitious guys the bigger tasks.

Create a tighter feedback loop for those who you see as having difficulties.
And create opportunities for people to collaborate, and in the process compare
themselves to others on the team. And every once in a while sit with them
while they're working for maybe 15 minutes at a time. Don't expect them to do
things your way, but by the end of the session offer a few suggestions. And
make sure they set goals for themselves. "How long do you think it will take
you to finish that?". Make a note of their goal. And then when the time is up
ask them "So have you been able to finish that?" If not, what's wrong, and how
can we help you? If so, then good job let's move on to the next thing. And I
saw in other posts the suggestion that sometimes you should break down the
tasks into smaller more digestible chunks instead of having them do that.
Great suggestion.

Finally, it's not an infallible metric (and in fact probably not a good
measure for anything performance-related), but lines of code committed is I
feel a good "BS detector". I had a guy (arguably senior, and arguably
unmotivated) on a team I managed a while back who managed to commit less than
100 lines of code in a month. That's as close to an "obvious sign" that
something is wrong as you will probably ever see. Writing code is what
programmers are paid to do, so if they're not doing it there's no way to
assess their performance.

------
michaelochurch
You haven't made a case that they're incapable, just that they're not
comfortable coming to you for direction.

"Protect, direct and eject." You need to protect your top performers from the
political conflicts that high performance attracts. You need to direct the
people in the middle or those who haven't found a way to shine yet. We won't
talk about ejecting, because you haven't made a case for that yet.

Middle management presents a weird conflict of interest. You're still judged
on deliverables rather than intangibles (like an actual executive) but you're
going to have to take interest in your reports' careers if you want to have
credibility with them. You have to be a product manager (to get X done for
some "X" that is larger than you can do yourself) and a people manager, and to
manage up.

There's no silver bullet, but I think you need to humanize yourself and the
relationship. You don't want your developers to see you as "The Boss", and you
have to take interest in their careers and help them get where they're trying
to go (which may be off your team, for the two who don't seem engaged). The
difficulty of this depends both on your interpersonal skills and your
credibility within the organization. Ultimately, if _your_ managers (up the
chain into the executive suite) don't care about your reports' careers and
advancement, it's going to be a struggle to get for your reports the support
and resources that they'll need to be motivated again. If your managers are
bad, it's just a losing battle for you.

Ultimately, you're going to have to figure out what your reports (all 4 of
them; don't just focus on the 2 who seem to be lagging) want and make sure
they get it, and that they know they will have your support as long as they
don't betray your trust. Then you need to come up with a strategy that meets
your project-management targets but also engages them. That's not an easy
thing to do and it's impossible to come up with a general-purpose solution.

------
gcb0
you have a shitty development environment.

i bet the 2 fast developers and yourself never cared about unit tests. leaving
the people that don't want to write temporary test cases completely lost. they
probably sake their head every time they look at the code base, try to start
to sanitize it, realize it will take forever now, give up in the middle, and
end up just contributing to the mess.

