Having spent 10 years working as a mobile developer and consultant, I want to share what I’ve learned about managing a team of developers. For starters, let’s talk about several symptoms of bad project management. Most of my career I’ve been working as a freelancer, and these examples are based on remote type of work. However, I’m sure that they also relate to projects handled in-house.

Do you remember these ‘psychology quizzes’, where you get 1 point for each question? Here goes one of those.

1. Have you ever had your project underestimated? Who hasn’t?

We all suck at estimating – that’s a fact and you’d better accept it sooner than later. There is nothing wrong with inaccurate estimating, as we all need some idea of the effort required to complete the project.
However, the most common problem I see is estimating the amount of work without a clear definition of its scope. Let’s say you want users to be able to login to your app and save their favorite stuff.

So you ask your developer: How long will it take to add a login screen to the app?
Developer’s answer: I have no idea. Please tell me more. Do you want Twitter, Facebook, and Google+ support? Do you want the ‘Forgot Password’ functionality? Do you need input validation? Do we have any designs ready?
You: Well for now I just need a general estimate, so please give me your best guess for basic login.
Developer: Ok, if I have to guess, we can make the basic functionality ready in 3 days.
You: Cool, let’s get started!

And two weeks later the login function still doesn’t work like it should and the requirements pile up.

This might sound a bit exaggerated: however, you’d be surprised how often I get such queries. So if you constantly get your projects underestimated, please ask yourself if you can do a better job – in defining your expectations.

2. Have you ever run out of budget without anything you could show?

First of all, you do have a set budget for the project, right? I assume you have, but if you don’t, then it’s +2 points for you for this question, because without a budget you’re most likely to end up spending money on features that aren’t that important and don’t bring value onto the table.

Now ask yourself what will happen when you’ll reach the funds’ limit. In software projects, the most common scenario is to just add in more money (there are much better options, but we’ll talk about it later). But what if you can’t afford that? Do you have a list of features you can shave off the app?

3. Do you know how many tasks are still left to complete? I mean, in total?

I’m writing this article a few weeks after submitting a client’s app for Apple Store. The final cleanup phase of the project took around 6 weeks, which I originally estimated to be 2 weeks (we really do suck at estimation). After the main list of tasks was done, we found several bugs; the client also noticed that several features were missing. They weren’t covered in the wireframes and were never discussed. Oh, and also the whole deployment process resulted in a few extra tasks which we hadn’t taken into account, like plugging security holes or some data model changes.

This time 1 point for me for having hidden tasks.

4. Have you ever rushed your team to meet the deadline? And fit 4 weeks of work into 1 week?

As far as I can remember, I would do the most part of my homework on the last day before the deadline. The same applied to all of my projects in college. That last week of work often results in a great productivity boost – it’s a kind of magic, right? Well, not really – what it is is a kind of cheap trick for which you have to pay the price later.

Imagine you’d like to lose weight quickly – like 20 lbs in 1 week. Is it possible? Yes. Would your doctor recommend that? No. Do you think you could hold on to your new weight for long? No.

The same applies to software development. It is possible to implement a ton of features in a short period of time, however, sooner or later you’ll have to pay the price. Poor code quality would be the least of your problems. Whenever I’d work in such an environment, we had to deal with hard-to-track bugs, requirements that weren’t fully implemented, or critical issues which would pop up at the worst moment possible. Today when I hear about critical security issues or bugs occurring in really large companies, I see developers coding at 3 AM and their managers screaming – faster, we have a deadline to meet!

5. Have you ever had a critical bug slip in just because of communication problems?

I believe communication is the key ingredient to the project’s success. Not too much of it, and not too little.

Too much communication is often the case in large corporations, financial institutions, or governments. It manifests itself as a ton of bureaucracy – to get a thing approved for the projects, you have to wait for several managers’ and other CxOs’ decisions. In smaller companies and startups this may be micromanaging and constantly checking on a team to see how they perform and why things are so slow.

The other pole is too little communication. A product owner just hands over a set of general ideas of features and leaves the decision-making part to the developers and designers. After these decisions are made. it turns out that the result is far from what was needed and so the project has to take a few steps back.

6. 8. 9. 10…

I could go on with similar examples, but I believe that since you’ve gottrn as far as here reading, you already have at least 1 point. Here are few other issues I can think of:

• Do you know if your team is on track with their work commitment? And „Yes, sure boss” is not an answer here.
• Do your team members often need to wait for each other? Like Rufus the iOS developer is waiting for Roderick the server guy, to finish his work?
• Do you know what will happen if you lose contact with your developer? Think about all the passwords, accounts, the code, etc.
• Are your developers passive with their work and do they fail to report new issues or potential problems?
• Do you have clearly drawn roles and responsibilities in your team? Who has the final word on certain decisions? Who’s responsible for designing server side API? Who’s responsible for security issues?

If you’ve had other problems, please leave them in the comments, I’d love to hear about them.

Summary

If any of the above examples sound familiar, then my advice for you is to start looking at ways you could improve that.There are a lot of case studies which show that the same people, working on the same project, increase their productivity by over 400% just via implementing good management processes. For the details I strongly recommend famous book by Jeff Sutherland – Scrum: The Art of Doing Twice the Work in Half the Time.

The good news here is that it’s not that hard. It’s actually the easiest way to increase the quality of your product and limit the effort it takes to build it. In the end your developers are probably really good, maybe even great; however, without proper guidance their work and effort is wasted and they end up running in circles instead of moving forward with the project. Give them clear requirements and deadlines, communicate with them regularly, and you’ll see the magic happen.

But remember – it all needs to start with you. You are the leader. It’s your product. So it is you who needs to show you really care.