This morning, I went for tea (him) / coffee (me) with a really amazing guy at a Starbucks somewhere in West Yorkshire, Northern England (yes, that’s where I’m spending my holidays, yeeeeehaaaaa). He told me he wanted to get neither a picture nor a quote (and actually forbid me to disclose his identity unless I wanted to go into serious trouble ), so let’s call him Mr X (we agreed on that).

Mr X spent most of his career in the software industry. Mostly in the United Kingdom (Cambridge & Oxford mainly), despite a brief stay in Silicon Valley about 2 decades ago.

A former math teacher for a little while a long time ago in a galaxy so far away, Mr X has long been a software developer (Cobol, Fortran, Pascal, LISP and finally C++ & Java) until the early 2000s, and then became a sales rep for a major public global enterprise software company until last year. Mr X now works in sales in his son’s company (nothing to do with technology anymore) – still in B-to-B sales.

Leaving aside many interesting things we talked about, I absolutely wanted to share 2 things with you, drawn from Mr X’s experience.

1) Being a sales rep in a public software firm

Mr X told me about how a sales experience in a public company could be such a nightmare under poor management.

Public companies release revenue targets on a quarter-to-quarter basis. And should the company miss its revenue target scope by a margin point, the markets would hit very hard on the stock (software being a growth market, software stocks are highly correlated to sales rather than, say, EBITDA – although I believe this stance is less and less true under current market conditions). So, when the management feels it might miss the sales target and hence risk a stock backlash, all sales representatives of all business units worldwide are told they’re bound to close all deals from negotiations already initiated, no matter the price, no matter the profit margin.

It all results in having sales reps rushing to agree on deals on which the software company, the company they actually work for, actually loses money (but increases revenues, true, and matches short term market expectations, true, and increases sales rep bonuses, true as these were indexed to gross revenues and not revenues targets). Moreover, quarter in quarter out, the same trend repeated as the sales reps had often lost their best deals at the end of the precedent quarter due to management unreasonable overestimated sales targets.

This irrational rationale actually made Mr X quit his high-wage job as a regional enterprise software sales rep for a global software leader after 5 years in business. Mr X said he felt that, through abiding by the management sayings, he harmed the company more than actually having clients respect it more and more – and went to work with his son in a totally different industry (100% brick-and-mortar, if you see what I mean).

I think it’s always interesting to see how an apparently very abstract / strategic decision, namely a financial communication figure, can have such a deep impact on the mindset of the troops on the ground. I guess in this global company, the management had no clue what was actually going on outside their fancy headquarters.

2) Old school software developers perform better than rookies

Mr X climbed the software development ladder up to being in charge of recruiting hackers and managing software development projects.

Until recently, Mr X organized hacking competitions within his teams (last competition occurred in 2001, a couple days before he quit his software development career). Success criteria were a combination of velocity (how long will it take you to complete the job), efficiency (how much ROM and hard drive will your software need to run), effectiveness (does it actually do what we initially wanted it to do?), readability (they’d rank the clarity of the code) and performance (does it run fast).

In almost 3 decades hacking code, Mr X told me no rookie ever won any of the software development competitions. Since most his software developers were working together, all of them did pretty much a similar (good) job at hacking code fast (velocity), making it work under initial specifications (effectiveness), write clean and comprehensive code (readability), and have it run under respectable delays (performance). But only “old school” software developers could write efficient code. Old school software developers are people who have experienced times when a huge hard drive could store, say, 4 kbytes of data back in the late 70s. Consequently, since they really outperformed the rest of the team on the efficiency criterion, “old school developers” almost won all editions of the hacking competition.

I guess the 2-digit growth on the consumer electronics and mobile phones markets are sort of highlighting again the need to write efficient code today.

Like

Unlike

Related posts:

1. 7 good software project management videocasts
2. 2 resolutions for 2007: visit a cluster of innovation every year & brush up my programming skills
3. My call: software companies can't take off well in financial centers
4. Microsoft IDEAS software startups web 2.0-style
5. Catching up on software and entrepreneurship books