You Have Choices. But Reality is Still Reality. Part 2

In the first installment on this topic, we discuss the adage “…it can be Good, Fast or Cheap, pick 2”, and why the adage holds so consistently true. In this installment, we will discuss a few of the beliefs and resulting actions of the individuals that seek to find a path around the truth.

More resources always saves time

The task is going to take 1 resource five weeks…. Why don’t we use 5 resources and get it done in a week? This is one of my favorites as it comes from an absolutely honest place. The inquiry is a genuine expression of the desire to help, and an attempt to translate existing business knowledge to IT. For instance, it is pretty common to identify staffing needs via piece count and demand. I need 750 pairs of jeans, 1 individual can sew 10 pairs per day and it will be 75 days, or 10 individuals can sew 100 per day and take 7.5 days.

 And in some circumstances, adding resources can reduce time (while increasing cost). However, frequently the tasks in IT are not conducive to scaling resources. Particularly at the task level where this approach is generally suggested. If it takes 1 baker 3 hours to bake and ice a birthday cake, 3 bakers cannot accomplish it in 1 hour. Some steps are sequential and must be done in order due to prerequisites. The cake cannot be baked until the batter is mixed, the cake cannot be iced until it has cooled. Other sub tasks are most efficiently done by 1 individual. 3 bakers stirring the batter will not improve the process; three bakers cannot effectively ice the same cake at the same time without impeding the others.

 Outsourced = In-house

This is part of the process that creates friction among IT and Leadership. The belief that an outsider, whether a local contractor or an offshore firm, can interact within the domain as well as an insider. The justification is, “We need a baker, if all our bakers are busy, we can look outside the organization for a baker of equal skill and the process won’t suffer.”

 The reality is that “Domain Knowledge” is more than functional knowledge. Domain knowledge includes abstract components such as culture awareness (internal and customer), business knowledge, jargon, and many more. Furthermore, it includes environment specific knowledge and practices. Returning to our bakery, an authentic French pastry shop in New York City could easily find extra bakers to fill a project need. However, they may struggle with recipes written in French, with metric measurements, and foreign concepts of quality and performance. Additionally, environment specific knowledge that includes which spots in the oven is too hot or cool, where utensils and supplies are stored, which thermometers and timers are accurate along with dozens of other nuances of the kitchen will cause frustration and delays.

 The end result is the auxiliary bakers will, in fact, bake cakes, but they will not be able to match the speed, efficiency or quality of the “In House” bakers until they have been in place long enough to be “In House.” Expecting the same quality and number of cakes is a recipe for disaster.

 Buy vs Build

One of the decades old arguments in the IT world. Primarily in development, but increasingly in infrastructure and services with the advent of the Cloud, Platform as a Service, and Infrastructure as a Service. The debate is not the failure. The failure is in the belief that one is always better. Buy versus Build is a balance of quality and features that meet the business need at the price point that adds value.

 When the need is common enough to align with existing features, and the scale and scope are large enough that usage offset the cost of a quality solution, then Buy is a viable choice. When the need is unique enough that customization would be required, and usage is limited enough that ROI on a Buy solution may be impossible.

 The issue is when Buy vs. Build is predefined and one or the other is always the right choice, it isn’t. It may be heavily skewed one way or the other based on industry, organization size and skillset. But it is never always one over the other.

 Hire skilled but inexperienced to keep cost low

From a long term strategy perspective, many leaders find this an attractive approach due to the simplicity of the idea and the straight line to cost savings. Unfortunately, this approach has two dramatic shortcomings that remove all value before it gets off the ground. The first is the first descriptor, “Skilled.” Identifying the genuinely skilled without the vantage point of previous work is difficult at best. Additionally, the process of identifying the skilled resource is time consuming and is even more time consuming without the evidence provided by prior experience. As the truly skilled without experience are reasonably rare, the identification, recruiting and hiring is infrequent and slow, unlikely to meet immediate demand.

 The second descriptor, “Inexperienced” is problematic as the resource builds experience quickly once hired. From the point they have built the experience wage pressure from the competition will entice them to leave. The result of the departure is to have to start the process over again. The realistic defense is to elevate the wage to meet market expectations. They are essentially voiding the entire premise of keeping costs low.

 Retain with culture vs money

The follow up strategy is to focus on “Culture” rather than wage and benefits to retain a skilled workforce. The underlying belief is that a highly skilled and focused workforce will sacrifice cash and benefits for “Culture.” Some organizations cling to this strategy in the face of its objective failure. They point to inverse examples, of organizations that pay a premium for high stress, high output, and multiple conflicting stakeholders as “proof” that culture and pay are inversely related.

 A significant problem with the approach is “Culture” is subjective and personal. What is attractive and worthwhile to one may not matter to another. Finding a culture that appeals to multiple individuals AND is worthwhile enough to sacrifice tangible assets is virtually impossible. What is more likely is a work environment that accepts quality, output, and focus that would be unacceptable in the wider market in exchange for a lower payroll.

 In practice, an environment that promotes employee wellbeing, integrity, and collaboration can be combined with non-financial perks such as flexible schedules, casual dress codes, and employee events to create a culture that differentiates from the competition and helps to retain skilled staff at or near market rates..

 False at face value:

A surprising number of beliefs in common practice and leading to implemented decisions are objectively false on the surface and require little discussion when examined in the harsh light of day: “Automation always saves time,” “Over reliance on consultants” remember consultants have a vested interest in taking longer, QA is a cost that can be cut without consequence, Security is a cost, or any other “we’ll fix it in phase 2” mentality.

 Replaceable Cogs

The underlying belief that an Engineer = an Engineer = and Engineer. That as long as an individual has an understanding of the technology in question, they are a replaceable cog in the machine. Whether referring to an Infrastructure Engineer, a Java Developer, or a PL-SQL Administrator. That the activity is “Transactional” that a block of code, a connection to a server, or a stored procedure is an isolated transaction and any competent technician can accomplish it with equal speed and quality.

 Just as the first entry above was one of my favorites because it comes from a place of genuine desire to help, and an attempt to translate business knowledge to IT, this one is the one belief that I find objectionable. It comes from a place of dismissive superiority, and devalues the skill and knowledge of the IT world and attempts to avoid translating business knowledge to IT.

The belief intentionally disavows any impact of skill, experience, domain knowledge or even dedication to the organization. The belief is objectively false as determined by the free market for employing said resources. Entry level, Junior, Mid Level, Senior, and Architect level resources command differing salaries, specifically because of the skill sets and understanding they bring.

 If anyone in your organization holds this belief, I is likely that your organization has a strategy and leadership problem. The higher up in your organization this belief resides, the more prominent, and pressing, your strategy and leadership problem is.

 Further reading

Knowing what the ramifications of decisions made is key to identifying the 2 aspects your organization wants to maximize. In the next installment, we will discuss how to use this list of ideas to create a checklist, to identify tradeoffs when attempting to squeeze one of the three sides of the adage “…it can be Good, Fast or Cheap, pick 2.”