I recently joined a startup as a Developer and the work environment is very casual to say the least. There is no top management in the team i.e everyone reports to the founder.

The problem is the founder is busy chasing investors so usually there is no one to report to. Since the pace at which we were going was pretty slow, the founder asked me to manage the team.

Now i have experience as a lone developer for startups so I've never really worked with teams. And as far as i know the Team Management in Start-ups is much different from MNCs. I tried to apply the Scrum method but turns out it doesn't really work for startups as there are just too many things that needs to be taken care of. Also the team we have, according to me procrastinates a lot. Like they complete one task then go on fb,twitter etc. Also since everyone is also learning new things all the time, i can't just assign a task and give it a time frame. Almost everyone in my team is fairly new with like 1-2 Years of experience.

I am trying my best to handle them but it turns out that i can't expect a time frame, that i myself expect myself to finish the job in.

How can i manage them so that our productivity as a team can increase and they can stop spending hours on social sites. Do i just assign them tasks after tasks so that they don't even get time for these things? I am just confused about this as i also have to the development work while managing the team.

  • Daily meetings are good. You get a picture of what everyone is doing. 5 minutes on Facebook a day ain't a huge deal, but if it's over 30 minutes it's a lot. You need to delegate a bit Commented Sep 20, 2015 at 18:49
  • 2
    Work expands to fill the time available for its completion. With no deadlines, no time pressure, no cats around (your founder) and the mice will play. Commented Sep 20, 2015 at 20:35
  • if you think social sites are causing a problem, why not filter internet and block social media, either between certain hours, or just block altogether?
    – Kilisi
    Commented Sep 20, 2015 at 20:58
  • Also posted on PM:SE here: pm.stackexchange.com/questions/16257/…
    – Marv Mills
    Commented Sep 21, 2015 at 11:56
  • 1
    Out of curiosity, when your founder hired a bunch of very inexperienced people what did they expect to happen? Are these people otherwise good employees? Or are they the cheapest employees that could be hired? Context for why a startup hired a bunch of inexperienced people would be really helpful.
    – enderland
    Commented Sep 21, 2015 at 12:25

3 Answers 3


Scrum method but turns out it doesn't really work for startups as there are just too many things that needs to be taken care of

Project management takes time, no matter what your method is. The more tasks you have, the more time it takes and the more annoying it is. It doesn't matter whether you dump the data into Microsoft Project Server or a cardboard Kanban chart. The data is there, it needs to be handled. There is no such thing as:"There is so much too do that I can't write down what there is to do."

Maybe this is already your first problem - if people don't see how much there is to do, nobody ever has to worry about whether the next social media post or the next task is the appropriate choice.

The second problem: If you don't know how much time you need and how many developers you need, how do you want to know how much money your company needs? Whatever it is you do, there needs to be a milestone - which might be just to get something up and running to show investors. You need to plan the tasks for this milestone and the amount of work.

i can't just assign a task and give it a time frame.

That's right. Nobody cares about deadlines, when they are artificial. A time frame is also not the right tool to increase productivity.

How to stop people from not working, when they should? Tell them. They get paid for working. Working 14 years on Duke Nukem might basically be worth an award, too, but most startups can't afford that.

If you have a milestone and a list of tasks up, you can flat out tell them the truth that when milestone 1 is not met, the company has no more money and basically no chance to get more money, because there is nothing to show investors, which means termination of most contracts. Of course, this approach needs to be coordinated with and approved by your boss. But it is the best way to teach what it means when people don't work - that it's not about you being a party pooper, but that people will lose their job in the end.

  • I've found that if you let people set their own deadlines they're more likely to be met. "How soon can this task be completed?" Is my approach. If it doesn't fit your PFD then you may have to crash that task or ask "What needs to happen to hit this timeline?" Commented Sep 24, 2015 at 17:47

First off, don't worry about what the team is doing every minute of the day. If you're coders have "hands on keyboard" three to four hours in a normal work day, that's high productivity. There is a myth that the 12 hour work day, seven days a week is more productive than eight hour days of steady and sustainable pace. Focus on results, not if Joe codes 30 minutes, FBs 30, codes 30. Focus on what gets done.

Agile practices work because of three things, Clarity of the Backlog, Accountability of the Team, and Measurable Progress.

Clarity of the Backlog: You need to carve time out with the founder to make sure what is being worked on is the right thing. This can be done pretty easy and in small spurts of time using the solution for team accountability.

Accountability of the Team: Many startups find Scrum to be too much process. Things are changing to fast and people are often very specialized. You're probably going to have a lot more success with a straight Kanban board with Work in Process limits.

The kanban board is a straight rank ordered list of work to be done. Any work that has to be done is placed here. Even non-coding things like "order new desk for the new guy." There is no time box for work. Instead people pull from the top of the backlog and work on it. You set work in process limits so that people are not working multiple projects at a time and even encourage swarming of tasks by multiple people. When ever the founder has a few minutes, drag him to the board to verify the order of things and ask for anything new. Hold a daily standup, just like Scrum, so the team can talk about the work they've done and plan to do. Review weekly what got done.

Measurable Progress The only way to truly measure is through the shipping of working, tested software. Try and get to a continuous build environment as soon as you can. When someone checks in code, you know instantly if it worked or not based on if it kills the build. At the very least, try and have monthly milestones where the product goes through a build and is shown off.

You can find more agile project tips at the Project Management Stack Exchange forum.

  • 3
    "Focus on results" - the lack of results is the problem in the first place. Commented Sep 20, 2015 at 18:46
  • A month is a long time in the life of a start-up. When I was working on a critical project in a start-up environment I reported tests passed every week. Commented Sep 21, 2015 at 11:50

From the way you describe the situation, I gather that your self assessment is correct - you need additional support. First off, you need training. There are lots of courses, anywhere between $500 and $5000. Book one.

Second, you want to keep things simple. Scrum can be rather overwhelming, so slim things down. I suggest to start with only the following:

  • Keep something resembling Scrum Sprints, but simplify. Agree on a goal with the team, make them come up with what they want to achieve by the end of the week. This will help them to figure out on their own what to work on when one task is finished early. Best figure out what to achieve next week by end of Thursday.

  • Keep the daily Standup, but keep it short. Never ever let it run over 10 minutes or people will get bored and sabotage the meeting. If something else needs to be discussed, agree on a follow up meeting to discuss it right after the Standup - only people relevant to the specific discussion should join the follow up meeting, and that might mean even you don't need to attend. Standup should be status report to the team (not to the team lead) and what everyone is planning to do for the day so that people can coordinate their work better.

Remember: You don't want to tell them what to work on - you want them to figure out what to work on. You don't want to coordinate their work - you want them to coordinate their work with each other.

Once you got these two things running reliably for 3 weeks straight, you can start looking into other parts of Scrum, and they will make a lot more sense with the experience you gained in these 3 weeks. As someone who hasn't had much feedback, you'll almost certainly find the next thing from Scrum you'll want to implement then will be Retrospectives. You also might want to shake things up by using Kanban as inspiration for the Standups.

On the Facebook/Twitter thing, use borrowed authority if you can. Let the boss tell the team he's noticed a lot of traffic to social media and that he's happy with people occasionally using these services during breaks or when it's necessary for work, but that he'd appreciate it if the privileges don't get abused so he isn't forced to block the services.

You must log in to answer this question.

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