Tuesday, February 28, 2017

How (not) to impress a potential CTO

The other day I was at an event for start-ups and entrepreneurs - no, not the “Agile for Startups” event I’m speaking at in a couple of weeks, for once I was in the audience. Half way through the organisers decided to do a type of speed networking - so we could get to know each other, find employees, find clients, find investors, whatever.

One of the people I got to spend a few minutes with was an entrepreneur on the hunt for a CTO. As I often, usually (always!) find at these sort of events, there are far more potential non-coding entrepreneurs than there are “techies” to go around. Such events seem to be populated by non-techies hunting techies.

As soon as she heard I code she saw an opportunity… and she blew it. So for the benefit of other entrepreneurs hunting techies…

What she said was:

“Our product is 80% built, we had an intern last year and now we need someone to finish it.”

I also ascertained that: the start up was her and her business partner and as yet they had no customers. So I could also deduce that they had not validated the product Lean-Startup style, they had built and now were looking to “finish” it and find customers. So their start-up strategy already posed question.

When I asked “what is the technology stack?” she didn’t get the question at first asking and then said “I don’t know, its not my area.”

So whats’s wrong here?

“80% built”

That shows how little they understand about IT products, it ain’t never finished. Once you start using it people want changes, people see opportunities, digital business models depend finding new ways of using technology to create value.

If it was “finished” then… where is your business? - in a digital business the product is never finished.

Any CTO they hire is going to spend most of their time educating the founders - probably why they need a CTO in the first place!

But think for a moment, what if she is right? What if it is 80% done? Then the remaining 20% does not represent a lot of work for the new techie/CTO to do.

“an intern”

OK, there are some students who are awesome coders. Some of them are wasting their time at University, they should just go and earn big money. I was probably one of these people, I went to University and my degree has helped me later in life but…

The chances are this intern is better than average 20-something coder who has left behind a big mess - without unit tests. The CTO they hire is going to spend the next few years cleaning up that mess.

Lets put this together:

  • This is has not been validated in the market so it is a technology play
  • The founders not only lack technology skills but lack an understanding of technology business
  • A technology play by non-technical entrepreneurs just sounds like trouble

What lessons can we draw form this?

1. Firstly don’t confuse wanting a CTO with wanting a programmer. I think this lady and her partner do need a CTO and they do need a programmer, they may even be the same person - and I certainly hope any CTO remembers how to code. But… in trying to sell the role to me she was very confused.

2. They do need a CTO because this is a technology play. But I don’t think they see that, they see the need for a coder. They need to think more clearly.

3. She needs to recognise that “80% completed by an intern” is not a good sales pitch to any programmer (let alone CTO) worth their salt. It plays down both the amount of work to do, the challenge and promises a big mess to clean up.

4. Not knowing the technology stack is criminal: it is the most basic question any techie is going to want to know - a PHP Lamp stack is completely different to a Java AWS stack - and it is the most basic filter when recruiting technical staff. True it is not so important if you are hiring a CTO for a company with 50 developers but in a small startup the technology and business strategy are intimately connected.

Finally, yes, I could be tempted by the right opportunity to be a CTO - even a coding CTO - maybe one day…

Friday, February 24, 2017

Every project is test driven in the end

Let me give you the punch-line and then explain myself:

As soon as testing starts every “project” becomes a test driven.

If there is no formal testing period then that phase begin the moment customers/users start using the product.

I’ve recently been watching a slow motion train-crash, I had no power to avert the train crash and those I could alert didn’t want to hear me. So I was thinking: what will happen in the end?

The project has been forced on the organization by external authorities. Even if it wasn’t the budget allocated means it is too big to fail, it will take careers with it so it must succeed. It will be an exercise in pass the parcel with everyone attempting to show they did what was expected to avoid blame.

Anyway… in the end, I thought, they will enter a testing phase, as with all testing phases it won’t be just a test phase it will be a test-fix-test-fix until such time as the organization runs out of the will to continue. Just like every traditional project.

Which, when you think about it, means that when this project enters testing it will become Test Driven.

Sure the project will spend months “designing” and “implementing” but the project is so big nobody can understand it. Only when the parts are brought together, and the deadline is close, will people do what it required.

At that point they will be test driven.

Up onto that point all the planning, designing, implementing and what not is just shadow play, people avoiding doing what is needed.

This argument can be extended to every traditional project where testing is left to the end.

Between the start of work and the start of testing work might be done but how much of this is usable, how much of this is finally included in the solution is anyones guess. Once testing all work is test driven.

All software development is test driven, in the end.

Wednesday, February 01, 2017

It's all digital, stupid.

I’m the stupid one.

For years now I’ve heard people talk about “digital” but I failed to grasp the significance.

It started with “digital agencies” which I took to be advertising agencies which did websites, although the websites they were trying to build contained a lot of functionality. These odd advertising agencies seemed to offering services more akin to Logica than Stirling Cooper.

I ignored the digital label, after all I reasoned: everything in IT, in software development is digital - analogue computers never really took off. “These fools” I thought, “are stating the bleedin' obvious.” Digital was a label attached almost without meaning. Or so I thought.

Perhaps on one level “digital” is a marketing term, and perhaps because of that it holds little meaning. But, it is a term that people identify with, and because people identify with “digital” it has meaning.

Slowly, over the course of the last year, its dawned on me that I was the foolish one. The label digital isn’t attached without meaning. Adding digital means those who use the label have come to my world.

My world always was digital but the rest of the world wasn’t. Now they are.

For years I, and others, have been arguing that software has the capacity to completely rewrite the business world. “Software is eating the world” as Marc Andreessen said. I’ve been saying: “Every company is a software company” for years but I just discovered that Forbes magazine said it too!

I’ve been making this argument but I don’t need to, everyone else has worked it out. It is only IT folk like me who are slow on realising that everyone else wants to be in their world.

And Agile? - do we need Digital Agile?

In the new digital world Agile just is. Agile is tablestakes, don’t bother trying to play in the new digital world if you don’t at least aspire to Agile.

None of these digital-whatevers would try and be anything other than Agile.

True they may do Agile badly, true they may have vestigial waterfall thinking, they may find it difficult to break away from the traditional supplier model and even undertake projects but in the digital world nothing else works.

Many of digital-somethings out there are there to disrupt the incumbents. The incumbents may be adopting elements Agile and Digital but they have non-trivial legacy problems: legacy process, technical legacy (with technical liabilities), legacy mindsets and people who understand success in the legacy world not in the new agile and digital world.

Agile was the midwife at the birth of Digital.

In the days when IT folks clung to the idea that everything could be known in advance, and written down - in cryptic language nobody reads - and change actively resisted, then creating software technology was the preserve of high priests. By democratizing the process Agile has allowed more people to engage with the technology.

Agile and Digital, maybe not strawberries and cream, more like self-raising flour and sponge cake. Agile allows everyone to have a go, and everyone has a chance of winning!

This piece first appeared in my newsletter last month. Subscription is free from the Software Strategy website.