Ask HN: How to manage developers who aren't very good?
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?
206 comments
[ 4.4 ms ] story [ 65.7 ms ] threadEDIT: 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.
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.
Sometimes people need development to become productive members.
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.
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 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).
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 also be that another developer would get the work done. Unfortunately is it not easy to know which option is correct.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
> 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.
Development is so vast. You can be doing embedded systems, mainframes, aircraft software, or web software.
It was shocking because it was rude and uncalled for.
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.
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?"
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
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.
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.
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.
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?
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.
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.
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.
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.
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.
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).
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.
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.
That's far from an interrogation
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.
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.
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.
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.
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".
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.
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.
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").
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.
I managed to fix this by getting a new job where I didn't have to manage. ;)
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.
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.
- 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!
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.
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.
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).
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.
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 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.
-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
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.
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.
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.
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.
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.
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.
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.