Bell Curves and Professionalism

Are you a professional programmer? Professional technologist? A professional?

Are you familiar with the bell curve? Bell curves are used to explain everything. Equal distribution of objects in gaming, student examination placement, equal opportunity hiring distributions, setting consulting rates contextual to population densities and regional competition, house and land prices, understanding or explaining behaviour of people in groups and even IQ.

You may or may not realize that bell curves are also used by companies and employees as a defense for mediocrity. Obviously they don't say it like that.

My company is competitive with everyone else in our industry, region and city.

Ever wonder why your company spends more money on art in the hallway, sculptures in the atrium, real estate for potential development that never happens, charity drives or spectacular buildings using the latest in technology and design? If you look at where the money is spent, it will teach you what the company actually values.

Being provisioned with a cube, chair, HVAC, sunshine, subsidized insurance and company-match retirement plan is not valuing you. It is being industry competitive and following the law. You can sue for poor ergonomics in the US. So a chair, desk, HVAC and proper lighting are non-conversations. Health insurance is provided to be competitive. After it is provided, it is then subject to legislation. There aren't that many types of insurance packages and they are all regulated similarly. And retirement plans? Same options, different wording, same regulations.

So most employers aren't going out of their way to get you; just enough to be between the 10 and 2 O'clock positions on the bell curve. Be just enough legal. Be just enough competitive. Be just enough and keep the rest for the hallway art.
If you reflect on the recruiting fair you attended before being hired at Company X, you were likely sitting in a room full of HR Reps and Recruiters arguing over who's vanilla ice cream tasted the best. And when you picked one, you believed you'd somehow chosen the best vanilla ice cream available. Who knew? Right?

If that sounds jaded, then let's look at the efforts made to retain you.

Christmas parties with open-bars, company meetings, annual reviews with a +/-3% cost of living increase, recognition in the company newsletter, abuse the boss for charity events, promotions to lateral roles containing new responsibilities without a change in authority or compensation, per diem travel coverage and a USD$14 desk clock for your five-year anniversary.

I am competitive with everyone else around me.

Let's polarize just a bit before you pat yourself on the back for being highly competitive and valuable. Who really cares if you're competitive at a mediocre, center of the bell curve company?

If the above conversation depresses you, incites apathy and makes you feel like none of your choices matter in this giant machine of industry, accept your chosen position on the company's bell-curve of mediocrity as a clone. Get a t-shirt and wear it proudly. You are not as special as mom led you to believe. Your company is mediocre and so are you. In fact, consider yourself a kernel of corn in a vast corn field where your particular shade of yellow is lost in the spectrum. You, my friend, are a gradient.

However, if the above conversation ticks you off, its possible you may be a professional and you must then do something about it. Set the bar for yourself rather than accepting what is handed to you. Be better every single day than you were the day before. Read books, attend classes, go to conventions, contribute to community expertise groups, teach classes, take online courses, write and publish, propose and counter-propose cultural change in your team, project and company. Figure out how to daily evolve into something more valuable than the day before. Practice your craft. Play for the long-game. At the end of a 10-, 20-, 30- or longer year career, what will you be?

This conversation comes down to your personal work ethic and professionalism. If your company invests in your professional improvement and pushes you to be great, consider it a bonus. They are not obligated to do so and such behaviour definitely cuts into the art acquisition, storage and display strategy. The reality is your work ethic and professionalism is singularly your responsibility. You are responsible for your well-being, your professional behaviour and your work ethic. Your company is likely choosing to be between the 10 and 2 position of the bell curve to manage margins. Where do you choose to be?

We know companies normalize to the competition somewhere between 10 and 2. We also know that people normalize to the company's performance measurement frameworks somewhere between 10 and 2. We also know that companies and people homogenize into a culture. In this example, given companies and people are homogeneously normalizing between 10 and 2, they then fall into a comfortable existence otherwise known as mediocrity. Thereafter processes, procedures, measurements, rewards and penalties are built around this culture of mediocrity to protect it. Mediocrity becomes your reality and the basis by which you are measured.

Take responsibility for your professionalism.

If you would like to know what a professional software craftsman looks like, read Robert C Martin's The Clean Coder: A Code of Conduct for Professional Programmers. Don't stop there. Follow up by reading Robert C Martin's Clean Code: A Handbook of Agile Software Craftsmanship.

If you're content being between the 10 and 2 position on a bell curve, stop telling people you're a professional. Professionals pursue their profession through continual self-improvement regardless where they work, who they work for and the team with which they journey. Professionals practice, hone, sharpen, challenge, deconstruct and reconstruct their engineering and behavioural disciplines regularly. People living between 10 and 2 do not.

Reflecting on our previous conversation about companies that invest in hard assets. Consider this: art accrues value simply by sitting on a shelf. Ironically, people do not. If you choose to exist between 10 and 2, where do you believe your company will next invest?

Leadership Waste

There are far too many incompetent people in technology leadership positions today.

Too many people think technology leadership is defined by documentation, time-tracking, statusing, balanced organizational charts, effective calendaring, well-run meetings, tools, immutable technology stacks, immutable processes and procedures, RACI diagrams, cost-accounting, risk and issue management, as well as, checks and balances that would make any historical oppressionist proud. This is, at best, management. It is not leadership.

Inversely, there are some in technology leadership who turn the dial in the opposite direction and believe having little to no engineering, operational and behavioural framework fosters innovation. This is at best, naive; more likely, irresponsible. The absence of structure is neither management, nor leadership.

We're then inclined to wonder which method, too much structure or not enough structure, will give us the longest, highest return on investment. Both considerations are the wrong focal points.

Ask yourself some questions about your current teams, leaders, operation and systems.

  1. How much software in your supported systems is actually executed in production?
  2. How many features out in production systems are actually used by customers and with what frequency?
  3. How much money was spent to build the system you currently maintain in production?
  4. How much money is spent to maintain the system you currently have in production?
  5. When did or when will your organization realize a break-even return on investment of the system you currently have in production?
  6. What are the areas of your system and operation with the highest risk exposure to industry regulatory and compliance breach?
  7. Which parts of your system have the least probability of reliability and how do they relate to the primary ways you make money?
  8. Name ten ways your system could be exploited by 'baddies' out in the ether. Now name ten ways it could be exploited by your own teams/employees.

If you know the answers to these questions, well done; please go teach others. If you don't know the answers to these questions, you should. Fix it. This is an automated instrumentation conversation accessible 7x24x365 for evaluation, decision and action, not a one-time report for you to file in your CMS.

If you don't think these questions are important, you should be fired because you have no idea how to actually add value to the organization that thinks you're an expert.

What are some of characteristics of a useful technology leader?

  • Understands the steps it takes to deliver a solution and seeks to eliminate both the number of steps, as well as, the execution time of each step itself
  • Understands the wait time in between each step and seeks to minimize or otherwise eliminate wait time between execution steps
  • Fully understands each and every system, sub-system and component required to make money for the business and eliminates everything that isn't used or otherwise doesn't protect existing and generate new revenue
  • Constantly seeks to eliminate architectural, operational and organizational dependencies, redundancy and complexity
  • Seeks to automate everything including source integration, unit/integration/specification testing, standards inspection, performance, information security, deployment, systems health and generally things touched more than three times
  • Understands the rivets, bolts and welds of the technology operation, but understands we're running a revenue-generating business, not an aggregation of technologies

My favourite conversation regarding operational waste is undelivered software. It isn't enough for some organizations and leaders to be unaware of un-used, un-executed software in their production systems which take financial resources away from the operation. Some leaders take it a step farther and focus on building new, and extending existing, software that they don't deliver for weeks, months and even years. If these software leaders were hired by some manufacturing companies of hard-goods, they'd be fired. Inventory, whether stored in a warehouse or lost in the distribution channel, is unrealized money. Unrealized money is waste. You're fired.

Software businesses focus so diligently on implementing the fewest number of mouse-clicks to separate people from their money (for value of course), yet completely fail to realize that their own company is being separated from full company coffers by unrealized return-on-investment. Inventory waste. Process waste. Waste.

A useful technology leader that adds value to an organization delivers standards-driven, tested, demonstrable, revenue-generating, whole solutions to production in very short periods of time while constantly eliminating any and all forms of waste along the way. A wasteful technology leader generates, maintains, protects, measures and reports on said waste as if it is the deliverable itself and may not even recognize the difference.

How do you want to spend your money? Your answer should determine your employability and that of your teams.

Industry Standards

Why use them?

It comes down to a few(-ish) very simple reasons:

  1. When it comes to engineering, industry, regulatory and compliance standards, the team, project, product and company need to be above reproach. Why put yourself in the position to defend your own self-contrived standards, let alone stand guard over them for years to come? Make your standards eq industry standards and then merely talk about your implementation of industry standards during an audit. Let the industry audit validate your use of industry standards, not your deviation from them.

  2. Spend your development budget inventing new things that make money for you and your company, not re-inventing things that already work and hoping for a raise for duplicative effort. The NIH (not-invented-here) syndrome continues to thrive in the software space. People who suffer from this disease should be coached away from NIH behaviours. If they simply can't get past it, they should be fired or sent to your competitor so they can waste all of their innovation money on command and control, maintenance and support efforts.

  3. On-boarding new staff costs money. Whether from the street or fresh out of university, on-boarding is a manageable expense based upon the chops said people bring to the table coupled with how well aligned your organization is with generally accepted, generally practised industry standards. People do not come out of university or off the street knowing your cultural idiosyncrasies. How can they? And in all cases I've personally experienced, they don't go back to the street any better for their time living inside your customized world either. Some won't even put it on their resume. Consider that people on the street are highly likely to know industry standards, so you don't need to teach it; merely interview for it. Likewise, fresh university graduates may not have all of the street experience of others, but they are not graduating naive to current trends, technologies and standards. Again, interview for it.

  4. Today's frameworks, tools, processes and procedures are all built upon a common set of standards. When you deviate from the generally accepted standards you increase both your operational overhead and your organization's risk exposure to breach, exploitation, potential litigation and liability.

  5. You're simply not as smart as you think you are. The collective is usually faster, more comprehensive and generally smarter than the individual and using industry standards inside industry tools enables teams to move more quickly and correctly than the inverse. If you can't see that, you shouldn't be leading.

Personally, I'm selfish. I like to go to sleep at night in peace. Most of the people I enjoy working with think like this as well. In order to meet the selfish goal of sleeping in peace, simplicity is required.

In order to be simple we don't just need to eliminate complexity, we need to prevent it. Guard against it. Using what exists every time possible, and automating most everything based upon those commonalities, is the foundation for success, not success itself.

Why would I use a tool for something other than its designer's original and intended use if I have a choice? Why would I possibly contrive my own coding and formatting standards outside the bounds of the specific language or vendor recommendation? Under what circumstances would it make sense to witch my own frameworks?

There are seldom exceptions. It would be great to hear your comments regarding why it makes sense to invent your own context-driven standards versus leveraging industry constructs as a launchpad to get where you need to go.

It's sad to see, but some leaders simply don't get it. Forcing your teams to stray from generally accepted industry practises and standards to then maintain and seldom evolve custom-to-your-environment ideologies is a travesty. Worse yet, maintaining custom standards simply precludes your team mates, teams and operation from focusing on and helping the business rise to new challenges.

Think about it: Exactly how are you helping the business look out the windshield when you're spending all of your time polishing the tailpipe?

Omnipresent Orthogonal Relationships

Not too long ago I spent some time with a friend of mine visiting from a third-world country. I always enjoy our conversations. Regardless the topic, whether philosophical, theological, historical, scientific, economic, political or otherwise, we seem able to discuss multiple related, unrelated, like and opposing positions on the same topic merely to consider the merits of an idea, all without offending the other person. Many times the conversations are simply thinking, wondering and pondering out loud in the presence of the other. Often, one of us offers colour to the conversation not otherwise present when thinking alone. Fulfilling. Challenging. Some of my favourite conversations.

Because we have no expectations of the conversation or the results, discovering relationships between ideas that previously seemed unrelated is actually a great part of the fun. Starting with a blank slate and no agenda enables discovery. Discovery often yields broader and deeper understanding of a subject which leads to application of an idea.

For example, one conversation we've had in the past pondered the relationship between Maslow's hierarchy of needs at an individual level, the establishment, management and evolution of a nation-state, global economics, the military-industrial complex and very large systems with built-in checks and balances. Thematically, where we ended up was the discussion of managing populations. Like I said, we often let the conversations wander to see where they will go.

When I think about meeting the individual needs of a person, it seems achievable. When I think about meeting the individual needs of a person lost in the foreign-soil occupying military-industrial complex being used as a tool of international nation-state sovereignty and power through interdependence, it is an overwhelming and seemingly useless endeavour. Such a large system and I, being nothing more than the dot of an "i".

You and I have limited resources. We are easily capable of focusing on one individual, perhaps even multiple. However, when it comes to focusing on very large systems such as poverty, drought, genocide, war and politics, it is plausible that we'll feel overwhelmed by the enormity of the problem. How does one add value to an individual in light of the larger system? Do we even realize the size of the system? Is focusing on the individual slighting the system at large? Is focusing on the system slighting the individual?

This journey inevitably led us to a parallel conversation regarding software system sizes, complexity, testability, growth capability and the definition of health.

The questions posed included:

  • "How do you know the system will always work as it grows?"
  • "How do you know when the system will fault and fail well in advance of the actual events?"

As we discussed the implications of addressing this feature, that feature, that widget and this widget individually and absent the context of everything around it, the challenge of delivering new software seemed easier to address. Remember, we are more easily capable of meeting the needs of the individual over solving drought.

However, in every case we explored, discussing a feature addition absent the larger system level context created new problems. Technical debt, feature and feature-attribute duplicity leading to end-user, customer support and marketing confusion, longer build, implementation and verification timelines and unnecessarily complex infrastructure, though not in all cases did all of these things apply. While addressing an individual feature made me feel as though I accomplished something, it did not address the larger systemic complexity problems inherent with growth. As a result, addressing an individual element in the system without considering the larger system implications began to look like a lie.

Sure we can provide a laptop for one child in one family in a village and tell the world we solved literacy. The misrepresented literacy message aside, how will the laptop impact that child's security in that family and village? Perhaps not an intuitive causal relationship. Nonetheless, related to each other they are for sure.

Similarly, we can add as many individual widgets to a system as we desire. One widget at a time is easy. However, at what point must we consider the relationship of the new feature to all existing ones before the system faults and fails resultant from fragmented solutioning?

When we choose to focus on a widget, we only solve those things related to that widget. However, when we choose to explore an idea with the intent of discovering larger orthogonal relationships, our solution will more likely be systemic in nature.
We have to remember that everything is related to everything else all of the time even when, because it is easier for us individually, we only want to focus on the dot of an "i".