10

How can I ask for a better definition of the tasks I get assigned?

Today the tasks are basically just a user story without any technical definitions on how it should be solved.

They expect me to find the solution by myself and once it's solved they will check if that was the way they want it or not.

This is somehow OK, but the problem is they change their mind between every task. So if I take the feedback from task A and apply it to task B, then suddently they don't want that for task B and can even suggest it to be solved as I did in task A before the feedbacks.

I have been working on cleaning up and implementing new functionality in a very central part of the product because it's very difficult to maintain (due to messy code; one class has more than 4k lines).

During this work I have implemented it the same way as it is done in other parts of the application and split things into smaller parts, so it should be easier for new developers to understand the code and it's more flexible to make changes without breaking the whole monolith.

But doing so, and talks during the development, make it clear they don't want it to be solved how it's solved (splitting up the code was agreed upon) other places with basically the feedback "we are now going reinvent the wheel and it might not be right to do it as it's done other places in the application".

This makes me kind of frustrated because I have no idea what they want and only thing I know by far is that they don't want it the way I'm solving it.

How can I ask them to write the tasks for "dummies" where somebody actually have a plan for how they want it to be solved?

Some background

I'm currently working as a 'sub-contractor' for a company because they are not able to hire the staff they need to be part of their team. During my time in the team their best developers have quit. Sometimes I wonder if this behaviour is because they feel threatened by "external people".

I have now canceled the contract with them and I just want to complete my work and leave in a clean way without looking like I'm just arguing with them.

Information added after asking the question

I have also made technical documents describing how I plan to solve it. This has never resulted in any feedback or yes/no, and if I ask about it when the task is completed, the answer is they have so much to do, so there is no time to go through it.

4
  • 2
    What you do now is nothing since you have left.
    – Solar Mike
    Jun 26 at 8:50
  • 3
    By the contract I still have 3 months left, so I have to do something in that time Jun 26 at 8:54
  • What size of a company are we talking here? Jun 26 at 9:08
  • Its a very big company, maybe one of the biggest in the country. They have very many different products where every product is a totally seperate team. Many of the teams comes from small companies they bought up. Jun 26 at 10:08

8 Answers 8

50

How can I ask them to write the tasks for "dummies" where somebody actually have a plan for how they want it to be solved?

You can't.

The reality is, they don't know how they want it solved.

Take whatever you are given, ask a lot of questions, write up good notes and share them, implement the solution as best you can, then don't be surprised when they want changes.

Plan on subsequent change. Learn to be less frustrated or learn to live with the frustration.

1
12

It can sometimes help a lot to put together a mock-up/"stub" simulation of your proposed solution, show it to the customer, and ask "Is this what you want?" That helps resolve the missing details before you spend too much work on what may be the wrong solution.

The risk is that some customers don't understand that a simulation does not mean a solution is close to complete. Someone actually came up with a user interface style for Java that makes the display look like it was sketched on a napkin to help emphasizing that what's running is only a code sketch...

3
  • Dan Bricklin needs to update his Demo program... :D
    – RonJohn
    Jun 27 at 3:26
  • It sounds like the problem isn't a user facing one. It's the actual implemention that they don't agree with.
    – Tom Bowen
    Jun 28 at 9:11
  • @TomBowen: Not getting enough direction seemed to me to be the original complaint, not disagreeing with direction.
    – keshlam
    Jun 28 at 12:44
7

In your question you refer to "they" several times, but you don't say who "they" are. In software development there are often lots of people involved with different skill sets and different responsibilities. Reading your question it seems you are using "they" to refer to a few different people with differing skills and responsibilities. They key to your question is to understand this landscape and where you fit into it.

The normal way of things is that a product owner writes a user story that defines a task to deliver business value. The story often doesn't have technical design in it at this point because it is supposed to define the task and the business value; not how the solution is implemented. Likewise the person who wrote the story should not feedback on to the suitability of how you implemented it, unless there is an impact on the story, eg some NFR or acceptance criteria are not being met.

With the above in mind, the actual technical design is normally handled by a different person. This may be a technical/solution architect, a tech lead, lead developer or whatever. The person and role varies, but it should at least be clear who has design authority. This is where we get to the crux. It appears unclear who has design authority, however from what you have said it is not you, but someone on the client side, and that person isn't giving you guidance until afterwards. They aren't telling you in advance what the implementation looks like, they are coming back afterwards and telling you what you've done isn't right. This is bad for everyone. It means work is repeated and costs more, and isn't a conducive environment for job satisfaction.

What I suggest is that;

  1. You identify who is the technical design authority for work to be done.
  2. You proactively seek out guidance and approval from this person or persons. This could mean asking them for a design, or taking a design to them for approval/signoff. Do this on a story by story basis.
  3. You document the design and the approval and create traceability. This could mean putting it on a wiki page and linking from the jira story, but whatever works for you and the client. You could even incorporate this into the jira lifecycle with a design/approval stage. Don't start coding until this is done.
3
  • Thank you. "They" are the customer. The product owner writes the user story and after that there is no task planning or anything how it should be implemented. There is no technical/solution architect, but there is one unofficial "tech lead" and this is the person give the "this is not how I want it" feedback. I have tried to add documentation and ask for more, but the attitude is that the code documents everything and we should not spend time on documentation (this message goes to both internal and external developers) Jun 28 at 10:44
  • Documentation is not design. I suggest you go to this unofficial tech lead and ask for a design before you start. If you don't get one, then create a rough design yourself and ask them if they approve it.
    – Qwerky
    Jun 28 at 10:48
  • This is what I have done and there is no answer. When I ask for their feedback and I dont get any, I take this as they agree. But maybe I should require a yes/no answer before I start anything. Jun 28 at 11:30
6

This is quite often what you will see as a (sub)contractor. The company generally doesn't see any strategic or long term value in making sure you understand all of the details of the product because you are viewed as temporary. In some cases they specifically don't want you to know that much about their product.

Your job as a contractor is to complete the tasks assigned. For each new task you should ask for specific details to be performed/implemented. You shouldn't make assumptions about how this task is related to previous ones until they say so.

As long as you are contractor, you shouldn't expect to get much inside information about how everything works and what their larger plans are. Some companies may try to hire contractors who have shown good skills. If that happens, then you'll learn about a lot more of the internal plans and information.

Update based on comment:

Each time you get a new task you will need to ask how that task should be implemented. There is no magic way to phrase the question. Hopefully, over time they will give you a better overall picture so yo can be more autonomous, but until then, just ask every time.

4
  • 1
    I agree that I dont need to know their plans or get inside information. However that is why I ask how to ask for a clearly defined task where they have some plans on how they want it to be implemented, so I dont have to guess the right way to solve it. We are now talking about implementation, not UI/functionality - this is clearly defined and does change and that is OK and part of development. Its the question "how do you want this implemented" Jun 26 at 22:36
  • "how do you want this implemented" is a fine way to ask. My point is that you are likely going to need to ask every time until(if) they give you more information.
    – cdkMoose
    Jun 27 at 11:24
  • @cdkMoose, how would you deal with somebody who maybe isn't articulate enough to answer a question like that? You're presupposing that the non-developer has a coherent master plan and can communicate usefully about it. What do you do with somebody who has no clear idea what they want, and who doesn't have the free time or energy to talk about developing or transmitting a clearer idea?
    – Steve
    Jun 28 at 1:55
  • @steve, If that person doesn't understand the project well enough or can't articulate it, the organization has much bigger problems. I'm presupposing that it is out of OP's control and they will get what they get. Sometimes that is the hand you re dealt as a contractor.
    – cdkMoose
    Jun 28 at 12:49
5

I think you may need to be a little clearer on setting expectations of what you are going to do before you start working.

Information added after asking the question: I have also made techinal documents describing how I plan to solve it. This has never resulted in any feedback or yes/no and if I ask about it when the task is completed, the answer is they have so much to do, so there is no time to go through it.

For me, the main issue you have here is not requiring agreement with the proposed methodology prior to starting work. You are coming in externally to the company and need their buy in on how you will make your change before you start.

Rather than just forwarding on these documents and starting even if they haven't replied, try something like this in your communications:

Bob,

Please find attached a document that lays out my proposal of how I will implement FeatureA. The estimate to complete this work is XX days.

In order to meet your deadline of XX Jan 2099, I will need to start work by next Monday. I will not be able to start this work until we have agreement on the implementation plan.

I look forward to hearing from you.

GreenMountains

And then if you haven't heard within a reasonable timeframe, follow up with them:

Bob,

Just a reminder that I will be unable to start work on FeatureA until we get agreement on my implementation plan. Please can you get back to me on this by XX Jan 99 otherwise I will be at a standstill.

GreenMountain

4

Keep having meetings with them until they give you a well-defined list of deliverables.

If they change their mind, then create a change-request process and spend your time doing that.

At the end of the contract, you present all the work you've done and then that's it. If they wasted your time having vague ideas and changing their mind, then that's their problem. You just need to record all of it down so they can't accuse you of doing nothing.

5
  • "Keep having meetings with them" - what do you do if the target begins to limit or refuse such meetings, or if they render them ineffectual by not thinking through what they say or do during the meetings (i.e. it just becomes a context for hip-shot decisions and remarks which are reversed at each subsequent meeting, so that nothing is communicated or settled to any greater degree than if the OP had held no meeting at all)?
    – Steve
    Jun 28 at 1:59
  • @Steve Then you take good meeting minutes and document everything said. For higher skill methods, you proactively suggest possible solutions due to lack of input, and then work on that. If they reject the work (per OP), then go back to emphasizing that their initial proposal is to do nothing and reiterate step one and ask them again to define what the requirements are. In consulting world, this is straight-up billable hours. If they want to waste time, that's on them. You record what they did with the time to CYA (cover your ass).
    – Nelson
    Jun 28 at 2:16
  • The difference is if no meeting is held, liability is on OP. If they held a meeting and nothing was done, then the liability is on the attendees. You always act to cover your own butt and let people know that lack of progress is due to THEIR inaction, not yours.
    – Nelson
    Jun 28 at 2:18
  • Many of us are concerned with the effectiveness of our labour and quality of our output for its own sake, not simply with how liability for fecklessness will be allocated. Also, in very large organisations, a high quality paper trail for a failed project may be a valuable information product to allow someone to go back later and diagnose the problems, but in smaller gigs where you're hired as a software developer (not a PM) you might not even be authorised to spend billable time producing such a paper trail, and there may be no interest whatsoever in interpreting what such a trail would say.
    – Steve
    Jun 28 at 3:59
  • My point - to be clear - is that it may be no psychological comfort for the OP, and also the hirer may not tolerate you billing them for lawyering behaviours - they may disallow that work to be done if you explain what you are doing and why, or if you do it without clear prior authorisation you might just end up fighting over your bill.
    – Steve
    Jun 28 at 4:09
1

The issue here seems to be that you're getting given requirements, solving the work in a way that satisfies those requirements, and then being told that actually there were hidden requirements around how you met those other requirements.


So, there are two ways I can think of how this situation could have arisen and your response should depend on which of these you think is relevant:

Option 1 - You're a Junior Dev

Your solution meets the functional requirements but it might not satisfy some of the following implicit requirements:

  • Your code is messy
  • Your code is unperformant
  • Your code doesn't conform to SOLID principles
  • Your code doesn't conform to the architectural/code standards.
  • There's some context you're missing as to why this other solution is better in your business context.

In this case, you need to speak to whoever your lead is and work with them to learn about these things and how your future solutions can conform more closely to these. It's easy for a junior dev to think they're doing something in a similar way to other parts of the system but they're actually missing some key component or context through no fault of their own. Pair programming or thorough code reviews are good options here.

Option 2 - Your Leads are Control Freaks

This situation arises when your code is perfectly good, meets the requirements, and doesn't diverge in any meaningful way from the standards set out by your team. In this case, your leads just don't want to give up their control over the implementation.

Unfortunately, this situation sucks because it boils down to a lack of leadership skills and emotional maturity amongst your leads. So dealing with it is likely going to require walking a fine line so as to avoid upsetting anyone.

I'd suggest trying some of the following, how you approach it will depend on how close you are with your leads:

  • Ask them to articulate why their solution is better than yours.
  • Ask them if your solution conforms to the standards.
  • Ask them if the standards need to be adjusted so as to align everyone with their way of thinking.
  • Tell them you feel that they're undermining you and that you need them to trust you to deliver on work in a professional and technically sound manner.

You should always approach this with an open attitude towards learning. Even as a more senior developer, you could still have a missing gap in your context or knowledge that they can fill in. At which point this issue somewhat becomes moot. However, if it truly is just that they're undermining control freaks, then you need to be willing to stand up for yourself and have an honest, frank conversation with them.

Remember (in most companies at least), you're paid to take business requirements and transform them into a technical implementation, you're not there to just type code in that someone else has told you how to implement.


Good luck!

1

they change their mind between every task

This is called 'moving the goal posts' and 'making you hit a target in the dark'. Unfortunately, not unheard of in software development, esp. large companies where the left hand doesn't know what the right hand is doing. It's very common sign of bad or clueless product/project owners/managers, and a toxic culture/environment.

This makes me kind of frustrated because I have no idea what they want and only thing I know by far is that they dont want it the way I'm solving it.

You need to (in writing) explicitly demand that they clarify why they don't want you to solve the problem the way you propose, and demand for an alternative way. CYA. Always document. Paddy lays out some very good templates for wording that without proper user stories, specifications, and acceptance criteria, you're not gonna be able to build anything successfully. You're the constructor, and you gotta have clay to make bricks, and you gotta have blueprints to build to house. Same goes with building software.

You must log in to answer this question.

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