Counting Our Way To IT Failure

Sage Words From My Better Half

I have often been challenged by my wife to find a way to make my IT career exude the essence of a traditional 9-5 labor experience.  She wants what is best for both of us, quality time together.

Assuming you have had a normal IT experience as a manager and/or employee, when you signed up for this early on in your IT career, did you think it was going to be so hard?  My experience has been trying to find the wins in the chaos.  Contain the crazy with all your might, and you might get close to happiness I would say to my self.

But 20 years and several companies later, my only recourse was to venture out on my own, control more of my destiny and still, manage the chaos.

There is an explanation for this, and there is an actual solution.

For years I wondered about the reasons for this condition.  I am convinced that this condition, left unsolved will continue to produce divorces, health conditions, Hoarder Houses of Code and a host of other issues.

The problem stems from something Steven Lowe points to in this insightful article Agile’s Glass Ceiling.

My interpretation of the nature of the problem is that even though we left the industrial age it still has not left our managerial mentality.  Don’t get me wrong, I don’t blame anyone.  We are all conditioned to do what we know.  And we know how to count.  We have to.  It is in our blood.  The reason the Industrial Age was so successful is that we could design a bunch of tasks that are profitable, train people or robots to do those tasks with as little variation as possible (Six Sigma) and rinse, repeat, measure and go on vacation.  It feels good to get a well-defined job done successfully and be rewarded for it.

This model is extremely powerful in the manufacturing industries and the like.

This model, however, is killing the IT industry.  And it has everything to do with the lack of a “job well-defined”.

In fact I believe it is so bad that someone decided, in our IT culture, to continue to try and make our counting more effective by focusing on DevOps metircs, a good thing but not the whole thing!

That and other distractions (Lines of Code, Test Coverage, etc) keep us from seeing how bad we are doing upstream in our processes.  DevOps is powerful for a purpose, but it will never cure the need for a new mode of creative empowerment.  At best it can tell us we are failing, or worse, pretend to tell us we are succeeding when we lower the bar.

Are we doomed?  Is this it?  Do we have no way out of this?  Do we keep telling ourselves we are Agile when we are not able to update our features quickly?  Do we keep telling ourselves we are meeting our goals when our customers cannot use the solution we provide?

Short answer, no, there is hope.  But we have to believe differently to behave differently. It’s such a raw fact of life that we don’t like to discuss this. That is often my biggest challenge and I am sure I am not alone.

Managing Different Is A Journey

There is emerging out of various parts of the Agile world these thoughts and admonitions surrounding team and individual Autonomy.

And as soon as I say that managers all over the world have night terror visions of employees throwing rave parties in the office and getting absolutely nothing done.  And as soon as I say that employees have depressing feelings of not being trusted to accomplish the needs of the business.

Last night I had a short conversation with some friends in the business while out here in Amsterdam at the DDD Europe conference about some of this and my brain did not shut off when I went to sleep, apparently.

This morning I awoke with this mental nudge to consider the tension happening here.  After a few minutes I had this initial thought of “Autonomy vs. Alignment” and on the surface that sounds like the appropriate description of two things pulling on each other, each one trying to take center stage.  But I was not satisfied. I believe the reality of this struggle does contain both ideas, autonomy and alignment, but in a different way.  I don’t believe these two things are at war with each other so I was not done meditating.

Then the phrase “Autonomy and Alignment” hit me.  And without trying to over think it anymore, I did a little digging.  It turns out there was a thesis published by an insightful PhD candidate Gisela Bäcklander entitled, Autonomous, yet Aligned: Challenges of Self-Leadership in Context this past August.  The paper references the Spotify examples of team autonomy and company alignment, but it goes far deeper into the challenges we are really facing in this knowledge work era.

As I was reading it, I began to realize what my wife was seeing from outside of my space.  She saw the results of my need to have a life and at the same time thrive or at least survive in a corporate environment that is setup to fail from the onset.

The struggle is not between Autonomy and Alignment, and it is not even between Manager and Employee.  The struggle is about a difficult and very real migration from Dictated Alignment toward Autonomous Alignment.  Everyone seems to want this very real state of affairs.  Getting there a struggle we actually have to work on together.

To add more salt in the wound, the old model actually sets us up to fear this change and prevent a real restructure of the way work is accomplished. The issue is you have to lead differently to have people follow differently, yet the old managerial mentality is all most people know.  We do what we believe will work, even if the evidence is proving us wrong.

In fact this struggle is the struggle that drove me to find better ways to design software so that I can minimize the impact of the output metric mentality. It helped me code defensively when requirements were horrid.  It is how I came to adopt Domain-Driven Design (DDD) in ever increasing ways over the years.  It is the reason I left corporate life.  It feels like the reason I am writing this blog.

The Domain Intelligence series I am writing is pushing me to consider how a transformation might successfully take root by using some key DDD concepts from teh core of the business on out to all who work to make the company a profitable and wonderful place to work.  I knew going into this blog project that there would be light shed on deeper aspects of enterprise design issues and more.  This personal struggle fosters my continued passion.  I do believe in a better software world than most of us get to enjoy. I have seen success enough to know it can be repeated just like poor Agile implementations can consistently repeat failure.

The next several posts will explore what I believe can be helpful and healthy building blocks from my DDD experience that can help bring a successful outcome to your organization while your competition may still be measuring output.

Until Then – keep at it.