Focus on Outputs … not Inputs
I had a financial crisis last week.
Now, before our stakeholders get worried, I should explain that it was the Bank of Mum and Dad.
I was abroad when two of my grown up children contacted me to say that they each needed money for different reasons. As the CFO (their Mom!), was also abroad I was the person with the financial crisis.
One of them is a Customer of a modern financial services company, while the other (slightly older one) uses a conventional Bank. After about 30 minutes negotiating two-factor authentication and other security related obstacles, I managed to transfer some funds to the older one, which would be cleared in their account in 48 hours. For the younger one, I used a mobile App, and they had access to the funds inside 10 minutes.
Needless to say, the comparison between the two payment methods awoke my interest. In the first case, I was busy for about 30 minutes while in the second I was busy for about 30 seconds. The output was the same, but the input was vastly different. Which leads me nicely onto the reason I was away.
I attended the DevOps Exec Summit and spent 2 energising days in the company of bright engineers and innovators. There was much debate about how to remove the constraint that is financial controls. One leading UK bank has made significant progress on bringing their PMO into new ways of working and that presentation inspired this blog. (The video is 25 minutes in duration).
One evening after the Summit, I met a good contact who is working for a large bank in London. He is an experienced DevOps engineer who has been making a small but growing difference delivering automated release pipelines, and breaking every rule in the book to deploy pre-productions to the cloud.
His boss was heading off on leave and tasked him with justifying a tools expenditure that would make engineers more productive. This comes at a time when the Bank are trying to recruit 3,000 engineers. The issue was ‘We want to buy this tool but we have to come up with a chargeback model for the business.’
My youngest son just started his first job working for a gaming company as an animator and will no longer be dependent on the Bank of Mum and Dad. When he was deciding between job offers, a key factor in his deliberation was that the particular company he chose were providing great tools and equipment so he could produce higher quality outputs while growing his portfolio and skills.
Interestingly this company, unlike my pal’s Bank, did not bother with a chargeback model. No more than a builder has a chargeback model for his hammer, their attitude was – give folks the right tools, and let them work. They are interested in the output, not the input.
Organisation’s who are driven by delighting customers create an environment for engineers where they can be more productive, more motivated and don’t have to account for HOW they do their work but WHAT they deliver. This environment connects engineers to customers in very real ways.
Change is very difficult. There is no Director of a company facing down ‘born digital’ competitors who is not wary. But they face a leadership challenge. How can they be credible with their teams if they don’t change accounting models that force engineers to think of themselves as costs rather than value adders tasked with delighting customers.
The organisation that wants to hire 3,000 engineers wants to make their organisation attractive to engineers who think and act like digitally conceived businesses do. Having recruited someone of this ilk why would you subject that engineer who probably costs 100k pa to justify a 50p cost for his share of the tool? If a carpenter needed a new saw would he need to justify the spend or is it a cost of doing business like the coffee machine?
The correct and only way to govern this is to ensure the software being built is adding value, and organisations must quantify this at the appropriate level of granularity and periodicity that satisfies the finance department. This is an example of a leading airline where this model is in place.
So it works … its not theory. Engineers need to understand the anticipated revenue or cost saving to be realised by the feature they are building, or the piece of infrastructure they are provisioning. Its vital that engineers and finance people speak the same language… the language of value.
Forget the benefits that the tool vendor can itemise. Just get the tools, motivate the engineers to be more productive, and lead them to understand the value of their output.
If the output delivers value, why worry so much about the input?