Last month I spoke at the CIO Edge Conference in Sydney. The topic was on innovation in the digital finance space and how we can stay on top of the relentlessly increasing pace of innovation.
One of the things I discussed was using Wardley maps. While not something that deals directly with disruption and new business models, Wardley maps are incredibly useful tools for any business leveraging digital business channels. Originally published as an article in CIO magazine, they describe how the value chain of a system could be mapped against the maturity level of the individual components. Not only do they give a great tool to assess your Digital capabilities against your competitors but they also give you great insight into what components in your system need to be upgraded, either commoditised or customised, to ensure that your Digital innovation efforts are efficient and effective. It’s far too common to see companies focus on the surface layer components and activities without ensuring that the fundamental dependencies are in the correct state to support the customer visible capabilities. Fans of Eli Goldratt’s Theory of Constraints will immediately see their utility.
I came across an interesting post here on why Betfair should fear whatsapp. Strange bedfellows for an article but the general thrust of the piece is that a chat application is similar to a financial exchange, in this case Betfair, and could theoretically disrupt its business model. I have to be honest and say it’s something I’ve never thought of.
If you read what’s said then you might think that this is so. The author goes into some detail about the similarities and given the depth of knowledge in some of the other posts on his site you might think that he’s got a point. He even says straight out that “A betting exchange is really just a chat application – in place of messages, you have bets; in place of chat groups, you have markets; and in place of the chat transcript, you have the order book“.
If you haven’t seen this awesome parody video already, you need to. It’s a great example of what it can sometimes feel like as an expert in a meeting with non-experts.
Buzzword bingo, massive management overhead, ignorance of implementation details, solutioneering, management shutting down needed discussion, condescension, it has pretty much the full package of the worst the world can throw at you.
Of course it’s a taken to the furthest extremes otherwise it wouldn’t be funny but if you’re don’t think there’s a grain of truth to it, ask any technical person if they’ve ever been in this sort of situation and see what they say. It’s not that techies are geniuses and everyone else is an idiot, it’s just that without sufficient understanding almost any area of technical knowledge can be over-simplified to a level that defies reality. This is true for science as much as it is for technology.
The thing is, there another message other than experts have to suffer dealing with idiots all the time; it’s that experts need to be better at teaching and communicating to stop this scenario from happening in the first place. Continue reading →
If you know me it’s no secret that over the last few months I’ve been looking for a new challenge (stay tuned for more on that later!). While I was doing this I was struck by just how many organisations still don’t have blogs written by their technical department.
At a time where social media is EVERYWHERE this seems almost perverse. With the dependence on the web and mobile almost every company is now an internet company to some degree. An airline is in the business of moving people around in flying boxes but they have an enormous technical infrastructure. Banks are in a similar position and so are pretty much every company that sells something. Okay, not everyone is going to have a large development organisation but almost nobody has zero and because of this all companies will suffer similar issues around:
How do you attract quality technical staff?
How do you communicate complex technical issues that have a fundamental impact on the business with a wider audience of laypeople?
How to inspire and fulfil technical staff?
These are notorious hard problems to solve. High quality tech staff are far more productive than average tech staff and you only want to hire the best. Technologists are notoriously bad at communicating their domain to non-technical people, both internally and externally, and also tend to be driven by different motivations.
So why does having a technical blog help?
It’s free advertising for recruiting technical staff
Transparency drives quality both in the product and in the engineering culture
You are upskilling your technical staff for very little cost and can produce content for talks at conferences/whitepapers
You are engaging with your community and raising your profile which is turn means free brand marketing
Admittedly it’s only my experienceand not a rigorous survey but there does seem to be a fairly strong correlation between companies with a good engineering culture, i.e. places I would want to work at, and having a good tech blog. If your technical staff don’t have a voice what are we to think? That you don’t value or trust them or that the standard of your technology division is fairly low and you don’t want to expose just how bad they are? Either way, my interest in working there is going to be non-existent.
It might sound harsh but if you are in a technical leadership position you owe it to your company to have a blog written by your technology staff. I would go as far as to say that every technical person should have “write a blog post” in their yearly objectives.
If your technical department does not have a blog you might as well be announcing to the world that you are second tier and are happy to stay that way.
There is a brilliant article here written by Yammer’s VP of Engineering Kris Gale. The article is covers a talk that he did at Hack+Startup on why the traditional engineering organisation structure is dead.
The truth is that in many ways he is absolutely right. The rise of Agile, Lean, DevOps and Continuous Delivery all show that the landscape has moved wildly within the last few years and the structure of engineering organisations needs to adapt to this.
Kris points to a new engineering organisation which follows the following rules:
Small teams (2 to 10 people) doing small projects (2 to 10 projects)
All projects have a definite end date
Team members only assigned to one project at a time
No code ownership
Bug fixing is done by everyone
In his talk that went along with the article, he mentioned that he was deliberately contrarian and wanted to make people think and he’s succeeded and I agree with almost everything he says. Traditional engineering organisations need to follow this approach when it is right. The issue is that it is not always right. Continue reading →
The recent spat between Peoplebrowsr and Twitter raised the profile of one area of the social tech scene that is sometimes ignored – social scoring. Peoplebrowsr own Kred a social analytics company which offers social analytics and scoring to individuals and companies. Klout is another famous example of this and there are also Adobe Social Analytics, TrackSocial, SproutSocial, Kontagent and many others in this space. You might even remember BackType, who were famously acquired by Twitter in July 2011.
The unholy combination of social graphs, big data, nosql and massively parallel algorithms sounds like a winning hand in recruitment bullshit bingo but these paradigms/technologies form the core of this industry where the interactions and relationships between interconnected entities (people and companies to you and me) are parsed and analysed.
If you are a brand, then these companies offer real insight into your presence in the social media. If you are a person, then you probably don’t give a monkeys. Yes yes I know that having a Klout score of over 50 gets you into the Singapore Air lounge at SFO but lets be honest, if you are the sort of person that can take advantage of that benefit you are highly likely to have access to lounges anyway so hardly a deal clincher. Continue reading →
I was in the Facebook offices in London recently. Very cool offices in a very nice location but what one of the things that struck me most was the signage on the walls.
I have to say that I absolutely love this.
It’s one thing to hear this at conferences (which sometimes seem to exist for the express purpose of making us aware of our own incompetence!) or from coworkers who have your back anyway. It’s another thing to have this as fundamental aspect of the culture corporate and just a million miles away from the lip service that so many companies pay to this idea. You know the sort of company, they maybe have a nice motivational picture of an eagle along with a pithy comment about attitude and altitude and think they are being daring. If you are lucky your direct boss embraces the idea that being able to fail is a good thing and if you are really lucky your boss’s boss does too but the whole company? Really? Continue reading →
When I first moved into a position of leading developers I experienced a fair amount of good natured teasing that I’d do my best programming via Outlook and Omnigraffle. While this has been true (thankfully only to a point!) it has been outweighed by the ability to have a far greater say into the resourcing, architecture and implementation of projects and how my company does its work.
One thing that I’ve become painfully aware of is that the operational aspect of this position has a larger ‘people management’ aspect to it than I had previously thought. This is especially true when you extend your view to include recruitment, appraisals, motivating staff and the like and not just setting up your teams to deliver quality code as fast as they can. The soft skills of leadership tend not to come easily to those with a natural technical focus (describing almost every developer ever) so it only makes sense to take advantage of psychology research in the areas of skills assessment and motivation. These is a wealth of knowledge out there and I thought I would discuss a few of the more interesting/useful ones that I have come across.
It’s unarguable that Continuous Delivery has gone from being just a CTO friendly buzzword to a central requirement for a high performance delivery team. It’s no longer cutting edge to merely check in your code to source control and have Jenkins or other continuous integration box run the unit tests. You have to be able to get that code out into a live environment as fast as possible and that means Continuous Delivery. The ability to deliver code into production at will has a direct effect on your bottom line but to do this effectively you need two things, 1) understand the important areas of functionality that the customers really use and 2) be able to test these areas as quickly and easily as possible. The first is a business issue but the second boils down to automating your testing.
The trouble is that most of the industry holds on to a quality assurance process that is directly at odds with this. The reasons are mostly historical but companies have had varying levels of success in the drive to automate QA. The level varies on how highly the company values this ability. So what levels of QA do we commonly see?
This post on the temptation of data raised an interesting aspect of Big Data: that we run the risk of being overwhelmed by data and that organisations and investors are looking too hard for the one piece of data that will be the key to success. Drowning in data is a real risk to an enterprise and something that great leaders are aware of ( lesson 3 in this awesome leadersip slidedeck from Colin Powell – “Experts often posses more data than judgement”) but being swamped by the data is not the only problem.
Another problem with casting the net of big data wide in this way is that eventually you will end up finding some sort of pattern, any sort of pattern if you keep looking hard enough (there’s an XKCD for this). The human brain is a fantastic pattern recognition system and is easily fooled (see Pareidolia) and it’s far too easy to make mistakes like confusing correlation with causation. Continue reading →