Posts tagged with “start-up”…

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 »

What do you need to raise investment?

Posted by Aidan, 16th January 2009. Share this:

• angel
• business angels
• equity funding
• fundraising
• investment
• raising money
• start-up
• starting a business
• vc
• vct

So you've had the idea, done some research, and maybe got an early incarnation of your business running, perhaps even assembling a small team along the way. You need more money to make the business really tick over, and the banks are talking of rates in terms of "LIBOR plus something" or won't lend at all.

What do you need to have together to raise investment? The depends on the investors and the returns you can provide. Angels, early-stage, small funds, VCs, VCT and corporate venture teams all take different angles on investments. Angels can be the best and the worst -- investing after their emotions -- which can make fundraising easier. Watch out for the "Belgian Dentist" on your board: an investor whose only qualification to be involved in the strategic direction of your business is the money they have, rather than experience or connections they have in your field of business.

There's a whole laundry list of things to show. Here's a short checklist:

• Have a team together. Even if they're not involved full-time, show that you are connected with and can involve credible experts to sell or develop your platform. They can sell you. Most importantly: getting someone on board with you who has successfully launched or funded a business is magic.
• Demonstrate a willingness to bootstrap, and understand what a lean, agile business is.
• Present a strong business plan. Future capital expenditure that isn't broken down will confuse and scare investors. Make it easy to read, and cut out the rubbish. Can you do it in no more than five pages? Annotate it in the margin. Some investors read business plans all day, and they'll skim yours however short it is. Make sure they can see the good bits easily.
• Make sure the numbers are all there. Include a P&L for the first few years. Include summary figures up to five years. Show where the workings come from. If your business is converting web traffic into revenue, work the numbers bottom up and top down and see if they match (don't work on a market-share basis: "The market is worth $10bn and we will capture 0.1% of that for $100m", anyone can say that). If you have clear competitors, find out what their numbers are like. If you can't find the numbers online, call the competitors and ask. People like talking about their businesses and will often say more than they should.
• Have diverse revenue streams if you can.
• Demonstrate clearly that the business model is scalable, and back up your claims.
• Don't ever say there are no competitors, or that it will sell itself. Creating an entirely new product and marketing it is expensive, and if you think noone's after you're lunch you've not done your homework.
• Don't talk about "building a brand" unless you're raising millions of dollars or you really know what you're doing. It's not cheap or fast.
• Demonstrate a solid return on investment. Most investments will expect a 10x return on three to five years.
• Have a clear exit plan for your investors.
• Understand why you are building the business. Be clear it's not a lifestyle business. What do you expect in five years time?
• Show that the business is suitable for the current economic climate. Is it a business that will work in the credit crunch? Are there parts you should scale back or put on hold?
• Consider the funding runway you need. If you're asking for £50,000, is that the only capital the business requires? How many rounds of funding will the business expect? Professional investors will ask you this. Have you left enough runway: if the cost of your initial activity doubles, or your revenue is late, will the extra six months it could take for further fundraising run the company into the ground?
• Do you have any intellectual property (IP) in the business? Can you protect what you have with patents or trademarks?
• Build a proof-of-concept or a prototype. This makes funding much easier to obtain. You can really show would-be investors what they're buying into. Understanding somebody else's business is hard, and having a play with a demo product is usually easy. Building a prototype shows that as a founder you can get it together to raise your own seed funding and or executive on delivering the first part of your business. Prototyping also helps as we see most pre-money business change their plans at least three times. Investors will wonder whether you have settled those issues.
• Understand funding types on offer, and how each class of investor is likely to invest. Are you after cash for equity, or convertible debt? Do you know what class of stock you might offer, and how much?
• Make sure the company valuation is sensible. If the investment opportunity appears to be to good to be true, it probably is. And if it's that good, you probably don't need equity funding.
• Don't waste the investor's time, and do your research on them beforehand. A lot of investors talk to each other, and annoying one can be harmful. Don't approach the wrong investors for the wrong sort of funding, and understand what sort of investments they make.

This is by no means a complete list, but we hope it will be useful to many of you. For assistance with your planning, preparation, implementation and funding, please do consider Reincubate.

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 »

Bootlaw - legal tips for startups

Posted by Andrew, 26th September 2008. Share this:

• bootlaw
• entrepreneurs
• law
• legal advice
• meetups
• start-up

On Wednesday I was at the first of the Bootlaw sessions (also known as the 'Barry and Danvers show'). Bootlaw is a fantastic new idea from Barry Vitou and Danvers Baillieu from City law firm Winston & Strawn, offering legal tips to startups, along with lashings of beer and pizza!

This first session covered NDAs and termsheets - both of which are key documents that startups are likely to encounter quite early on in their business life. Barry and Danvers are able to turn what could be quite complex subjects into clear and easy to understand language, and I look forward to future talks. You can find out more about Bootlaw at their website.

As well as the practical knowledge gained at these sort of events they can also be a good way to bump into like-minded people. With over 30 people attending the first session we see future Bootlaw events as being a good way both to learn useful information and network with other startups and entrepreneurs. I was particularly intrigued by a number of non-profit and social enterprise startups that seem to be evolving - more on that in a future post.

The event was covered by the good people at Newspepper, so video and/or pictures of the event should be available in the near future.

This post has 0 comments »

How to recruit strong technical staff for start-ups

Posted by Aidan, 9th September 2008. Share this:

• hiring
• recruiting
• staffing
• start-up
• testing

Finding good developers or technical staff is difficult at the best of times, but if you're new to working with them, or are pressed for time or budget, it is particularly tough. Over the last ten years it hasn't got any easier.

We've hired an awful lot of IT, operational and engineering staff over the years, and we'd love to help you. However, if you're going it alone, here are our top tips:

• At least 95% of the programmers on the market aren't good programmers (see "Grand Master Programmer" if you're interested to know more). Spotting the difference is hard unless you're technical yourself, and even then it's still tricky. Development patterns and understanding of abstraction are good to explore with candidates, as often it's the principles of software development that matter. In most cases you're better off hiring the excellent Java developer over the middling .NET developer, even if you do use .NET, as a smart developer's skills will translate and bring extra insight.
• Test candidates carefully. Ask them to write you a program in a language they've never used before, in 30 minutes. You might have to test fifty developers before you find one who can do it well. Often you can find an experienced CTO who can help develop your test or vet candidates.
• Recruiters are not easy to use effectively. Most of them do not have domain experience, so even if they were in a position to evaluate candidates properly, they couldn't. Recruiters will ask for anything up to 25% or 30%. If you absolutely must use a recruiter, bear in mind that most will work for 12.5%. Of course, they won't tell you this, but once you've made clear you have agreements with some of their competitors, they'll come around after making all sorts of disclaimers.
• Good technical staff aren't always expensive. Recruiters have a tendency to ask for at least £30K for anyone with any experience. You'll find that a lot of these candidates are in roles where they're currently on something more like £22K, straight after starting. There's no reason you can't find a genius for around £20K, even in Central London.
• There are lots of niche sites for technology recruitment, but Gumtree has been working well over the last few years, and it's not particularly expensive. Monster are not only particularly expensive, but when using them before, I've only received CVs from foreign candidates, none of whom were cleared to work in the UK. Arranging permits to bring technical staff over used to be fairly quick and relatively inexpensive (<£1,000), but changes in legislation this year have made it much more difficult. Monster continued to bombard me with promotional mail after unsubscribing and deleting my account, so I'd stay well clear.

Assuming you've sorted out your recruitment, remember one more thing. If you haven't worked with technical people before, you may find them hard to manage if you lack technical skills yourself. Get lucky with a good communicator, or find someone (like us) with the experience to help and work with you.

This post has 0 comments »