From the Ask Tom mailbag –
Question:
I understand the concept of Time Span as it relates to a manufacturing environment, based on the the examples you used in your workshop. Our company is a software company, we write code, software as a service based in the cloud. Having trouble translating Time Span to this model.
Response:
The first piece of translation is to calibrate your production activity. In a manufacturing environment, production (individual direct output) is most often calibrated as a Stratum I role (Time Span tasks – 1 day-3 months).
Software programming (production of software code) requires a higher level of capability. Task assignments to write code that produce specific software functions, appear to fall within a short Time Span. A coding project might take two weeks to construct, code, de-bug, and test. Seems like a short Time Span task. But in the role of a programmer, the longest Time Span task (which calibrates the complexity of the role) may have less to do with programming and more to do with learning.
I often ask programmers, if you stopped learning about new routines, new programming objects, how long would your code be effectively written, current with the state of the art. The joking response is five minutes, but the real answer is somewhere between three months and one year. It’s not that their published code would stop working, but there are more efficient routines and ways of manipulating code invented every day. Time frame to obsolescence is somewhere between three months and one year.
A good example of this is the move to HTML 5. HTML 5 solves the current dilemma in the way video is handled on the internet, particularly with mobile computing, in a dispute between Apple and Adobe. Adobe would like all video to be handled using its Flash player, Apple says HTML 5 makes the flash player obsolete (and refuses to support it in their iPad and iPhone products). It will take some time for adoption of HTML 5, but programmers are having to learn its new routines. A year from now, programming code that ignores HTML 5 will still work, but fall short of generally accepted programming standards. So, the longest Time Span task, for a programmer, is not necessarily producing code, but continuously learning about new developments in code construction, requires minimum Stratum II capability (cumulative processing).
But writing code is not the whole story. A simple stand-alone function is useless. Software typically contains hundreds of functions collected together in a system that creates value for the user. Stringing those functions together requires Stratum III capability, a serial state of thinking. So, you may have programmers, but somewhere in your personnel mix, you will have a manager, also likely a skilled programmer, who decides how the functions are put together.
But a software system is not the whole story. Software systems, to be truly valuable are integrated with other software systems, with interoperability hooks, not only among internal software systems, but external software systems, like Facebook and Twitter. This integration will likely require a manager with Stratum IV (parallel processing) capability.
All of this discussion centers around production. Software companies have other disciplines which must also be integrated, like sales and customer service. Effectively integrating those systems into the mix requires Stratum IV and Stratum V capability.
Levels of work
Stratum IV – Parallel processing
Stratum III – Serial processing
Stratum II – Cumulative processing
Stratum I – Declarative processing
Tom,
From the software development perspective, virtually every software developer requires stratum III thinking – but not relative to his own production chain. This is true because ALL software paradigms evolve from cause and effect abstractions.
Software professionals are trained to use abstractions to model business problems. Their functions are usually complex and abstract representations of a business flow, or data about business processes. The cause and effect relationships in business processes are relatively obvious to software developers – however – they typically do not see their own activity as a business process.
So while we are required to exhibit stratum III thinking about the problem domain that we are working in – we often have only stratum I or II thinking about our own problem domain.
The retooling – that you describe relative to HTML 5, or any new programming paradigm – is not tremendously different than a machinist learning to use a different piece of equipment – the underlying principles don’t change dramatically, but the “buttons I push” are completely different. In most shops, that re-tooling is not as rapid or frequent as you might expect – but follows a more leapfrog pattern – skipping several generations at a time, because of the cost of retooling knowledge workers.
The individuals who exhibits stratum 3 and above capabilities with respect to their own problem domain – are focused on staying relatively current on tooling – usually using their own time and money to do so. These individuals are likely to end up in roles as software architects, or project managers or other technical leadership roles.
Learning to manage software development organizations requires applying the principles of stratum 3 and 4 thinking that we developed as programmers understanding our [customer facing] problem domain – to the domain of software development as a problem. It is amazing to me how difficult this is for many, many software professionals.
I loved reading the related “Mental Processing” piece. That was highly informative for me.
Thank you for this one. For some time I’ve been wondering how the concept of Time Span might be applied to work with less tangible output. This really helped me see the concept in a new way.
Hey Tom, Great post, as always.
From a software development perspective, the term “serial thinking” sounds a little off, especially in the field of the more powerful Object Oriented programming languages. For me it evokes an image of things strung together in a neat line. It might be better described as collecting a whole set of objects with interdependencies and plugging them together in a spiderweb of connections with each other. Rarely do the objects work with each other in a straight line.
In my experience, software development is most effective when the design of a software system is sort of “sketched out on paper” first by a Software Architect (Stratum III) who builds the overall vision with Use Cases and such to describe the inner workings. Then the code itself is produced by people at the Programmer/Analyst (Stratum II) and Programmer (Stratum I) levels. They are generally given an object to build, with the inputs and outputs of that object dictated to them because that’s what the other objects in the system will be expecting when they pass information back and forth across those connections, so to speak.
Other than that little nuance, your description was bang-on, as far as I’m concerned! 🙂
Cheers,
Kevin
Kevin, Thanks for the insight on how these principles work in highly technical disciplines, specifically programming, which, in my mind is the most difficult discipline for managers to get their heads wrapped around. For most, it’s a magic black box operated by wizards and gnomes. -TF