Ask HN: How to manage developers who aren't very good? | Hacker News Reader

Ask HN: How to manage developers who aren't very good?

179 pointsmarktangotango203 comments

Before becoming a team lead, I was the type of developer who, when given a task, would dig into the application api's, the database schema, the configuration, whatever it took to fill in the gaps to accomplish the task. Sure I'd get stumped sometimes, but I'd always try to ask for help sooner rather than later.

Now, I'm a lead of 4 developers. Two are like I was, I can give them a task, they'll go do it with minimal guidance. The other two will spend hugely more time on tasks. I've notice they tend to go off on tangents, spending time things that aren't relevant, like setting up vm envirnoments they don'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.

It's baffling to me, it's like they're "scatterbrained", ie not focused or concentrated. How does one manage people like this?

View on HN

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?"

You're absolutely right, management is not programming. But management is LIKE programming in that there are frameworks and libraries developed by people before you that you can use so you don't have to learn everything the hard way.

In this case, I suggest the OP read up on the situational leadership framework [1] (Wikipedia is a good start but I suggest you pick up a book since they explain it far better). It is designed for the exact problem OP is encountering: what to do when you have people with different levels of expertise at a task. In a nutshell, it's about helping your subordinates manage the experience curve by recognizing where they are and providing the right kind of encouragement at the right time.

[1] http://en.wikipedia.org/wiki/Situational_leadership_theory

This one goes to my reading list cue..

To elaborate a little more on jonstewarts excellent answer: It sounds like you're comfortable with two of them because, in your words, "Two are like I was". You manage 4 people. You're lucky that you can relate to two of them and their work styles. I say this because everybody works a little differently than everybody else.

And everybody is going to have strengths and weaknesses. As a great manager, it's up to you to play to each person strengths. The other two employees may be scatter-brained, so perhaps task them with very specific goals that aren't as time critical as the other ones. The term Rock Star Programmer, is so fucking overused, overhyped and just plain stupid and I wish that it never entered into our vernacular.

It's also your job to realize realistically, where your employees have weaknesses (trust me everyone does). A great manager will help bolster areas that people are weak in, in a way that doesn't demean them.

Management ain't easy.

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.

We also thought this way. We had our daily standup at half past ten, which was right in the middle between coming in and going to lunch.

Now we moved it to quarter to two, which for most of us means a bit after lunch. Now we have no interruption throughout the morning, and the hour before the standup we're not working anyway.

Yeah, I'm a fan of first thing in the morning--if everyone gets to work at the same time--or after lunch, where it helps ease people back into work whilst digesting.

I'm sorry that standups have been like an interrogation for you. They should really be for the team's benefit. The team as a whole should care about delivering the product, and should use standup to communicate about current progress, and especially to help each other with any blockers.

It sounds like these engineers have tasks they think are important: I don't think anyone spends several days setting up a VM for fun. Does everyone have a say in what user stories are worked on? Do they have a mechanism to suggest improvements, and help prioritize them against the rest of the backlog to figure out what's most important?

Likewise, I'm sorry you've had a bad standup experience. A standup should absolutely not be an interrogation, and perhaps I dwelt too much on the "competitive pressure" aspect. That competitive pressure should come entirely from within a developer, just from the normal psychological desire to achieve and do a good job and to know that someone cares about what you're doing. The manager actively needs to counteract the competitive part, to ensure that it's okay in the standup to say "I'm stuck" or "I fucked up" or "I need help".

I hate 95% of "Agile" (i.e. wolf-in-sheep's-clothing micromanagement) but I actually think that a daily standup is often a good thing or, at least, a necessary evil.

In organizations, people will form suspicions, e.g. "does that guy actually pull his weight?" It's not a good thing. It's not what people should do. It's what they will do. Standups allay that suspicion. Of all the political games that an office environment can make you play, standup is one of the easiest ones, and that's good because even with the losses you mentioned (such as regaining focus) it's limited in the amount of time it takes, and you still have 50-65 percent of your time for real work, which is 3-4x what many programmers get.

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.

Impromptu status pings are more disruptive (and, in some companies I've seen, obnoxiously frequent, like 1-4x per day) than scheduled status meetings. If you've decided that you need status updates, you should have the standup instead of having the whole office on edge all fucking day.

15 minute standup meetings right before lunch are an ideal way for a team working on scattered parts of a big project to stay connected to reality. They shouldn't be structured as interrogations. Rather, each team member (works for non-programmers too) gives a brief summary of recent and near-future work, their longer term trajectory, and anything they need another person to review. Other team members then have the opportunity to point out they are working on similar things and need to make sure integration of the separate parts goes smoothly.

"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.

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.

I do agree that communication is the intention, but in practice, that's just not how it plays out.

I've never had a standup go on for longer than 15 minutes. Perhaps one of the ultimate takeaways for the OP is that there are N tools in the manager's toolbox, and N^N ways to abuse them.

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.

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.

It's easy to sabotage standups in this manner by asking questions of others that you know will cause extended discussions. Especially on topics that have previously been "settled" by fiat.

> 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.

A stand-up shouldn't take more than a couple of minutes per person, at the most. The thing that seems to help the most with this is to set aside a section of the whiteboard for the "Parking Lot". If the discussion starts getting off-topic or taking too long, the leader says "let's put this in the parking lot for now", makes a note of the topic on the whiteboard, and you move on to the next person. After the main part of the stand-up meeting is done, the Parking Lot is addressed, but only people who want to discuss it (or are needed for such discussion) need to stay.

As jonstewart said, the standup is for communication. In my team the morning standup will occasionally take less than a minute, a much shorter interruption than getting up for a cup of coffee. It makes me aware of what everybody else is working on and their progress, which I think is valuable.

If it acquires a have you done any work at all? vibe, you just fight it off with honesty. A half-hour standup is just insane. A large 'scrum of scrums' standup with dozens of people/teams shouldn't take longer than 15 minutes.

I've never seen a huddle exceed 5 minutes. Ever. Even sit-down meetings, in large corps, rarely exceeded half an hour (Fortune 50 type companies).

I find the daily update hugely useful as a quick run-down into the changes in strategy happening, and as a chance to know the focus of what others are doing.

Perhaps I'm just lucky? Industry and location: Banking (UK); Finance and Technology (China).

I've experienced all range of standups. My current teams (I have two) both get in / get out in under 15 rather consistently. On occasion, parking lot items may extend beyond the 15-minute mark, but these are typically NOT requiring all team members' participation (so non-participants are free to leave). As a SM, I keep the team on track, reminding them to stick to the 3 questions and not much else (we do enjoy some banter - few teams take themselves so seriously that they don't allow any banter), but I keep the overall standup short, to the point and respectful of our time.

The daily standup: it will make a really bad team perform a little better and it will make a really good team go to pieces.

If the team is doing really well, no one will suggest a standup.

Are you hiring?

This sort of stuff tends to get imposed from above, or by busybodies enraptured with ideas and theory as opposed to practicality. I'm endlessly told how nothing but agile works, despite the fact that I'm 48, and successfully lead dozens of projects before agile was an idea, on time and on budget.

This is exactly what I have though. I code the same way as I have for years. (I am more organized and disciplined, but that is down to experience, and nothing to do with the way I work being labeled "agile").

If I was to take a list of aglie practices, I maybe end up ticking half of them. Same things I did when waterfall was all the rage.

How I wish you were right.

As part of my job I have the pleasure of a "quick morning standup" every day, and it's one of my least favourite parts of the job. It also routinely becomes a "not-so-quick morning standup" meeting.

In my group standups are more about everyone touching base on what they're doing and what issues they have so that other people a) know that they're not duplicating effort and b) can chime in to help if they think that'd be helpful.

That's far from an interrogation

I have an anecdote about daily stand-up meetings. The project I was on had its tasks written up in Excel spreadsheets, planned up to 2 years in advance. The management discovered, after seven years, that things were not being done that should be done.

So they implemented daily stand-up meetings at exactly 8:50 am, including every single person on the development team, as well as all the testers. The natural politicians on the team immediately pivoted towards writing down every bullshit thing they did during the day, so they could recite them the next morning as evidence of productivity. Incidence of scheduled meetings that would require at least one of the seniors to be present exploded.

Every single one of those damned meetings was scheduled for 10 minutes, and lasted at least 30.

The stand-up is not the problem. Incompetent management is the problem. Management fads won't do anything to address the underlying deficiencies. The actual problem with that office is that smart and unethical developers are leading the incompetent managers around by the nose, using the very process and metrics that the managers had created to hide their lack of development knowledge.

As a result, the senior developers assigned themselves the privileged tasks that sound important but don't actually require much work, assigned the grunt labor to juniors, and gamed every last one of the management metrics to make sure everyone on board with "the program" gets paid until the gravy train runs off the cliff.

So naturally, every last line of that code base is DailyWTF candidate material. The management does not understand technical debt, so the seniors issued them high-interest loans from their own bank.

This is not the fault of the developers. It is 100% the fault of the managers that allowed that toxic creature to take root.

So with respect to the question post, I suggest that the "slow" employees may actually be testing their new manager's capability to manage them. This is particularly relevant if any of them have ever worked for another company.

Assume they are trying to establish their own slack margin, so that they can safely read HN every morning, or some other equivalent time-waster, without falling behind on assigned tasks. If so, implementing a daily stand-up will only confirm that you are a management novice that can be manipulated.

Just establish a tough, but fair, work standard, and check to see if the "slow" guys speed up in response, or continue to struggle for more hours. For the former, you will need to court their favor by assuring them that good productivity will not be punished. For the latter, you will need to continue their education by sharing the knowledge and experience you and the faster developers have acquired during your careers--but subtly, so as to not embarrass them before their peers.

I think that your opinion is definitely valid and just goes to show that different things work for different people. I actually really enjoy stand up because it's the only way I get to know what other people are working on. It also makes it so that it's easy to prioritize depending on dependencies.

However I would argue that the problem isn't stand up itself, but a culture of not being able to say you didn't finish something. After I realized in my last company that it was okay to say I couldn't finish something in time, the environment quickly felt much nicer to be in.

Yeah, I left my last company because of SCRUM gone wrong (1 hour daily "stand-ups" and 6 hour sprint planning meetings). One criteria in my job searches now is no Agile/SCRUM (to me, it's just another name for micro-management).

My favourite take on the standup meetings is not to structure them as reports on what each team member did yesterday and planned to do today. They can include that if necessary, but I prefer using them as an opportunity to exchange knowledge. The team members should be encouraged to discuss any issues they ran into and share the ways they resolved them, and the lead should listen and make note of any recurring issues -- both related to technology and to the personal -- and see if they need resolving on a more individual level.

Its essential to regularly update what tasks are done and what tasks are being worked on by whom, but if you use some other system to handle those updates and keep people aware of the updates (e.g., visual artifacts updated as items are completed and pulled for work, as in kanban), then you don't need to do that in the standup meeting.

Identifying issues encountered (both to share knowledge of how issues were resolved and to gather information on addressing barriers that haven't been resolved) is a pretty standard element of standup meetings even when they include progress updates, and certainly a good thing to keep them for if you've moved the status updates to another channel.

I am sorry - but I dont understand why your attitude towards daily standups is so pessimitic. I do agree that what you describe can be one possible outcome of standups, but, if everyone (at least individually in their own way) is looking to ensure that the project/undertaking succeeds, then there are a whole lot of other benefits that standups do provide.

One advice to the OP - dont think of yourself a "manager". I always think of myself a "lead"er - as in "lead by example". So, anything that i ask (and consequently expect from my team) is definitely something that I would also do given the same circumstances. Going by this, the standup (as an example) is where I am the first one to share what I did yesterday, something interesting that I found out about yesterday, and what I hope to accomplish today. I add any blockers that I came to yesterday couched in the "can someone please help with this problem?". Since I open up the "discussion", its not even considered an interrogation - its just sharing my accomplishments, interesting things, etc with my peers/team mates.

What about having each person give you an oral review of what they did at the end of the day to spot problems?

> Of course, you don't want to micro-manage them every hour of the day; that's not scalable.

While some managers want to stay away from so called micro-managing at all costs (either because they are afriad that their employees won't like it or becuase they are lazy) it has to be said very clearly: There are certain situations when so called micro-management (very precisely set goals with clear metrics, large amount of detailed instructions, frequent controlling and immediate corrections) is absolutely necessary to push someone's growth forward. Of course such management style isn't scalable and ultimately must be changed when the employee's competences grow. It's just an investment into future performance.

Of course as in case of every investement you need to evaleate if it makes sense. Assuming that the employee has only one particular area that needs to be improved, the answer usually will be "yes".

Standups, like so much of "agile", could be beneficial to every member of the team. I've insisted on them as a developer.

Unfortunately, standups, like so much of "agile", are a perfect disguise for wolves in sheep's clothing.

I've been incredibly burned by agile, and I realized it's because agile encourages a developer to let down his or her guard at the wrong moment.

Going through the agile manifesto, I can now see how each one of these has gone wrong for me.

http://www.agilemanifesto.org

"Individuals and interactions over processes and tools". Right, we all get together, discuss what we're working on. It feels very collaborative. But there will be this tool, this time-tracking system, that we'll enter stuff into, and your name will be next to those things with a deadline. If you don't meet it, we'll interact with you as an individual about why you aren't meeting your deadlines.

"Working software over comprehensive documentation". Again, sounds great. Rather than spec'ing out every little detail, let's work together iteratively to get the right product out. Here's the thing - you just allowed the people who are putting your name next to a task and a deadline to never commit to exactly what they're trying to build and by when. The deadlines are yours, but they'll enjoy changing their minds, because, you know, "agile."

"Customer collaboration over contract negotiation". The trap has been set, this is where it is sprung. Most developers, I'll guess, aren't truly in contract situations where there are lawyers and signatures and so forth. The tend to work on internal projects. But make no doubt - if someone can turn to you and say "you committed to getting X done by date Y", and it's in there in the system, you are in a contract situation. But because it was "agile", you didn't negotiate properly, and now you'll get rolled.

"Responding to change over following a plan". I assure you they will hold your feet to the fire if you don't follow the plain that was clearly in the "contract" and documented in the progress tracker system. However, because it was "agile", you never really got them to commit to what they were asking of you, so they retain the ability to change and adapt. If it suits their purpose, so can you, if not, you're "in breach". If it's internal, this isn't some lawsuit, it tends to be a sit down with people, including your manager (and perhaps a few other managers), where people act like they're all here to solve a problem and get things back on track, with a heavy undercurrent that it's your fault.

Standups, while not part of the manifesto, corrupt similarly. Instead of "here's what I worked on yesterday, here's how it went, here's what I'll work on today", they become a daily application of pressure and reminder of deadlines. It appeals immensely to someone who would like micromanage a developer. They're meant to keep communication open in complicated projects where it can be difficult to make estimates under uncertainty (you know, a software project). But they often end up with one person trying to explain complexity to an exasperated (and perhaps manipulative) person who really just wants to apply (often artificial) deadline pressure.

Unfortunately, "agile", for all its promise, turned out to be amazingly fertile ground for manipulators. I think this, more than anything else, is what has so badly damaged "agile."

Waterfall seems like a discredited old system, and I don't love it either, but it has a huge advantage for developers. It requires people who will insist on and enforce deadlines to state upfront, in considerable detail, exactly what they want.

> Waterfall seems like a discredited old system, and I don't love it either, but it has a huge advantage for developers. It requires people who will insist on and enforce deadlines to state upfront, in considerable detail, exactly what they want.

Except it never really worked that way, which was the entire problem with waterfall. Waterfall works best in a static environment with guaranteed funding because it doesn't react well to shifting priorities. In reality, requirements change and budgets get cut, which sets off a chain reaction of change management activity in a waterfall model. Agile is so much better -- you reassess requirement priorities every few weeks and that dictates what you work on over the next few weeks. In very few situations under which software is developed today is it even possible to state upfront what you need with any certainty. Waterfall assumes that requirements gathering and development take place serially, whereas agile recognizes the reality that they are more or less concurrent.

Waterfall still has its place - if I were developing a nuclear reactor or an airplane, waterfall is still the way to go. But for projects where 100% requirements completeness is unnecessary (and let's be real, nobody runs a full regression suite after every sprint), Agile will get you a better product faster and cheaper. Everything you said is true -- agile is a fertile ground for manipulators, but so was waterfall.

The manipulation is a byproduct of any reasonably large organizational structure, and if you want to stop it, it's got to be a cultural thing. Bad actors will exist under any development methodology, it's up to the leader of the engineering organization to stand up and refuse to allow his/her people to be abused.

Interesting answer, but I think you're refuting waterfall in general rather than the narrow point I was making about it. Overall I agree with you, waterfall is worse than agile. But to me, this is like saying that fighting and communicating only through lawyers is worse than getting together with trust and working out an agreement. Right, totally, agreed. But if the other side lawyers up and prepares for the "let's find who to blame!" that they suspect will happen in a couple of months, and you go in all ready to collaborate and work together, you're going to get steamrolled!

Dude, you're a programmer. If you're in an organization where this is the norm, go find another job with a more enjoyable environment. There's a million out there for you.

Right, but I was saying that the "biggest benefit" of waterfall was never actually one to begin with -- Agile was built around the assumption that requirements will constantly change because that's what happens in the real world. If requirements accuracy is the most important thing in your project, you deal with the change management implications. Otherwise, you go Agile and accept that you may not be able to guarantee a specific feature by a specific date/release.

It's a two way street though: the business folks need to understand that they're giving up some control and predictability in exchange for lower overhead and faster delivery. This is the hardest part of Agile IMO since most business / product folks don't like not being in control. Agile gives engineering more autonomy, but only if the business respects that autonomy. If the business starts dictating too many processes/priorities, the whole thing crumbles into a waterfall mess (even if you call it "Agile").

You might be on to something here, but what else can a team leader do to manage other developers besides organising daily standups?

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?"

Great psychological insight here. The intimidation factor can make you deeply want to step up your game, but it can also lead to some odd behavior that results in less transparency. Manager beware.

I think in general managers (well, everybody, really) need to be aware that people have different inclinations to share. Some people are the type to speak up and possibly dominate the conversation in a meeting, others are silent until prompted. Some people need to be probed multiple times to get their true thoughts.

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.

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.

This might be a reflection of either your working environment or your attitude. A lot of times companies will try to implement agile methods but if team members have the wrong attitudes about it and it can create a very unhealthy work environment.

If your team members make you feel like you aren't doing enough on your own, then intimidation makes sense. If you feel that you have to be able to get everything done right & quick on your own, then intimidation makes sense. If you feel you are working together as a team to help create a quality product/service, then standups should be a welcome break in the day to let everyone know how your progress is and ask questions. For me, it is sometimes "okay, I'll keep trudging through this problem until the standup, then I'll mention my problem and maybe Jane will have some insight on ways to help me improve".

How does "intimidation" make sense? What does that word mean, as used in your comment?

In the context of the post I replied to, feeling like the weakest developer - intimidation may make sense if you're afraid to share your progress (or lack of progress) because your team members are judging your development abilities, or if you just don't have confidence in your development abilities. If the attitudes of the team members is laden with competition and judgment versus cohesion and improvement, standups can be hell. But that's a team/attitude problem, not a standup problem. Standups shouldn't feel intimidating.

I'm not saying it was a consciously intimidating atmosphere, or that I felt judged. You're right, standups shouldn't feel intimidating. But depending on how they're structured, they can be. The standups I've taken part in felt more like a time to update management on what you're working on, not a time to get help.

They usually had far too many people involved. I think that's a standup problem, not an attitude problem. It's hard to speak up amidst 10-20 people (much less when they're all brilliant developers) when the whole room just wants to get down to work. It just doesn't feel like the place for issue-specific discussion.

Ah, I'm sorry - I'm a big Scrum proponent and I forgot that standups aren't always just a small team. What you described sounds pretty painful and more like a progress report that may not benefit the team much. I think I'd also feel intimidated in that situation and would probably seek out help separate from the standups. Any way you could plant the seed to break these standups into smaller groups based on the areas of the project you're working on? I think it could help!

No worries :) The situation I described was five years ago, and I think they've done what you described. They're a crazy successful company, so regardless they're doing something right. These days I'm on a small team, and in the intervening years I've gotten a lot better at managing myself and managing "up".

That experience should teach you to speak up and ask for help privately before the standup time.

Well, I was eventually fired from that job because I wasn't consciously aware of that effect at the time, and was basically unmanaged so neither side acted to correct the issue until it was too late. I learned a lot from that experience after the fact.

But in a situation where one person is the experienced team leader and the other is a junior developer, possibly fresh out of college, I think the onus is on the team leader to ask if they need help rather than expecting everyone to speak up on their own. Maybe the junior doesn't realize they need help. Maybe they're too busy with trying to progress on the code, possibly affected by personal problems, to think about their process.

A lot of the improvements that have made a difference for me as a developer and an employee in general have been learning how to work and manage both myself and the people around me, not learning more about a language or framework. I think that's a big part of a manager's job.

I find the opposite. I'm fairly new at a company, and worry about not looking bad. Sometimes, things stall. The next morning, I can explain where I got stuck, and get someone who the group trusts involved. If it's a hard problem, and the best programmer gets bogged down as well, I look okay. If they solve it in 10 seconds, I'm unblocked. Either way it's way more comfy than sitting on it for a week wondering when I'll get in trouble.

Totally. I think it depends on the group - especially group size. The intimidating standup I was describing was I think around 15 developers, mostly working on separate issues. It worked for them because the majority were very self-starting, skilled devs.

And I was speaking more to the general idea that OP shouldn't expect everything to bubble up to them automatically, because different people work and behave differently. Learning about that is an important aspect of being a manager.

>sitting on it for a week wondering when I'll get in trouble.

Mandatory participation in a meeting isn't going to stop that. You take the proactive approach and ask for help, but you're asking in the meeting. Why wait? Fire off an email to the last person to look at the code? Send a chat message to the person who wrote that segment of the spec. Flag down your favorite senior developer on their way back from the restroom.

The question or problem can always wait until the daily meeting to be resolved, but it can't be answered until you ask.

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

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.

> * 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?

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?

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.

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!

> 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.

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.

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.

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.

Regarding 1, I'll link to a comment downthread (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.

I think the part about backing off the level of detail is important. I've learned a lot about breaking down a large goal into smaller tasks by having it done for me a couple times. Even the first time I was laughing at how specific some tasks were, but it gave me a model to work from when I planned the next one myself.

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.

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.

I agree. If I were you, I would try to understand why they behave as they do. They may be distracted because of reasons outside of work (such as an illness in the family, or a divorce lurking around the corner etc.). Or they may be overwhelmed with the complexity of the task and so they just try to do what they think they can instead of working straight towards the solution. After all, we are all people with ups and downs, and limitations of our own. The follow-up should depend on what you find.

Saw this link on a previous HN thread: http://www.insead.edu/facultyresearch/research/doc.cfm?did=4...

I like how it describes the negatively reinforcing cycle of closer scrunity which results in worse performance etc. I'd also suggest personal coaching: don't tell your devs what to do, get them to realise what would be the most expedient method of proceeding (http://en.wikipedia.org/wiki/GROW_model).

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.

> 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.

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!

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

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.

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.

Pretty low on the page, and not management focused, but this is quite important if you're writing anything but the frontend component of webapps.

If you're developing locally on, say, a Mac, but you're pushing your code to production on Ubuntu Linux, those VMs are going to save you money by preventing bugs in the long term.

Of course, with modern development tools like Vagrant and Puppet/Chef/Ansible/Salt, setting up a VM should be quick and easy (and be something you can get one person to do and share their results with the rest of the team).

Do You know of any good examples of how to do it?

I was once considering creating a VM for each of my side projects, but unfortunately, I found they are tightly configured to the hosting environment! It's most probably my mistake, so maybe you could answer how to avoid following:

* I thought I could share VMs across computers, but having created a VM with hardware virtualization made tied it to a Intel Host with the virtualization extension. At home I have some laptops which are AMD's and don't support it.

* Is there a way to setup a whole VM from a script, including network card tunnels and shared folders?

* Is it possible to access a project environment, within a linux VM, which requires a Windows domain authentication? I guess it didn't work for me, since the requests originating from the VM lacked the necessary NTLM headers.

Have you heard of Vagrant? http://vagrantup.com/

I'm not sure about the NTLM part (and I understand NTLM is basically deprecated at this point, you should use Kerberos instead) but I believe it does everything else you're asking for.

You should look into vagrant. It can help you with many of these things, essentially just providing a framework to get started. Writing the bootstrapping scripts will still be up to you, but it helps.

For ntlm there are a lot of solutions for Linux, but the one I have used was cntlm to give me a local proxy to call through for convenience.

A proxy! Ah, why I never thought of that, so simple... Thank You

As mrj and kyllo said, Vagrant.

It takes care of the VM setup (including memory and disk allocations, shared folders, and basic access), and provides hooks for scripts to set up the rest.

In my case, I favor Ansible for setting up the rest of the VM, as opposed to shell scripts. It automates package installs, configuration changes, and managing services. Once these two bits are configured properly (about a day's task, for a moderately complex system) Vagrant can re-build a development VM from scratch in about 10 minutes.

Best part? Once you have the CM scripts nailed down, you can use them to build your staging and production environments in the same way your local VM was built.

Seems it might help in my current case... On my local dev machine I've replicated a project environment (Jenkins, Sonar, Artifactory, SCMManager). It was a huge boost for some tasks and I'm considering moving it out of my machine for others to use as well. If I do so, than I would probably configure it all manually, again from scratch.

Do You recommend making it a Vagrant recipe this time? Are there any similar ones?

Sounds like there be dragons that I would like to avoid. I'm curious what your environment is:

* VM host machine OS (Windows/linux/OSX)?

* Virtual machine (HyperV/VMware/KVM/...)?

* Guest OS (Windows/linux/OSX)?

Thanks!

So, my host is mostly Windows (work laptop comes with it normally and at home I like to play games a lot).

The VM was VirtualBox.

The Guest OS I always used was Ubuntu Desktop (I remember starting with around ~10.10).

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.

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.

To me it sounds like he is frankly a poor micro manager that expects his developers to have boundless enthusiasm for bugs.

Also note this is a double submission his first submission didn't go well so he reposted a week later. Sounds like those two developers are job hunting to me and I would too.

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.

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).

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.

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.

I have always naturally thought about what I'm going to complete during a day over the commute to work. I'm convinced that successful people tend to do this. Standups are nothing more than formalizing this process for small teams, which is especially useful for members who may not already be planning their days' work in advance.

The autonomy comes because he decs choose their own 2-4 hour tasks

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.

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.

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

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.

And raise the overall productivity of the team.

A good manager is able to get the most out of the team they're given, and yes,sometimes that means showing down part of the team so everyone can pull together.

Yes, you will cut a part of development time and turn it into education time. Then, you end up with 4 good workers.

If the senior devs can help mentor the junior ones then at some point you could have 3 or 4 productive devs instead of just 2. Not saying take away a big part of the day but maybe a 1/2 hour or hour long meeting every morning to get the junior guys on track.

Sometimes people need development to become productive members.

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

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

Whose role is it to train them? What happens when the superstar wants to change projects?

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.

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.

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.

So you want to deny that there are people who are just inefficient? I have seen this often. As I said, these people exist in all professions and this issue is not related to good engineering practice, writing specs or anything like that. That's good practice, of course. But there is no indication that this is the problem here.

The OP made clear that the setup VMs that they do not need and ask questions "then a week later come back with the same question as though we had never talked about it". I can't see how this is related to writing specs or following proper software engineering guidelines.

Sure he might judge these people wrong, but he certainly has much more information than you. You have no information at all!

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

Yes, that's exactly what I thought you were. But this is not a helpful attitude if you don't have the necessary contextual information.

Because people impose their predetermined views quite strongly. If you have already have a view of someone, anything that remotely confirms that is used as evidence. Where things don't confirm that that are forgotten.

If your going on a date with someone and they pick their nose, you probably think they are a slob. If someone has been married to someone 20 years, and they pick their nose, you might say "but they have a heart of gold".

Forcing yourself out of lazy views, is quite hard.

Yet its the number one thing thats important in management. Not jumping to conclusions, being able to see from another position, being able to reframe your views and so on.

>So you want to deny that there are people who are just inefficient?

He's offering a different perspective on what the problem might be. If your default view is that these people are "inefficient", you're probably going to be a terrible manager.

>The OP made clear that the setup VMs that they do not need and ask questions

Because the OP is having trouble figuring out what the problem is. If it was as straight-forward as "These guys don't do any work" then the solution is pretty obvious, isn't it? He also says, "Two of them just work with minimal supervision". Well, if everyone was like that, we probably wouldn't need managers.

> 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.

Having personally been in this position, i'd say your wrong.

I've been close to being fired at some companies, and others promoted within months.

Mainly because of the different culture. I'm happy for it, finding a good company or position with the same values is really nice.

um, your point doesn't logically refute mine. in response, i would posit that maybe you're not as good as you think you are.

I don't see the world as flat out, good or bad programmers. So I don't see myself as a good programmer or a bad programmer. It is highly dependent on what skills you ask me to use.

I will gladly admit i am not good at lots of things in software. But I know what i am good at.

Don't ask me to build slick User Interfaces for example, but I can build a reliable distrubuted fault tolerant backend if you want. I'd imagine Linus might not be that good at building slick angular apps, but you don't judge him on that.

I care about being able to thrive in my role, doing good productive quality work, and getting well compensated for that.

I am not ego maniac how likes to think he is awesome 1% programmer. I have realistic ideas of what i am good at, and try to find positions that use them.

It's honestly a shock to me that instead of trying to be more open minded you accuse the person of being "not as good as [he/she] thinks [he/she] is"; let's try our best to remain civil here please.

In any case, I believe you two just have a misunderstanding. It sound as if you believe a "good" developer is one who is consistently capable of producing quality work, whereas the person you are responding to considers a "good" developer to be one who is capable of producing quality work. In my experience most people also share the second definition but that's besides the point.

I can't imagine it's hard for you to believe that if we consider someone is "good" if they are capable then being good has nothing to do with their level of motivation which is directly affected by their workplace. That being the case, obviously any developer will produce to varying degrees depending on how well they fit with their company, or probably more accurately their team.

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

Why? There isn't some discrete separation of good companies and "fucked up" companies. There are good companies, bad companies, and companies of all levels between. And even in companies there are good and bad teams. Just because a great developer doesn't perform on one team doesn't mean it's the team's fault; it could just be a poor match.

you are not going to convince me to change my definition of 'good developer' away from

> one who is consistently capable of producing quality work

if you disagree with that, i don't even know how to respond.

for what it's worth, i never considered myself a very good developer. i was not capable of consistently producing good work. that's part of the reason i co-founded a startup and do a lot more than development now.

i don't see how this is so shocking for me to suggest. most people aren't that great at things.

I believe your developer does not exist. I've never met a developer consistently good at everything in development.

Development is so vast. You can be doing embedded systems, mainframes, aircraft software, or web software.

I disagree with that, but I don't think that's the point. The problem is that as far as I can tell you're commenting with your own definition of what a good developer is while everyone else appears to to be using a different definition, or at the very least the person you were responding to was.

It was shocking because it was rude and uncalled for.

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.

How many different kinds of environments have you been in.

sometimes manageing doe's involve fireing - its not nice and almost all people dont like do it but sometimes its required.

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.

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

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.

Maybe that's what he has to do but it seems to be jumping the gun a bit to go straight to firing.

>> 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.

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.

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.

This is normal.

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

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.

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."

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?

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

I would argue that the most important management skill is herd people to "get sh*t done", being skilled in firing people won't save your ass if you don't deliver

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

See also this oldie article: Don't Let Architecture Astronauts Scare You 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.

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.

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.

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.

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!

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.

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.

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.

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

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...

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

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.

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.

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.

> 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.

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.

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.

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.

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.

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...

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.

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.

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.

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.

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.

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

2. http://www.publicspace.net/Vitamin-R/

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.

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

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.

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.

Maybe try to find ways to increase your metacognition frequency? https://en.wikipedia.org/wiki/Metacognition

Keep a work diary; This will allow you to both list & justify what you have done, and to personally review whether you are doing the right thing as you go along.

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.

Have you tried the Personal Software Process?

http://en.wikipedia.org/wiki/Personal_software_process

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.

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.

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.

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.

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

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.

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.

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.

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?

that book is a good starting point https://pragprog.com/book/rdbcd/behind-closed-doors

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.

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.

Go read Peopleware and then come back to this thread.

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.

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.

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

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

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

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

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.

fire them?

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.

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.

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."

Oh I totaly agree its hard to tell from just one side of the story but I have experinaced similar problems at a major publisher before now.

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.

That kind of dev drives me nuts.

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.

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.

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

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...

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.

Reply on news.ycombinator.com