Our Entrepreneur Academe mentoring session on Technology

This week was our sixth Entrepreneur Academe mentoring session. As usual we met at the City Business Library at Guildhall, home of our partners in this project, the City of London. The focus for this event was technology and our eminent and stimulating panel of mentors included:

Matt Mower, Startup CTO
Melanie Marchant, Director Emerging Tech, Turner Broadcasting
Jacqui Taylor, Founder & CEO, FlyingBinary
Dave Weller, Chief Enterprise Architect, Thomson Reuters
Louise Beaumont, CMO, Platform Black
Andrew Fletcher, Data Innovation Lab, Thomson Reuters
Helene Panzarino, Growth Mgr, Growth Accelerator

Obviously each of our teams have very different technology needs: some of the companies are tech companies but, at the other end of the spectrum, we have businesses for whom technology is an enabler rather the business itself. However, some common themes quickly emerged.

I’ll go through some of the individual questions and issues that came up in a moment, but it’s worth saying that a subject we kept returning too came out of the very first question posed by Frugl’s Suzanne Noble: the stark differences between entrepreneurs and technologists. Different cultures, different drivers and different languages. Of course, some entrepreneurs are technologists, so these problems aren’t universal.

The problem was articulated in different ways. How do I keep hold of developers? How can I keep them motivated? How do I ensure that their goals are aligned with the company’s? Indeed, how do I make the right hiring decision with a techie in the first place?

What emerged from the discussion is that there’s no single answer or “silver bullet” – the problems do somewhat go with the territory. That said, there are some general pointers, and the key one is communication. If you have a dev who’s a poor communicator, that can be disastrous, no matter how brilliant they are. Likewise, if you communicate poorly with them.

For that matter, beware of brilliance. Don’t look for a technologist whose skills and knowledge are out of scale with the project at hand. Apart from anything else, they’ll get bored pretty quickly. Remember, curiosity and challenge are key personal drivers for most devs.

Wherever possible it’s certainly worthwhile trying a dev out on a short term contract on a small specific piece of work, not only to assess the quality of their output but to see how they fit in with the team. And, again, to see how communicate.

All of which said, Louise pointed out that many of the issues here apply to other disciplines: sales or marketing, say. But because most of us understand sales and marketing better than we do code – or think we do – we don’t see the problems in these arenas quite so acutely.

Beyond this overarching theme, here are some of the concerns and questions that arose.

Virtual working is common for start-ups and tech may even be outsourced – but that doesn’t mean it isn’t hard – it is. But it’s great discipline for a bootstrapped company. (And for the record, the challenges with virtual working don’t go away as your company scales – indeed they can get a lot worse.)

Don’t treat contractors differently to your staff. Communicate with them as you would your core team and keep them just as motivated.

Seek advice on technology decisions. As CEO it’s important to know what you’re good at and where your gaps are and to fill those gaps with good advisors. But note, good advisors should help you make better decisions, not make them for you.

Remember, full documentation is key with technology – if your dev walks, you need their replacement to be able pick up the project and run. And, of course you need to own the IP for any tech developed for your company.

Oh, and when a dev does move on, look out for “back doors” into the system they’ve left behind.

If you’re fund-raising now, make sure you’re thinking of the round after this one. If you’ll need more money, what needs to be done in the business and technology-wise in order to attract that next round of investment? Then think back from there.

For businesses where the personal safety of both the customer and the company agent is an issue, it’s worth considering that – because of authentication protocols – mobile might well be a better choice for platform than browser-based web.

The subject of hackathons brought out a few differences in the room. In principle, yes, they can provide a very useful platform for finding tech talent. Furthermore, hosting them can be a good route to finding some new solutions to a company’s problems but the resources to do that are beyond most small businesses. Hackathons also tend to attract a certain kind of developer, not necessarily the right kind for your business. Again, the sort of developer that spends a weekend coding away for little more than free pizza, coffee and beer is likely to be someone driven by challenge and problem solving – very driven. And that may not be the person you need. There’s also a sense building among some developers that hackathons increasingly don’t look like such a great deal (although I should point out that we were far from unanimous on this point). Meetups were also mentioned as a good way to find people with the skills you need.

It’s worth considering putting a PhD into your team to do their research if it aligns with a project’s needs. But approach with caution as this can prove a real management overhead. And make sure they’re firmly embedded in the tech team.

When the discussion turned to Ebarts, our social currency startup, we had a pretty lively exchange about crypto currencies, currency transferability and fraud. It’s not strictly relevant here but I was taken with the observation that when it comes to fintech, you need to be engage with the regulators from the get-go.

One last point – one that warms the heart of this 47 year old – is that when employing technologists, there tends to be an assumption that it’s all about youth. This may be down to simple economics – or possibly a prejudice that younger devs will be hungrier or more up to date with the latest tech trends. But there can be a real value in taking on a dev who’s got years of experience behind them; apart from anything else, they might not get bored quite so quickly…

Simon