73

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?

4
  • 1
    Comments are not for extended discussion; this conversation has been moved to chat. – motosubatsu Apr 13 at 12:00
  • "...since we have half the team suddenly becoming developers and as the only actual software developer..." So, the "team" is you and someone else? What constitutes "an army"? – teego1967 Apr 14 at 11:42
  • 2
    So has management also relinquished its role and can you make executive decisions? I very much doubt it. This smells like a half-assed misguided attempt at covering their inability to hire/pay experienced staff. It's noble for you to try and correct the issues, but I suspect this is insurmountable for someone in a non-managerial position. – Flater Apr 14 at 14:24
  • 3
    If they have communicated the expectation that you are the one to make this all work, then I hope you realize that your manager and his manager are signaling that they are going to let you be a scapegoat. They may seem like "nice guys" but they are cowards who won't protect you from stupidity now and won't protect you from blame later. – iconoclast Apr 14 at 21:19

13 Answers 13

144

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.

9
  • 64
    “when this catastrophically fails, you're likely to get blamed for "not teaching them well enough"” - I wish I could upvote this a thousand times – Joe Stevens Apr 12 at 6:40
  • 18
    One addition to the OP: DO NOT SIGN ANYTHING, especially avoid any statements, contract updates etc. And if you can't take the paper to your lawyer or union representative (or just home to read it, but your employer does not need to know that) definitely signing it would hurt you. – Mołot Apr 12 at 13:32
  • 2
    "Do Not Sign Anything" - includes signing off check-ins / code reviews / pull-requests. – freedomn-m Apr 12 at 14:37
  • 8
    Also, make sure your source control system is tracking who the author of each commit is! – DanK Apr 12 at 15:21
  • 30
    When this blows in your face as mentioned in comments above, you can go down with style and just tell them you couldn't teach others how to develop because you yourself were learning how to write finance reports and design user experiences. – Chapz Apr 12 at 15:22
39

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.
10
  • 9
    I'd say harm is done to the actual system by these people not doing their normal job anymore - if your QA spends all their time writing unused unit-tests, then who is doing the QA work? – Erik Apr 12 at 8:28
  • 25
    @Erik Why, UX of course :D – Mołot Apr 12 at 13:33
  • 22
    I do not agree that unit tests are easy to write. I had seen in my experience unit tests that are testing wrong things, do not contribute meaningfull value to the project and are in the codebase just to be maintained. If non-dev person writes unit tests they will only be a thing to maintain in the future without value. – Shoter Apr 12 at 13:50
  • 2
    @Shoter Oh... unit tests are easy to write. Making them useful, covering needed corners, making them performant, etc... THAT on the other hand... Just like learning chess rules is easy. Becoming a Grand Master is not so much. – WernerCD Apr 12 at 14:34
  • 2
    I think you'll have a hard enough time teaching them what unit tests are supposed to accomplish. For my first two years as a dev junior I just wrote tests that 'touched' the necessary code, without really validating it did what it was supposed to do in a sustainable/flexible way. – Weckar E. Apr 12 at 15:40
25

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.

5
  • 4
    While I think most of these suggestions are good, the asker is not a manager and I'm not sure if they can do any of these things. – Erik Apr 12 at 8:29
  • 7
    @Erik "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?" The other answers answer the first question, I attempt to answer the second. – Gregory Currie Apr 12 at 8:30
  • 1
    @GregoryCurrie "Manage exceptions"? I may fail to see your intentions here, but I think you meant to write "Manage expectations"...? – orithena Apr 12 at 13:52
  • 1
    @orithena Spot on. Thank you. – Gregory Currie Apr 12 at 13:55
  • "people will quit" <- Maybe sooner than later. Sooner for the best employees who can find another job easily and can see the incoming mass failure of the company. – A. Hersean Apr 12 at 14:02
15

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.

4
  • 7
    "he'll end as the scapegoat" - I am not so sure about that. Managers tend to be the scapegoat only after everyone below is gone. OP is installed as a supervisor for this team, that means if this team fails then OP will be the first person to be in problems. – puck Apr 12 at 6:15
  • 1
    @puck I didn't get that he was the supervisor. Just that everyone else is hiding behind Slack, so he sees it as his problem as nobody else will do it. – Matthew Gaiser Apr 12 at 6:49
  • @MatthewGaiser you are right, supervisor is never mentioned in the question, but as the only programming-aware person I see OP as some kind of responsible person in this upcoming mess. – puck Apr 12 at 12:38
  • @puck, the manager is a dev, best for the op to keep out of the firing line, he's already done enough. – Kilisi Apr 12 at 12:58
7

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

6
  • @ColleenV "Just following orders", right? Honestly, even though there's nothing illegal going on here (probably), if the OP is still there next year and the next new hire asks why this software is a pile of *@&! and the OP says "we were just following orders"... It's in the OP's best interests to either find a way to make things not a pile of *!&# or get out ASAP. – user3067860 Apr 13 at 12:18
  • 1
    @user3067860 It's called doing what you're getting paid to do. I could try to teach our hardware guys to do software. That's not what I was hired to do and not the best use of my time or their time. If they're being required to do work they don't have the skill to do, they need to take that up with their manager who should get them the proper training to do it. If I try to provide that training, my work suffers and they get half-assed training. I get a bad performance review, they get a bad performance review, and the actual problem never gets any visibility. – ColleenV Apr 13 at 13:18
  • 1
    @user3067860 - To be blunt, not necessarily true. It's in a dev's best interest to a) always do their best work, and b) to be as helpful as they can to others WITHOUT endangering "a." But it's not in a dev's best interest to play manager unless they have specifically been given that role. // I've been involved before in mutli-year projects that never even made it to production --because of management decisions. Those were the best years of paid, hands-on learning I ever received... and no one has ever blamed me for the product not shipping. – Chris Sunami supports Monica Apr 13 at 13:55
  • @ChrisSunamisupportsMonica Actually, you do seem to be right. Because my resume of actually keeping something alive and working after it made it to production despite the horrible design decisions made before my time and above my head is viewed as basically useless. So yup, just do your best to make sure the project never actually goes live, and then you can spend years on "paid training". – user3067860 Apr 13 at 16:59
  • 2
    @user3067860 - In my experience, the only hope for sanity and job satisfaction as a dev is to be process-oriented, not goal-oriented. There's a world of difference between my suggestion --which is to do your best at your own work, while accepting that the ultimate fate of the larger project may be out of your control --and what you're implying I suggested, which is to actually sabotage a project, or hope for its failure. mit.edu/~xela/tao.html – Chris Sunami supports Monica Apr 13 at 19:28
6

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.

6

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

3
  • To add to that, what I've seen is if you need more of X during a sprint you find the non-X'ers who are best at it. The OP would be expected to find the few testers who want to get into coding and put them on the easy stuff (if you always need many more coders, then it's just a bad team mix and not your fault, unless you can play to the team's strengths). – Owen Reynolds Apr 12 at 16:36
  • 2
    This. I don't understand why a UX designer would decide to take, e.g., a bug fixing ticket. Just let people in the team take tickets they are interested and competent in solving. It's not up to management to distribute the tickets anyway. – njzk2 Apr 12 at 20:42
  • 3
    I don't think "you" is misinterpreting management. I think it is a game of telephone that probably started outside the company. Some director heard this exact idea, described it poorly to the board, who described it poorly to the CEO, who; and so on. – Odalrick Apr 16 at 8:02
5

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.

3

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.

2

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.
2
  • While the other answers are trying to be helpful and proactive... the truth is, this is the right answer. Bail. This isn't just a red flag, this is the company covered in a red shroud. It's a dead company walking, at this point. Start job hunting and interviewing. – Dewi Morgan Apr 12 at 16:41
  • 1
    Actually I'm trying to be helpful and proactive too. And Xono communicates the direness of the situation as well as I do. – DJClayworth Apr 12 at 17:29
0

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.

0

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.

-1

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.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .