10 ms·

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

• cronin101 12y ago
  Pair the "junior" developers with the ones that you are more happy with and have them learn productive habits through collaboration and observation?
  • DanBC 12y ago
    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.
    • karmajunkie 12y ago
      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.
    • Raphmedia 12y ago
      Yes, you will cut a part of development time and turn it into education time. Then, you end up with 4 good workers.
    • wil421 12y ago
      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.
    • johnatwork 12y ago
      It's a long term investment. Of course the worst case scenario is that the developers leave afterwards.
      • sarciszewski 12y ago
        If you train them, the risk is that they leave. If you don't, the risk is that they stay.
    • sukilot 12y ago
      Whose role is it to train them? What happens when the superstar wants to change projects?
• estava 12y ago
  Maybe you need to pick your battles. Your question reminded me of this video: John Maxwell The 5 Levels of Leadership https://www.youtube.com/watch?v=aPwXeg8ThWI https://www.youtube.com/watch?v=aPwXeg8ThWI See also this oldie article: Don't Let Architecture Astronauts Scare You http://www.joelonsoftware.com/articles/fog0000000018.html http://www.joelonsoftware.com/articles/fog0000000018.html Sometimes people have good ideas that may be a little overkill for your project. Running a VM could help with creating test environments. Although there may be alternatives to that. So maybe they just want to test more. Maybe they are more QA types. Try to understand where they are coming from and give them some guidance. :-) Cheers.
  • th3iedkid 12y ago
    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.
• kappaloris 12y ago
  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.
  • pzs 12y ago
    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.
  • lifebeyondfife 12y ago
    Saw this link on a previous HN thread: http://www.insead.edu/facultyresearch/research/doc.cfm?did=46698 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 http://en.wikipedia.org/wiki/GROW_model).
  • madez 12y ago
    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.
    • 12y ago
• DanBC 12y ago
  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.
• UK-AL 12y ago
  They might have different values, maybe they come from environment where they do everything by the book, and "correctly"? Your environment is get things out the door fast sort of environment? Doesn't mean their bad, just different values. Should have worked out their values at interview stage. In a different company they could be the stars, and your the guy close to being fired.
  • quonn 12y ago
    I don't like how you reduce a possible difference in efficiency to different "values". Like in all other jobs, some developers are less efficient. The OP asked for advice how to _manage_ them, not how to fire them, so there's no need to defend someone you don't even know. He wants to work with the people he has and the situation he is in, not be told how these guys should not have been hired or that they supposedly have different values.
    • UK-AL 12y ago
      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.
      • quonn 12y ago
        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.
• cphoover 12y ago
  fire them?
  • spacecowboy_lon 12y ago
    Thats a bit brutal but not that deserving of down votes if "and then a week later come back with the same question as though we had never talked about it" is actualy whats ocuring. That is a bit of a red flag that you have employed "cheap" people who have gone into the biz becuse its a good "professional" job for familiy or social reasons. Fireing is a last resort but if they are not willing to learn sometimes that its the best solution.
    • mangamadaiyan 12y ago
      Keep in mind, you only know the manager's side of the story. Maybe they go back to him every week with the same questions because they didn't get good answers the first time around, and didn't know where to look! It's not too hard to fire a dev, it's harder (and more frustrating) to figure out the real problem in situations like these and fix it.
      • emodendroket 12y ago
        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."
      • spacecowboy_lon 12y ago
        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.
• jonstewart 12y ago
  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?"
  • exelius 12y ago
    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 http://en.wikipedia.org/wiki/Situational_leadership_theory
• matt_s 12y ago
  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.
• icedchai 12y ago
  This is normal. I managed to fix this by getting a new job where I didn't have to manage. ;)
  • lafar6502 12y ago
    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.
• wojt_eu 12y ago
  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.
• spot 12y ago
  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.
• jules 12y ago
  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.
• qvikr 12y ago
  Your definition of "good" and "bad" is probably off tangent. As a manager, you take up a new role of being the "coach". It's your job to help your team play at the best performance they possibly can. Letting go of someone is the simplest thing anyone can do... but if you look back at your own career, chances are you'll find more than a couple of instances when your peers put up, tolerated, and coached you to where you are today - just don't close the doors you walked through.
  • smackfu 12y ago
    Yeah, if "good" means they manage themselves, and "bad" means he has to work at managing, that's not a great expectation.
• monroepe 12y ago
  That kind of dev drives me nuts.
• acjohnson55 12y ago
  It's going to be a process, but you have to break down the problem, and attack it piece by piece. I can identify a couple issues in your short description: - Untimely completion of core tasks. There may need to be more frequent check-ins with more granular goals, along with accountability or at least retrospection for missed checkpoints. If a checkpoint is missed, the dev and you have to figure out the why of it and how the process can be improved in the next iteration. - Lack of resourcefulness/grit. This can be taught. This is where it helps to pair someone with a strong developer or yourself. As a teacher, we modeled the learning process as I-do, we-do, you-do. It may be enlightening for an unproductive dev to see better habits in action. But you can't just show a skill and hope it will be replicated. You have to gradually shift more responsibility to the other party to transfer the knowledge. - Misspent time. Not every subproject is useful for its own sake. Hold your team members accountable for demonstrating the value of tangential work beforehand, and put your foot down if you're not convinced. Everyone loves a side-project, but it's not a substitute for progress on the core goals. Most people want to improve, but everyone has some mixture of compentencies where they will naturally self-improve and ones for which they will need mentorship. This isn't the sort of thing where you can make one exasperated speech and see overnight improvement. The goal should be gradual, consistent increases in productivity. And don't forget, since just became a team lead, you also need guidance and continuous feedback. Be proactive in seeking it. Good luck!
  • mreiland 12y ago
    > Not every subproject is useful for its own sake. Hold your team members accountable for demonstrating the value of tangential work beforehand, and put your foot down if you're not convinced. Everyone loves a side-project, but it's not a substitute for progress on the core goals. Disagree with that. Sometimes they're working on improving things you don't want to be improved and they should be. As long as they're getting the work done, who cares what else they do.
    • acjohnson55 12y ago
      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.
• brucehart 12y ago
  Develop a process that adds more openness and accountability. Hold a 15 minute daily standup meeting where each developer shares what they accomplished the previous day and what they plan on accomplish that day. Spend some time creating very distinct tasks for each developer that are 2-4 hours long. Tell the developers which tasks you expect to get completed that day and not to get sidetracked. They are providing the engine power, but you are steering the boat. Many developers get sidetracked because they are afraid to confront the fact that they don't know how to do something. Make it clear that it's okay not to know something but it's not okay to just avoid a task in front of them. Find roles for them where they can excel. Imagine being a coach of a basketball team. Some players are good shooters while others might be good at defense and rebounding. It's up to you to find these strengths and use them together. A fast developer may get excited about doing new development but hate doing things they consider grudge work. These slower developers might like doing work like testing and documentation (and actually be better at it).
  • mattmanser 12y ago
    Daily standups, especially with 2-4 hour long "tasks you expect to get completed that day" is simply thinly disguised micro-management. It is the antithesis of all the advice on how to make people more productive and excellent at their jobs, which is to make them autonomous. Sounds like a nightmare environment.
    • brucehart 12y ago
      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.
    • 12y ago
• moron4hire 12y ago
  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.
  • emodendroket 12y ago
    Maybe that's what he has to do but it seems to be jumping the gun a bit to go straight to firing.
  • slantyyz 12y ago
    >> 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.
• gokhan 12y ago
  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.
• wballard 12y ago
  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
• kyled 12y ago
  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.
• musgrove 12y ago
  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.
• cubano 12y ago
  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.
• bane 12y ago
  It's ultimately about making them make the right decisions, and building up a non-broken mental model of how to do things. Lots of their actions are likely just from ignorance of alternatives, but it could also just be a broken decision making process. The idea is to make them part of their own reformation: - Don't set deadlines, make them set deadlines, document it, then hold them to it. Make the penalty for missing their own deadline big. Because you've documented it, if they make a pattern of missing their deadlines, work with them on learning to better gauge and estimate their level of effort. Review the cases where they miss the deadline, find out why, build up a pattern. It could be they just don't understand how some library works, or how the build tools work etc. It could be an external dependency they have no control over. Either data-point gives you tools to help them learn how to do this most basic of tasks. - If you tell them something once, and they come back again, the second time make them write it down in a binder of notes, if they come back again, make them refer to their own notes. If they come back yet again, make them do a full report on the topic, put it on an internal wiki, and treat it like a High School writing assignment. It sucks for them so they'll never want to do that again, but it produces useful information for other people. - Don't tell them what to do. But make them describe their strategy to tackle the task. When it sounds like they're doing something wrongheaded, ask them why they're doing it that way instead of the obviously better way. Maybe they have a good reason, maybe it's out of ignorance. Take it as an opportunity to make better ways available to them. But the decision for which way to go is up to them, so long as they hit their self-imposed deadline.
  • jnbiche 12y ago
    > 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.
• jpswade 12y ago
  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.
• ap22213 12y ago
  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.
• agounaris 12y ago
  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.
• franze 12y ago
  that book is a good starting point https://pragprog.com/book/rdbcd/behind-closed-doors https://pragprog.com/book/rdbcd/behind-closed-doors
• unfamiliar 12y ago
  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.
  • nitrogen 12y ago
    Maybe try to find ways to increase your metacognition frequency? https://en.wikipedia.org/wiki/Metacognition https://en.wikipedia.org/wiki/Metacognition
  • probablybroken 12y ago
    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.
  • jmagoon 12y ago
    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.
  • nradov 12y ago
    Have you tried the Personal Software Process? http://en.wikipedia.org/wiki/Personal_software_process http://en.wikipedia.org/wiki/Personal_software_process
• kyllo 12y ago
  Go read Peopleware and then come back to this thread.
• brudgers 12y ago
  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.
• edw519 12y ago
  1. Give direction with appropriate detail. Be prepared to give very detailed direction to junior people. I sometimes ever go as far as putting lines of code right into the technical specs. Most technical leads hate to do this. They say, "I might as well write it myself." That's because they look at it as an expense. I consider it as an investment because people learn from it. This should make things run much smoother. Important: the level of detail should decrease over time. In fact, your junior person should start pushing back: "I don't need that much detail anymore!" If this doesn't happen, then they're not learning fast enough. This is not normal. 2. You must have your finger on the pulse of everything going on all the time. Not every little detail, but you must know where each project is, plus or minus 10%. Don't let yourself lose track of anything; that's when problems start. 3. Reviews must be daily, not weekly. You don't need status meetings, emails, or project updates, just one minute reviews. 3 day old problems are 2 days too old. 4. Peer review everything your people do until you're absolutely certain you can let someone else do it. And even then, continue to peer review something they do every week. You are responsible for their work; peer review is one of the best ways to stay one top of it, insure quality, and teach. And always be brutally honest with peer review, never bashful. Tell them what's not good enough, what you want, and why. It may be uncomfortable at first, but it will save everyone headaches later. 5. Read "The One Minute Manager". Then do it. 6. Be nice, have fun, and get shit done.
  • hyperpape 12y ago
    Regarding 1, I'll link to a comment downthread (https://news.ycombinator.com/item?id=9009056 https://news.ycombinator.com/item?id=9009056): you're in tricky territory if you're giving direction that detailed. Giving a level of guidance that's appropriate is good. Treating a junior dev as incapable of working except as a puppet is soul-crushing.
    • jkaunisv1 12y ago
      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.
• mariusz79 12y ago
  Well, maybe it's not that they aren't very good but that you suck as a team leader? :)
• vpeters25 12y ago
  Maybe you could try an agile approach where instead of assigning tasks you put them in a board and allow each team member pick the one they like to do. Our experience is this makes each team member pick tasks that fit their strengths, or challenge themselves. You, as a team lead, can leave them along to handle it. They will ask for help, or mention they are stuck in the daily stand-up. EDIT: I guess I didn't need to be that blunt, thanks downvoters for pointing that out.
  • emodendroket 12y ago
    So what do you do about the perma-tasks that are on the board forever because no one wants them?
    • vpeters25 12y ago
      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.
• jleonard 12y ago
  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.
  • falcolas 12y ago
    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).
    • eurekin 12y ago
      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.
      • mrj 12y ago
        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.
• leading_who_ 12y ago
  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.
• protonfish 12y ago
  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.
• jackgavigan 12y ago
  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?
• jkaunisv1 12y ago
  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?"
  • porter 12y ago
    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.
    • jkaunisv1 12y ago
      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.
  • mrharrison 12y ago
    If you are stalled on something, AKA blocked in agile terms., then its the job of the scrum master to have people unblock you. Stand ups and agile are put in place to help people. Its sounds like the people in comment thread have had poor scrum masters/managers. I'm an engineer and scrum master and love the process of helping and being helped. Thats the whole point, not accountability.
    • jkaunisv1 12y ago
      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.
• rglover 12y ago
  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.
• TeeWEE 12y ago
  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.
• wallflower 12y ago
  I constantly like this comment from an AskHN from jlcfly from a while ago. I hope most of us embrace this philosophy as the reality is programming as an art is much more important than programming as a rote skill. And teaching programming as an art is much more about understanding the individual than it is about teaching them like a soldier (Andersen Consulting bootcamps - are an outlier). "Teach them to be better than you. That may seem counterproductive. I have a type A personality, and I have decent coding skills. I've been in your situation a number of times. I also know there's these mythical expert developers out there that I can't seem to find (or afford). So, what to do? A few years ago I realized that if I continue down this path, I'll end up with some serious health issues due to the stresses that come along with having a reputation for being a really good developer. So, I decided that instead of searching for developers better than me, I would teach developers I work with how to BE better. It's taken a lot of patience. And it's taken me quite a bit to LET GO of my way of doing things. I had to take my ego out of the picture. (VERY hard to do.) Nowadays, I realize that developers don't have to BE better than me. I simply have to ALLOW them to do what they do without being so obsessive about it. Turns out, even junior developers really CAN do good work. They just need a little guidance that only comes with experience, and then they need me to get out of their way." https://news.ycombinator.com/item?id=8649415 https://news.ycombinator.com/item?id=8649415
• reacweb 12y ago
  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.
• ghettoCoder 12y ago
  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.
• eurekin 12y ago
  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!
• fsk 12y ago
  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.
• datashovel 12y ago
  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.
• joedrew 12y ago
  Read this paper ("Set up to fail: How managers create their own poor performers"): http://www.insead.edu/facultyresearch/research/doc.cfm?did=46698 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.
• gcb0 12y ago
  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.
• vishalzone2002 12y ago
  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
• Simp 12y ago
  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=46698 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
• zpool 12y ago
  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...
• markbnj 12y ago
  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.
• PaulHoule 12y ago
  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.
• ProAm 12y ago
  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.
• mjv 12y ago
  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.
• michaelochurch 12y ago
  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.
• throwawayx 12y ago
  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.
• kendallpark 12y ago
  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.
  • 12y ago
• ScotterC 12y ago
  Introduce them to Pomodoro techniques [1]. I've seen this same problem with junior devs and they're not fully aware of it themselves. When you get them to track themselves using a tool like Vitamin-R [2], they'll be more aware of it and also want to fix it. 1. http://en.wikipedia.org/wiki/Pomodoro_Technique http://en.wikipedia.org/wiki/Pomodoro_Technique 2. http://www.publicspace.net/Vitamin-R/ http://www.publicspace.net/Vitamin-R/
• bonn1 12y ago
  Most of answers here focus around management as a general topic and ways to handle the two weaker devs. Nobody recommends to fire them. I am also not giving this advice because I am not aware about the entire company and team situation and can't oversee all implications. And maybe you might be the problem for the two weaker devs. I just know that the most important management skill is 1) to make the decision to fire somebody and to do this not too late and 2) then to execute it smooth and fast. And most managers are neither good at 1 or at 2 because of lacking practice. It's a though decision, it doesn't feel good to fire somebody and often managers ask themselves if they made mistakes in their leadership. But if you say that you just don't feel good how they do their work and if you don't see any potential for improvement then why don't you spend the budget for better engineers?
  • sukilot 12y ago
    Presumably if OP could find better engineers, he would. In the mean time, make better developers.
  • gclaramunt 12y ago
    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
• rbosinger 12y ago
  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.
• dugfresh 12y ago
  Is it just me or are there a lot of excuses made for these two developers? In every profession you have to do what your boss tells you. If you don't know how to do it you should speak to someone - a peer if not your boss. If you don't want to do your job (pass over for a promotion, the work is uninteresting, etc) then TS! It's irresponsible to slack off because you don't like some aspect of your job or work. If you're paid to do a job, then you should do it. These developers have the luxury of finding another job because the market is so red hot. A lot of other professions don't have this luxury.
  • sukilot 12y ago
    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.
• Jemaclus 12y ago
  Someone already mentioned Situational Leadership, but I'll just expand on that a little. There are four main methods of management in this paradigm, and it depends on how your team members work. * Low competence, high commitment -- these guys don't know wtf they're doing, but they're happy to be there. They need direction and guidance, very hands-on. The strategy here is "I talk, I decide." * Low competence, low commitment -- these guys don't know enough to work on their own (but maybe aren't totally incompetent), and they're discouraged. They need direction AND encouragement. The strategy here is "We talk, I decide." * High competence, low commitment -- these guys know what they're doing and can work on their own, but maybe they're bored or intimidated or not confident enough to really take charge of their own schedules. They need encouragement and advice. The strategy here is "We talk, you decide." * High competence, high commitment -- these are the ones where you say "Here's a problem, go solve it". The risk here is that they'll leave -- they don't need you anymore, right? The strategy here is "I trust you, you decide, but I'm here for advice if you need it." That's just a really rough overview, but I suggest picking up some management books. Like my boss tells me, "if you're trying, you're one step ahead of the game." Good luck.
  • brational 12y ago
    > * High competence, low commitment... The strategy here is "We talk, you decide." Can you elaborate on this one? What do you talk about and how do you steer them to their own decisions?
    • Jemaclus 12y ago
      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?
• sukilot 12y ago
  I bet you'll get great advice about making employees more productive, from people slacking off on HN on a work day.
  • brational 12y ago
    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...
• deleted 12y ago
  [deleted]
• IgorPartola 12y ago
  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.
• thirdtruck 12y ago
  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!
• tenpoundhammer 12y ago
  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.
• Thetawaves 12y ago
  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.
• endeavor 12y ago
  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.
• codecrazy 12y ago
  Fire the two losers and ask the two good ones for friend references. Time is too valuable to have to deal with unqualified help.
• codecrazy 12y ago
  Fire the two losers and get resumes of the two good developers' friends. Time is too precious to deal with poor help.
• gumby 12y ago
  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."
• Panamfrank 12y ago
  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.