How can I lead co-workers into active problem solving instead of expecting explicit numbered instructions?

Question

I am a software developer with 10 years of professional experience. In order to gain experience leading a team, I have decided to be involved in a side project with a friend who switched careers via a coding bootcamp, people he met there and some fresh college grads. This friend has over a decade of experience in other fields with some management experience. So he runs the weekly meeting. Said friend and I are responsible for the back-end programming portion of the project.

Most meetings or weekends when I try to work with him, he says he's too tired from his day job or family. He did ask me to help once, but I had unplanned obligations and when I got home, I followed up to which he replied he was burned out.

I have written functioning code and given it to friend to make some changes to. It's a good opportunity to gain experience and ask questions. I have written instructions on how to run everything he needs, and prerequisites he needs like Python and a JRE. However, I didn't go through every step to install the prerequisites; I gave him links with instructions. He is insisting that he be provided with explicit numbered instructions; I explained that the purpose is to move from an I'm lost mindset to an I can solve this mindset. All of this can be learned by searching and reading.

It's an important skill in software development when you're faced with a challenge which is why I objected. Later, he told me I make the meetings toxic that I need to be supportive and honestly, I'm aggravated. I would be more receptive if he tried things and had questions. I find helping people who ask programming questions at work rewarding when I can solve them, but it seems like he just wants to be spoon fed. What can I do to lead appropriately? Am I asking too much of someone with coding bootcamp experience?

Edit: I've been texting him since November and asking at the meeting if he looked at it and to reach out with questions. He almost always said he was tired. He has only recently said he looked at it.

Answer 1

The hardest part of getting going on any project is getting the initial compile to work, the "Hello world" step. It's unreasonable to tell someone, particularly someone who isn't an experienced dev, "here's some links, download some stuff and get going".

There are only two possibilities: it really is pretty simple, in which case you writing out the steps is maybe 30 minutes of your time, not a big deal, and you might as well just do that rather than having hours of arguments.

OR the more likely case: getting the dev environment running is going to involve the usual pain of obscure error messages due to missing packages, wrong versions, incorrect search paths, etc etc etc. In which case your buddy has a good point that he needs more info.

I'd suggest just doing what I usually do in such cases: set aside a couple of hours when you two will sit together and get his environment running. Keep a document file open and track the steps, the problems, the error messages. At the end of that time you'll have that complete list for when you need to set up yet another machine.

When working together on the setup, your co-worker should be the active person, typing commands and maintaining the setup document. Your job is to be a resource, keep him on track, and help when he's stuck. This is going to be harder than it sounds because you'll have the urge to just grab the keyboard. But by having him type the commands and write documentation he stays engaged instead of falling into a passive watcher role. He will also find things that need to be documented that you consider too obvious to mention.

Answer 2

The first step into "leading co-workers into active problem solving instead of expecting explicit numbered instructions?", is actually making sure the problem being solved is relevant.

Requiring someone with a very rudimentary understanding of programming to set up their own programming environment, is likely to kill off a lot of motivation to learn. There is a reason a lot of websites have online interpreters so users don't need to install anything or screw around setting things up.

Answer 3

You're right that in IT people being able teach themselves is an important skill, but I don't think you can teach it by handing them some links and saying "get on with it", you have to actually teach it.

When they get stuck you need to show them the techniques that you would use, that you've completely internalized and probably think of as just common-sense.

So sit down with your friend, ask them what they've tried and then walk through what you would do, in that situation, if you didn't have the knowledge about JREs and Python versions. I'm guessing you'd focus on the importance of exact error messages, where to search for them, how to focus on the most relevant answers on stackoverflow or use the official tutorials, recording the steps you've taken, so they remember what they've done and also in case some fixes don't work in combination with each other.

I'd also focus on recognizing when you're making progress ("OK, so our first file has an issue with M1 chips, but now we've downloaded the new one, we get a different error, so we're moving forward); as a relative beginner it's easy to get disheartened and just think you're still stuck, when you've actually got a bit closer.

Hopefully at the end of this they have a working IDE, and also know more about how to self-serve themselves but also when to reach out to you and what you'd need to know to help them.

Answer 4

You said you are doing that to gain experience leading a team (and teaching I suppose).

So the first thing you need to learn about teaching is that it is not a passive act. You don't give someone material and tell them to figure it out. To Google it. To look on Stack Overflow.

That will only lead to that person being frustrated with you and with sites like Stack Overflow. Because we are not a service for people that don't really know what their problem is, they will just get downvoted and closed.

I wrote about it in detail over at SO Meta:

Every time we have an intern or apprentice, we should teach them how to find help here, instead of just rolling our eyes saying "oh come on just google it". Every time a friend asks for programming help, we should take them by the hand and teach them how to use SO instead of just sending them a link over IM.
[...]
We need to be better at helping before people get downvoted here. In meatspace. Where it counts.

Teaching is an active act. You need to be doing it. What you should do is provide a list and then taking the time to do it with them. Explaining things. Helping. Making sure they don't get stuck. Active teaching. Not just sitting somewhere saying "you can come with questions after you have stumbled around long enough and wasted enough time on your own to be worthy of my help".

If you do the same in meetings, I can see why they don't like it.

That said, you said you were not even brought into the team to teach, you were brought into the team to get a job done. If I bring someone into a team to get a job done, and instead of a job done they give me a vague list of things I have to do to get the job done myself, I would seriously question their value to the team.

So as a first step, make sure you get the job done. This is your first priority, because this is where the team sees your value.

As a second step, ask the team where you can help. And then help. By doing the job with them, by having teaching moments that cannot be had from online tutorials. Because sending someone a vague list of what to do is nothing else. It's just another tutorial, just not as well done as the previous ones.

So if your colleague needs their environment set up, do not leave them to it. Do not send a numbered list of steps. Take the time and do it with them. Screen sharing or sitting next to each other at a desk. Let them try their best attempt, if that doesn't work, explain yours. That is how they learn. Do not leave until the job is done. That is how they will see you as valuable to the team.

Answer 5

From a personal point of view, I've been on both sides: yours, and your friend's. As arguable as it can be, I found that these are parts of a Dunning-Kruger effect¹ combined with a bad timing/organisation.

1. From his POV, you expect too much from him at this stage of your cooperation. He has other things to do, with very low experience, and needs more from you. That leads to point #2.
2. He probably feels overwhelmed right now, while you expect more from him. With such mindsets, your relationship will effectively slowly become toxic.

To my experience, you should, both of you, calm down, sit down, discuss, reorganize the todo list, and walk at a slower pace if possible. Right now, he feels lost, with his head under the water, with you keeping pushing down.

It's not because you can do it fast that he can keep the pace². So it would probably be better to chunk this into smaller bits, so that he can success doing them. Set new goals with less "Google this / RTFM" parts and more (smaller) goals he can achieve. Important points, not all of them or too much. Otherwise, your collaboration is doomed, and, for the sake of both of you, "cutting down the losses" now would be a better thing to do.

The last paragraph of the Dunning-Kruger definition says that the source of this error (thinking that others have the same skills and abilities to understand and do things as fast as you) is not the self-assessment of one's skills, but an overly positive assessment of the skills of others, know as a form of the false-consensus effect. Also known as consensus bias, it's a pervasive cognitive bias that causes people to "see their own behavioral choices and judgments as relatively common and appropriate to existing circumstances. In other words, they assume that their personal qualities, characteristics, beliefs, and actions are relatively widespread through the general population."

^{1 & 2. Every day, I teach/coach different people with different skills and mindset. The hardest part of my job is to find where to point the cursor so that they learn better. I'm obvioulsy more skilled, not obviously smarter.}

Answer 6

Incremental Learning only works if there's something to increment on.

The poor guy has nothing. The DEV environment isn't working, the configuration instructions are incomplete, and he has no idea what's going on, since setting up the DEV environment is really a Systems Administration task.

Without a working environment, he has nothing, and building on top of nothing is literally one of the most difficult task in existence.

Your first task for this (effectively) junior developer shouldn't be setting up a DEV environment, but to run code.

In addition, you also mention both Python and JRE (Java). That's just about as confusing as ever. He might be trying to python main.java and have no idea what's happening. Python isn't going to tell him that he shouldn't be running Java code in Python.

Answer 7

It seems like your friend hasn't moved past the "tutorial hell" stage.

One way to move past that stage is to find a project that has been done a thousand times before, so you can find many good tutorials on it and many github repos on it.

Then the person must start the project, only using general documentation, without following any of those specific tutorials/repos they found earlier. Even if that person does every single thing wrong, that's a very valuable thing to do. It primes their brain to receive the correct information.

And yes, once they're stuck for a certain amount of time, they can briefly look at one of those tutorials just like if it was a hint (and if one tutorial/hint doesn't work, they'll need to look at another one, hence the value of finding a project that has been done a thousand times before). And they'll need to repeat this cycle trial and error many times over.

Problem-solving is a muscle. If your friend doesn't practice that muscle, they're not going to progress.

Am I asking too much of someone with coding bootcamp experience?

Not everyone from a coding bootcamp is stuck in tutorial hell.

With that said, I do think you've done too much for that person already. Stop writing the code for them. I don't think that's going to help. And no, I don't think numbered instructions are going to help either. Writing a bulletproof tutorial is going to take you forever to write, but pedagogically speaking, one more tutorial is not going to help them progress as a developer.

Aside from teaching them about "tutorial hell", you can also drill them and give them short bite-sized programming tasks from Codewars (or later on from Leetcode), but past a certain point, you may need to say "no" to them and walk away from this project.

Your friend is correct to a degree. If you two do not see eye to eye this issue, your meetings are going to become toxic. And good leaders know how to lead teams, yes, but they also know how to cut their losses and move on.

Answer 8

I don't think this is a problem with instructions, active problem-solving, or anything else technical. They're telling you what the problem is: they're tired, they're burned out, they don't have the energy to take care of both their day job and this side project. Something has to give, and right now it's the side project.

There are a variety of options, each with pros and cons. Fundamentally they boil down to either reducing your friend's workload (day job, side project, and general life) to a level that they can manage; or making this no longer your problem.

The latter is simplest - you can quit this side project, then you no longer need to care about its success. That will likely have a very negative effect on your friendship, and it won't help your friend.

Reducing your friend's workload has many options. Here are some:

• Can someone else do the work that they're supposed to be doing on the side project? Maybe hire another team member, or spread the work over existing people?
• Can the side project be put on hold for a while?
• Can your friend reduce their load at their day job? Maybe change roles, maybe drop a project, maybe take a sabbatical, maybe go part-time?
• Can someone help out at home? Maybe that means hiring a cleaner or a nanny or a meal service.
• Have they explored therapy or similar? It's no panacea, but there may be tools (and I don't necessarily mean software tools) that your friend can use to help manage their workload.

It's possible that his plan was/is for you to do all of the work. It's also possible he genuinely thought he'd be able to juggle it all and he might've even thought he'd be doing most of the work. It's easy to misjudge a software project and one's own limits. Especially when you're brand new to the field. It sounds like you might be the only person on the team with enough dev experience to really judge the scope of this project.

I think it's worth meeting with your friend outside of work and having a frank talk about the problem and what to do about it. I would rehearse a bit to find some ways to phrase things that won't put him on the defensive. Talk through what the options are, consider trying some of them. Most of the options I listed can be undone if they don't help. The two of you can probably come up with more options.

I would talk face-to-face in a casual, comfortable place. If face-to-face is not an option, then a video call or phone call. Text or email adds a ton of risk for misunderstanding.

You can also discuss this with the other founder. Maybe you do that before your conversation with your friend, maybe after. Maybe you make it a three-person conversation. Personally I'd lean towards one-on-one with your friend first, but you'll be a better judge of the personalities and possible outcomes here.