Handling a lack of leadership

Question

I started my first ever job eight months ago, as a Junior Developer. Basically, my job is to write PHP, and up until now it's always been picking up small tasks that need doing, and doing them.

Now, along with another developer (I'm not sure what his job title is, but I don't think he was around for long before I joined), we are to completely recreate the company's billing system from scratch.

Normally, I would absolutely love this kind of challenge. However, the task is just too big. There is no real specification other than vague things like "make it work like the old one but better". There is no project manager or anything, just the boss who wants it done. It is to be done by the middle of October, otherwise the other Director will write it himself - it should be noted that this person is... well, not a very good programmer. To cite an example, I had to fix code of his that established a new MySQL connection every single time he wanted to run a query, and never closed any of them, then wondered why loading a page with a few hundred queries on it crashed the server...

I'm not the only one disgruntled by the lack of proper organisation and leadership - I've had discussions with colleagues, one of which has been around since almost the beginning. We're all in agreement that leadership is lacking.

But I'm not sure what to do about it. The way I see it, I have three options:

1. Deal with it, and do the work as best I can within the situation.

2. Quit on the grounds that it is difficult/impossible to work in these conditions.

3. Explain that the work I am being given is not suitable for a "Junior Developer" and that either someone else should be in charge of it (ie. a proper project manager) or I should be given a higher job title (and salary with it)

I... really don't know what to do. This is my first job, and I have little idea how things should be... Any advice on this matter would be very much appreciated.

---

I thought I'd leave a follow-up for you all.

After talking it through with my father, my coworkers, and finally my boss, it's been decided that I will continue doing my ad hoc "small tasks that need doing", on a part-time basis. This has the added benefit of giving me time to work on my personal projects, which had pretty much ground to a halt in recent months.

Thank you everyone for your help, it has indeed been very much appreciated.

Answer 1

I suggest option 4 (or 3++)!

From what it sounds like that work is not really suitable for any developer, not just a junior developer (unless you are at a very small company [aka startup]). Billing systems are no joke and you need a whole group of people to produce quality software (project managers, QA, etc.). Option 4 (being similar to 3) is explain to the business why you need a clear scope and proper support to make the project is successful.

One of the ways you can do this is by asking lots of questions. If the company fails to understand that the project can't be done with what you have been given, get out right now.

There are some things you should not do: continue working as is, even for more money. If you don't have the time or resources, a larger paycheck shouldn't change that (and besides, programmers don't really care how much they are paid unless the work sucks [its at the bottom of the article]). This will either put you on a death march or indicate to the company that you are able to do projects with impossible deadlines.

Answer 2

As a result of the obvious fact that you cannot just demand leadership (that's an indictment of the current "leaders"), ask for the next best thing: Time. Time to become a leader of sorts yourself. As you've stated, given a reasonable amount of time, you can accomplish the task. Therefore, a lack of leadership, while demoralizing, does not necessarily hinder your success.

Lay out a professional level of effort (LOE) estimation document that details the tasks and how long you'll require to execute each one. There'll be push back on the timelines but be prepared to defend your timings professionally, for each task. Ultimately, a compromise should result. Make sure your communication regarding the estimation is on record with emails, and that all stakeholders are in the know (in case they decide to be unreasonable about the timings and the project goes pear-shaped as a result).

---

Possibly unrelated, this sounds like a small shop, possibly a one-man firm or family-owned firm. Be prepared to exert your influence and hold your own in the face of pressure. There'll be many more situations like this. The good thing here is that your situation is a resume-building opportunity. There will be a lot of work to do and too few hands to do it, leaving you with a fast-track from junior to senior developer and a lot of opportunities to get your hands dirty.

Ultimately, you don't want to spend too long there, to spare yourself the risk of burning out

Answer 3

If you have no leadership, then you have to provide it. Sit down with the current systems and document what it does, go talk to users and find out the problems with the current system and what they need changed in a new release.

Then once you have a better idea of the scope of the problem, create a list of tasks to be done and time estimates. Likely you will find that it is not physically possible for two people to rewrite a billing system in the time available.

So then you take your requirements and your time estimates to your boss or the person who authorized this and say, "Can we move the deadline out to based on our analysis of what needs to be done or which of these features can we move to the next release in order to get it done by the deadline?" At a minimum, you need to agree on the order in which tasks need to be done, so that you have the best possibility of things being delivered that are usable even if all functionality is not there. For instance, data entry tasks would take precedence over reporting tasks because if the people entering the data can't do it, there is nothing to report on.

You will also want to prepare a basic risk analysis because billing is the lifeblood of a company, if they don't bill correctly, they don't get paid. They need to understand that rushing such a thing is an unacceptable risk to the company.

Answer 4

First off, realize that it's not uncommon for clients to not know what they want. You shouldn't attribute the fact that in this case the client happens to the boss as well to a lack of leadership - in this respect, your boss is apparently just as uncertain of what he wants as the average client.

Note that there's a realistic chance that your client assumes you have enough information to start programming because he knows what a billing system looks like, and come on, how much variation can there be in a billing system, right?

What needs to happen next is that someone needs to tell him that it doesn't work like that, that we're not able to do mind-reading and that he should try to describe what he actually wants the billing system to do, how it should behave and how it should be used.
Depending on the client he might be able to convey that on his own, but most likely that information has to be pulled out of him (as @IanHolstead recommended: ask a lot of questions), or it might even have to be visualized for him in terms of UI mockups (or sketches, as @M.C. said) in order to decide what he wants and doesn't want.

Depending on how good of a job this person does, during their conversations the client might realize one or more of the following things:

• The idea that I had so far is not self-explanatory, and actually requires more than a few minutes to explain properly to someone else
• The idea that I had is not even complete, there are a lot of details that I hadn't thought of before. In light of these, I might even have to reconsider some of the wishes I had earlier.
• The thing I'm asking for is much bigger and more complex than I anticipated when I asked for "just a billing system".

Getting the client to realize these things is the first step in getting the proper requirements as well as the proper time to implement them. It's still no guarantee to actually getting them, but with these realizations there's at least a fighting chance.
One word of warning: the less the client knows about how a software project progresses (and the more he is used to calling the shots), the more he needs to be guided in the process by someone who does.

Knowing all this, the question you should be asking yourself is: should I be the one doing this, or is this best left to someone else?

Answer 5

I think this is one of the best lessons you can learn from new jobs (and probably a harder thing to deal with for a first job), so you should consider this as something you investigate for your next job, and whether it is something that you find very important for your job satisfaction.

If you look at the options you have proposed, option 1 will not solve any problem other than relying on you to cope with it for as long as possible, at which point you'll either leave, someone else will fix the problem (or leave). I can just see this going down badly and resulting in you leaving.

For option 2, you need to consider whether it is a good time to leave the job or not, otherwise leaving will create a bigger problem compared to staying just a little bit longer.

For option 3, for a new job this might not be something that the management will warm up to. However, it is useful to put the idea out there is you are considering option 2 anyway so there's nothing to lose and everything to gain.

Answer 6

It's common to work on projects where the requirements are poorly-defined. Unfortunately, part of your job is to make it clear that the requirements are poorly-defined. The fastest way to do this is to start creating some sketches of what you intend to build, based on what they have told you thus far, and then send those sketches to them for review. Often, folks don't know what they want until they see it-- conversely, they know what they don't want when they see it, and in this case you can use that to your advantage.

Please note: I mention "sketches" because you said you're being asked to rebuild an application. That could mean changes to the existing interface, or a new interface entirely, and it's here where you have the greatest opportunity to achieve common understanding with your colleagues. For the users of the application, the interface is all they know; they won't approach this project from an engineer's perspective.

Good luck!