Thoughts: Bridging the Customer / Engineer Gap

In smaller environments, the biggest obstacle to completing a successful software project is resources.  Budget. Time. Materials.  And by "smaller", I mean environments where there's no need (or desire) for layers of bureacracy between those that ask for things and those that provide them.  I'm aware of all sorts of technical definitions for "small" and "large" in the business world, but let's face it: they are all subjective and contextual.

Having spent quite a few years in "small", "medium" and "large" environments, I have been lucky enough to have experienced the challenges and benefits each entails.  To break it down in tabular style…

	Small	Medium	Large
Biggest Challenge	Resources	Direction	Disconnect
Team Size	Usually Individual	2 or 3 at most	May be a department
Communication	Face-to-Face	Mixed	E-mail, MS-Project, ERP system, Visio, IM, WebEx, etc.
Frameworks	Industry Trends	Best Practices	Procedural and Instruction based

I could go on, but you get the point.  And to be fair, it's not just a series of burdens brought forth by the software folks.  No.  It's also often equally matched by the customer or "user" side.  It's not uncommon in the "large" environments to have customer "points of contact" (POC) or "customer lead", etc.  They may in turn employ a hidden team of "power users" that help steer the requirements, do the testing and provide the final feedback.  All of that being channeled (usually) through the POC.  I tend to see this arrangement as a match-up of two pyramids with link between the two pinnacles.  Then again, my head is pointy anyway, so that could be affecting my view.

The Handicaps of the Extremes

Whatever else may come into play, from what I've seen, the single biggest handicap to each of the "small" and "large" environments is almost a direct "fit" for the other.  Where one excels, it is the answer to the other's failing.

For "large" environments, the problem is disconnect between participants in the project.  From developers, to team leads, to project managers, to liaisons on both sides, to POC's to power users, to customer management, and (on both sides) back to the financial stakeholders.  The comments you may likely hear from any one of those at any given time may be something like "I haven't had time to do my job *AND* keep ___ informed.".  With the current economic downturn, and reduced or capped staffing levels, this is only becoming more common.

For "small" environments, the problem is often a lack of planning for the "long haul".  Because projects are often staffed to the bare minimum, even single people doing each job function, there is a tendency to focus on the "hear and now".  The drawback is not thinking out ahead to the next version, next quarter, or next year.  Things may suffer such as documentation, code modularity, refactoring, and general optimization for future extensibility.

The best comparison might be the Tortoise and the Hare.  The large environment is often MUCH slower to execute than the small environment.  The small environment is often much shorter on long-term planning.  One builds a product that will likely last and be more stable and reliable at 1.0.  Yet the other oftens gets 1.0 out the door faster, and even with more defects, is more capable of making on-the-fly fixes to improve stability.  However, the challenges remain, and need to be addressed.

The Speed Bumps

The biggest barrier to all of this is the entrenched views people have.  It's pervasive regardless of rank.  Managers, group leaders, and workers alike, all tend to have persistent, stubborn views about the other side.  Teams in larger environments often scoff at the methods of smaller environments as "wild west show" or "shooting from the hip".  Yet smaller teams often scoff at the methods of larger environments as "stodgy", "boring", "slow" and "inflexible".

A closed mind is not unique to just one side of this either.  A small environment usually means being hostage to one developer with one view of how problems can be solved.  A large environment usually means many more people, but no less flexible in their approach to solving problems.  One is personal.  The other institutional.  Same problem.

They're both right.  And they're both wrong.  There are aspects to each "side" that can be of incredible use to the other.  All it takes is a willingness to explore them, and a rigorous communications path throughout to foster it going forward.

Solutions

Believe it or not, the solutions to each of these challenges is rather simple:

For the small environment projects, employ someone familiar with large scale projects. Make sure they hold a substantial position in the project team.  They must have significant input and steering capacity.  If they only have power to offer advice it won't work.  Even if you can't afford to hire someone on full time, at least try on a consultant.  They don't have to write any code or prepare any documentation. Just pick their mind for ideas.  Time is valuable, but ideas are way more valuable.

For the large environment projects, employ someone in each functional entity who is familiar with small environment projects.  They too must have significant input and steering capability.  They should also be encouraged to meet separately from the legacy team members so that they can compare experiences and share ideas.  Legacy team members are often too burdened with policy and procedural concerns to free their minds to focus purely on the project.  This is also important because no two of these former small-team folks will have the same small team experiences.  It's important to foster and maintain their flexibility, and creativity to shore up the rigid policy-driven thinking already in place.  Blending them in is usually a bad mistake that wastes the potential benefits they could deliver.  And as with the comment in the preceding paragraph: consider a consultant to help spark new ideas and provide fresh insight into how you could shake things up.

Think of how Apple and Google differ, in every way, from IBM and Microsoft.  From the products and services they pursue, to their marketing, to the ways they treat their employees.  But this is way more than simply looking at well-known companies and how they're perceived.  This is about *you* taking a different approach to how you view and tackle projects.  If you're immersed in one of these worlds, it can be very difficult to think from the other side, or "think outside of the box" (your box).  But you can at least try.  Don't give in to the usual office joking about the "other" side of business strategy.

The Gains

If you're working in a small environment, you stand to gain efficiency, stability, reliability, extensibility and as a result, reduce support costs, and gaining more competitive advantages by just becoming more efficient and proficient.  Taking on new projects becomes less complex and less expensive as well.  You gain productivity.

If you're working in a large environment, you stand to gain flexibility, innovation, creativity, and spark enthusiasm in an otherwise drab landscape.  Let's face it, following policies and procedures ad nauseum tends to kill enthusiasm for the task at hand.  It's an assembly line perspective.  It tends to bleed creativity and innovation.  When you feed enthusiasm, you also feed productivity.  Your products not only absorb new ideas and new capabilities from the new freedom of thought, you gain the added force of an energized staff.  You gain productivity.

Do you see the common point?

I may be taking some time off from writing on the blog for a while.  If you have any thoughts or comments, please post a comment.  Thanks for reading!