How to manage an army of not-really-devs trying to write code for the sake of project management?

Question

We recently adopted a new management methodology that says there are no roles on the team (a "cross-functional" team where "all team members are developers") and everyone should we doing everything so we now have UX designers and QA engineers trying to ship code with some copy paste and online courses.

I have never been a manager before and I am not a manager of these people but since we have half the team suddenly becoming developers and as the only actual software developer (sorry if pejorative, but none of these people have written code before) not just ignoring newbie slack messages I am not getting anything done.

It doesn't help that each developer has a certain number of points required per sprint and there is no difference between people based on experience. The newbie developers really shouldn't have the same point expectation as people who have coded for years.

I approached my manager, but the project management method has been dictated from the top. Manager is also a dev and doesn't really want to deal with it. His manager finds the methodology strange but isn't willing to go against the people with the certs. Basically I dont think it can really be changed all that much so I need to learn how to work within the framework.

What are my options for dealing with this? How do you manage an army of really green people and get useful code out of them?

Answer 1

Cover your butt, and have an escape plan ready, because this will probably blow up in your face

You can't take a bunch of people who have never written code before and suddenly expect them to start making useful contributions. It simply doesn't work that way - learning to program in a nontrivial fashion takes months to years even for those with a knack for it. The fact that they're putting the same sprint expectations on everyone shows exactly how out of touch the "geniuses" who thought up this idea are. Unfortunately, since it sounds like you're one of (if not the only) dev present, when this catastrophically fails, you're likely to get blamed for "not teaching them well enough" or some such nonsense.

Realistically I'd say start polishing up your CV and looking for a new place, because any company that institutes a policy like this for more than a week is so incompetently managed that the best thing you can do is run very far, very fast.

In the interim, protect yourself. Send an email to your manager (and perhaps those higher-ups) clearly laying out that this approach is unworkable, that you cannot rely on the quality of code written by people who hardly know how to write an if-else statement, and that you believe both schedules and product quality will be severely impacted if this policy continues. Then, note that you're spending a lot of time answering beginner-level questions while still being expected to output the same level of work as everyone else, and ask for prioritisation - are you expected to do your work first, or to help these others get up to speed? If the former, you now have official authorisation to tell these people "just google it". If the latter, you now have a reason for reduced output compared to others, and the next steps here would be to introduce an enforced pull request process and essentially switch from developer to code reviewer.

It may not be what you want, but as I said, if this policy continues through more than a couple of weeks of greatly reduced output, it's time to leave. You should also make a point of informing your manager/higher-ups of the differences in output, quality and task completion before the new policy as compared to after. You need to showcase how ridiculous this policy is in terms they understand (i.e loss of profit) to get it reverted.

Answer 2

I work as a software developer for the department of heart-diseases in an hospital. So I hope by God this weird interpretation of "cross-functional teams" doesn't spread to here. Letting the doctors and nurses write code seems like a very stupid idea, not to mention the idea of me having to perform heart surgeries.

That being said if you absolutely have to abide by this obviously stupid idea, I suppose letting the not-really-devs try their hand on writing unit-tests seems like a good option.

1. Unit-tests are generally easy to write.
2. Letting the not-really-devs write unit-tests might expose that they sometimes have different ideas about what the system should do than the developers. so it actually might be useful in some cases.
3. If the unit-tests of the not-really-devs really suck just don't use them. No harm is done to the actual system.

Answer 3

My answer is going to ignore the fact that this is a terrible idea, and I'm going to write about how I would try to make it work if I were the manager.

Petition for more time

Significantly increase the projected deadlines for all outstanding projects.

Prioritise work

Ensure that your "real" developers are able to do the most important work, and ensure that you have sufficient bandwidth to make the most important tasks happen.

Manage expectations

Ensure all stakeholders are aware of the significant problems that may occur.

Organise training for employees

There needs to be structured lessons that gives your people the best chance of becoming competent programmers. If these have to be literal lessons, make them lessons.

Reist the urge to use employees as teachers

It's tempting to use employees as teachers to teach the other employees to code. That is not their skillset. Teaching is a profession. Learning programming from scratch requires professional help.

Borrow tech leadership from other teams

There are going to be a lot of code reviews that need a lot of work. Get as many experienced hands as you can to help the transition, even if they can only assist with code reviews.

Start hiring. Now.

A section of employees won't like this sudden and expected career shift, so start interviewing replacements now. Because people will quit.

Offload ill-suited team members

You are going to have team members that won't be able to adapt, but won't quit. Look to move them to different teams, and look to swap with interested candidates from these teams.

Heavily invest in tooling

You need to take use of listing tools to the next level. Hopefully they can catch as many problems as possible.

Answer 4

This isn't your problem, it's your managers, and further up the hierarchy.

Just keep your back covered and handle your portions. Eventually if everything comes crashing down there will be changes, but you don't have the authority to make them and most importantly you don't want any responsibility for them.

Your manager is the one who will need to deal with it. If he doesn't want to, he'll end as the scapegoat. Getting involved more than you already have is just putting a target on your back if/when things go South.

Answer 5

Yeah, you should get out. However, as a CYA step in the meantime (or if you think your workplace is prone to fads but they quickly blow over and you just want to mitigate damage while you wait this one out)...

Pair programming is definitely agile, and in this case you can pair your non-experienced developers with experienced ones. Your non-experienced developers should be contributing, regularly taking turns as the hands-on-keyboard partner, but they'll have a backup and someone to guide them. I also wouldn't turn my nose up at strategically making the non-experienced partner's hands-on-keyboard time dedicated to less dangerous tasks (unit testing, as someone else mentioned, or areas that have similar existing examples already in your code base that they can use as models). When they're the observing partner, they should have a lot to contribute since UX and QA usually have the best idea of how something fits with the rest of the application.

Side note, obviously "everyone contributes the same story points worth of work" is decidedly NOT Scrum or any flavor of agile, but if you're going to try to deal with that then you might try pointing out that the team velocity is going to at best remain the same (realistically, decrease) since testing still has to be done. If you had (say) 4 devs and 4 QA producing 16 points of work, you now have 8 (half-developers) and 8 (half-testers) still (at best) producing 16 points of work. Just in case some bright spark in your management got the idea that if 4 dev + 4 QA = 16 then 8 generic people = 32.

Answer 6

I have never been a manager before and I am not a manager of these people but since we have half the team suddenly becoming developers and as the only actual software developer... not just ignoring newbie slack messages I am not getting anything done.

The sections in bold indicate that you are making this your problem when it doesn't have to be. You are not the manager, so you are not responsible for your coworkers. And you've indicated you are NOT able do your job AND train them as well.

You should do your own work to the best of your ability --that's what you were hired for, and it doesn't sound like you've been explicitly instructed to go above and beyond that. Under normal circumstances you want to be as helpful as possible to all of your teammates, but in this case it would put you in the untenable position of having to singlehandedly compensate for a disastrous decision by the actual management.

In my experience, the only hope for sanity and job satisfaction as a dev is to be process-oriented, not goal-oriented. Do your best at your own work, while accepting that the ultimate fate of the larger project may be out of your control. http://mit.edu/~xela/tao.html

Answer 7

You may be misinterpreting management

No roles and cross-functional teams are usually initiatives to get the team working together and take ownership of your product as a whole. If bugs get deployed into production it is not the QAs problem, its a problem for the whole team.

Management is unlikely interested in having lots of substandard devs, but far more likely to want self sufficient teams working towards a common goal

Although this can manifest itself as anyone can work on any ticket, in practice teams and people will self organize to a process that works best with their skillset. Devs will pick up development tickets, UX will pick up design tickets, QA will test (manual, unit or defining acceptance criteria depending on your chosen flavour of QA).

Managing the team is now about making sure you have the right proportion of jobs in the right areas so everyone is used to their best of their abilities

Answer 8

What are my options for dealing with this? How do you manage an army of really green people and get useful code out of them?

First of all listen to @Xono and prepare to leave early enough.
In the meantime prepare your managers for the future. I found some arguments that I would like to list here.
Communicate them regardless if you are asked to or not.

• There will be a lot of time used to teach yor team, show them how to do things generally and how to think as a developer.
• There will be a lot of time to find errors in the software that arise sooner or later, where later can mean while running in the productive environment.
• This can mean loss of reputation.
• Some team members will quit because they don't see themselves in this position to do everything. Guess what this would mean? Right, this will delay your project even more.
• Also a lot of time will go by because even experienced people can't simply switch from one thing to the other. Every workflow programmed by someone is different, so if I have to know them all in detail because I do everything, it means more time to learn that.
• Prepare for confusion ... better call it "organization" because people (including you) don't know what to do any longer, instead everything must be organized again and again as tasks change and change.

Show this you managers. Not as a "can we do...?" but as "this is the outcome that you silently accept".

Be aware you are the direct responsible one for that.

Answer 9

First of all, this situation is hilarious (for outsiders, I guess not for you)

The most important thing is to document your perspective now (instead of when everything has already collapsed). Write an email to your manager/s saying:

"I am very uncomfortable about the idea of bringing untrained developers into the project. I'm happy to cooperate with management, but I'd like to list out my thoughts before we fall into some very difficult times:

• [how long it takes for developers to become proficient]
• [how skill and efficiency is hugely variable in software development]
• [how programming can be very frustrating and unpleasant for those who don't enjoy it (big impact on work morale)]
• [how my own work will cease as I become full-time teacher, OR how team morale will go down when people need my help but I block comms because I'm trying to keep up my output]
• [how poor code quality introduces technical debt that could permanently stall later improvements to the product]
• [how poor code quality introduces bugs that will damage the reputation of the company/product]
• [how you wouldn't trust a hospital's accountant to perform heart surgery, or an airplane steward to land the plane]
• etc, etc

When you've sent this email, the best case is that they realize how absurd it is and go back to normal. The worst case is they try to blame you for the group's output—when this happens you have a paper trail documenting your view against this practice from the start.

Answer 10

I don't disagree with the other answers, and read Xono and puck. This is such a mess that unless the company changes course the project is doomed, and I would be preparing my resume.

You should also communicate the unworkability of this plan by every means available, as forcefully as possible, and I wanted to add some other options for doing that.

1. Absolutely tell your senior managers all the reasons why this isn't going to work. But you also need to give them concrete data to prove it.
2. Make a request for training for all the people who can't program. Ask to enrol them in programming courses.
3. If the above is denied, assign them to learning the language(s) you are using with free resources. Do this even if they don't complete any work because of it.
4. Make for yourself a rough estimate of the number of story points the entire project will take. You will need it later.
5. Make sure you don't allow any stories to be completed until they are of sufficient quality. You yourself spend time making sure that the newbie's don't introduce bugs, and making sure they understand what is needed from them.
6. The likelihood is that your team will be hugely unproductive in the first few sprints of this, completing only a tiny fraction of points. When this happens, tell the bosses that they are seeing the reality of this method of working.

Answer 11

It looks like an amazing opportunity, given you take a few precautions. Perhaps an escape plan could be in order, but not necessary :)

If it is in your power, put experienced developer as subject mater expert and, with his help, break the tasks down to the core.

Meaning that each task should be completeable "in one sitting" with minimal supervision / googling

After a month of this, produce a report of green developers time to complete tasks and experienced developer time to break outstanding big tasks to these tasks.

Having these numbers management will be appraised about the situation and can make an informed decision.

Answer 12

It seems like this is an experiment. Sometimes experiments fail and this one is likely to fail. The first thing to try is to just wait it out until the people who are running this experiment figure out it's not working. The worst that will happen is that deadlines will slip and there will be bugs. It's not the end of the world.

Every "large enough" team should have newbies and these newbies should be mentored and given opportunities to grow mastery. But if what you're describing is accurate you got "all newbies" except for yourself, that's a bit too far.

It could be that the ones in charge have not even the slightest idea of what is involved in SW development and have unrealistic expectations. It happens a lot. To some extent, it is your responsibility to communicate the nature of the work. To some extent, the people in charge need to see the consequences of their decision.

Answer 13

This is the kind of a very tricky situation. Making a team of non-developers to write code is something you shouldn’t attempt, unless there you are not answerable to a client or you are working on an experimental project. Writing good code requires good experience, knack, decent coding instinct, and passion for writing code. Nurturing an ‘army’ of non-developers to turn them in coders, given to the kind of hierarchy you are working with, is just going to be extremely difficult. Even an experienced team coders do go wrong under pressure and certain circumstances. Instead, what you can do is that, as a rudimentary step, learn from experts about how to smartly manage team remotely and ways to improve developer productivity and code quality.

Here, you can learn more about ways you can manage remote development teams through engagement, transparency, team flexibility and decision making.

Here are some very useful insights about how you can boost developer productivity and improve their code quality.