Developers can't see what they're doing wrong

Question

I am a tech project manager, and I recently moved to America after 13 years in Europe where I worked as a software engineer. I worked for important customers and developed in any sort of environment.

I am now leading a team of two senior and a junior backend, two frontend developers and two DevOps engineers.

After one month, I came out with a list of technical debts to cover, including important ones (password and key exposed, development environment not protected, code duplication, lack of integration and UI testing and so on...).

Every time I request a meeting with the developers, they simply say: "It works, why change?". Once they told me: "You're wrong!" in a very rude way.

I recently left a comment on a PR for not respecting one of the SOLID principles and their reply was that I was nitpicking them. (Please note that I wasn't rude in my comment.)

The CTO completely trusts me, he said: "If they don't want to do what you tell them to do, they can simply quit the job!"

I always considered myself a leader (i.e., "Let's do this!) and not a boss ("Do this!"). Getting people fired is the last thing I want, especially now that one of them has a small child.

I would like them to understand why I want to do something. The former PM left for this reason and she warned me.

P.S.: No, I don't want to change company. I am paid really well and I have an excellent healthcare plan for me and my family.

Answer 1

I would like them to understand why I want to do something. [...] Any advice?

Don't theorize, show them.

Their current state of mind is that they know what they do works. And you come over and tell them that theoretically this is bad. You will never win anyone over by telling they are doing a bad job, while you could do a much better one. Everybody can say that. It's like people sitting on their couch watching TV yelling at professional athletes that they could have made that play better.

If you want them to follow you, lead by example. If you see something that needs improvement, show them how it fails. Provide them with a practical, real world solution.

You want a code adhering to more of the SOLID principles? Then give them a practical example why the current code is not optimal ("If I do this, it breaks") and then suggest a real alternative ("I have changed it to this, now it can no longer happen").

You have many regression bugs that would not happen with better testing? Well, compile a list and have them test each and every one of them with every release. That is what is neccessary for the business. And then write one of those as a unit test, show them how simple their life could be and let them decide whether they want to spend their time doing busywork going manually through a list of tests for hours or if they want to have a fancy automated test suite they can run by just snaping their fingers.

The point here is to not tell them what could be better. In theory everything could be better for them if they just won the lottery. Pick a specific case, show them why it's bad and then provide a working solution. Not a buzzword or a theory but a practical first step they can take right now.

Answer 2

Simply telling your subordinates to do something they can't see the benefit from is a recipe for disaster, which you already acknowledge, so make it fun for them. Gamification may not be easy for you to do, but can pan out to smooth out other, rougher, spots.

In a study conducted by Sharp et al. (2009), the researchers suggest the most influential factor on developers’ motivation was their ability to identify with their work. This means that most developers must find a sense of purpose in the work that they do, or their motivation to continue working will decrease.

https://medium.com/gameful-design/does-gamification-work-in-the-software-development-process-76780e49e545

You might also want to block out some time to show them not only how to do something, but also how it improves their code, their ability to maintain it, and how it can speed up their development process. Another answer by nvoigt talks about it, but I'll say it slightly differently: Show, don't tell.

You'll probably need to start out slow, such as 2-3 hours one day a week. Start out with something that's a complete mess, or simply over complicated and difficult to understand. Maybe it's something they all hate working on, but don't show them how to fix it yet. Just use it as an example, then have something else, something simpler, to show them how to do minor improvements to code can have major effects. Once you go through maybe 2-4 of these small improvements over a couple of weeks, bring it back around to the "monster mess" and use the same techniques you showed them previously to reduce, reuse, and generally uncomplicate the spaghetti code you first showed them.

You might even want to iterate through this approach. Teach them a couple things then use it on the "monster mess". Teach them a few more things, then use it to further improve the monster. Lather, rinse, repeat.

And don't just do it all yourself. Ask for ways people can see to improve the code. It's only partly a lecture, you need to get your people involved in the process. For correct answers or even close concepts, you an hand out mini candy bars, like Halloween candy (the good stuff, not the cheap junk). This also gives them an extra sugar boost for the brain to work better.

You may find that some of them already know what you want to use, but are under them impression they don't. I'm mostly a self-taught programmer. I've done lots of research over the years and understand all kinds of concepts, but I don't necessarily know the terms for those concepts. (I recently bombed an interview because of this.) They may also already use the concepts and think you aren't recognizing them for it. Or they are using them incorrectly and need only minor adjustments to do it correctly, instead of an overhaul of their process. There's a lot of different social or culture issues you may be running into that are the cause of the friction, rather than it being anything to do with the technology.

Outside help

There's also plenty of websites that are centered around gamifying coding, even if they don't necessarily teach SOLID or the other principles you're trying to implement. You'll just need to research to find one that does. I've used CodinGame to improve my coding skills, but I don't remember specifically what principles, if any, the challenges taught. There's many challenges on the site and most are made by members, so they keep getting added to, so there might be something there you can use. Just make sure to get approval to do this on company time first. And yes, it needs to be done on company time, otherwise it becomes "homework" that likely won't be done.

Implementing peer programming can also help. Pairing up a senior and a junior to work on a task can teach both of them new things. It can also help them to overcome a hurdle in their learning. This can be the equivalent to 1-on-1 teaching, without you having to do the teaching. Also, one of the best ways to learn is to teach. If you can explain it to someone else, you understand it. And the easier you can explain it to someone else, the more likely you truly understand it and aren't just repeating what a book or article says.

Don't force it

No matter what you do while trying to get your team to do these "new" principles, make it compelling to them as a developer. Don't use a Performance Improvement Plan (PIP), like another Answer suggests. Putting people's jobs on the line is nearly a guaranteed way to get them to leave regardless if they complete the PIP. And if they stay, they won't trust you to try to implement more changes and another PIP. Just like every other part of life, ultimatums rarely work and almost never improve trust.

Explain to them how it's going to improve their work and personal lives. An exposed/unencrypted password can lead to breaches that'll leave them working around the clock to try to patch and restore anything mangled by the hack. Don't leave this up to chance or some imagined/unspecified distant time in the future, ask them how they would react if this happened during an important time in their life, like a wedding, vacation, kid's sports game, or whatever. Make it a practical example, relevant to them. Then remind them that fixing it now prevents that kind of disaster.

Explain how making things simpler reduces their mental load when making future changes. Explain how reusing the same methods can not only make the code simpler, but also makes it easier to find the code they are looking for. Explain how polymorphism can reduce lines of code and how sometimes it may not be appropriate. Yes, explain how some of the concepts you want to implement aren't always necessary or sometimes unnecessarily overcomplicate things. Also explain that most of these changes can be done iteratively as they are needed, not "just because I said so". Most of these concepts are just "rules of thumb", rather than set is stone, which is probably what they are really pushing back against.

Sure, this leave the door open to changes happening more slowly, but that's probably going to make it work better. Just like a diet, if you make too many changes too suddenly, you'll be off the diet faster than you got on it, and you'll never be able to get back on the diet.

Caveat

Don't try to do too much all at once. I had a manager give my department a several hundred page book on SOLID principles and made us all read it. It was so boring, I couldn't make it even 5 pages without nodding off. This was while the manager was trying to make us change a very significant amount of how we wrote code almost overnight. Yes, we needed to make those changes, but there were so many changes that we couldn't keep up with it all. And it was all a command, with no room for questions or even explanations of what or why the changes were needed. Along with other significant changes in management attitude, this led me to find a different job after 4 years of being there.

Your people likely have gotten comfortable in their positions. That's not necessarily a bad thing, but the changes you are trying for are making them uncomfortable. Being uncomfortable is generally when people learn things, just don't make it too uncomfortable or you'll lose people. And you can lose them without them actually finding a different job. Make sure to work with them when they struggle and be understanding when they have reservations.

I'm not saying to baby or coddle them, just don't be a brick wall, where everything bounces off and they can't get any answers.

Answer 3

It sounds like you are stressed up because of this. You need to get this stress out of you. Here's what I would recommend:

It sounds like the team doesn't know the importance of all the technical issues you have pointed out. There are two ways of making people understand:

1. Make them fix those issues and then track results
2. You take care of those fixes and showcase the results

The latter has always worked for me. When you get this right and when the team sees the value out of what you have done. They are forced to take care of it going forward, naturally.

You can just pick one of those technical issues, that you are familiar with and where you think you can make a difference.

Get started and keep us updated...

Answer 4

You need to attack this problem on multiple fronts:

First, offer to pay for classes that teach the practices and reasons for using them. Offer a bonus and/or pay increase to any of them that earn certificates. Give that no more than two months to start getting some traction. You may find that some of them are willing to put forth at least some effort.

Plug the data holes. You need evidence to support your claims. All code check-ins should map to a bug, feature or user story. Start measuring time spent working those bugs and features. Add frequent post-mortems. You all need to know exactly how much effort goes into rewriting code vs adding new code, for every task. Go back and analyze old bugs. What was the root cause? Was it a day-zero bug or introduced because "code that works" was bent to add something new?

Hire a consultant to review your codebase and development practices, and write up a top-ten list of things the company should fix.

Start preparing to fire people. First, bring in a senior engineer on a temp to perm basis (preferably one with said certification(s)) and start working with them to fix some of the more egregious issues. After a few months when the temp has a handle on the code base, hire them and bring in the next temp, then fire the dev that worked the hardest to block your efforts. Rinse and repeat.

One way or the other, you must have the right team on the job. If it's not the current hacks, then you have to replace them. While you can be a mentor, and promote life-long learning and continuous improvement, it's not your place to educate them, because that's just not your skill set.

Answer 5

Preface

Since this question was posted on Project Managment Stack Exchange and not on The Workplace or some other relevant site, the only valid way to answer this from a project management perspective is to focus on organizational and project management responsibilities. That means trimming away a lot of the non-essential parts of your question, and focusing on the core project management aspects that have either canonical answers or at least widely-accepted best practices.

TL;DR

You may or may not be involved with a dysfunctional organization, but you are certainly misunderstanding your role within the project management space, and may lack the appropriate skills and organizational empowerment to do your job successfully. Your primary objective should be to collaborate with both your leadership team and your developers to iron out functional working agreements that meet the organizational objectives for the project while simultaneously empowering everyone (including you) to continuously refine the process until it meets its outcome-based objectives.

Situational Analysis

There's a lot of material in your question that basically boils down to a few key elements:

1. You may be dealing with some differences between US-based and European work cultures. Even if that's not a direct issue, it is certainly coloring some of the perspective and framing of your situation, and you need to acknowledge this aspect of the issue.
2. The CTO is not taking ownership of the problem or willing to exert direct authority. When a C-level executive says that people are free to quit (rather than that they may be fired) that person is refusing to exert direct authority and putting you in the position of having to resolve the problem through influence rather than delegated authority.
3. Your development team is resisting your recommended approach, whether presented in the form of suggestions, directives, design principles, or whatever else may be at issue. The fact that they are doing so in a way that you perceive as rude is an indication that you have not earned their respect through either delegated authority or soft-skill influence. The end result is that you have no ability to effect meaningful change, if that's even an organizational goal for you.
4. From a project management perspective, nothing in your post addresses metrics, KPIs, project controls, or anything else measurable. Change is hard, and needs to be led from a place of vision and through the application of enlightened self-interest. Project management as a professional is often a difficult role precisely because it's a role with a great deal of accountability, but very little direct or delegated authority. As a result, project managers are usually most successful when they focus on project controls around budget, scope, schedule, and quality, rather than on architectural or engineering issues.
5. Your conception of your role needs clarification. Are you intended to be a middle manager, a servant-leader, a coach, a business process thought leader, or something else entirely? The fact that you don't have a clear idea of how you're supposed to be leading the team, and no direction from senior leadership of what you're supposed to be leading the team to accomplish, are always indicators of an organizational process problem.

There are certainly many other issues raised by your post, as well as the way you're framing them. Nevertheless, I strongly believe the short list above covers the majority of the actionable issues, and the ones where you should focus your immediate energy.

Recommendations

There is no completely canonical list possible to people-and-influence problems, but framing them as organizational issues lead to fairly clear-cut solutions. While not exhaustive, I would certainly recommend some combination of the following activities:

1. Ensure you get clear guidance from executive leadership about the scope of your authority (if any), as well as clear expectations and metrics for how your performance in the role will be evaluated.
2. Any problem that can't be solved within the scope of your authority or influence should be clearly communicated to senior leadership along with any supporting metrics and recommendations. What they choose to do with that information (if anything) is their responsibility rather than yours.
3. Unless it's been made explicitly part of your job, don't think in terms of change management. Think in terms of measurable outcomes. Work with the team to identify desired outcomes, key performance indicators that measure progress towards those outcomes, and any necessary process controls required to achieve those outcomes. In other words, create shared accountability for clearly-defined outcomes rather than trying to generate top-down change that you can't create without the team's active collaboration.
4. Stop accepting responsibility for problems that you lack the tools, skills, authority, or other means to control. Create shared accountabilities where you can, refer other problems to the organizational level where they can be solved, and ensure that all parties (including you, the developers, and the CTO) are all crystal clear on who has accountability for what within your existing organizational culture.
5. Remember that you are now a "Tech Project Manager" (whatever that actually means within your company), and not a developer. Just as you want to earn their trust in you as you perform your role, you also need to build and demonstrate the trust that they need to perform theirs. If that's not happening, that's part of what you all collectively need to fix.

Roles, responsibilities, trust, collaboration, and working agreements are never one-size-fits-all. These are things that must be honestly and openly discussed, especially at key inflection points such as team composition changes or organizational shifts in roles-and-responsibilities. You won't solve these problems overnight, but if these things are not foundational to your plan for addressing the problems you've identified, then you're ultimately solving for the wrong set of problems. Transparency, communication, and collaboration are your best tools, so make use of the them as often and as effectively as you possibly can.

Answer 6

From your post, it comes across as the entire team is not on board. Therefore, it isn't them; it's you and your management.

• How is the team pulling work?
• How are estimates being handled, by whom?
• Are the consequences of technical debt an actual management concern?
• Will new development be halted until all this technical debt is corrected?

Answer 7

Put them on Performance Improvement Plans.

They're currently not performing adequately, and you've got a list of ways in which their performance is deficient. Fortunately, there's a tool for improving performance that utilizes exactly those sorts of lists: the Performance Improvement Plan.

Motivation is classified into two types, intrinsic and extrinsic, and since they seem to lack intrinsic motivation, you need to utilize extrinsic motivation, and that's ruled by incentives. You can do this by offering bonuses for high performance, but it sounds like your main problem is that their performance isn't even adequate, and that's what the Performance Improvment Plan is designed to address. The Performance Improvement Plan lays out the incentives very clearly: complete the following goals by the listed time, and you'll be avoid losing your job.