Blog: Effective Software Development Management with Jay Bregman

ICT KTN Online Business Essential Clinics #3 Effective Software

Development Management with Jay Bregman, 5th October 2011

 

Jay is a successful tech entrepreneur based in London and the founder and former CTO of eCourier, the online delivery service for which he has received many notable accolades including the award for “Most Inspirational business 2007”.

He describes himself has having a passion for logistics. He likes to figure out how people are connected in the real world, how they communicate and what tools can be developed that make that process more straightforward.

In his most recent venture Jay recently founded Hailo, a mobile service that gives you a direct line to London’s infamous Hackney carriage – black taxi – network so that you need never again be stranded after a late night party or rush to the airport.

 

Below is a breakdown of Jay’s presentation into key points and if you would like to view his slides as a further support they are available on slideshare.

 

1. Solid foundations

The overall advice Jay impresses upon us is to put effort into the foundations of a project, namely the people and contracts that will determine how successful the outcome will be. It is the nature of start-ups that this process should be conducted relatively quickly but caution and a methodical approach is advised.

 

2. Get a good team

Through his endeavours Jay has picked up a lot of experience is software development management and the key to success in his view is always work with a good team. Projects with bad people that are badly managed will fail, projects with good people but again badly managed with however come through eventually.

 

3. Recruiting

The best place to start in getting a good team together is to ask around, look towards your friends and their networks, ask them for recommendations seek out those people who come with solid reputations. Also consider using recruiters – not one, several – so that you cover all bases and speed up the hiring process.

 

4. Developers like small, interesting companies

In the current climate the market for developers is hot and therefore competitive. It can be difficult to catch the developer of your choice, especially when you’re unable to offer the high salaries they can currently demand. Start-ups do however come with an advantage over larger corporate employment – they’re small! Developers like to be involved in companies where they can have a more hands-on experience and see the effects of their work. Providing them with freedom, flexibility, the all important equity share and the ability to build relationships with you as the founder and your network is a more exciting prospect with greater potential than perhaps a larger company environment. Also, a great idea wouldn’t hurt either!

 

5. Due diligence 

During the recruitment stage don’t skimp on putting your developers through their paces, it  will pay off in the long-run and quality developers shouldn’t have an issue with sitting a code test in the interview stages. If you can ask an expert to draft the test.

 

6. Contracts / IP

Spending the time to prepare a solid contract with a project outline, a clear set of deliverables, a non disclosure agreement and an IP assignment form or an intellectual property agreement will save you the possibility of pain in the future. Funders prefer for companies to be the owners of the code, that way the project is insured against collapse in the future should the developer leave. Don’t worry whether or not you may seem pedantic to prospective developers, it is always better to have clear agreements from the beginning.

The question was raised, is it ok for developers to work on other projects while they are with you? Jay advised that it would be fairly unreasonable to impose such restrictions on the developer. Creating a fair and flexible environment is more productive and instills a sense of trust. It is a good idea however to ask the developer at the interview stage what other project they have in the pipeline so that you can discuss any conflicts of interest.

 

7. OUT v’s INsourcing

The answer is relatively straightforward, if the project requires standard coding and is therefore low risk, go for an outsourced team. If the idea is one that needs some innovative problem solving and specialised skills then consider an in-house team. Building a new product can be disruptive and although it may be more expensive to have someone in-house the greater value will be in the technology you create. Jay also advises anyone who is considering using off-shore developers to do so with caution, it’s best to have previous experience working with an off-shore team as it could cost a lot more if things go wrong. A good tip from a member of the group is to consider having a member of the off-shore team work from London, it costs a bit more but it concretises communication channels.

 

8. Tech co-founders

Finding an appropriate tech co-founder is difficult as those are the people in short supply. Jay advises that a way to entice them would be to make them a 50/50 partner, not just an employee. Having a tech co-founder will increase the chances of obtaining funding for the project as you will appear to investors to have a more solid proposal on offer. In taking on a new founder Jay stresses that you should pay as little up front as you can, agreements should be made around key milestones to secure drive and commitment. Ask partners to take a portion in cash up front, an equity percentage and then a portion of cash on delivery.

 

9. Tools, tricks and management

Putting the correct infrastructure in place for record keeping, project management and bug tracking is essential and particularly pertinent to coding work. Tools are there to provide transparency, clarity, risk minimisation and workflow optimisation. NB: Developers don’t have an impeccable track record in accurately estimating the time it will take to complete a piece of work and so these tools help to construct a more realistic prediction.

You will need a software code repository to finish a project and it will help management in keeping track of a developers workload. Another good thing about the repository is that it centralises the work rather than having lots of pieces of code scattered across individual computers. It reduces risk, creates transparency and therefore aids communication

 

10. When it starts to go wrong

Jay’s main advice is to begin with an end in mind. Shifting from an idea into the components of a project needs a lot of back and forth amongst the team so have as much discussion as you can before starting. Poor contracts will harm outcomes especially if a key person decides to drop out midway through. You need to protect yourself against this eventuality in the contract as hiring someone new will inevitably slow things down. Be vigilant about hitting your targets, repeatedly missing them should be an instant red flag and issues should be nipped in the bud early on.

Finally, remember you don’t have to have every feature available in the first version, the emphasis should always be on quality and don’t extend past deadlines, instead restrict the amount of work for completion.

 

Jay would like to invite you to sign up to the beta testing of his new project Hailo.