https://zwischenzugs.com/2021/07/12/if-you-want-to-transform-it-start-with-finance/ Skip to content [4f37af910d] zwischenzugs If You Want To Transform IT, Start With Finance zwischenzugs Uncategorized July 12, 2021 15 Minutes tl;dr - 'Money Flows Rule Everything Around Me' When talking about IT transformation, we often we often talk about 'culture' being the problem in making change, but why stop there? If we take a '5 whys' approach, then we should go deeper. So, where can we go from 'culture'? Here I suggest we should consider a deeper structural cause of cultural problems in change management: how money flows through the organisation. If you want to change an organisation, you need to look at how money works within it. I talked a little about this in a recent podcast. Picking Up Two Old Threads In this post I want to pick up here on two threads that have cropped up in previous posts and bring them together. 1. 'Start with Finance' An aside I made in this somewhat controversial previous post: Command and control financial governance structures just aren't changing overnight to suit an agile provisioning model. (As an aside, if you want to transform IT in an enterprise, start with finance. If you can crack that, you've a chance to succeed with sec and controls functions. If you don't know why it's important to start with finance, you'll definitely fail). zwischenzugs.com/ was picked up on by many people. They wanted to know more about why I was so vehement on that. Unfortunately, it was a throwaway line, and there was too much to unpack and it wasn't clearly formed in my mind. But like many throwaway lines, it revealed a thread that might be good to pull on. 2. 'Culture - Be Specific!' Previously I was triggered by Charity Majors (@mipsytipsy) to write about my frustration at IT's apparent inability to probe deeper than 'culture' when trying to diagnose problems in technical businesses. "Culture" can't be broken, any more than "complexity" can be the cause of failure. Fucking get specific. -- Charity Majors (@mipsytipsy) February 6, 2018 Since then, I've spent more time in the course of my work trying to figure out what's blocking companies from trying to change and increasingly have worked back from people and process to sales and funding. The Argument The argument breaks down like this: * To achieve anything significant you need funding * To get funding you need to persuade the people with the money to part with it * To persuade the people with the money, you need to understand what they value * To understand what they value, you need to understand how their cash flows work * To understand how their cash flow works, you need to understand + your customers/clients and how and why they part with their money + the legal and regulatory constraints on your business and how it operates Or, put more engagingly: But the finance office designs HR... pic.twitter.com/qOYaNpdQFD -- ^[ (@backslashx1b) May 30, 2021 Any significant decision or change therefore gets made in the context and constraints of how and why money is distributed to, and within the business. In addition to this systemic level, there is also a more visceral personal level on which money flows can change or affect behaviour. Compensation, threats of firing, and bonuses can all drive good or bad behaviours. Or, as it's been put pithily before: When you've got them by their wallets, their hearts and minds will follow. Fern Naito This is not to say that all culture is 100% determined by money flows. Individuals can make a difference, and go against the tide. But in the end, the tide is hard to fight. --------------------------------------------------------------------- There is a precedent for this argument in philosophy. Karl Marx argued that societal culture (the 'superstructure') was ultimately determined by material relations of production (the 'base'). From wikipedia: The base comprises the forces and relations of production (e.g. employer-employee work conditions, the technical division of labour, and property relations) into which people enter to produce the necessities and amenities of life. The base determines society's other relationships and ideas to comprise its superstructure, including its culture, institutions, political power structures, roles, rituals, and state. The relation of the two parts is not strictly unidirectional, Marx and Engels warned against such economic determinism as the superstructure can affect the base. However the influence of the base is predominant.^[1] Wikipedia, Base and Superstructure [karl_marx_001]You have nothing to lose but your blockchains. --------------------------------------------------------------------- What Does This Mean For IT? The theory is all very interesting, but what does this mean in practice? There is a very common pattern in software companies' histories (especially if they were founded before the Software-as-a-Service age), and understanding their flows in terms of their histories can explain a lot about how and why they struggle to change. I have seen it multiple times in the course of my work, both as a consultant and as an employee. The Four Stages Stage I - Hero Hacking When a software company starts up, it often builds a product for a few big customers that sustain their cash flow in the early days. These times are a natural fit for 'hero hackers' who build features and fix bugs on live systems all night to help get that contract signed and keep their customers happy. Your few customers are all important and demand features peculiar to them, so you keep delivery times low by having customer-specific code, or even forking the entire product codebase to keep up. [stages1]Stage I - customer asks, customer gets Stage II - Pseudo Product Now that you have some customers and they are happy with the product, its features, and your staff's dedication to keeping them happy, more customers come along. So you sign contracts with them, and before you know it you have numerous customers. Of course, you're selling your services as a product, but the reality is that it's a mess. Each installation is more or less unique, and requires individual teams to maintain or develop on them. [stages2]Stage II - Customer pays, customer gets... eventually. Things have gotten more complicated. This is where things start to get more complicated. * Features grow and diverge for difference customers * Features get built in parallel for different customers, sometimes similar, but not the same * Database schemas diverge * Porting features sounds trivial (it's a product, right?) but gets messy as code gets passed around different codebases * Some attempts are made to centralise or share core functionality, but this can slow down delivery or just get too complicated for teams to maintain Grumbles from customers and between development teams start to increase in volume. Stages IIIa and IIIb The last two stages are closely related. Either or both can happen in the same company. Stage IIIb doesn't necessarily follow from Stage IIIa, it's really just the same problem in another form for the SaaS age. Stage IIIa - We Want To Be A Product Company As you get more and more customers it makes less and less sense to have these different teams porting features from one codebase to another, or copying and pasting for individual projects. Customers start to complain that their system is expensive to build on and maintain, as feature x requires 'integration' or some kind of bespoke delivery cost for their deployment. At this point someone says: 'Wouldn't it make more sense for us to maintain one product, and maintain that centrally for multiple customers? That way, we can sell the same thing over and over again, increase the license cost, reduce delivery cost and make more profit.' Stage III is where the cracks really start to show, and we go into how and why this happens this below. [stages3]The product vision - more customers pays less, and product improves Stage IIIb - We Need An Internal Platform As the (pseudo or real) product offering grows, or as you increasingly offer your software as a service on the cloud rather than a package delivered in a data centre, you invest heavily in a 'platform' that is designed to enable deliveries to be faster, cheaper, and better. You might even set up some kind of platform team to build these cross-product features. It's a similar justification to the product one: 'Wouldn't it make more sense for us to maintain one platform, and use it to deliver products for multiple customers? That way we could reduce cost of delivery for all the customers that use the platform, and increase quality at the same time.' Where Does It All Go Wrong? So how do things go wrong? From Stage I to Stage II, things are relatively smooth. Everyone understands their role, and the difficulties you face are tough, but tractable and clear. As you go to Stage IIIa/b, it feels very tough to move towards the envisioned target. Everyone seems to agree what the goal is, but the reality is: * Customers still want their new features fast (and faster than their competition), and don't want their requests to be 'put on the backlog' * The merging of the codebases seems never to happen * Attempts to write new, unifying products are difficult to build and sell All of these difficulties and failures can often be tracked to money flows. Similarly, with platform teams: * The business wants to build a platform, but balks at the cost and struggles to see the value * The business has built the platform, but doesn't accept that it needs a team to sustain it * The business has built a platform for reliability, but 'heroes' still want to fix things by hand for the glory rather than quietly tinker with a CI/CD workflow Again, all of these difficulties and failures can often be tracked to money flows. How This Happens - Money Flow Patterns These difficulties come down to challenges moving from project to product, and these difficulties in turn come from how money moves into and through the business. Stage I Money Flows - Hero Hacking In Stage I, the money flows are simple: * Team builds software in cheap offices, often on low salaries with the promise of growth to come or fun, adventure and really wild things * The first customers are won because the product does something cheaper or better than the competition * The money from the first customers * More money comes in as customers demand modifications or maintenance on the delivery The reality at Stage I is that there is no real 'product'. There are projects that deliver what the customer needs, and the business is happy to provide these as each individual project is profitable (either on a 'time and materials' or a 'fixed cost' basis), and that results in a healthy profit at the end of the year. The price that's paid is that each customer's codebase and configuration diverges, making porting those features and maintenance patterns a little more costly as time goes on. But no matter: the business has a simple model for cash flow: keep the customer happy and the money flows in, and each customer gets the development and maintenance attention they pay for. [stages1]Stage I - customer asks, customer gets Stage II Money Flows - Pseudo Product In Stage II, the money flows are much the same, but the cracks are starting to show: * Customers are still happy with the attention they get, but: + Projects seem to take longer and cost more + Features that are apparently part of the product can't be just 'switched on', but require 'integration time' + The quality of the software feels low, as fixes are required because of these [stages2]Stage II - Customer pays, customer gets... eventually. Things have gotten more complicated. At this point, customer executives start to say they yearn for a product that has a more predictable quality to it, and a roadmap, and is cheaper and feels less bespoke. Can't all us customers just pay a lower fee every year and get a steadily improving product? At the same time, the owners of the business are asking themselves whether they couldn't make more money the same way: instead of 15 customers, wouldn't it be great if we have 150, all taking the same product and paying (say) half the cost they are now? That kind of margin looks very tempting... The result is that changes in external demand produce a desire to change the development model. Stage IIIa - We Want To Be A Product Company In Stage IIIa (and Stage IIIb), if the money flows stay the same as in Stages I and II, move to becoming a product company will feel extremely difficult. This is felt in a number of ways. Here's one common story: * The company sets up a 'product team' that is responsible for productising the various disparate codebases and hacks that made up each customer's bespoke setup. * This product team tries to corral the project teams into sacrificing short-term customer delight for long-term product strength and consistency. * The product team spends a lot of money doing all the work that is required to make a product, but customers are proving less willing than they said to believe and buy into the product. They find it difficult to change their priorities from the feature delivery times and speed of support they are used to, to accepting delays for a cheaper productised product. Productisation Debt Time and again, development and product teams tell their management that they have to make a call: sacrifice customer satisfaction for the product, or build up 'productisation debt'. * Do you tell your biggest customer they are going to have to wait another month for a feature because the product has a release cadence and standards that are greater than they are willing to accept? * Even if they have the money ready to get the service they want? * Are you willing to watch the relationship with that customer deteriorate over several very difficult meetings as you explain to them that they can't have what they want when they want it anymore? * Are you willing to risk losing them completely? * Do you tell them that they suffered an outage because of a change made for another customer last release? + Will it be any comfort to them to know that this feature is now available to them (fully fixed in the next release)? [stages3]The product vision - more customers pays less, and product improves The result is that it takes a much longer time and more money than thought to get a successful product model going when the older money flows continue to push the organisation towards its old habits and culture. Why trade the feel-good factor of giving the customer what they want now for the slow burn of deferred rising profits in the future? On the face of it it the arguments look simple: your profit margin will go up if you productise. The reality is that finance (and therefore the executives, shareholders, salespeople, HR, reward systems etc) have gotten used to the project-based money flows and cadences and find it incredibly hard to give up for some uncertain but better future that may be years away. What you end up with is a more complicated version of Stage II (simplified here with only two customers for 'clarity'). [stages4]The Product reality - customers and finance want to keep the relationship the same Rather than your customer teams fighting with the customer to give them what they want, you now have more forces acting in opposition within your org, including: * The product team fights with the customer teams for resources * The customer team fights with the product team over productisation calls * Finance fights with the product development team for resources The result is likely to end in failure for your product strategy. Stage IIIb - We Need A Platform The 'platform' stage is really a variation on the product phase (Stage IIIa), except that this time the customers have no visibility of the productisation or automation of what they're sold. This is effectively a product built for an internal customer, the finance team who hope for money to be saved per project over time after an initial investment. [screenshot-2021-07-05-at-07]Platform team money flows similar This can be easier or harder to achieve than Stage IIIa depending on the attitude of the internal customer vs the external customer. Again, this can be affected by the details of the money flows: if the work to build a platform is on the books as capital expenditure (as opposed to operational expenditure - see below), executives may well ask 'is the platform built yet?' This question can baffle the team, as they're well aware that such a platform is never 'finished', as there are always efficiency-generating improvements to make. In both Stage IIIs, if the benefits of the platform are not quantified in financial terms from the start, then getting the funding required becomes difficult. This means that you should: * Measure the cost of delivery per project pre-platform, so you can compare to post platform * Ensure that the cost of the platform is 'baked in' to the sales cycle, so that there is a concept of platform profit and loss that can also be measured * Set expectations that 'profit' may be a long time coming, as is the case with most capital investments. Would you expect to build a house and start turning a profit in 1/20th of its lifetime? Money Flow Patterns The above patterns are common to small-medium sized software B2B software businesses, but they are not the only patterns that drive cultures and behaviour inappropriate to their stated aims. Here we list some significant patterns and their effects on culture, delivery and operations. Opex vs capex Opex (operational expenditure) and capex (capital expenditure) are two different ways that business spending can be categorised. Briefly, opex is regular expenditure, and capex is significant, long-term expenditure. Software projects' costs have traditionally been categorised under capex, but as cloud computing has arisen, more and more of their costs have been moved to opex. The designation of the spending can make a significant difference to how the work is treated by the business. * They may have different approval processes * There might be more money in the 'capex pot' this year than the 'opex pot' (or vice versa) * Your business may mandate that opex costs are preferred over capex costs because they see the management of assets as a burden * Or (as seen above) if the building of a software platform is considered a capex, then it might be considered as 'done' rather than as something that needs to be maintained as an opex There are tax implications to both capex and opex that can further complicate discussions. The line between what a capex and opex purchase is is not always clear, and most projects will have some kind of mixture of the two that make working out the effect on the business's profit and loss account for that year difficult. Project-based funding Project-based funding is where money is allocated to a specific project and/or outcomes, as opposed to product-based work, where funding is usually allocated continuously. Project funding may be on a 'time and materials' or 'fixed cost' basis. The cultural patterns associated with project-based funding are: * Pride in customer service and satisfaction * Prioritisation given to delivery over long-term stability * Scant attention paid to maintenance costs * Mounting technical debt and increasing complexity over time * Lack of co-ordination / duplication of effort between project teams * A 'hero' culture, as fast fixes to problems that arise gain attention over slower improvements * Perceived higher value for customer-pleasing project work over central and internal infrastructure work Yearly funding cycles / business unit funding Yearly funding cycles are where money is allocated to projects or products at the same time every year. This is normally driven by accounting cycles, which are almost always yearly. Yearly accounting cycles make a mockery of technical teams' attempts to be truly 'Agile' in response to business demand. If a released MVP product flies off the shelf in February, then you can't get funding to scale it up until January next year. Strict yearly funding cycles are also often associated with centralised funding within large business units that sit within larger organisations. This can make working in an agile way even harder, as there are two levels of politics to negotiate before more funding can be gained for your team: your own business unit's internal politics, and the business unit's relationship with the central funders. First mover bears the cost Individual business unit funding also makes it significantly harder for any kind of project whose benefits cut across business units to get off the ground, eg 'Platform' or 'Infrastructure' work. Costs for such projects are typically borne by a single centralised business unit that is perceived as delivering little business value, so is starved of funding. This can also be characterised as a 'first mover bears the cost' problem. No money for hard-to-measure benefits Some organisations take a strict view of cost/benefit for any given expenditure that they make that must show some direct, tangible return on investment. In general, this is sensible, but can result in difficulty getting funding for projects where there is not a readily measurable return. For example, what if your investment: * Helps retain staff * Enables more dynamic and faster business outcomes * Reduces the risk of a failed audit Is there a way to measure these, or even the language to state them as benefits at all? Many businesses have no leeway for these qualitative benefits to factor into business cases. What Is To Be Done? Whenever you want to debug a misbehaving program, you want to get to the root cause. Workarounds are unsatisfying, and ultimately result in further problems as the workaround itself shows its failings. I feel the same way about 'cultural problems' in organisations. It's not enough to put posters up around and office imploring people to 'be more agile', or instruct people to have a daily stand-up and a two week work cadence to drive cultural change. No, you have to go to the root of the structures that drive behaviour in order to make lasting change, whether it's on a personal level or organisational. And my argument here is that the root of behaviours can be traced back to money flows. So, what can you do about it? Here's some suggestions: * Involve the CFO/finance team in the change program from the start * Explain to finance the reality of what you're doing * Learn to speak the language of finance - talk to them Most important of all, if you're going to change the behaviour and goals of an organisation, you are going to have to change the way money moves around it. As Einstein said, doing the same thing over and over and expecting different is the definition of insanity. If you can engage with finance in an open and enquiring way, then together you can make lasting change; if you don't, then you will be fighting the tide. Just ask Marx. --------------------------------------------------------------------- If you enjoyed this, then please consider buying me a coffee to encourage me to do more. [bmc-button] Share this: * Email * * * Tweet * Share on Tumblr * Pocket * * Like this: Like Loading... Related [4f37af910d] Published by zwischenzugs View all posts by zwischenzugs Published July 12, 2021 Post navigation Previous Post How To Waste Hundreds of Millions on Your IT Transformation Leave a Reply Cancel reply Enter your comment here... [ ] Fill in your details below or click an icon to log in: * * * * Gravatar Email (required) (Address never made public) [ ] Name (required) [ ] Website [ ] WordPress.com Logo You are commenting using your WordPress.com account. ( Log Out / Change ) Google photo You are commenting using your Google account. ( Log Out / Change ) Twitter picture You are commenting using your Twitter account. ( Log Out / Change ) Facebook photo You are commenting using your Facebook account. ( Log Out / Change ) Cancel Connecting to %s [ ] Notify me of new comments via email. [ ] Notify me of new posts via email. [Post Comment] [ ] [ ] [ ] [ ] [ ] [ ] [ ] [ ] This site uses Akismet to reduce spam. Learn how your comment data is processed. Follow me on Twitter My Tweets Top Posts & Pages * If You Want To Transform IT, Start With Finance * Bash to Python Converter * How (and Why) I Run My Own DNS Servers * Anatomy of a Linux DNS Lookup - Part I * Ten Things I Wish I'd Known Before Using Jenkins Pipelines * 'AWS vs K8s' is the new 'Windows vs Linux' * Why Are Enterprises So Slow? * Ten Things I Wish I'd Known About bash * Five Things I Did to Change a Team's Culture * Ten Things I Wish I'd Known About Chef Recent Posts * If You Want To Transform IT, Start With Finance * How To Waste Hundreds of Millions on Your IT Transformation * When Should I Interrupt Someone? * An Incompetent Newbie Takes Up 3D Printing * GitOps Decisions * Five Ways to Undo a Commit in Git * The Halving of the Centre: Covid and its Effect on London Property * Why Do We Have Dev Rels Now? * The Runbooks Project * Some Relatively Obscure Bash Tips * Riding the Tiger: Lessons Learned Implementing Istio * The Astonishing Prescience of Nam June Paik * Notes on Books Read in 2019 * The First Non-Bullshit Book About Culture I've Read * Why Everyone Working in DevOps Should Read The Toyota Way * Surgically Busting the Docker Cache * Software Security Field Guide for the Bewildered * The Lazy Person's Guide to the Info Command * A Hot Take on GitHub Actions * Seven God-Like Bash History Shortcuts You Will Actually Use * How Long Will It Take For The Leavers To Leave? * Goodbye Docker: Purging is Such Sweet Sorrow * Seven Surprising Bash Variables * The Missing Readline Primer * Apple's HQ, Ruskin, Gothic Architecture, and Agile * Eight Obscure Bash Options You Might Want to Know About * 'AWS vs K8s' is the new 'Windows vs Linux' * Pranking the Bash Binary * Bash Startup Explained * Git Hooks the Hard Way * Notes on Books Read in 2018 * Six Ways to Level Up Your nmap Game * Five Things I Wish I'd Known About Git * Eleven bash Tips You Might Want to Know * Learn Bash Debugging Techniques the Hard Way * Why Are Enterprises So Slow? * Anatomy of a Linux DNS Lookup - Part V - Two Debug Nightmares * Anatomy of a Linux DNS Lookup - Part IV * Anatomy of a Linux DNS Lookup - Part III * Anatomy of a Linux DNS Lookup - Part II * Anatomy of a Linux DNS Lookup - Part I * A Docker Image in Less Than 1000 Bytes * Autotrace - Debug on Steroids * Beyond 'Punk Rock Git' in Eleven Steps * Sandboxing Docker with Google's gVisor * Unprivileged Docker Builds - A Proof of Concept * Learn Git Rebase Interactively * Terminal Perf Graphs in one Command * git log - the Good Parts * Five Key Git Concepts Explained the Hard Way * Create Your Own Git Diagrams * Five Things I Did to Change a Team's Culture * Centralise Your Bash History * How (and Why) I Run My Own DNS Servers * Ten More Things I Wish I'd Known About bash * Download a Free Sample of Learn Bash the Hard Way * Ten Things I Wish I'd Known About bash * Project Management as Code with Graphviz * How to Manually Clear Locks in Jenkins * How I Manage My Time * Ten Things I Wish I'd Known About Chef * Vagrant and Ohai / Chef IP Address Hack * 'Towards a National Computer Grid' - Electronic Computers, 1965 * A Complete Chef Infrastructure on Your Laptop * Ten Things I Wish I'd Known Before Using Vagrant * A Checklist for Docker in the Enterprise (Updated) * OpenShift 3.6 DNS In Pictures * Puppeteer - Headless Chrome in a Container * My 20-Year Experience of Software Development Methodologies * A Non-Cloud Serverless Application Pattern Using Git and Docker * Run Your Own AWS APIs on OpenShift * Dockerized Headless Chrome Example * Convert a Server to a Docker Container (Update II) * Automating Dockerized Jenkins Upgrades * Ten Things I Wish I'd Known Before Using Jenkins Pipelines * Five Books I Advise Every DevOps Engineer to Read * Things I Learned Managing Site Reliability for Some of the World's Busiest Gambling Sites * Clustered VM Testing How-To * Easy Shell Automation * 1-Minute Multi-Node VM Setup * Migrating an OpenShift etcd Cluster * A Complete OpenShift Cluster on Vagrant, Step by Step * Learn Kubernetes the Hard Way (the Easy and Cheap Way) * Docker in the Enterprise * Terraform and Dynamic Environments * Bash to Python Converter * Hello world Unikernel Walkthrough * A checklist for Docker in the Enterprise * A Quick Tour of Docker 1.12 * Power 'git log' graphing * ssh -R (reverse tunnel) man page hell * Writing a Technical Book * Interactive Git Tutorials - Rebase and Bisect * Hitler Uses Docker, Annotated * Linux Scales * Play With Kubernetes Quickly Using Docker (Updated) * Convert Any Server to a Docker Container (Updated) * CI as Code Part III: Dynamic Jenkins-Swarm Example * Docker 1.10 Highlights - Updated * CI as Code Part II: Stateless Jenkins With Dynamic Docker Slaves * CI as Code Part I: Stateless Jenkins Deployments Using Docker * Docker Ecosystem Rosetta Stones * Understanding Docker - A Tour of Logical Volume Management * Automating Docker Security Validation * The IT Crowd Was Right - What I learned by reading a lot of RFCs * Understanding Docker - Network Namespaces * DockerConEU 2015 Talk - You Know More Than You Think * Docker Migration In-Flight CRIU * A High Availability Phoenix and A/B Deployment Framework using Docker * Quick Intro to Kubernetes * Take OpenShift for a spin in four commands * RedHat's Docker Build Method - S2I * RedHat's Docker Build Method - S2I * Bash Shortcuts Gem * A CoreOS Cluster in Two Minutes With Four Commands * The Most Pointless Docker Command Ever * My Favourite Docker Tip * Convert Any Server to a Docker Container * A Field Guide to Docker Security Measures * Docker SELinux Experimentation with Reduced Pain * Storage Drivers and Docker * Play With Kubernetes Quickly Using Docker * Play with an OpenShift PaaS using Docker * Scale Your Jenkins Compute With Your Dev Team: Use Docker and Jenkins Swarm * Docker in Practice - A Guide for Engineers * Fight Docker Package Drift! * Win at 2048 with Docker and ShutIt (Redux) * Set Up a Deis (Docker-Friendly) Paas on Digital Ocean for $0.18 Per Hour in Six Easy Steps Using ShutIt * Create your own CoreOS cluster in 6 easy steps for $0.03 * Make Your Own Bespoke Docker Image * Taming Slaves with Docker and ShutIt * Docker - One Year On * Using ShutIt to Build Your Own Taiga Server * Using ShutIt and Docker to play with AWS (Part Two) * Talk on Docker and ShutIt * Using ShutIt and Docker to play with AWS (Part One) * Phoenix deployment pain (and win) * Phoenix Deployment with Docker and ShutIt * Docker, ShutIt and the Perfect 2048 Game (Videos) * Docker, ShutIt and the Perfect 2048 Game (4 - Halfway There) * Docker, ShutIt and the Perfect 2048 Game (3 - Brute Force Escapes) * Docker, ShutIt and the Perfect 2048 Game (2) * Docker, ShutIt, and The Perfect 2048 Game * My Favourite Secret Weapon - strace * Shakespeare's Vocabulary Considered Unexceptional Follow zwischenzugs on WordPress.com Website Built with WordPress.com. Write a Comment... [ ] Email (Required) [ ] Name (Required) [ ] Website [ ] [Post Comment] Loading Comments... Comment x Send to Email Address [ ] Your Name [ ] Your Email Address [ ] [ ] loading [Send Email] Cancel Post was not sent - check your email addresses! Email check failed, please try again Sorry, your blog cannot share posts by email. %d bloggers like this: [b]