I'm technical referent but I lost the lead for technical decisions

Question

I was recruited as a Freelance (Technical Referent) in a solid company in order to build a new version of their mobile app that I suggested them myself.

We need you because your skills are scarce and we really enjoyed your personal mobile app, that you showed us during interview. If you accept, you will lead the project.

I am very experienced in programming fields so the proposal interested me.

I started a prototype and even added some great features, when both chiefs came and told me this weird thing:

We love what you built at this time for our next mobile app, but your skills and your code quality are too high to be understandable by all the developers team. We had a meeting (without me so), and we dropped some methodologies you recommended:

• No more Test-Driven Development and no more unit tests.
• No such high-demanding code reviews.
• Some copy paste from the old version of the application, in order to go fast for other developers. (The old version code was totally unreadable and ugly; believe me).

No need to tell you: I had some hidden tears hearing that...

It's true, I'm perfectionist. It's true, software programming is my main passion.
It's true that I have uncommon skills for programming (according to many developers I know).
It's true, I expect a very high quality of coding.
It's true, I wanted/want to help the team to improve itself, with free lessons from me, detailed code reviews etc.

My chiefs keep expecting of us a good quality of software, because they aim to be the country's app leader in their field.

I struggle to accept those new "guidelines" because it's against my professionalism about software.

Two days ago, I saw a mountain of code from other developers aiming to be integrated into the application that makes the whole work badly. If it goes on like this, soon it will be too late.

How should I convince chiefs (non-programmers) that to end up with a really good software requires all the methodologies I tried to impose and good developers (I don't dare to reveal to them my thoughts about the other developers' poor skills)?

In one month, I will decide whether I renew my contract (they want) or search for another mission.

-------UPDATE------- 15/11/2016

I just talked with the client (company's director) about this situation.
Now, I understand the whole:

They were clearly not aware that I work here on behalf on my own enterprise named "XXX".

The reason is that my headhunter sold me as a simple consultant of HIS company, a simple resource so, rather than presenting me as an enterprise's president, aiming to provide services on my own.
I've just learned it!

So the client admitted that as seen as a "simple ressource, besides having the title of expert", I was too much a decision taker on the project that was entrusted to me; that "scared" people.
He understands my attitude and my misunderstanding of the situation.
In my mind, I was acted as a completely and autonomous separated entity, aiming to provide a service, although being present locally, in open space.

On my contract with this headhunter, it was written that I will act as a representative of XXX, not as "Michael".

As XXX and to increase my reputation, I expected such strict methodologies of development in order to build a great product, and not be braked by the "poor" qualities of the global team.

Note that only two people worked with me on this project, not 10.
It should not be those two co-workers (that clearly claimed not wanting to evolve and learn methodologies of coding) that would avoid me to produce a really good product.

I have to talk seriously to this headhunter right now...

Good lesson for me.

Answer 1

This line destroyed my confidence in your firm's leaders:

No more Test-Driven Development and no more unit tests.

That's such a bad decision, I cannot imagine working somewhere that behaves or believes that. You will waste 10 to 100 hours fixing errors, because they want to save 1 hour by not using Test-Driven Development or unit tests.

That's bad programming, bad business, and betrays a lack of understanding of systems thinking. Such people cannot be trusted. They are incapable of reliably making good decisions in ANY area of the business.

Without systems thinking, leaders will in the long run harm you.

Get out now.

Answer 2

Remember that coding does not exist in a vacuum. Even code that's less than ideal can solve real business or humanitarian problems.

Quality is not an all-or-nothing proposition. There are certainly situations where a team is so junior that introducing complexities can kill productivity and morale, and fail to deliver even the basic goals of the entire project.

I'm guessing you yourself did not start out your career doing TDD, mocking, programming to interfaces, dependency injection, composition over inheritance, distributed version control, and the like.

Try to compromise. Make a plan with the chiefs for introducing modern software development practices over time. Offer to teach the rest of the team in these principles, using one-on-one mentoring, lunch-and-learns, or self-directed training.

See if there are nice-to-have features that the team can use to experiment with techniques that are newer to them, where you would oversee code quality, reviews, passing tests, and whatever else you find necessary.

It's about finding a balance between immediate productivity and long-term sustainable development practices.

That will, of course, take time, and you'll have to determine whether that time is worth your personal investment. If the chiefs are not willing to compromise, then likely that decision will be made for you.

Answer 3

I've fought this battle more than twice.

Here is what you are going to come to realize at some point: No executive wants to admit (and probably even to themselves) that they are producing garbage. They will either face the pain, and make the necessary changes to produce a good product, or they will "justify" the decision with a combination of woes about a budget crunch and irrational rationalizations such as you've outlined, above.

The organization has spoken, and you can't fight this AND deliver a good product at the same time.

You either make peace with putting your name on something you know is not up to your standards, or you find somewhere that your talents and standards will be of benefit.

Answer 4

It's not your product, basically you need to conform or move on.

As a freelancer you should have experienced this before. You have to work within what the people paying you will allow you. It's obvious they don't like your lead style and you are disruptive to their team so after reviewing their options (without you) this is what they came up with.

Make sure you get paid, and try and leave on good terms when you're ready, but don't get upset over a product you don't own.

Just a suggestion, but programming skills aren't everything when working with a team in any sort of lead role. You might do a lot better looking for solo projects which can really make your skills shine out. This is one of the reasons I'll often turn down jobs that involve an unknown team who couldn't do it themselves (if they were competent and efficient, they wouldn't need me). I prefer to start from scratch either solo, or with my own team. Less headaches and more job satisfaction (more money as well usually).

Answer 5

Put your money where your mouth is. Leave.

Resign from the position informing the whole management chain that you are unable to fullfill what you were hired for, and as such, as a freelancer, rather resign from the contract than support a sub standard development effort. Inform them that this is a breach of contract (assuming you were hired to actually do those decisions) and as such you do not see it justified to waste your time - and their money - on your salary.

There is not a lot you can do. Unless you have ulterior motives (need the money for some other projects) that is the most sincere way to handle this, given that you personally struggle with how the project goes.

Alternatively contact higher up and try to find a way to make things work in an acceptable level. It is possible, thugh, they work with people that should rather flip burgers at McDonalds - seen that in quite a lot of bigger companies. I was once hired to teach VB developers C#. A one month curriculum condensed into 3 days ("we can not have them not working for a month, and the are all experienced developers"). Well, the expereienced developers did not know the difference between an array and a hashtable/dictionary on a fundamental level, so the whole time was wasted. That is the level in some companies.

You can not fight it. The fish starts stinking from the head - which is management. They do pay for it, over time. But it is not your job to change it. If you can not stand it, leave.

Answer 6

I would focus on different things. Because:

No more Test-Driven Development and no more unit tests.

This sucks but it's understandable. It's a huge shift in paradigm and it suits best a brand new project, not a continuation of an old one.

No such high-demanding code reviews.

That's understandable too. IMHO the level of demanding should be increased gradually to let people learn new skills.

Some copy paste from the old version of the application, in order to go fast for other developers.

That's understandable and can be OK - if those old pieces of mess get nicely separated from the rest of the project.

Now, you've listed the things they've dropped, but the list cannot be judged without knowing how much of your recommendations were left in place. If those 3 were the cornerstones of your methodology, there is nothing left of your design and that's bad. If those were only 3 out of 15, then most of it is still in place and dropping those 3 really is what it says on the label: cushioning the shock for remaining programmers.

But the other part is the most alarming to me:

We had a meeting (without me so), and we dropped some methodologies you recommended.

They asked you to design something and then they modified the design without consulting you. That is the red flag. Either for them or for you - because it could be you who just refuses to hear their arguments to the point they have to issue a direct order.

If you estimate that they've dropped most of your plan then it can mean they don't understand anything. They want their code to improve, they can pay your salary, but they won't pay the real cost: the effort. It's like a guy buying protein supplements with with vain hope that a product will magically give them muscles without exercise. Protein supplements don't work this way and neither you are a magic product that can fix their process without changing it. It's terrifying how many people think that magic bullets are real.

From the other hand, commercial software production is not striving for absolute perfection, it's just enough strife (which means time, which in turn means money) invested in perfection today to save even more effort (read: time, read: money) in the long run. Every fix costs money and it's justifiable only if leaving the bug costs even more. What you really need to be good at is compromise. Not everyone is cut for the job (certainly being too much of a perfectionist is not helping), the only way to find out is to try it.

It's up to you to decide if the amount of design freedom left is enough. If you feel they've hired you to do a job and now they're saying you can't do the job then staying there can be just wasting everybody's time.

You can always treat the job as a lesson. Distance yourself, observe and learn. Even if you're technically perfect you still need "working with other people" skill. Heck, working with people not as good as you requires even more of that skill.

Answer 7

I would not concentrate too much about the decisions that were taken. The important information here is: they took upon themselves to have a meeting without you about things that were you responsibility. It shows a loss of confidence in you.

You need to understand where that came from in the first place. You look technically adequate considering what was asked from you: you convinced them as such. But they didn't hired you because you are technically good, they hired you to fix a problem they had and thought you could do that.

I can see multiple issues that could happen with this dissonance (the fact you think they hired you for one thing, compared with the real reason):

1. Lack of goals:

   • Did they tell you what they expected of you?
   • Did you ask what they wanted?
   • Did you miss something they told you?
   • Maybe you heard: "We want quality software!" when they meant "We want a software that people use!".

2. lack of transparency: You arrive at this new job and you apply all the best practice known in your fields.

   • How did you communicate about it?
   • Did you go too fast?
   • Was everybody aware of the consequences because there is always a trade off?
   • Did you explain the learning curve will hurt productivity?

3. Support from below: Your methodology impacted the lives of your team, they need to be convinced they are going into the right direction.

I can only speculate at this point but I can see why, in the space of few months, the devs freaked out because they don't see the added value (yet) of the changes and your bosses freaked out because the features are not coming as fast as they thought you would deliver and the devs are getting back at them, unhappy.

You have to learn from this experience for the next time as things are pretty advanced in your case.

But if there is anything to save, it is through trust and patience. If anything,

• Go with the flow by acknowledging the problems they brought up.
• Accept most of their changes and add your most valuable points (only on the condition you would see a future here)
• Make a schedule to reintroduce the best practices slowly but surely, explaining what problems those methods are fixing (no need for parachutes in cars, but a seat belt can help ;)

Convince people to be on your side, whatever the cost, because if you cannot do that, your battle is lost.

Answer 8

I'm not sure of the exact details of your situation, but having technical expertise and being to lead a team to do things a specific way are two separate things I think. The book 'Extreme Ownership' goes deep into team dynamics, perhaps it would be helpful.