Planning Technology Delivery: Thinking it through Backwards
What distinguishes technology delivery from software engineering
(Image credit: 7NEWS Sydney)
Technology delivery is if nothing else, the traversal of that tricky gap between the current state and the desired state of technology operations.
Of course to even have a desired state presumes that you have invested sufficient time and resources in discovery to identify both what that current and desired state to enough people involved.1 You have pursued that identification to the necessary extent that allows you to establish a broadly accepted “Definition of Done”.
Let us say you have arrived at a reasonable initial expectation of desired state with acceptance from your stakeholders. And you have a sufficiently strong grasp on the current realities of the organization, its teams, vendors, etc. to begin to plan that journey from start to finish.
One of the marks that distinguishes the architect or technical delivery manager from the software engineer is their ability to think over what this entails, and to exercise it in practice.
They make things happen.
Environment Management
One starting point for thinking over technology delivery is the question of environment management.
Many who write software, even with years under their belt and enviable comp packages, have simply spent their entire career in localhost.
When they have met their acceptance criteria locally and pass PR review, they consider their work finished.
Whatever goes wrong after localhost is someone else’s problem because it worked locally. A position often reiterated by their business stakeholders.
But this is a radical limitation of software engineering.
To think software development in the lens of only one environment.
Whether the mindset itself is good or bad, to ignore the multi-environment dimensions of cloud applications is debilitating from a systems engineering perspective.
And there quite a few environments out there sometimes.
sandbox, rnd, dev, qa, staging, nonprod, preprod, uat, prod-a, prod-b, bobs-env-do-not-delete
Depending on the organization, the path from local to production can turn out to be a marathon, whose procedures may or may not be documented or socialized.2
It is this gap which can stall projects for months. When the question “How do we get it to production?” was asked at the end rather than the beginning.
Every organization has a process whether they know it or not, if they have something running in production.
For every environment the organization has between local and production you will need to identify:
Source code/build artifact release process
Cloud resource management
Environment variable/secret management
Credential/key management
Domains
QA process
GRC requirements
Approval chain and change management.
Organizations with a robust platform strategy can significantly minimize and abstract away the overhead for all these criteria, with mature architecture and service delivery patterns for you to extend.
Other times, organizations can be rather disheveled when handling this, whether they are new or old. This is especially true if the organization is migrating between IT service delivery strategies or cloud providers while also introducing new workloads at the same time.
If you are working through a project one step at a time, perhaps an Agile flow with rapid, narrow, iterative development, you do this at the cost of potentially deferring large, expensive questions around architecture and technology delivery.
The complexity and time required to corral stakeholders and release requirements and the input of QA, security, infrastructure, or a Change Advisory Board can crush initiatives that are code complete but have nowhere to go.
Questions that don’t occur to someone until the end should have been posed at the very beginning. This is one point which Waterfall gets over Agile (at least in practice, if not in theory).
Hence a key tenet of technology delivery excellence is thinking through it backwards, so to speak.
You need to be able to envision not just what it needs to be, but where it needs to be and how it gets there.
Thinking it through Backwards
It is simple enough to offer this phrase “think it through backwards”, but what does it look like to think in this way?
The key is that this is a mindset rather than a set of knowledge that can simply be listed.
Environment management is one of the most generic, comprehensive examples of how technology delivery needs to be thought through from finish to start as well as from start to finish.
But you can extend this any number of directions.
The possibilities are infinite, and this itself also tends to confuse professionals.
What are all the requirements that we need to engineer for to ensure technology delivery to a sufficient degree?
To reiterate a basic truism: you simply cannot check all the theoretical boxes.
There is no such thing as the infinite, perfect app.3
The application is a set of finite instructions and requirements.
Well-engineered technology depends upon embracing the cliche that design is the adjudication of competing trade-offs.
To be able think through it backwards you must have a very clear sense of what that desired end state is and architect the software or platform accordingly.
This is something acquired naturally and iteratively through work experience, if you are willing to pay attention and learn from your missteps.
For some organizations TCO (total cost of ownership) is critical to accepting a new workloads. Other organizations, startups in particular, waive this as a non-material concern until an investor or board flags the OpEx.
GRC can be a primary concern in some organizations, a secondary or tertiary consideration in others.
QA and SRE may have right to veto release in some companies, or live in perpetual reactive mode in others.
The stakeholders you are working with as well as your project sponsor, and their chain to leadership, should most directly inform the prioritization of these factors not only in architecting the application but in gaining stakeholder consensus to ensure its delivery.
You can extend past experience to inform these questions, but you should not trust it completely. Things change between and within organizations. Stakeholders move around or out. Budgets change. Technology trends, vendors, and market forces can impact the stakes of your technology delivery.
This is why even if one were to catalog all of the various possible “finish line” items you should think about, it would not remain clear which are material or relevant for your use case.
Technology delivery is a continuous learning and planning cycle. You have to stay up to date on what is going on among people and process and technology. Losing sight of these can invalidate your whole plan.
You must spin a spider’s web to lightly but tightly tie together often vastly different departments. And that web must be maintained as requirements shift, turnover occurs, and even if project sponsors change. So long as you remain committed to your mission of executing delivery.
Keep asking yourself, where your north star is for your project and how you can reverse engineer your path to getting there.
Questions to Ask Yourself
To provide at least some specificity to this mindset, here are some questions you could consider as part of adopting this mindset:
What is the most immediate step that would come before this final objective?
Who or what is a gatekeeper to my ability to cross a delivery milestone?
Are there comparable examples to my initiative, a tale of success that provides a clear chain of execution for technology delivery?
Are there lessons learned from that comparable example have other material factors changed?
Conversely have there been any comparable earlier initiatives like this one that have failed or been suspended? For what reasons?
Based on the friction or time investment certain questions face, which considerations are worth deferring until the “rubber hits the road”? To what extent can I carry out a best effort analysis and document decision making here?
Which stakeholders do I need to involve now to minimize later delays? What stakeholders even want to be involved now? How do I document this?
Who is most knowledgeable in this organization or BU about getting things done? Seek the high signal-to-noise ratio individuals who can convey accurate information efficiently and forthrightly.
If working with a new technology library or provider, what open source information is available around production bugs (e.g. GitHub issues), which ones are most material for my use case?
Based on team and personnel resources, how they are allocated, and the business sponsors of that allocation, what will be the relative velocity of various teams in completion of their objectives. Will some drag behind others? How can this be remediated or documented?
What teams and which team personnel need which level of detail on architecture, delivery particulars, etc. ? Do not inundate the junior dev with timelines. Do not flood the product owner with architecture. Know the audience and consider which items of information is crucial for individual personnel to meet their work commitments. Technical verbosity can lead more often to losing someone’s ear than gaining it.
These may come as obvious questions to some, but it is easy to forget these in practice.
Waste emerges in many forms across technology spend.
Lack of delivery alignment is one of the most common and preventable contributors to waste and delays I have observed in my time.
A robust and clear-headed sense of how to get X to Y is not an easy thing to communicate and learn, but such a capacity can save organizations immensely.
Desired state is of course also fairly difficult to discern. Practitioners know how hard it is to get multiple stakeholders to align on an end state, or for that matter even for a single stakeholder to stick to the same picture for more than one meeting.
There is an irony that while so much of computing technology has been standardized over the decades, there is not a single, definitive framework or model for environment management in depth. No RFC, no NIST standards. ITIL and of course NIST SP 800-53 explicitly require a separation between “prod” and “non-prod” but that is the extent of the control.
One example of such a rabbit hole: Is your document processing microservice able to reconstruct corrupted document payloads with non-UTF encodings for a dead language with readily configurable integrations for Amazon Kinesis, Kafka, RabbitMQ, and IBM MQ all while developing its own post-quantum encryption algorithm to secure data? (With an in-process, automated counter-pentest agent)