I do not have tasks due to business analyst concerns

Question

I'm working at some software startup. I'm well paid and the project needed to be built from scratch. Some months ago, I got hired as senior programmer, then I've designed and implemented a framework to be filled with content, which means to add more code.

The problem comes with this "content." I'm always struggling to think what this content should be. When I ask my bosses, they only tell me vague ideas on how the work has to be done, but there are details I'm not aware of and I shouldn't be the one thinking about them.

When I've pointed these problems, they promised me that these tasks will be discussed "soon" between the founding partners and technical officers; so far I still do not have clear requirements for the job.

I'm losing the motivation due to this event, and when I've expressed myself honestly about it, all I got was a, "You should be self-motivated."

So, how should I approach these issues?

Answer 1

First answer: Don't talk about lack of motivation. Talk about wasted work. You cannot produce anything useful without guidance. That means that you going without guidance is wasting the time and money of the company. That really is the core of your problem, and it's one that will resonate better than vague stuff about motivation.

Second answer: It sounds like no one above you has any particularly strong ideas, and none of them are making it a personal priority, which means it's constantly getting put off for whatever it is that they are making a personal priority. You don't have the subject matter expertise to come up with the correct answers on your own. Do any of your bosses have that subject matter expertise? If you can identify one that does, go to them personally. Figure out a series of concrete questions beforehand that will give you what you need, and that they can understand. Ask them for concrete answers, and tell them that without those answers, you're blocked. Once you have that, implement it.

Third answer: There are a few things to realize here.

• No one has any real idea what they want right now. If they knew what they wanted, they'd be telling you.
• Most likely, once you produce something that you can demo (anything), you're going to get a lot of feedback about how it's wrong and you need to fix X, Y, and Z. There's a natural human response that says that they're unsure, so they don't want to commit to being the first person to say something, but they can absolutely find something to nitpick or fix in an existing product. If you can create something that's even vaguely correct with that initial product, you'll probably be doing reasonably well.
• Your product (presumably) is going to have users. What you really need is one or two people who can simulate your user base reasonably well, who have experience doing the thing that your product is supposed to make easier, and who can give you feedback on what they want and need. If those peopel don't exist yet because it's intended for in-house usage, and the startup hasn't really started doing anything yet, then that is exactly your problem.

So... get what feedback you can (from user-equivalents if possible) and create something. It may be that you're not the person who should be making these decisions, but it sounds like that's going to be part of your role regardless. Just try to make things flexible and maintainable enough that when the inevitable "fix all the things" demands start coming down, you can adapt to them.

Answer 2

Having decades of experience in business analysis, I consult with clients to help formulate, tune, and prioritize their needs clearly for technical gurus like yourself to create technical solutions. Whether it's waterfall formal requirements or Agile methologies stories they may include if needed: wireframes, process flows, decision matrices, new db field info etc. These are the skills a seasoned BA/BSA brings to the table.

None of these I have seen provided by the programmer because it's not typically their skill set/job. I'm the one that deals with the stakeholders, the buffer so the programmer can focus on the technical aspects of the build.

The wireframes are shell mockups that we get buyin and tweak prior to deep coding. If not, you usually end up with a very frustrated techie.

Some BA's also have the skills to QA test what's been developed and even write the end user guide and/or provide training.

I think the company you're working with could solve this issue with the addition of a very seasoned Well rounded BA.

Answer 3

I would code it up to my standards as a developer, and the way I "Vision" things including nontechnical stuff. Then, I would represent my work and just wait for feedback. If I get asked "why like this", I would argue that I am proactive and love production to keep going and not be blocked.

If they need things to change, or business requirements has changed - or provided, I would then revisit the code and implement the changes/requests.

Also, Can "you should be self-motivated" mean that you can personally contact "founding partners and technical officers"? If yes, do that.

Answer 4

This is a foundational part of the software development lifecycle, and you are completely in the right to be reticent to develop without clear requirements.

Unfortunately, your company seems to have the same problem as many (mine included) which do not properly understand the purpose of a business service analyst (BSA). Your BSA would be the person who would be making meetings with all the leadership and making sure to gather requirements, so that instead of spending all your time in meetings gathering vague requirements, you can focus on developing software.

The reality is, without a proper BSA you will need to take on more of these responsibilities of gathering requirements yourself. HOWEVER, if your employees have the nerve to ask "what's taking you so long?" You can immediately shoot back with "the project is still blocked due to incomplete requirements, if you want this done faster, I need you to give me the time I need to gather proper requirements and acceptance criteria"

Without these, YOU will be on the hook if the software doesn't turn out exactly how they want. However, if you have proper requirements you can shoot back with "this release captures the functionality of the requirements, if you want to change it, we can put it in the next release". In my experience, people actually feel more respected all around when there are requirements agreed on by all parties before development even begins. Ultimately it's the communication issue that has plagued tech for years.