The Case For Negativity

One of the pillars of the scrum framework is transparency. When gathering in an organization to accomplish some goal, openness of that kind necessitates honesty. Honesty sometimes necessitates negativity.

From what I’ve observed, the pendulum has swung to positivity in the workplace to a fault. This is hurting our ability to be open. I understand the impetus to lean into a happy-go-lucky, “go team!”, “rah rah!” persistent attitude. It has several desirable affects from the perspective of an employer. It gives the appearance of a warm and caring environment where everyone belongs. At a surface level it is inclusive and inviting. My guess is that for most people this helps retain them at a company. A sense of belonging is a key grip to hold when work gets otherwise untenable. In the mind of the employee, the organization becomes a functional family that they chose and were accepted in to.

The downside is that the real work doesn’t happen where the sun shines.

Something that is so often and easily lost in an office is that work is dirty, hard, and frustrating. It hurts and takes it’s toll on you. And that’s OK! That’s what’s supposed to happen when you are creating something from nothing. Part of you is necessarily sacrificed. There is a real cost to how you spend your time. If that cost is not acknowledged, you are more apt to waste it creating something you don’t believe in.

This is where the illusion needs to be bolstered by delusion or it falls apart. How many people love their team/coworkers/environment far more than they care about the function of the organization they are a part of? I’d wager more than would be willing to admit to it. Things fall apart for those in the organization with duties that directly translate to the core mission of the organization – the morlocks that keep the machines running. For these people, glossing over the pain is unacceptable. Being critical, cynical, or blunt is essential to the success of producing anything of quality. I challenge you to name any worshiped captain of industry that didn’t embody these traits.

The Few

I have observed the Pareto Principle at work in most companies, especially larger ones. A majority of the work (or architectural direction, at a minimum) is the product of a few individuals. Again, via observation, I have found these people to trend negative in demeanor. Work isn’t fun. It’s challenging, but rewarding. In my mind there’s a segmentation of time well spent between fun/relaxing time and productive effort towards a goal. Both are necessary for a fulfilled life. Only one of them is necessary for creating almost anything tangible.

The success of your organization may hinge on a few people, but the success is shared. Give people a pass on coming off a bit surly if they are getting work done. Forcing a smile or exaggerated enthusiasm costs time and energy. Both are precious resources that need to be focused as best as possible, especially in today’s distraction heavy work environment. Swearing has been proven in studies to increase pain thresholds. It can be a tool to help tolerate frustration and difficult tasks.

Screw you then.

Does this mean that if you are productive you have license to be a complete jerk? No. There is the counterweight of respect to keep things orderly. But respect does not necessitate a smile or even any positivity at all. At work we’re all a team aiming at a goal. That’s bond enough.

Doing It Right The First Time

Reflecting back, the only time I’ve ever done something right the first time is when it wasn’t my first time doing it.

As a contractor, I encounter eerily similar situations at most places I involve myself with. Even businesses not in the same industry. Most businesses are trying to solve similar problems across multiple domains with slight variances. This is exactly the reason learning design patterns is a good investment of your time.

If I’ve ever come into a new project and nailed it on the first try, it’s only because I recognized the similarities from a previous project, employed the things that worked, and avoided the things that didn’t.

From the perspective of full time employees, it’s a challenge to be allowed to fail a few times at one employer. A contractor can have a few “challenging” gigs and then stumble upon the perfect redemption project for a win. A full timer would have to get a rare blessing from above to rewrite something for the third time.

Build something small and scale it

The axiom “build something small and scale it” is a great strategy. The problem is knowing exactly how something will scale. Users have a way of turning your well thought out schema on it’s head. Still, something small is far easier to rewrite. Build something small, release something small, rewrite something small, release a rewrite of something small, and scale it is not as fluid off the tongue. It’s more accurate, though.