When I started at Flipper back in October 2019 (feels like an eon ago now) I took the time to reflect on what it means to be a Chief Technology Officer / Head of Development based on my experience at Digital Forge.
Rather than picking up a book or looking at other peoples blogs, I did what I usually do – make something up. Ultimately everything humans do that’s worth a damn is “made up” by someone (and polished in the fire of failure!) so I’m good with that. It also fits with my personality profile on 16 Personalities of a “Logician”. I’m probably wrong in some way, but *shrug* I’m happy with the result of my musings.
I wanted something rooted in the Agile Manifesto at the heart of all agile frameworks, something that leveraged my understanding of the commercials of business, and something that ties in my understanding of the importance of systems that can change and evolve with business needs.
I’ve broken the role into 5 areas. If I was click-bait I’d put them on a separate page covered in adverts for making money at home, but we can be better than that. *<:OD
You may be surprised that I – of all people – start with fleshy meat bags. It is all about the people actually, the technology is secondary and detail. Motivated developers, who have fun doing their job, delivering high value, well designed change return a far better investment in terms of value to the business. There’s a mind boggling number of things to consider to create a motivated, happy, high performing team (or teams) – especially to someone like me – but it’s the core of what we’re going to achieve (and across the business I might add).
This piece boils down to team (fostering a high performance, cohesive, collaborative team), growth (couching and mentoring, personal development) and morale (getting up in the morning excited to come into work).
Businesses never stand still – like a small mammal evolving 100 million years ago – if it stands still it’s dead. It’s incredibly important a company (and it’s product and services) can change as a result of the various influencing pressures altering it requirements / objectives. Even if we stand still, the market, regulations and customers never do… so we must be able to change, and sometimes rapidly.
Agile provides the framework from a process perspective, but that’s just 1/3 of the equation. It’s also the people (above!) and the technology.
From a technology perspective, change is about the architecture of the products involved; their shape – often multi-dimensional (those flow charts you get shown only cover one perspective) they should be designed with separation of concerns and SOLID at their heart. This reaches into development, change control, quality assurance and testing, CI / CD deployment and ongoing maintenance and support.
I’ll talk about enabling change in business across several other blogs, its a deep and interesting subject to me.
Return on Investment
Certainly for service and technical industries, development and technology forms a large part of their operational expenditure. It’s really important what we spend our time doing is returning at least equal (and usually more) commercial value back to the business and crucially the customer. If it doesn’t there needs to be a damn good reason why not (strategic, long term goals outside the usual budget rhythm).
For me, a key part of this is prioritising work frequently (also know as constantly) and ensuring we’re recording the cost and value of change. We need to plan long term, seeing the “infinite game” to make sure we’re not working ourselves down a dead end, causing us more, far greater costs in the future (Technical Debt!).
Having a great relationship with the business and the customer is critical to figure out prioritisation of work and thus return on investment.
Another key part is optimisation and efficiency. That doesn’t mean squeezing every drop of effort from our developers, that’s a fools strategy. I mean making things slick, cost effective and fun for our teams. Chop out the unnecessary process and bureaucracy, review licence costs and processes on a routine basis. The sprint retrospective is a great example of this in action.
Handling general requests from the business, monitoring the service, raising BI data to the business etc etc. We need to make sure what we deliver is running well, as expected and the business has the data they need to validate their past and future decision making.
I must say, I love a good dashboard. Getting telemetry right is hard to do – but when it all slots into place to provide a tangible representation of your systems, they can just come to life in a way that gets the IT / developers really engaged and excited.
Maybe that’s just me.
Security & Compliance
The most boring part of the job. Sure, security can be fun – and it’s certainly part of the job creating robust, secure products.
Compliance just sucks – we usually have to do something because some third party is making us do it or the company would have to pay X; they seldom actually make sense alone, or don’t actually form part of our priorities if it wasn’t for the big stick waiting to clobber us with hefty fines.
I feel for those in Financial Services, where this is a big part of the job.
Thanks for making it to the end – let me know your comments and the bazillion other things I’ve missed out! 😀