I often go into new and different organizations that have new and different tech stacks. Once I finally get my arms around unstructured data analysis tools like Splunk, it is probably time to change, to go work with a rails shop that is using Amazon Web Services (AWS) combined with docker to create build-deploy pipelines that use CircleCI that …
It’s all fine, don’t worry about me. I can pick up a yeoman’s understanding of the technology soon enough. The problem is the difference between an understanding good enough to help the business and good enough to be a practitioner. I tend to ask how the tool works, to see more than a demo of a build-deploy run, but how to actually create and maintain a new project.
Sometimes people are surprised by the question, and say “it’s super easy, you just do it” without actually showing me anything.
For example, I once saw a fitnesse demonstration that had a bunch of code functions, inputs, and expected results. Run the application and it reaches down into the Software Under Test, calling the code function, comparing actual to expected.
But how did it work?
Someone had to actually write some code to connect the two systems, right?
Asking these sorts of questions I got familiar answers, such as “it’s super easy.” Eventually I realize the person does not know how to do the work, as it has been done by someone else. That means, to the person who benefits, it appears to be free.
Yet to get started, to get set-up, the system needs a prime mover. This prime mover will do work that is often glossed over, yet necessary for the organization to advance. I call this apparent contradiction the Charles effect.
A few years ago I was on a long-term contract, far from home. I often worked late or stayed later than most, sometimes billable, sometimes not, as I was allowed to use the internet and it was more sociable than my empty hotel room.
As I stayed late I saw another long-term employee, named Charles, who was slowly converting the build system from TFS to Jenkins at night. Charles did not have permission for this. This was a side, part-time project he was doing at night. Each TFS sub-project needed to be ported, the build steps repeated and changed slightly. Jenkins needed to know what failure looked like and how to run the automated checks.
It was not an easy task.
Charles had real progress after perhaps a month at night, four nights a week, two hours per night – and was probably done in three or four months.
A few weeks later, the company CIO was in town, and one of the technical staff members was keen to show off Jenkins. “Look”, he said “See the pie-charts, the data, the build results – it kicks off for every checkin!”
“Impressive” said the CIO. “How does it do that? How long did it take to set up?”
“No trouble at all” said the programmer. “It’s super-easy.”
No trouble at all?
This, I am convinced, is how innovation is done in the United States. Except for a few enlightened laboratories, the ideas are cranked out by the Charles’s of the world, right up until they are good enough for anyone to grab – then they are co-opted by everyone and their cousin.
The story here isn’t sad. Charles got to work on some real cool software that was not just cranking out a new column in the report. The team really did appreciate him. The work effort, however was invisible. It seemed free.
If you are a manager, I hope you are asking yourself how to attract and reward people that will do this kind of work. Google’s famed twenty percent time comes to mind.
If you are a technical contributor, the picture may be a little more scary. You might not have the big idea, or be willing to “just do it” on your own. That’s okay. Find your Charles, figure out what he is working on, buy him a beer, and make sure he is appreciated. Along the way, figure out how his mind works, and push yourself to try something new and different this year. Start with a little time at night, just a bit, here and there. If nothing else, consider a code generator for your most boring tasks.
I’ll say it again: This kind of worker is responsible for most of the real technical innovation on software projects, which is invisible to traditional management systems. Managers, find it and reward it. Technical staff – figure out how to get more of it out of your team.
But don’t ever, ever take Charles for granted. The same frameworks that are super-easy to use are usually not that easy to get started.