

Ask HN: How would you manage an existing software team? - ClickBeepWhirr

I'm a 30 year old guy who built a small business selling desktop support and general office IT consulting.  I sold this company 3 months ago.<p>A very interesting opportunity has come along : an old client of mine has setup a small software company with 2 coders.  The plan is to sell subscriptions on a SaaS basis to small businesses for common small business requirements - invoicing, expenses, timesheets, forecasts.<p>He wants me to manage the company, and get the product built and delivered.<p>I've examined the business plan, and I think the business model is workable.  There are plenty of competitors in the market, but with my insight into small business, I have some unique ideas that would make for a compelling product.<p>My problem is that I know very little about software.  I've run a few successful software projects in my old business (websites, inventory tools and so on), and I have a decent understanding of IT and business, but this would be a very new venture for me.<p>There is an existing team working on these solutions, and they say they're about 50% ready to launch.  In reality of course, this could mean 20%.<p>I'm comfortable with the marketing, sales, budgeting, accounting, business side, but I'd like HN's opinion on actual product development.<p>My current plan for the product development is :<p>Have the existing code independently examined by a 3rd party with no stake in the project.<p>Setup a SVN Repository, and Bug Tracking systems.<p>If the code checks out, work with the developers to build a realistic set of phases and milestones in the project.<p>Hire a part-time tester to test the coder.<p>Give the developers plenty of space to work.<p>Once I'm sure they're the right guys for the job, consider some kind of share arrangement for their services to increase motivation.<p>Release.<p>Improve.<p>Repeat as necessary.<p>Am I coming at this completely the wrong way?  How would you approach this challenge?
======
swombat
_Setup a SVN Repository, and Bug Tracking systems._

If those two developers haven't done that yet, step 1 should be to fire them
and hire real developers.

I think I'd need to know more about your specific situation to help.
Ultimately your success will depend on two key principles:

1) having quality developers in the team

2) giving them the right structure (including plenty of space) to work
effectively

From the sound of it, you don't trust whether those existing developers are
any good. There's a million ways to find out if they are, some of which are
described in my old article at [http://inter-sections.net/2007/11/13/how-to-
recognise-a-good...](http://inter-sections.net/2007/11/13/how-to-recognise-a-
good-programmer) , but you'll have to figure this one out for yourself, I
guess.

If they're no good, you need good ones. If they're good, then I would suggest
toning down the control/paranoia in your plan and trusting them.

~~~
ClickBeepWhirr
Daniel,

Thank you very much for your reply. I got some great pointers from your
article, and I look forward to chatting with the developers and casually
bringing up some of the points you mention.

I'm interested in your proposition - if they don't have an SVN repo and bug
tracking systems they're not real developers.

Are there any other very clear indicators that these aren't the guys you want
on your team?

Co-incidentally, if I do need to setup this kind of environment, do you have
any recommendations on the software infrastructure I should use?

~~~
ErrantX
I'll reply here as swombat has raised the point that struck me.

My first question really WOULD be why are thye not using SVN. It could be they
are: or perhaps using Git, Mercurial etc. (I would personally go with
mercurial over anything else on a smaller team).

Or it could be that as they work in an office together they have different
methods of source control between themselves.

Your first job is obviously to get some proper offsite SCM (I always recommend
offsite for a small startup - that way you have a few guarantees. BitBucket
(mercurial) give you one free private (hidden) repository [1] and GitHub (git)
have fairly cheap plans for private repos [2]. Both of these integrate with
most of the popular ticket / project management sites with little work.

Swombat is right: if they dont have any kind of control going on with their
code then your looking at some bad programmers. But I would say SCM discipline
is easy enough to learn: so dont automatically give up on them. Find out what
their preference is (if any) and work with them on a good workflow plan for
how to get the code into SCM and how to checkout and develop it from there on
a day ot day basis (a common problem we have here with SCM noobs is that they
tend to forget to check in at the end of the day, for example, or at lunch.
Eventually leading to all manner of pain!). As it's a small office it should
be easy to manage though :)

[1] <http://bitbucket.org/plans/>

[2] <http://github.com/plans>

EDIT: as an addendum I would personally ignore all the comments about adopting
Agile development practices (especially things like Scrum which was
specifically mentioned).

The major reason is that they simply do not work as well for you as they do
for the people that "invented" the practice. Strict guidelines never work if
you just implement them. Agile tends to be for teams that want to sound trendy
and hip ;) it's faster just to develop your own process naturally.

Also if you leap into the office with all these new "agile" ideas you'll just
be considered "management type" and probably not be greeted well by the
existing team. You obviously need to bring in stuff but in as relaxed a way as
possible is probably best. As it is a small team it wont take long to have a
few meetings to decide the way forward - and with so few members there is not
likely to be long drawn out discussions.

If you go in with some sensible stuff like SCM and workflow ideas and ask what
they think of them you'l get a good response I'll bet.

Oh - and outline your role to them as clearly as possible. They might, for
example, think your beign brought in to assess them and get rid of them (which
in a way might be true - but best not to say that :D) rather than to manage
the product so they can get on and code.

Hope that helps.

------
anamax
> There is an existing team working on these solutions, and they say they're
> about 50% ready to launch.

> ... work with the developers to build a realistic set of phases and
> milestones in the project.

Somewhere between these two statements there's a problem.

What makes you think that they don't have a set of phases and milestones, that
said phases/milestones are somehow inadequate, or that you can do
significantly better right now? (I'm perfectly willing to assume that you can
do better three months from now, but I'll bet that they can too.)

If they don't, you've got a huge problem. But, you haven't said anything that
supports that assumption. So, why are you making it?

------
jacquesm
For someone without experience you're doing pretty good, I've seen plenty of
people approach this in the dictatorial style and fail miserably.

Asking the coders to set their own milestones and then keeping them to it has
worked well for me in the past. That way it is not your deadline they have to
make but their own, which goes a long way towards making people accountable.

good luck!

------
ClickBeepWhirr
Thanks! I'm an IT guy at heart myself - Dilbert style management makes me
break out in hives.

Appreciate the feedback on the milestones. I'm very interested in what a coder
would generally consider to be best practices in a software rollout, and how
to keep people interested, motivated and on track.

Any further insights or feedback would be great.

~~~
ErrantX
out of interest does the existing team work out of an office or from their own
locations? And also is it their full time project?

(I have some comments to make but the specifics depends a bit on the answers
to those questions)

~~~
ClickBeepWhirr
Thanks for your reply.

Currently they're working out of an office, but I'm open to more flexible
arrangements. Yes, this is their full-time project.

------
DanielBMarkham
It all sounds good, but I would be careful about planning.

As a manager coming in from the outside, you're going to want long-range
plans. What we've found is that coders are notoriously unable (along with the
rest of us) to predict on a long-term basis.

That doesn't mean don't plan months and years out, but it means as far as
_commitment_ , have your programmers commit to little chunks of work at a
time. Put together a big list of stuff that needs doing (but not too big,
maybe 50-100 items max), then pick a time frame, like every two weeks. For
each time frame, ask your programmers to commit to doing whatever they think
they can from the list. At the end of the time frame, have them demo what
they've done -- and fight the urge to micro-manage in the middle.

By having fixed timeboxes, a prioritized list of stuff, and giving control
over commitment to the team, you can have lots of little wins over time, which
is a great morale booster and also helps you spot problems much earlier than
with a long-range plan.

~~~
ClickBeepWhirr
Very interesting perspective - I've tended to work with people by doing big
picture proposals with a list of deliverables, but this kind of bite-size
requirements could be a great way to get a feel for the team.

This could even become my standard way of working with coders.

Thank you for taking the time to comment.

~~~
abiglan
Look at the Wikipedia article for Scrum (development). It outlines this
approach reasonably well, and is "easy" to implement (e.g. the developers will
not reject this as "over process") Be agressive in terms of commitments
(making and missing) and hold to the fixed timebox. I -highly- recommend a 1
or 2 week timebox (-not- 30 days) as it forces more decomposition and only has
people commiting to what they really know. Do the demos. Focus on vertical
slices of functionality (e.g. don't just build the breadth of the UI
component, take a single button and get it working down to the DB (for
example)) -force- the developers to use a CM system and as part of the
retrospectives, review checkins/branching, etc. This can evaporate after you
are convinced that they are using a CM system (a month or two?) ask about unit
tests (even if you know little about software) if you sense BS, then you have
a real problem. If they are developing UT's as you go. This is a good sign.
Your hired tester should be able to review unit test coverage breadth with you
(plural). hth

