Engineering as a Service
If you’re a hardcore Batman fan-- and who in banking technology isn’t-- there’s a line from Nietzsche's Beyond Good and Evil that should sound oddly familiar: "He who fights with monsters might take care lest he thereby become a monster." That line-- my guess is-- was recycled into Christopher Nolan’s The Dark Knight as “You either die a hero, or live long enough to see yourself become the villain.”
Did I mention what this blog is about?
Yep, IT consulting.
You See the Bait But Never the Hook
I’ve been partnering with the big IT consulting shops for decades now. We all have.
In theory, they fill a vital gap: when we have more code to write than we have full-time engineers to write it… bam… a relationship for life.
Contractors, we can all agree, were never meant to be permanent staff augmentation but then again, projects were never meant to be endless. And I’m not talking about complex multi-year nightmares. I’m talking about a path to mature portfolio governance: a need for the entire Street to reinvent tech finance in a way that reframes IT budgets as technology investments… with statements of work that have hard start and stop dates... commitments with executive accountability… solid business cases that hold the funded to the seemingly high bar of providing quantifiable client value after the delivery.
And the clearest indicator that your shop is lagging on that maturity curve? Programs that have an end date of December 31.
But I digress.
Contractors, we can all agree, have never been the problem. Our reliance on them is a reflection of the failings of our own operating discipline.
We say yes to more demand than we can reasonably supply and use consultants to compensate for our inability to say no.
We bolt on engineers to monolithic teams and assume that our culture (and its aspirations) will stick, when in actuality, the cost of rotating heads forces our culture to drift.
We farm out deliverables without farming out real ownership.
We pay for average and expect the extraordinary.
I could go on. Any of us could. Whether we’re on one side of the wall or the other.
So... it isn’t the outsourcers we need to fix. It’s us.
We’re the ones manufacturing Soylent Green.
--
[Again, it would be fun to stop the blog right here and dramatically drop the mic. But there’s that pesky Noah Principle.]
Building the Ark
So what are we doing about all this in our shop? First, we’re genuinely committed to changing how the entire enterprise governs technology investments-- forcing ourselves to invest and grow responsibly.
Second, we’re building out a team/function called Engineering as a Service (EaaS) as an internal alternative for staff variability. Think of it as an internal consulting capability-- staffed entirely by 10X engineers-- that allows our governed/funded programs to scale software development up and down on demand without large lock-in costs.
The service operates like an external resourcing vendor. Business and technology groups in need engage with EaaS, jointly writing SOWs with start and end dates. Contracts are agreed, and engineers are deployed.
EaaS engineers move not from never-ending-project to never-ending-project but from tangible software deliverable to tangible software deliverable. Working software is the primary measure of progress. [Those 8 words should seem eerily familiar.]
The model offers the benefits of resource elasticity without some of the drawbacks:
Because EaaS is staffed in-house and serves in-house, engineers are already familiar with the company’s people, processes, ecosystem, businesses, user base, operating model, and strategic priorities – eliminating the months-long acclimation period faced by fresh incoming developers and accelerating time to market on our software commitments.
When resources are sourced from external vendors, quality control can sometimes be a concern. As an enterprise-run shared service, the hiring, training, and support of engineering talent are uniformly controlled and consistently monitored by EaaS business leadership.
When temporary contracting staff exit a company, they take with them the accumulated subject matter expertise and institutional knowledge that the company has invested in them. With EaaS, knowledge not only stays in-house, it grows over time. And engineers – who are moving from deliverable to deliverable – are constantly broadening their understanding of the business and deepening their skills.
The Rules on the Ark
EaaS is grounded in key principles that amplify the agility, efficiency, and quality with which it delivers.
We deploy as teams. An internal consulting arm could theoretically help fill staff augmentation gaps – plugging in a person here and there to address an absence or a short-term need. EaaS, however, follows a different model by contracting out whole teams (what we call pods). Production solutions are handed over to sponsoring tech groups when completed and the engineering pod rolls onto its next assignment.
We keep it small. Our team sizes are about 5 engineers per pod. And each pod is given the autonomy to self-organize, which fosters cohesiveness, collaboration, agility, and accountability.
We focus on the engineering. Non-development activities are handled by a central administrative pod that handles project management and app management tasks. We don’t need engineers clearing roadblocks, and removing bureaucratic distractions. So our engineering support pod does what its name implies: freeing coders to spend the majority of their time coding.
We stress ownership and autonomy. Our engineers are the opposite of mindless order-takers-- sharing architectural decision rights with our internal clients. This is particularly important for teams in satellite offices as they suffer disproportionately from... well-meaning folks in NY and London.
We follow consistent Agile practices. Pods execute standard agile ceremonies and prescribed behaviors including daily stand-ups, weekly retrospectives, 2-week delivery sprints, and a cadence of demos with project sponsors.
We commit to a devops mindset. We joyfully make substantive investments in our continuous integration/continuous delivery discipline. And we encourage the use of automated processes for code building, packaging, scanning, testing, and deployment.
We use smart shortcuts. Pods take advantage of common frameworks, reusable code, code generators, shared services, and open source solutions to accelerate delivery.
We invest in learning. Two hours per week are dedicated exclusively to team-based learning focused on expanding technical skills and business acumen. It’s not that the rest of the week is learning-free. It’s not. But carving out time for learning sends exactly the right signal.
And we measure everything! Data drives the continuous cycle of evaluation and course correction.
--
Our practice isn’t perfect yet. Far from it. But early evidence suggests that it’s a worthwhile experiment.
Remember how I said that we measure everything (five sentences ago)? Well, here’s the picture that our early effort paints:
Improvements in the ratio of engineers to engineering support – from 65:35 to 80:20
A near doubling of the amount of lines of code changed per day – from 269 to 524
Elimination of change failure rates – from 2.2% to 0%
A doubling of the time spent in development tools – from 13% to 30%
Greater technical expertise – from 12% rated as expertly skilled in Java to 88%
I might play a skeptic on TV but those are some encouraging numbers.
And the most hopeful part of this transformation is that the internal teams who engage EaaS are starting to pick up their habits— from Agile to DevOps, from better client engagement to a more committed use of shared services and frameworks.
Transforming your operating model this way begets more of the same. Its scalability is limited by supply side concerns (your ability to hire great engineers) but there will never be a lack of demand — not with our collective experience with external contractors struggling in an old school operating model that was never designed for them.
Final Thoughts
Now you hopefully understand the Batman quote. I’ve spent a career cautioning others on the risks of contract work-- a hero’s life-- and I’m now dabbling in face paint.
Before you ask all the tough questions, know that we’re at the start of a journey. We’re anything but mature. But it’s already paying off.
We’re now grappling with issues like:
Service Definition – capabilities, costs
Resource Management – skills & business matrix, certification
Pipeline Management – supply vs demand, prioritization, slotting,
Marketing
Financial Management
Governance, governance, governance.
And if we get it right, we mature our operating discipline and we become the high bar.
It’s funny but that original Nietzsche line ends with “And when you gaze long into an abyss the abyss also gazes into you” -- which is so badass that I have to wonder why more comics-loving nerdlings (like me) don’t devour his writing.
That said, he was right. It does feel like the abyss is looking our way.
Totally worth it.