19

I'm a senior software engineer that works in a small group (4 other colleagues and one immediate manager to us). For an R&D project, we work with a contractor to develop some software tools and do some research and development for a software that is going to be incorporated into our future product.

The area of this specific project is my immediate expertise; although my manager is pretty familiar with the topic, he is not necessarily an expert in this area. I'm the main point of contact between the contractors and the product owner and my manager.

The result of each sprint is presented in biweekly meetings to our group (me + my 3 colleagues + my manager, we are all senior software engineers).

There is a crucial tool that needs to be developed in this project and there is an issue with the current implementation by our contractor. I did some tests and I'm pretty sure that I know what the problem is and how to resolve it. In order to show the feasibility of my solution and demonstrate that my idea could indeed get rid of the current issue, I created a Jupyter notebook and send it to our contractor last week to possibly use it and hopefully they could build on top of it to get rid of the issue.

Today, in our sprint closure meeting, the contractor team acknowledged that they got my notebook and that indeed it solves the issue that we are facing in our current development. After that, when they jumped to presenting their results, they still showed results that were produced by their old implementation. I asked if they got the chance to incorporate my notebook into their current workflow, and they respond that: well, while my solution seems to work but they prefer to stick to their original implementation without giving clear explanation why.

I don't want to look like someone that is pretty picky, but my main concern as the main point of contact for this project is that we won't be able to reach the project's goal without resolving that issue and my manager also has the same opinion. I set up another meeting this week to discuss this issue further and possibly dive into more technical details to get to the bottom of this problem, but my main question is: how can I make sure that our contractors incorporate our guidance into their development without being rude or looking as someone that is too picky?

9
  • 2
    @DaveG No, it is still their implementation that is broken. Mar 28 at 21:58
  • 4
    Did your company approve something any time earlier which would allow them blame that approval for that bug (like someone approves a house plan with 2 bedrooms and later realizes that there are 2 kids so the mom wants another room and papa also agrees?)
    – androidguy
    Mar 29 at 8:05
  • 2
    Read the contract. Maybe the penalties for missing a deadline are too strong, so they just push forward such that they can tick all the boxes. If this is the case, talk to your contract manager/project manager how you can give them some time to do the work you want them to do.
    – lalala
    Mar 29 at 14:39
  • 1
    Are you paying by time or, is this fixed price? A small contractor (possibly one man), who is paid by the hour/day will probably be more flexible and, may offer technical advice and, you can come to a better solution together. A larger, fixed price contractor, may have costed the project based on assumptions and feel that you are "moving the goal posts."
    – Jodrell
    Mar 29 at 15:49
  • 2
    @JoeStrazzere I’m not saying they can’t get replaced but I believe it’s a bit difficult and the decision is with the upper management. Mar 29 at 21:06

7 Answers 7

70

we won't be able to reach the project's goal without resolving that issue

This isn't picky at all. Delivering working software is the entire point - if developers are delivering software which doesn't work, they're doing it wrong.

my manager also has the same opinion

This is good - it means it shouldn't just be able to degenerate into a "Mithridates said, contractor said" discussion.

how can I make sure that our contractors incorporate the technical comments and our suggestions into their development without being rude or looking as someone that is too picky?

Just ask them how they intend to resolve the issues with the current implementation. There are three realistic possibilities how they respond:

  • They continue to waffle without giving a clear explanation. In that case, you need to push them for a clear answer - while this is direct, it is not rude.
  • They describe a path forward which is different from your solution but you think may be feasible. Here, you probably need to give them a small amount of leeway to show their solution can work; I would suggest timeboxing it and agreeing to move to your solution if they cannot get their solution to work.
  • They agree to implement your solution. All is good.

In the worst case scenario, you may decide that the contractor is not the right person for the job. In that case, you will have to start the discussion with your manager about how you replace them with someone more appropriate.

2
  • 6
    +1 Being direct and clear about what is expected from someone who is doing work for you is not being rude or picky. I would much rather be known as "that person who will tell you exactly what they want" than "that person who expects you to read their mind" or "that person who is so afraid of sounding confrontational that you can't understand their motivation for bringing up a topic." If someone is willing to listen and change their mind when presented with a good reason to, most people won't view their directness negatively.
    – ColleenV
    Mar 29 at 16:38
  • 21
    Also, keep in mind that there's a chance that the contractor doesn't understand OP's solution well enough to implement it, and doesn't want to admit that and risk looking bad. A discussion like you mention is a great way to resolve this, as you can discuss the solution in more detail and give both sides the chance to ask clarifying questions. It also helps with the fourth possible response: your solution solves the problem but it creates some other problem that you're not aware of.
    – bta
    Mar 29 at 18:52
35

There is a key point that needs to be addressed regarding your technical guidance. That is:

Does the software actually work and do what you asked them to do, in terms of the actual response to user inputs?

If the answer is "no", then give them actual reports of bugs - what the software does and what you expected it to do in different circumstances. This is very different from "technical guidelines". You should expect that these bugs will be fixed.

If the answer is yes, it does work, and your technical guidance is you saying "we would prefer if internally the code had worked this way" then you can't really make them change things. You asked for code that did something, and they have delivered code that did that. Of course it's different if you told them in advance (and preferably in writing) that you wanted something done a certain way - then you can reasonably ask them to make changes so it works the way you told them to. If you didn't do that, and you wanted things done a certain way, then there's a lesson there that you should give your requirements in advance.

6
  • 3
    I completely agree with this answer. If the software is missbehaving according to what's on the requirement, then file a bug. If there are no requirements, then you've learned a valuable lesson when dealing with contractors. Everything. In. Writing
    – Arriel
    Mar 29 at 20:40
  • What if there are Non Functional Requirements?
    – Jodrell
    Mar 30 at 7:13
  • 4
    @Jodrell: Either you wrote those requirements down, and can refer to them in writing your bug report, or you didn't and you can't. If you're in the latter case, tough luck.
    – Kevin
    Mar 30 at 15:24
  • 1
    @Jodrell it should be treated in the same way. "It should handle 5,000 concurrent users" can be defined, tested & have a bug report submitted in just the same way as "it should send me a 'forgot password' reminder" Mar 31 at 9:59
  • @anotherdave. You could have NFRs around coding style and design, rather than just performance based NFRs but, as Kevin says, unless there is some referenced standard or defined constraint, there is nothing to reasonably QA against. There might be the offer of "Best efforts" with an eye to subsequent work.
    – Jodrell
    Mar 31 at 18:13
9

Do you have a DOD (Definition of Done)? Does it Include UAT?

When dealing with third party contractors I find having an Explicit Written out Definition of Done to be very helpful. The Story isn't Done until it meets the pre-agreed Definition of Done.

Does your Definition of Done Include User Acceptance Testing? If it does then create a Bug that expresses the Issue and leave the story\feature request open till it gets fixed.

If you Don't have a DOD or it doesn't include UAT then get one written up and get everyone's agreement. Then as you move forward you'll have controls to enforce what you need and ensure the project stays on track.

3
  • 1
    Yes, we communicated our definition of done and what we expect from them in a written format and we discussed it a few times during our meetings. But, my feeling is that they don't follow that closely, and I don't how to get them to do it. Mar 29 at 20:11
  • 2
    @MithridatestheGreat, if the work has not met a pre-agreed and written DoD, SoW or contractual list of requirements, then you should have some leverage, next is to exercise it.
    – Jodrell
    Mar 30 at 7:16
  • 5
    +1 for mentioning acceptance tests. They should be part of the contract, and the contractor gets paid once all tests are passed successfully. Unfortunately, R&D projects often overlook this.
    – Siorki
    Mar 30 at 13:03
6

how can I make sure that our contractors incorporate our guidance into their development without being rude or looking as someone that is too picky?

I would give the contractor time to implement your solution. They needed results to present and perhaps that was all they could do until they get their head around your solution. Nowhere in your question does it say using your solution was mandatory.

If it's not implemented at the next meeting would be the correct time to push, make sure you have your manager on your side. Ideally your manager just makes it happen.

5
  • 4
    "Making it a directive" can change the status of a contractor to employee, with nasty tax consequences in the UK and probably elsewhere. What you can say is "we think it would be a good idea to do X instead of Y. If you disagree we might consider looking for a different contractor" - see, no directive.
    – gnasher729
    Mar 29 at 13:22
  • @gnasher729 yeah, it's how you word it I suppose. If the manager says do it this way, then the contractor doesn't have a choice. Perhaps my definition of directive is different. I've reworded it.
    – Kilisi
    Mar 29 at 16:04
  • Not in this case, I suspect but, I'm not sure which countries law is involved. This involves a team of contractors working externally and sounds fixed price. It would seem reasonable for the client to have some Non Functional Requirements but they may not be agreed to.
    – Jodrell
    Mar 30 at 7:06
  • @Jodrell still the managers problem I reckon.
    – Kilisi
    Mar 30 at 7:07
  • 2
    @Kilisi, agreed, the best thing is to escalate and send it up the chain, hopefully it will come back down on the other side. In the meantime keep trying directly.
    – Jodrell
    Mar 30 at 7:10
5

It rather depends on the contract you employer has with the contractor.

The contract may set out what they have to deliver and in what timescale. They are working on the project in their own way.

Then an employee of their customer tells them that they are doing it wrong, and tells them how to do their job. Their response is to listen politely, then ignore it and carry on as before.

Realistically, your job may be to ensure that what they deliver meets the stated requirements, and nothing else.

1
  • Doing as they are told can turn contractors into employees with bad financial consequences for everyone involved. If they are told they are doing it wrong they have the choice of listening and ignoring it, or listening, ignoring it, and independently figuring out that what they were told was an excellent idea. Either way, if they don't deliver what was agreed on, you or your manager check your contract.
    – gnasher729
    Mar 29 at 13:20
2

I'd ask you to consider two things.

First, good software must:

  1. Do the right thing
  2. ...for the right reasons...
  3. ...in the most obvious way possible.

If software fails to satisfy even one of those three criteria, it is a complete failure, period.

People are wrong when they say "if the software produces the right experience, it's good enough." That is 100% false. Why? Because unless this is one-off software that you're going to throw away later, the source code needs to be high-quality so that long-term ownership is not a nightmare: it has to be easy to understand, modify, and improve. So if the source code is organized around ill-fitting concepts, or if it's filled with problematic anti-patterns, that means you're buying a piece of garbage.

It's a mistake to get hung up on whose implementation gets used. But:

  • if one implementation is clearer than the other, it is better;
  • if one implementation adheres to more of your organization's best-practices than the other, it is better;
  • if one implementation is organized around the same first-class business concepts that are used by the rest of your organization, and the other is not, it is better; and so on.

Second, contractors are supposed to build software that satisfies all the requirements. Setting aside all other arguments about what makes software "good enough," you still get to hold the contractor to the business requirements: unless they are all satisfied, the contractor is not holding up their end of the bargain. You state:

there is an issue with the current implementation

and:

still they showed [buggy] results that were produced by their old implementation

So, it's quite clear that your contractor isn't even satisfying the first element of the aforementioned triad: their software does not do the right thing.

In light of that fact, their reasons are irrelevant: there is no rationale that can justify delivering software that fails to fulfill its purpose.


Perhaps the contractor has a different solution than yours in mind; fine: you are entitled to have them brief you on their plan in detail before they spend your money and time implementing it. Do not take "no" for an answer!

But you need to go to that meeting with an open mind: perhaps their solution is better than the one you're in love with, or is no less good. Do not lose sight of what's important: does the software do the right thing, for the right reasons, in the most obvious way possible? If the answer is yes, everyone must be satisfied; if the answer is no, more work remains. Nobody's ego has a role to play in this.

3
  • 2
    By your definition, most, if not all profit producing software is a complete failure, period.
    – Jodrell
    Mar 30 at 7:07
  • 2
    ...for the right reasons... is very subjective. ...in the most obvious way possible. is also very subjective. Even Do the right thing can be subjective, even when it's part of a spec or test.
    – Abigail
    Mar 30 at 11:33
  • 1
    There are a lot of correct ways to build software, and many of the most correct are far from the most obvious: and in many cases the most obvious ways don't actually work. Operating systems and compiler construction abound in this kind of thing, but it also appears in application programming.
    – user207421
    Mar 31 at 2:51
2

Most other answers have focussed on "the software needs to work" for why your fix should happen. I'm going to give a dissenting view here.

All of the software needs to work, all of the time

Your contractors are responsible for the whole of the software, not just the one missing/incorrect feature you've found.

It's entirely possible that your fix works for the specific issue you're dealing with, but has knock-on effects elsewhere. Maybe it breaks other functionality; or maybe it's functionally OK but it has performance issues which mean it won't scale up when you have a million users or a million points of data; or maybe it's only a sunny-day solution and doesn't consider error/exception-handling conditions; or maybe it uses a library which legally you can't include in a released version.

The important thing which you've given them is clear evidence of what the problem actually is. How they get a production-ready solution to that problem is their job. It's quite literally what you're paying them money to do, after all. You just need to set the expected deliverables and the deadlines.

You need to decide if this is a sprint or not

If this is a sprint, then what they're doing should have been established at the start of the sprint. If you've come along with something new, then it goes in the next sprint.

If you're going to stop the sprint and have them do something else instead, that's doable - but it needs more discussion than just sending a proposed fix. And if you wanted your fix to be added to the sprint (which is generally not how sprints work), that's also doable - but again you need a lot more discussion. You need to get clear buy-in from your manager, their manager, and their engineers. Normally that involves a meeting with everyone talking through it. There also needs to be an expectation that pulling someone off something else mid-sprint is going to involve some context-switching for them, which will be slightly less effective.

Basically the level of discussion needed is way beyond just "sending a notebook".

And you need to be a senior engineer

I'm concerned about the phrase

without giving clear explanation why.

If this is a thousand-foot-overview meeting for management, I wouldn't expect to discuss technical issues. But if this is a technical meeting between engineers - and a sprint closure meeting certainly is that! - then I certainly would. A discussion doesn't mean that they should just infodump on you. It's a conversation. If you have questions, you need to ask the damn questions!

As your manager, I would consider it unacceptable for one of my senior engineers to sit through a technical discussion about what's been delivered and only afterwards say "I didn't think that was right, but I didn't like to say anything". If you're a senior engineer, your job is to be on top of the technical details and know enough of what your more junior engineers (or contractors) are doing. If you don't ask, who else is going to?

I'm also concerned about you not appearing to respect the sprint planning process. You can't just chuck something across mid-sprint and expect it to happen.

Seniority as an engineer isn't just about how good you are as an engineer, it's about how well you can use your experience to enable your team. An unpleasant truth is that the more senior you get, the less time you spend doing your own work and the more time you spend digging other people out of holes. It looks like you've got the technical side sorted, but you can still use some practise on the team-leading side of things.

It's all a learning process

The positive elements to take away from this are a strategy for the next time. Firstly you need to get proper buy-in for changes you put forward. And secondly you need to not be afraid to be Captain Awkward if it looks like someone is trying to weasel out of giving a straight answer.

You must log in to answer this question.

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