Rethinking the Talent Search

In a recent article in CIO Magazine (May 1, 2011), Kristen Lamoreaux, president and CEO of Lamoreaux Search, echoes the sentiments of the inimitable French Prime Minister Georges Clemenceau by suggesting that hiring and retention are too important to be left to HR.  She calls CIOs to action, recommending that they take the lead and get creative by cross-training existing employees, revitalizing employee referral programs, and sponsoring innovation contests, all with an eye toward keeping employees engaged and excited, and having a great recruiting story.

Ms. Lamoreaux does not suggest that the CIOs take matters into their own hands, but rather that they work in concert with HR toward a common goal. Yet among her many valuable points, she may have omitted an important and worthy consideration:

Outsourcing does not have to mean outside the country, or outside the company. It may simply mean outside of IT. And ‘existing employees’ doesn’t have to mean existing IT employees, particularly when it comes to application development. After all, some of the sharpest development resources in the organization do not work in IT.

Tactical developers bring valuable resources and motivation to the table. Their domain expertise, business knowledge and coding and problem-solving skills make them ideal candidates, not for recruiting so much as for inclusion. How? By lending some support to their efforts, by making technical training available, by granting a bit of access, by offering a seat at the applications discussion table, and by allowing them a little room to maneuver, the enlightened CIO can integrate tactical developers into the development cycle.

An enormous amount of added value stands to be gained, not just to the efficacy and useful lives of the applications themselves, but to the business ownership of an essential factor of production as well as to the IT-business partnership.

A business side manager who has realized the benefits of tactical development might echo both Lamoreaux and Clemenceau and say that application development, particularly tactical development, is much too important to be left to IT.

Dear Mr. CIO

I recently read of a disturbing trend: nationally, only 1.5% of incoming college freshmen major in Computer Science.  Incredulous, I reached out to a colleague at a local university. He confirmed that, at his institution, the figure was actually less than 1%.  Meanwhile, thousands of software development jobs are shipped overseas, to India and to Russia.

A future crisis is not difficult to imagine:  in a year or two, or five, who will write the code?  And by code I don’t mean the design of web pages or mobile device apps, I mean the business logic that actually drives our business processes (and inhibits them when it’s lacking).

I believe that business users understand their problems, and in most cases understand what’s needed to solve them.  If they also had at their disposal the resources to devise and implement solutions, then many of their problems would be short-lived. I characterize this problem solving activity as Tactical Development, that is, business users building software to address the many short-comings of today’s business systems, short-comings that keep them from realizing their goals.

Tactical Development is already going on to varying degrees in operational departments of businesses across America, and is often critical to the efficacy of business applications.  But business needs more and better tactical developers, and it needs to acknowledge the important role that tactical developers play and to support their efforts.

May I ask, sir, how supportive are you of the tactical developer?  Would you know one if you saw one?

Please consider.

Thanks,

TacDev1

Renegades, rogues and phantoms

During a recent slog through the tech slush pile (also known as a review of the literature), near the end of a rambling stew of corporate group-speak peppered with buzz-words (and oddly labeled ‘Thought Leadership’), I came across the following recommendation made by the CIO of a well known American company:

“If you want to position your organization to use technology to drive business value . . . then create and enforce clear IT policies throughout the organization to prevent adoption and utilization of renegade IT solutions that don’t support corporate IT strategy.”

Ah, yes. The renegade solution. The shadow system. The terms ‘renegade’, ‘rogue’, ‘phantom’ and ‘shadow’ conjure up images of cowboys, of pirates, of covert operatives on secret missions . . . wonderful grist for the Hollywood drama mill . . . but hardly an accurate depiction of the tactical developer.  Tactical Development is interesting and rewarding work, but it’s not nearly as intriguing or romantic as all that. And characterizing it in this way amounts to little more than propaganda.

If the user were fully satisfied with the product delivered by IT, or by its vendor partners, there would be no need for the shadow system or rogue solution, and there would be no need for the business to look elsewhere for answers to its operational problems.

If rogue solutions, purpose-built to solve business problems and entirely consistent with the business agenda, are out of line with IT strategy, then perhaps it’s the IT strategy that’s in need of some alignment.

The simple truth is that every shadow system is a working testament to the unwillingness or inability of IT to deliver. Every single one.

It’s also true that some of the best ideas for utilizing technology to further the business agenda come from the field, and if these gems don’t quite align with the corporate IT strategy, that’s no reason for the business not to pursue them.  They represent potential markets, or operational efficiencies, or opportunities for competitive advantage. The CIO who ignores them, or dismisses them, or actively attempts to ‘prevent their adoption or utilization’, may soon find herself out of the (business) loop.

Congrats to Attachmate

I recently received an email from Jeff Hawn, Chairman and CEO of the Attachmate Group, announcing Attachmate’s acquisition of Novell, Inc. That email caused me to pause and reminisce about my very productive and fruitful days as an Attachmate user.

In those days, we used Attachmate’s terminal emulation software as our primary means of connectivity with our mainframe business applications. That product came equipped with its own built-in scripting tool, a version of VBScript known as ExtraBasic.

Positioned as it was at the point through which most data passed, and at the fingertips of every user on every desktop, ExtraBasic offered considerable strategic and competitive advantage.  It was only a short time before we users realized how to leverage ExtraBasic to capitalize on the data flow.

Although our initial developments were simple macros and shortcuts, we eventually went a little crazy. To take advantage of ExtraBasic’s full COM support, we developed functionally rich DLLs, which together became the basis for full-featured and nearly standalone applications, interfaces with local data bases and lots of automated data entry. And oh, how we had our way!

I know more than a few seasoned tactical developers who cut their coding teeth on ExtraBasic, and proceeded from there to success on many other platforms. And we all came to understand and appreciate the value and the power of having our hands in the code.

Mr. Hawn and the folks at Attachmate are to be commended for putting development tools into the hands of operative users at the point of contact with their applications, and for launching or forwarding the careers of tactical developers everywhere.

From this tactical developer, thanks, and best of fortune in your future endeavors.

The Tactical Developer's Manifesto

The Problem of Incomplete Systems

               Computer software, and in particular business applications, often come up short on the promise to deliver full functionality and operational support to the end user. Whether monolithic stand-alone applications or broad enterprise-wide collections of nominally integrated modules, most suffer from gaps in functionality and control, discontinuities at integration points, partially implemented functions, and unresolved technical and operational issues. They are, from the perspective of the operational user, incomplete.

One Size Fits All

               No system can be all things to all people. Business practices vary among industries, and among enterprises within industries, and even among departments within enterprises, and all for legitimate business reasons. Changing business practices to match system capabilities is often not possible, or seriously conflicts with the business model either philosophically or practically.  The system should not be allowed to, but often does dictate business practice, especially by way of its own limitations.

Conceptual Disunity

               Large scale development is usually modularized along functional lines. The sheer scope and breadth of such projects are at odds with the need for adherence to cohesive design. Separate teams develop in parallel, but not necessarily in synch. Business partners’ products share only a tangential commonality. Only a high degree of discipline can prevent deviation from the conceptual unity of a master plan. Such departures result in the gaps and cracks that are the symptoms of incompleteness.

Sub-optimization

               Faced with an ever-shortening time line and a dwindling budget, a development team will package up any unfinished business and defer it to a future release. Or an implementation team will collect a miscellany of loose ends and call the bundle Phase II.  As a result, operational users are left to their own devices, to invent awkward, quick and dirty, and clerical solutions to system problems.  These work-arounds, intended only to be stop gap measures, often end up as part of standard operating procedure.

The Pursuit of Completeness through Tactical Development

               In a dynamic market economy, gaps in service represent niches to be filled and exploited by enterprising entrepreneurs, but in a business operation, such gaps only undermine efficacy and productivity, especially when there are forces at work that prevent or delay their resolution.

               Through Tactical Development, business users, in the pursuit of completeness and full functionality, design and implement solutions to their systems’ problems. Tactical developers aspire to actualize the system, that is, to close its gaps and realize its potential.  They strive to master the tools of the trade, well enough to leverage and even exploit them. They endeavor to extend the functionality of their systems and tools.  And they pursue each of these goals in the interests of system efficacy, business productivity, customer service and competitive advantage.

Actualization

               Actualization means bringing the system to its full intended purpose; bringing its full force and power to bear on the business problem; having it do all of the work that it was expected (or hoped) to do. Actualization means completing the system and thus maximizing its value and benefits to its operational users.

Mastering the Tools

               Business systems and tools (report writers, query languages, macros, scripts, spreadsheets and data bases) are often not well enough understood to be used to their fullest effect.  It takes a depth of knowledge and insight, a mastery of tools and techniques, to actualize the system, bring it to completeness and use it to full advantage.

Extending Functionality

               While the complete system will perform in the expected way, it may also lend itself to unexpected uses and applications.  Armed with a mastery of tools and techniques, the tactical developer will discover those applications and extend the functionality of the system to unintended but necessary and desirable ends or other creative uses.

Principles of Tactical Development

               The ultimate success of both the business system and its users depends on a commitment to certain core principles: that business practice cannot be confined to, or defined by, system capability; that the system can only reach its potential by continued and sustained development; that continued development of the system depends on the continued development of the skills of the developer; and that the developer and the end user share considerable common ground.

The system should not dictate business practice.

               The system should support the business effort, facilitate business actions and decision making, and even evolve into a competitive advantage for the business. It should also do most of the work and give people what they need to do their jobs. What it should not do is limit options or choices, hamper decision making, inhibit or discourage action or force people to work around it.

Good software evolves.

               The prescription for incompleteness and creeping obsolescence, as well as the means of extending functionality and exploiting fully the potential of a business system, is continuous improvement . . . persistent, incremental and continuous improvement.

               Continuous improvement is synonymous with the pursuit of quality. In fact, when a less-than-optimal solution is the best that can be achieved given the current resources or the current environment (technical, political, operational), it represents a platform from which an assault on a better solution can be launched.  Continuous improvement doesn’t follow a straight line, but it also doesn’t settle.

Practice Makes the Master

               Continuous improvement applies to skills as well as software; skills mature and evolve, too, and not so much by passive training as by active practice.  Writers write, and in doing so hone their skills as writers. So, too, do tactical developers pursue mastery of their tools by cobbling code, experimenting with techniques and building prototype solutions.

               The time when ‘computer literate’ implied a certain set of technical skills is long gone; today, literacy is simply insufficient, as is digital savvy. Fluency and eventual mastery are the means to solve problems and achieve goals, and the pursuit of command of language is an ongoing imperative.

The Closer, the Better

               The essence of tactical development is proximity; it takes place on the front lines, where application meets operation. The closer to the customer that development takes place, the more likely it will be guided by the business agenda, which is often informed by a higher authority (like fiduciary responsibility) or superior principles (such as GAAP). And, of course, motivation to solve the problem is highest close to the customer.

               Business users understand their problems, and in most cases understand what’s needed to solve them.  If they also had at their disposal the resources to devise and implement solutions, then the problems would be short-lived. Tactical development aims to bring the degree of separation between the person with the problem and the person with the solution down to zero or one. Ideally, the understanding of the problem and mastery of the tools to solve it reside in the same head, that is, the head of the tactical developer.

On Being a Tactical Developer

Successful tactical developers . . .

. . . have a bias for action. They resist excuses, take the initiative, and invest themselves.

. . . resist sub-optimization.  They don’t allow good to become good enough, or, if good enough is all that is possible today, adopt a policy of continuous improvement, and make it better tomorrow.

. . . bring their own tools and skills to the table. They seek mastery, and invest in themselves to attain it.

. . . are their own best customers; it is their self-interest, the fountainhead of progress, that motivated them to take on tactical development in the first place.

. . . don’t lose sight of their operational responsibility and accountability, often answering to a higher authority.

. . . don’t dismiss tried and true techniques and tools, realizing that sometimes the best understood and most effective solutions come from trailing edge technologies.

. . .are self-reliant. They know that in certain circumstances, one well-armed, well-trained and highly motivated individual can be more effective than an entire army.

… prefer the surgical solution to the overhaul, and the deftly placed modification to the Angus MacGyver workaround. They know that tools are not to be used haphazardly or indiscriminately, but thoughtfully, judiciously and in line with the conceptual design and structural integrity of both the system and the business model.

. . .are fault tolerant. Mistakes are barely tolerable, but making them is inevitable, especially during exploration, experimentation, development and prototyping, all of which lead to the discovery of solutions and new uses for existing tools. 

. . . are self-aware. They know that every system and tool imposes its own paradigm, and don’t get so caught up in them as to lose perspective or objectivity. They are the masters of tools, not slaves to them.

. . . take the high road. They know that there is little to be gained from criticizing the system, or antagonizing the people who sold it, installed it or run it.  They acknowledge that, although it is incomplete, the system still does 90 or 95 or 99% of the work.  They opt to use their powers to push, pull or coax the system closer to actualization, and for the benefit of all. 

Salutation

               If you’ve been in the trenches for a while and have the hard won knowledge to prove it, congratulations, you’ve earned the title.   If you’re new to tactical development, welcome, an adventure awaits you. Either way, trust your own judgment and have faith in your ability to solve the problem.  Your technical skills are the tools with which you can carve out your destiny.

Signed,

TacDev1