Do you have a cost-reduction, or value optimization mentality?

What's the difference?  A monetary cost-reduction mentality focuses on just that - reducing costs.  IT is a cost center.  It's a business enabler.  Period.  This mentality has little awareness or concern for the value function presented by a given decision.  On the other hand, a value optimization mentality focuses on optimizing the value function through careful consideration of trade-offs.  Every decision presents trade-offs.  While a cost-reducer looks at a decision and sees fluctuating costs that must be minimized, a value optimizer sees an outcome spectrum.  The optimal outcome is the one where known trade-offs are considered and optimized.  One trade-off is cost, but it's not the only one.  In my experience, organizations focus on reducing the cost of IT.

Let's take an easy example that seems to come up frequently.  One component of IT is employee computing assets.  That may include things like smartphones, but most important is their computer(s).  This is the primary mechanism through which employees add value to the organization.  Different users tax their computers differently.  One might run their email suite and spreadsheet app on a regular basis, while the other is running one or more development environments, supporting tools, and related automation.  The machine that does the job for the serial emailer is not going to cut it for the software developer.  One size does not fit all.

The cost-reducer either fails to recognize or does not care that one size does not fit all.  He would also advocate infrequent machine upgrades because of cost.  The value-optimizer sees trade-offs abound.  Reducing the cost of computing equipment is critical for obvious reasons.  Developer (and other power users') time is also a critical cost to the business.  Developers are expensive, and their skills always in high demand.  The machine that reduces costs leaves the developer twiddling her thumbs while routine tasks complete.  Even a modest developer salary will quickly justify a better machine that minimizes thumb-twiddling time.  Organizations that don't take this into account are throwing money away and hindering productivity.

A quick sign of an organization focused on cost-reduction rather than value-optimization is one where people and services are centralized.  Centralization yields economies of scale, but (you guessed it!) has trade-offs.  The primary trade-offs associated with centralization are flexibility, and speed.  Mike Cottmeyer wrote this very short, great article called Reuse Creates Bottlenecks, on the topic.  Centralization absolutely has its place, but when teams need to deliver, it creates bottlenecks.  It creates dependencies that are outside the control of teams trying to deliver, and requires them to attempt to manage them.  Outside dependency management can easily cripple a team focused on delivery.  In Donald Reinertsen's book called The Principles of Product Development Flow, he succinctly describes the considerations for centralization versus decentralization.  He makes several more, but here are two primary points:

• "Decentralize control for problems and opportunities that age poorly."
• "Centralize control for problems that are infrequent, large, or that have significant economies of scale."

I haven't had the chance to read this book yet, but I've talked with colleagues about The New Gold Standard by Joseph Michelli.  The focus of the book is the Ritz-Carlton Hotel Company's approach to creating an amazing customer experience.  My understanding is that employees are enabled to spend up to $2,000 to make any single guest satisfied with their stay.  This is empowerment and decentralized decision making authority at it's best.  Solve the problem the instant it's exposed.

Now, let's acknowledge that this is an extreme example.  Different organizations are going to have different value functions.  The Ritz-Carlton's differentiated market position is unparalleled luxury, quality, and customer experience.  That position likely does not mesh well with most cost reduction efforts.  They spend, a lot, for extraordinary quality.  But I digress...

The Ritz-Carlton is doing what we strive to do as agile teams.  As software developers we build quality in by writing tests that assert our expectations and make sure we pass those tests.  Code complete features are tested as soon as possible, and if issues are found, they are fixed immediately.  When a quality issue arises, nip it in the bud as quickly as possible.  In our case, and in the case of the Ritz-Carlton, the optimized approach is achieved through empowered employees with decentralized decision making authority.

Organizations absolutely should consider shared service (i.e. centralized) approaches for infrequent, non-urgent problems.  Often times I think of employee benefit services as ideal candidates - functions outside the business value chain.  But for business functions and customer solutions, organizations must be structured to optimize the delivery of customer value.  Organizations can't just look at the cost reduction because there are trade-offs present and one size does not fit all.  Localized empowerment through decentralized decision making achieves the right fit for the problem at hand, and with agility.

Yes, decentralization creates inefficiencies, but often times those inefficiencies are optimal when compared to the bottlenecks of a centralized approach.  Realizing this, we can make better decisions that result in better outcomes for organizations as a whole.

How to contain those nasty change agents

We've all been there at least once in our lives.  Things are humming along nicely.  You're in a really good routine, operating at status-quo productivity level.  There are plenty of challenges at work,  needing to balance meetings with time dedicated to 401k management.  Then, in the midst of everything already going on, change agent Chad rears his ugly head.  When you find yourself in this unfortunate circumstance, here are some steps you can take to contain the problem before it spreads like wildfire and your environment is forever disrupted.

Limit collaboration.  It is through collaboration that the change agent spreads toxic ideas.  Avoid cultivating an environment in which collaboration occurs freely.  This can be fuel to the change agent's fire.

Feign interest in change movements.  Change agents thrive on their ability to influence to achieve positive outcomes.  They may be able to successfully change perceptions at the grassroots level.  If this occurs, do not worry.  The organization that you've spent years controlling will look to you for direction.  When this happens, dismiss or feign interest in the movement.  Overtly condemning is an option, but this may create a greater ripple effect than desired.  Optimally, you can absorb, but silently dismiss any proposed changes, thereby preemptively smoothing out the rough spots.

Prevent expenditure.  When change comes along, there are likely costs associated.  You can manage this growing change movement by preventing expenditure on new tools, technologies, equipment and training materials.  Without these elements for success, any change is likely to fall short.

Stifle learning.  Learning is another opportunity for ideas to spread.  When maintaining the status quo is critical, at times like these, lead by example.  Promote and embody a culture where learning is difficult, overlooked, and if necessary, reprehensible.  Persistent change agents may attempt to circumvent your expenditure-limiting efforts through frugal or organic learning opportunities.  In dire situations like this, direct prohibition of the effort may be your only option.

As Bob Dylan noted, the times they are a-changin'.  Sometimes we need to take matters into our own hands to ensure this doesn't come true.  After all, our future mediocrity depends on it.

Do doers matter when getting it done?

It seems like large companies believe doers don't matter anymore.  A developer is a developer, a QA is a QA, hire them by the masses!  Any warm body will do!  How did it get to this point?  More importantly, how do we get out?  How do we reinstate development to its proper level of importance; to the level of craftsman?

It's really interesting when you talk to people doing traditional enterprise software development.  Many developed software in smaller companies, startups, or even on their own previously.  If you ask them to rewind and think about how they operated in that environment you find that they embodied many characteristics of an agile developer or agile team.  Collocation, constant communication, collaboration, small chunks, frequent releases, customer focus, getting the job done with great engagement and satisfaction.  Fast forward to today.  Now they're entirely enterprisified.  Lots of documentation to make up for the lack of communication and collaboration, doing an unfulfilling, small slice of the delivery pie, unsure who the customer is and not really understanding how they intend to use the system, and unable to step in when gaps arise because role boundaries are cemented into the culture.  Generally these people say that they were far more effective in their former role.  Why?  They were smaller.  They were focused on the product and the customer, not the process and their role.

Successful small teams start with talented contributors.  Inevitably, greed or business need or both prevail.  Must get more done.  Realistically, if the talented group is humming along, the only way to get more done is to add people to the effort.  That all seems fair to me.  What usually happens at this point though is that a bunch of sub-par people are added to the effort.  That's the worst thing for the team for multiple reasons.

1) Initial ramp-up for new people is costly.  Add talented people, not sub-par people.  Talented individuals will ramp up faster.

2) As Fred Brooks talks about in The Mythical Man Month, increasing people on an effort increases the amount of communication required by the team.  But wait Jason, you just said adding people to the effort was fair?  Absolutely.  Add talented people, not sub-par people.  In my experience, adding talented individuals to a project only marginally increases timeline due to communication, much less so than adding mediocre folk.  This is really the same point as #1, but directed more at the ongoing cost of communication rather than the upfront (ramp up) cost.

3) A diminishing talent pool begets quality policing.  Policing is ugly for obvious reasons.

The diminishing talent pool is the issue I really want to highlight.  As this scenario plays out, the talented folks become "leaders" of sorts where they begin to focus less on implementation and more on leading, managing and overall design.  The thinking here is that having a top tier person design the system and set standards will result in a great and healthy system regardless of who does the development.  Managers in organizations think this works because, as Uncle Bob wrote in The Clean Coder, "they don't see the God-awful code."

The fact is, developers have both immediate and long-lasting impacts that make the role absolutely vital, arguably the most vital.  The code is what users interact with and experience.  Not the system design, underlying components, and certainly not a backend DB.  Users interact with apps written by developers.  Therefore, developers have an immediate impact in the form of product quality.  They introduce, reduce, and prevent defects in the product.  Devs also have a more indirect and long term impact on  users in the form of a product's changeability, testability, automation, and technologies that make up the product.  The code that David the Developer's writes today determines releasability tomorrow.  The code that he writes today determines how hard it is to change tomorrow.  And the code that he writes today determines the customer's product quality experience tomorrow (or even today if you really rock!).  How many sub-par David's can you and your customers afford on your team?

Age-old clarity on the role of architecture

A little over two years ago I was afforded the opportunity to embrace an agile transformation.  I suspect my experience shares parallels with others' agile transformations, particularly when I say that the road was bumpy.  One of the recurring bumps was the role that architecture plays in an agile environment - an environment where delivery teams increasingly focus on the present and embrace the uncertainty of the future.

I've recently been reading a classic software book for the first time.  That book is none other than The Mythical Man Month.  The first few chapters reveal some great insights in the areas I was expecting.  More interestingly though, it lends some fantastic perspective in at least one completely unexpected area - architecture.

For years now I have struggled to understand the role of the architect.  I've worked with many, all with the same job title, but many with different "day to day titles".  Those have ranged from application architect, delivery architect, enterprise architect, security architect, to most recently, user experience architect.  Sometimes while working with the great people in these roles, we clashed.  I think I always knew why in the back of my mind, but the reason has become much more clear recently.  Put simply, decision boundaries were not, and are not clear.

Fred Brooks says that the most important aspect of system design is conceptual integrity.  Conceptual integrity simplified is the relative ease of use of a system on a 'functionality offered' basis.  Increasing the functions offered by a system increases its complexity.  In fact, he says that complexity can increase beyond expectations because "the things one wants to do often requires involuted and unexpected combinations of the basic facilities."  Said more simply, functions must be combined to achieve desired behavior.  The point that Brooks arrives at is that "ease of use, then, dictates unity of design, conceptual integrity."  Ease of use is paramount in system design.  Ease of use is the primary responsibility of architecture.  He elaborates, writing that, "The architect of a system, like the architect of a building, is the user's agent.  It is his job to bring professional and technical knowledge to bear in the unalloyed interest of the user."

Where I have struggled with decision boundaries the lines between the what and the how are blurred.  Brooks clearly highlights the need for distinct separation between architecture - the what, and implementation - the how.  A clear example with a clock is laid out in the book.  The architecture of a clock consists of the clock face and the hands.  Once a person learns this architecture, he can read the time from a church tower or a wristwatch equally easily.  The implementation, however, is invisible to the user.  It's everything behind the scenes that results in the user's collective experience.  But again, the conceptual integrity is paramount.  Consistency and the ability to uniformly interpret the design must be the highest priority.

Several months ago I had a light bulb moment.  It's really an unremarkable thought, but for me it was powerful.  Every architect should be a user experience architect.  Their mandate should be to create the ideal user experience.  I believe that is what Brooks is really saying.

Systems today are very complex.  More and more users want to combine functions from disparate systems to achieve greater efficiency and insights.  Where users desire combined functions, design integrity presents serious challenges.  Architects need to be out in front of these challenges designing the combined experience, and making sure it happens that way.  That's not the role I see most architects playing today.  Their focus is far more on implementation and lower level design.  And I think the reason for that is that architecture has become the "next logical step" for the talented implementer.  But what does the talented implementer excel at and enjoy?  And what does she focus on?  Boom, conflict.

In the world that Brooks describes in The Mythical Man Month architecture often requires fundamentally different sets of skills, and some collaborative overlap with implementation.  Granted, the role of the architect varies wildly based on the product.  For example, a user experience architect for a web-based fitness system might ideally be someone interested in fitness with expertise in web technologies and web design.  On the other hand, a user experience architect for a set of APIs for use by developers is likely far more technical, and would undoubtedly he himself be a seasoned developer.

Architecture and development require a rethink and a lot of clarification.  Blurring the lines between the two creates role conflict.  There are certainly cases where the lines are blurred and collaborative efforts between the roles result in excellent outcomes.  Even so, we must ask ourselves if we have properly separated architecture and implementation responsibilities.  Because if our architects are focusing on implementation, are we focusing enough on the user experience?  We must ensure we have the right focus on the overall user experience.  Conceptual integrity is paramount.