Posts tagged with “cto”…

Chief Technology Officer job description (for web, start-up or corporate)

Posted by Aidan, 6th July 2009. Share this:

• chief technical officer
• chief technology officer
• cto
• interim cto
• job description
• start-up
• startup cto
• web cto

We've been swapping some thoughts with Daniel Kehoe, a consulting CTO acquaintance of ours from across the pond. Dan drew up his thoughts around a job description for a web Chief Technology Officer (or Chief Technical Officer), and invited us to follow suit.

Firstly, there's no one-size-fits-all description. Some companies look for a more strategic or a more hands-on CTO. Start-ups often hire at one extreme -- closer to a Lead Developer or VP of Engineering -- whereas corporates may focus on their CIO, which is potentially quite a different role.

We think the most important principle is that the CTO is the go-to point for all technology in the business. Some companies merge CTO and CIO roles, but when they're separate, it's typically the CTO that builds the technology and the CIO that exploits it internally. So long as that is clear, the specific responsibilities are often not hard to establish. We think a "best-of-breed" role looks something like this, and you're welcome to use it. We've highlighted points more specific to start-ups in blue.

Chief Technology Officer

Summary

The Chief Technology Officer (CTO) reports to the CEO or board and is responsible the company's technology strategy and implementation. As a technology leader, the CTO needs to be able to see IT at macro and micro levels simultaneously within the company. The role necessitates a hands-on approach, with periodic on-call responsibility. Responsibilities highlighted in blue are more appropriate for start-up companies.

Strategic

• Report to the CEO or board as an active part of the senior management team.
• Contribute to development of primary business plan, with input on focus, costing and approach (platform, build vs. buy, resourcing, hosting strategy, time & cost).
• Design and maintain a roadmap of projects to meet demanding business objectives, taking advantage of trends and new technology where appropriate.
• Where necessary, produce cost-benefit and risk justifications for IT initiatives to win budgetary support from the board.
• Ensure staff, partners, customers, and board understand the business' technological vision.
• Work as an industry thought-leader, representing and evangelising the company at conferences, on-line, off-line and with social media, and through working with and steering relevant industry bodies.
• Hold responsibility for IT governance of platform & services, including telecommunications, networks, infrastructure, engineering, media, and architecture.
• Prepare and test disaster recovery plans, and contribute to the broader business continuity plan.

Tactical

• Draw-up and control complete IT operational and capital expenditure budgets for IT.
• Where possible reduce operational and capital spending on an ongoing basis, through use of Open Source technology, cost-effective procurement, efficiency gains, and through coordination of activities and resources with parent and group companies
• Manage recruitment, development, retention, and organisation of operations, development and IT teams, keeping staff focussed, motivated and growing into future technical leaders, whilst satisfying budget and policy.
• Ensure uninterrupted delivery of IT services by defining and managing against external service level agreements with suppliers and internal agreements with end users.
• Where appropriate, patent or secure intellectual property by other means.
• Own and manage the development, operations and IT methodologies, including procurement, backup, email, internal groupware, IT project management, source-code management (SCM), bug tracking, deployment, release management, monitoring & performance, quality assurance (QA), application profiling, coding standards & review, management information (MI), business and web analytics, security, configuration management, architecture, infrastructure & hosting, intellectual property and networking.
• Ensure IT activity falls within applicable laws and regulations (DPA, PCI-DSS, SOX).
• Where developing a new system in a start-up environment, work with the business to develop use cases, user stories, user experience design and wire-frames. Work with others to produce graphic design for prototype. Choose platform and architecture for prototypes and V1 projects, and provide cost-effective 80/20 solutions.
• Own and manage the internal IT customer support process, and externally where appropriate.

Experience

• Five years' experience directing IT; a further five years' software engineering management or operations management experience; and two years' experience in a start-up or highly entrepreneurial environment.
• Demonstrable experience of each of the following: data warehousing, enterprise applications, networking & hosting, telecommunications, recruitment, outsourcing,
• IT governance, project management and software engineering.
• Understanding of relevant laws, regulations and information security best practices.
• Past responsibility for operational and capital budgets in excess of $1M, confidence with budgeting and spend planning.
• Past contribution to one or more Open Source projects.
• Ability to explain to the following technologies, standards and regulations to non-technical staff: AJAX, UNIX, RFC, W3C, HTTP, RDBMS, SCM, SEM, PBX, SEO, P3P, PCI-DSS, DPA, XP.

Personal

• Entrepreneurial attitude.
• Ability to excel under pressure.
• Ability to prioritise effectively in the face of business uncertainty.
• Excellent written and oral communication skills, for technical and non-technical audiences.
• Strong problem-solving and motivational skills.

This post has 0 comments »

Kublax insecure: what is going on?

Posted by Aidan, 1st May 2009. Share this:

• audit
• cto
• development
• security
• seedcamp
• turnaround

On paper Kublax sounds like a great start-up. They've set out to solve a real challenge faced by users of online banking. They're doing it with relatively little competition, are well funded, got through Seedcamp in 2007, have some really smart investors. What they're doing is a little tricky, although it's been done very well in the States by Mint, who are excellent.

I've been intrigued by Kublax's journey, having been following the space very closely. It was announced in passing during one of the TechCrunch Geek'n'Rolla presentations the other week that they were relaunching, seemingly without fanfare. Kublax had presented at the TechCrunch SeedCamp review event in September 2008, one year after getting funding, but were unable to show a working product.

Keeping it simple is as good a principle in business as it is in technology, much as it might make for glib analysis. Kublax' main priority was to address the pain they had identified: allowing users to bring their online banking accounts together for ease of use, better budgeting and to save money. Their main threat was that their implementation -- which by necessity requires the users to give up the online banking details they're not supposed to -- would need to be perceived as incredibly secure. Ease of use and security: that's it, a little mission statement for the developers.

Maybe the early roadmap looked a bit like this:

1. Build a prototype to explore the proposition
2. Raise some funding to pay third-party account aggregator
3. Building something easy to use and secure
4. Build a clever automatic tagging engine but also hire a bunch people to type in categorisations all day so that statement data gets correctly analysed
5. Start addressing shortcomings in service from third-party account aggregator
6. If it's working well, enhance the revenue generation mechanism and spend some money making the platform more robust, scalable, etc.
7. Profit

Something has gone wrong, however. Kublax is neither easy to use nor secure. That's a sweeping statement, so let's look into it.

Kublax is not easy to use

First off, it doesn't work properly in Firefox. At a quick glance, popups break and the budgetting table misforms. There's no tagging of transactions possible, no evidence that the interface learns, no statistical analysis from other users' general data, and poor initial categorisation of spend. I've put several accounts in it and less than 15% of spend gets categorised correctly, or at all. The interface is slow, counter-intuitive and fails to take advantage of a fair few Web 2.0 tricks that could really help.

The shortcomings from the third-party account aggregator haven't been addressed. The system can't recognise transfers between bank accounts, struggles with common direct debits, and can't figure out cash withdrawls in shops.

Take five minutes to log in to Mint. It's beautiful, and is based on the same technology. Yes, they raised around $16M more funding but it's a similar age and I bet it's not the technology that most of that cash has gone on.

There's huge potential in online account aggregation, but there's less functionality here than in Microsoft Money or Quicken.

Kublax is not secure

So what about security? Is Kublax secure? Well no, I don't think it is. There's at least one glaring security hole, and a huge amount of bad security practice to the extent that it is a good tool for hackers and phishers.

It goes without saying that making a secure product is fruitless if it isn't presented in a way that's trustworthy and secure. Getting that copy, branding and user-flow is essential to create the feeling of trustworthiness. Aside from SSL padlock icons in their browsers, most users have no idea whether what they're doing is secure or not, and the perception of security is emotional, and separate from any real security. The security FAQ is written in rather poor English with a liberal sprinkling of commas: "Kublax alerts can increase your financial security, by providing you with timely appropriate alerts". The FAQ includes this:

"What if my bank calls me to tell me that a robot is accessing my account and to terminate any account aggregation service? Have a look at your account and you'll see everything is normal. We do "read only" service and no transaction of transferring money can ever take place. Your bank has contacted you based on their misunderstanding of the way in which the service works. Put simply, there is no disclosure of your security details to us or to anyone else through your use of our service. [...] It is unfortunate but inevitable that in this modern age some of the older organisations find new services threatening because they do not understand the nature of the service or because the service may not show them in a favourable light in relation to their services or as against their competitors."

This reads like a phishing phone-call from Fonejacker's George Agdgdgwngo: "Good morning Sir, there is a pigeon in your bank account, I just need your bank account details". For a start, it's wrong. Security details do pass through Kublax and Yodlee, even if they're not stored. To suggest that the service is secure because it's not possible to transfer money suggests access to the read-only data is perhaps not so secure.

And anyway, it's not secure, with a cursory inspection showing up some really serious security flaws. Kublax has basic security errors including CWE-312 ("Cleartext storage of sensitive information"), CWE-311 ("Failure to encrypt sensitive data") and CWE-319 ("Cleartext transmission of sensitive information"). America's National Security Agency puts CWE-311 in the "top ten" most dangerous errors in the "insecure storage" and "insecure communications", and rates CWE-319 in the "top 25 most dangerous programming errors".

You can quite simply demonstrate all three of these errors by using the password reminder functionality. This sends your password -- completely unencrypted -- by email back to you, meaning that the sensitive data that Kublax do store is unencrypted and accessible by at least some of their employees. The message I received was:

"Dear ,

Your password for Kublax.com is PLAINTTEXTPASSWORD

Kublax Team. "

Oops! Awkwardly, when you use the password reminder functionality, Kublax doesn't confirm they've sent a reminder email. Rather, the site throws an error saying "You have been INACTIVE for a long time.Therefore for Security reasons we have logged you out".

That's not the full extent of the problems. Unlike secure sites, Kublax reveals the difference between an invalid email address and an invalid password as users try to log in. If you try to log in on Amazon, eBay, MySpace, Facebook, etc. and you get either your username or password incorrect, you'll get an error message telling you that one or both were wrong, but not identifying which. Would-be phishers with lists of email addresses to target for online-banking fraud can easily run their lists against the Kublax system to see which users are registered for online banking.

Having forgotten my own password for the system I tried about ten passwords before I got it right, and unlike secure online banking systems, Kublax won't lock you out after you try a number of incorrect passwords. This opens the door for brute-force hacking. Would-be hackers could easily look up the partners at Kublax's investors, for instance, and brute-force their email addresses. Even more dangerous is the face that the Kublax system has weakness CWE-521 ("Weak Password Requirements"), allowing users to choose passwords such as "letmein" or "password". There are good reasons for online banking services to restrict these choices.

Long-dormant accounts, such as mine which was last used six months ago, should probably be flagged as being dormant and require some form of additional security to reactivate, to prevent forgotten accounts being targets for hackers. There's no sign of this happening on the system.

With all of these obvious problems one rather wonders what the behind-the-scenes security of the infrastructure and back-end is like. It can't have undergone an external security audit.

What does all this mean?

From the outside, it's hard to see where it went so wrong. Other than having said hello to the Kublax team at the event in 2008, and having programmed using the underlying account aggregation software they use, I know little of the background. Some things are clear, though:

The technology implementation has been a disaster. The Yodlee account aggregator service that they use is not that difficult. In two weeks it's possible for a single coder to knock up something crude but essentially as functional as the Kublax site, and I know this because I've done so myself.

I suspect the problems have stemmed from a typical startup challenge: outsourcing technology is difficult for start-ups, and it's hard to get it right. I believe Kublax's technology is outsourced to India. Outsourced or not, there are a dozen Ruby on Rails agencies who could deliver a prettier, more intuitive interface than Kublax's for no more than £50,000, and in a matter of a few months.

And what next for Kublax?

A few tips from us:

• Take down the site until it's secure, and get an external security auditor in.
• Get in a new creative agency and brainstorm some designs with them. Look at Mint and some of their competitors for inspiration. Come up with a less clumsy way of integrating financial product referral: it drives revenues.
• Find a way to manage the capital outflow to the account aggregator. There's likely a massive burn rate for the business in this.
• If necessary, start raising another round of funding to buy some time.
• Get in a new CTO, and start prototyping an application with the new designs. Take that to the investors. The CTO should be cognisant that a highly productive web language will probably be more cost-effective than Java, but in a few months he should be able to catch up with the last platform.
• Don't forget SEO this time: it looks like an afterthought in the current platform.

A final comment

Reincubate are in the industry to build and contribute to growth start-ups. It's incredible that a Seedcamp winner should struggle so much with their technology, and we're always happy to provide constructive criticism and suggestions to move forward, as above.

There are valuable lessons to be learnt by other entrepreneurs looking to innovate in this field. Don't lose track of the consumer pains you're addressing, and if there's a threat around security, for instance, do everything you can to mitigate it.

As ever, we appreciate the feedback we receive.

EDIT: Interestingly, Kublax was tipped off about some of these security problems by Doug Winter back in February. He found a more serious security problem which has since been fixed, but concludes his review: "Kublax: security fail, usability fail and coding fail. If I were a VC who had funded this I would be quite upset".

JUNE UPDATE: No more than a month after this post we were pleased to see Kublax's new CEO announce an overhauled site which addressed some of these issues.

This post has 2 comments »

Start-up CIO best practice

Posted by Aidan, 31st March 2009. Share this:

• best practice
• cio
• cto
• start-ups

We were delighted to have a short piece on CIO best practice published in the March issue of CIO Magazine. Here's what we said:

Just like starting over

Running the information needs of a hot new online company may be attractive, but there are plenty of pitfalls to watch out for on the road to success

Online startups are on the rise, springing up around the country despite the credit crunch. With “Silicon Roundabout” firmly established in London's Shoreditch, there's more support than ever: the new online Dragon's Den, networks like Smarta and “Entrepreneur Country”, post-boom microfunds and virtual incubators such as Betaworks and Reincubate.

The startup CIO must operate differently from a typical CIO, and one of their first decisions will be around “build vs. buy”. “Buy” – or rather, outsourcing parts of the platform to an agency or partner – can be very appealing to a startup.

“Fail to prepare, prepare to fail” is often applied to outsourcing, but startup CIOs should heed another mantra: “fail fast”. Uncertainty abounds in their operating environment and CIOs should aim to make failures apparent rapidly, and before too much money has been spent. CIOs should be wary of Stockholm syndrome, where they find themselves starting to defend inadequate partners from their own businesses.

Outsourcing well requires experience, and all the more so for low budget time critical projects. Typical outsourcing best practices are not well-suited to startups, and most of the agencies within reach of a startup are more used to working with established businesses. With untested business models, few staff, and little time, how can startups create a strong, trusting long-term relationships with outsourced partners reliant on their revenue?

Success with the initial business plan is rare, and with many pre-revenue companies changing their strategies or products three or more times before they get to market, it is sensible not to commission projects fixed scope in entirety from the word go. VCs typically expect a successful exit from ten per cent of investments, and success on the part of the startup will radically – and often unpredictably – change requirements. Without a terms in the contract to change tack, the agency project manager might step back and allow the CIO to work directly with agency staff. This can break down methodology and muddle specification ownership. Close communication is vital, but CIOs should be aware of the risks of their CEO distracting the partners with talk about phase two when phase one is still the objective.

Alongside limiting the scope of projects, prescriptive technical specification is important. Agencies may be able to deliver products are that are beautifully search optimised, for instance, but may only do so where explicitly specified. Stakeholders should specify platform metrics to avoid costly or inaccurate data-mining processes. Web and user metrics are common, but there are also likely to be operational metrics that will be reported to investors, or which are key to monitor business performance.

Most UK PLC CIO's aren't at risk of bankrupting their companies if a project overruns by fifty per cent, and it's not uncommon for CIOs to renegotiate with suppliers or their board, weeks or months into a project. It is a lenient seed investor who will keep confidence in the startup CIO who admits they have underestimated core costs so significantly. Milestones will change rapidly, and investors need CIOs that are cognisant of the chance for unplanned technical cost.

Outsourced partners may want to work with their metrics rather than the CIO's, and are often keen to avoid specifying an effective man-month cost. This complicates tendering, and getting partners to report against the startup's own metrics is an important principle. Day rates of £600 or more are standard for many businesses but will rapidly cripple a startup.

Micro-proofing – or building inexpensive prototypes as often as possible – is a sound principle. Prototyping is cheap, helps the business to learn more about what it really needs, and can be a good benchmark for quality and cost-creep from the supplier. Startup CIOs would be well advised to double any supplier quotes involving more than customisation of an existing platform.

Delivery quality management is hard, and there is no substitute for robust due diligence. Vetting potential partners to find which are agile and follow best practice can save some unpleasant surprises later on. CIOs should cast a wary eye over partner methodology at the outset.

Outsourcing a project doesn't mean the CIO can just let partners “get on with it”, and an experienced technical person following the build and chasing agencies will be more likely to get results. A remote third party can often be found to support the CIO, should the partners be overseas.

To hasten delivery, the partner may customise an off-the-shelf product to address the project, adapting Open Source or customising a proprietary product. The CIO should determine whether the agency's choice is objectively the best fit, or if they chose because it either fits their other project work, or is a new technology that they would like to learn. Smaller startups should be wary of CMS platforms being shoehorned into ill-fitting “one-size-fits-all” solutions. Secure, robust solutions will not be delivered without the right components.

Less experienced CIOs might struggle not to get caught up with low level technical specifications, losing sight of the business need and investor's requirements. CIOs may find their CEOs or board have made assumptions about the technology strategy which are not made explicit, and even the need for developing or retaining technical IP can be unclear.

It is important to recognise whether the agency will be developing a product that the customer will own. If not, there may be a perpetual license or ongoing licensing cost. With a poorly worded contract, we have known some agencies to bill for a full “build” project, only to deliver a “perpetual non-transferable license”. The investors have subsequently fled.

CIOs need ask a number of further questions of their partners: if the project is being built for their ownership, is it being built on a proprietary framework? Is the partner offering escrow on the source code of that framework in the event of the agency's liquidation, and could it realistically be managed if that happened? Is the software being built using servers or software which could introduce additional licensing cost if hosting providers were changed?

One of our clients had outsourced work to Pakistan, and whilst looking at the publicly accessible development servers of their partner during our due diligence, we found we had full access to a variety of highly confidential documentation from their other clients, not to mention a full, unencrypted database backup of a UK retail business' customers.

Serious security failures like this are uncommon, but failure to comply with relevant legislation is surprisingly prevalent. Even if the partner had secured their servers, the fact that they were storing complete sets of user data outside the EU sets them in breach of the Data Protection Act, and their storage of customer billing details breached PCI-DSS (payment card industry) regulation. The customer's site did not comply with the updated Companies Act.

Where CIOs offshore and manage to secure tantalising sub-£1,000 man-months, most partners will not follow their business' legal and regulatory constraints.

Finally, partner contracts should model what would happen when only some of the functionality is delivered, and consideration of what defines a successful implementation is important. An agency may feel that they have delivered ninety per cent of the functionality, whereas the CIO may feel he has only fifty per cent of the tools he needs.

Web startups can fail catastrophically with immense technical complexity when poorly managed, and with best practice, methodology and specification being discarded. They can be left with a mess that is far from the expected delivery, with the cost of making good unclear or beyond budget. Partners may offer to write off invoices in exchange for equity, or a commitment to further work being put their way, but it is a desperate company that signs up to this after a project failure.

Being well equipped to engage at an early stage can make a startup CIO. The role is not for the faint hearted, but with careful planning it can be immensely rewarding and can propel the CIO into new career heights – or early retirement!

This post has 0 comments »

The problem with development consultancies

Posted by Aidan, 8th November 2008. Share this:

• creative agencies
• cto
• entrepreneurs
• start-up
• web shops

Many of the start-ups we work with have, at one time or another, taken work out to a development consultancy, web shop, off-shore developer, or creative agency. Coming from a consultancy background ourselves (but no longer being one) it's interesting to see how engineering, media and web consultancies fail time and again to serve the needs of early-stage companies.

It wouldn't be fair to say that these are all failures of the consultancies themselves: several are not strictly the fault of the third party, but rather that many founders are ill-equipped to engage with them. Taking on development resource, be it through another company or directly, is difficult, and it takes a certain set of skills to manage this. Agencies will rarely throw their hands up and warn you.

If we take a sample of the thirty or so entrepreneurs we've talked with over the last six weeks, very few are happy with their development partners. Of those who are relatively happy, most are still engaged with them and still awaiting the launch of their project. Signs of Stockholm syndrome are common. From what we've seen, there are six main areas of failure.

Compliance & security

One of our clients had outsourced some work to Pakistan, and whilst looking at the (publicly accessible) development servers of that company, we found we had full access to a variety of highly confidential documentation from their other clients, not to mention a full, unencrypted database backup which provided details of all of a UK retail business' customers.

Serious security failures like this are uncommon, but failure to comply with relevant legislation is surprisingly prevalent. Even if the third party had secured their servers, the fact that they were storing complete sets of user data outside the EU sets them in breach of the Data Protection Act, and their storage of customer billing details breaches PCI-DSS (payment card industry) regulation. The customer's site was itself in breach of the Companies Act.

Sending work to Pakistan, India or China can reduce your costs, although managers may struggle to realise a net saving. If you do manage to secure that tantalising sub-£1,000 man-month, will the people you outsource to understand the legal and regulatory constraints you have? Will they know what they are doing well enough to secure your site, or will they be in a part of the world where Microsoft heavily sponsor their training and they are limited to point-and-click on their servers? If you outsource abroad, retain a competent local expert.

Quality

Delivery quality management is a discipline that countless development managers fail to manage. Engineers and designers have a confusing plethora of tools and techniques to use, and it is not always clear to them which are best practice for the application that they are building. There are some principles which are almost always good to use: agile, design patterns, avoiding fixed scope, source code management, web frameworks, Open Source, and so on, but is isn't black and white. If you're going agile, which methodology should they use? Extreme programming? Scrum? Should they be test-driven? Should they use test-first and continuous integration?

Start-up customers usually have high hopes and low budgets. If it doesn't get delivered at a level of quality to get investment or revenue, they're sunk. A lot of agencies are used to working with established businesses and just don't understand this. Get an independent third-party to take a view on their methodology before they start. If the start-up has an independent technical face to follow the build and chase developers, agencies will be much more likely to deliver well.

Specification & contract control

Start off in control of the specification, and share it through user stories or something similar to create joint ownership. Founders know this, and they start off with a specification, but often as the cost of delivery increases and the product nears release, they start to tune their requirements. Most of the pre-money business models we see change three times before they get either investment or revenue. As such, it's not a good idea to commission your project fixed-scope in its entirety right from the word go. In the event that the developers actually build what was asked for, it's all but guaranteed that what was asked for is then not now what was required. When this starts to become clear, often the agency project manager steps back and lets the customer work directly with the programmers. All of a sudden there's no clear spec, the user stories have been abandoned, and the agency abandons its methodology.

Most agencies and consultancies that read this will say "of course we'd never do that, we're [agile/professional/highly competent]". Realistically, they're not. And it's often not their fault. It's mostly the fault of those engaging them.

Another issue with specification control concerns technical specifications. Sometimes the most remarkable things happen, and we've seen an agency that has delivered beautiful search engine optimised Ajax-driven sites release static Web 1.0 monstrosities. When we intervened and asked them why they built it to be SEO unfriendly the reply was "we haven't optimised it as there are hundreds of techniques and it's completely ready for SEO enhancement". Yes, anything that isn't search engine optimised is ready for being optimised...

Project specification should be done with a view to any compliance issues that business might face, but don't forget to specify the platform metrics. Web and user metrics are one thing, but what are the operational metrics that will be reported on to the investors, and which are key to report on to monitor business performance? Specifying which of these should be monitored up-front should save a costly or inaccurate data-mining process.

Finally, contract metrics are important. Your contract with the agency should handle what happens when only X% of the functionality is delivered, and consideration of what defines a successful implementation is important.

Cost and cost management

Odds are, you should double the cost if the project involves more than customisation of an existing platform. If they're good it may only be 50% more than quoted cost. If you build a prototype first you're much more likely to know what you really want, and to get a feel for build-cost creep. Micro-proofing, or building inexpensive prototypes as often as possible, is a great principle.

Intellectual property

It's really important to understand whether a business needs to establish technical IP. Contracts and specifications need to be clear. Are the agency developing a product that the customer will own? Or will they have a perpetual license, or an ongoing licensing cost? Are they building something, adapting Open Source or customising a proprietary white-label product? We've seen an agency turn around (after billing for the full project build) and when asked to clarify an unclear contract, they said "you have a perpetual non-transferable license". In short: customer has no technical IP and doesn't even own the product they thought they bought, investors flee to hills.

Even if the project is being built for ownership of the customer, is it being built to run on a proprietary framework? Are they offering escrow on the source of that framework in the event of the agency's liquidation (& could it realistically be managed if that happened)? Is the software being built using Microsoft servers or software, which will introduce additional licensing cost if hosting providers are changed?

Disengagement

Rather than spell out how disengagement from the agency can work, here's an oft-repeated series of steps which should provide food for thought.

1. Founder engages consultancy with specification. Low cost fixed-scope agreement. Contract formal but not always well-understood or as wide-ranging as necessary.
2. The project starts agile with an experienced team or experienced team lead.
3. The team start to deliver functionality, and the founder is able to try it out... and changes the specification.
4. The cycle continues with increasing changes to specification, leading to closer interaction between founder and developers. The project manager's grip weakens on project as it turns from fixed to unfixed scope. As the scope changes, so does the potential for cost, which isn't always clear.
5. Development speed is decreased: when the specification is changing a lot, it's more sensible to have fewer developers exploring the build, the idea being that it will get back up to speed once settled. Realistically, this is the point where agencies put their good staff onto whatever new business they have, and push their "work experience" staff onto the founder's project.
6. Technical complexity increases massively, and best practices are discarded. Developers now understand the specification to be coming from the founder, ad hoc. Cost may now be increasing beyond original quote on day rate of £600 or more.
7. Something gets delivered. There are a series of problems:
1. It's complicated and technically unsound. Maintenance or further development will be much more expensive.
2. A lack of product documentation becomes apparent. Excuses include "we allocated all resource on development", "the code is commented", "the specification is the documentation", "it's too simple to need it".
3. The product isn't search engine optimised / Web 2.0 / Ajaxified / Insert missing feature, but founder saw examples of the agency's work with that functionality. We've heard "we also do SEO, but we didn't design it into yours... you didn't ask"!
4. The agency presents a bill which is larger than expected. The founder isn't clear on what needs to be done to get the project to phase 2, although phase 2 is often academic as phase 1 has since changed. The bill will wipe out the founder's investment or more, and they're faced with a dilemma. If they can't pay the bill, do they play brinkmanship and wind down their start-up? The agency may offer to reduce the bill for an equity stake in the start-up, or a commitment to further work being put their way.

The really important bit: how to work with developers if you're a start-up:

• Keep it simple. If you think it's complicated or they tell you it's complicated, consider this: are you building a space ship? If you're not, it's probably not complicated. (Just because it hasn't been done before doesn't mean it's complicated.)
• Double their estimates and their time-costs. Ask them what their man-month cost works out as. If they start to tell you they can't break down their quote that way, put your fingers in your ears until they're finished speaking, and then ask them again. The metric isn't vital, but it's good to have, and it's also good to let the agency know you want metrics on your terms.
• Micro-proof: build a prototype first. Avoid fixed scope contracts (you will change, they will learn, there will be several phases).
• Create a plan for business technology for the next three years. Put in three or four milestones and phases. If you don't know what you'll want in Y3, make some assumptions. The milestones will change rapidly, but it's important to be cognisant of the likely need for further technical work and cost. Investors want to you think about this.
• When you're in the mess, you might be seized by Stockholm syndrome: but it's probably better not the devil developers you know. Get help.
• Make sure the developers are "agile" and use best practices, and get an independant third party to vet or manage them. This need not be costly.
• If programmers aren't project or development managers (and odds are they're not), and you haven't managed programmers before, don't talk to them about specification. Sure, it seems you're on the same page, but really you're not.
• Get help from people who have started web businesses before.

We'd love to incorporate any feedback into this article.

PS. If you found this useful and we might be able to help, get in touch. Also, check out Daniel Kehoe, a friendly American freelance CTO that we're in touch with every now and then. He wrote a great post on start-up disasters when getting a team together.

This post has 3 comments »