Monthly Archive: July 2019

A story from my first professional job search

In 1977 I decided to change careers, or more correctly I decided that after 18 months of working in a factory making screen printing inks, after trying and failing to land a job in Geology, it was time to swap a dead end job for a “proper job”, preferably one involving the continual deployment of intellect.
After consultations with a career counsellor, I applied for a job as a computer operator with a brewing company in London. I was advised that computing was “the next big thing”. Since I couldn’t even get in the door to get interviewed by any corporation looking to hire geologists, I decided that I had nothing to lose.
At an appointed time, I took part in a phone interview with a company recruiter.

I apparently passed the interview, because I was then summoned to an interview in London with the data centre manager for the brewing company.
Respendent in a newly-purchased suit that did not really fit me properly (having high shoulder points, a short torso and long legs, one of my mistakes that Iwould rectify later in his life as I actually learned something about clothing deportment), bright-eyed and bushy-tailed, I set off for London to attend the interview.
Underestimating journey times, he arrived 20 minutes late. Black mark. 
The interview with the data centre manager was going well, or so I thought. Then the interviewer set a trap.
“Do you consider yourself to be well-organized?” he asked. 
“Yes”, I replied blithely.
“Then why were you 20 minutes late for this interview?” He ostentatiously settled back in his seat and stared across the table at me.
I considered my options. One of the options was to bullshit, but my primitive DNA did not want to embrace it.
“I underestimated the journey time to this location” I said. “I learned something”.
The data centre manager smiled slightly. He nodded.

Then the line of questioning went in a different direction.
The following week, I received a phone call from the recruiter.
“The company does not want to hire you as a computer operator” he began. 
Uh oh, I thought, the lateness to the interview has doomed me.
“They do however want to hire you as a computer programmer”. 

The job was in a different location, and at a higher salary.
In due course, I arrived in London and took up the job as a programmer. A few months later, I actually met the data centre manager who had interviewed me. In a hallway conversation with him, he told me that he did not hold the lateness against me, because I had not attempted to bullshit my way out of the predicament. (They had also decided that I would be a better fit for the programmer job).

Life Lessons
1. Never bullshit. It catches up with you…sooner (probably) or later
2. You may not get the job you originally applied for. You might get a different job instead. You might even get a better job. 

Facebooktwittergoogle_plusredditpinterestlinkedinmail
Facebooktwittergoogle_pluslinkedinrssyoutube

Two great confusions in IT delivery

In my lengthy time in IT solution delivery, I consistently see two great confusions that, on many delivery and support teams, impede, prevent and degrade delivery quality.

The two confusions are a result of the inability of many people to conceptualize and abstract solution spaces.

  1. Process vs. Procedures

I consistently get asked to review or revise process documentation. When I examine the documentation, it rapidly becomes apparent that the documentation spends almost all of its time defining HOW an activity is performed, not WHAT activity is performed. In addition, the documentation does not specify any other essential activity that I would expect to find in a process definition such as Pre and Post-conditions, Inputs and Outputs etc.

Normally, when I point out that the document is really a procedure document, I am greeted with one or a combination of 2 responses:

  • The document is a process document, and what am I talking about (Confusion of process with procedure)
  • Why write a process document anyway? People just need to be told what to do (I want to cut corners)
2. Requirements vs. Design

I am often given documents that purport to be Requirements Definition documents, only to rapidly find that the document contains references to UI design, report design, operational procedures etc.

None of those artifacts and content items are anything to do with Requirements. They are the implementation of the requirements. When I try to explain this, the most common response I get is “that is what the client wants”. It then becomes apparent that, in most cases, the delivery team are order takers for the client, so if the client says “I want you to create a document that supposedly covers everything we need to know”, they obediently create a jack-of-all-trades-master-of-none document that is not only difficult to read, but also fails to properly elicit Requirements, jumping straight into solution design.

So What Are the Causes?

In both of the above scenarios, there are two underlying drivers for the mindset that led to the creation of mutant many-headed documents that are not what they purport to be.

  1. Inability to conceptualize and abstract

This is a classic blind spot. Like critical thinking, abstraction and conceptualization are “soft” skills that are often overlooked, in the same way that people management skills are often overlooked when promoting technical contributors to leadership roles. They are not easy to teach, and then it takes time for people to develop and hone them. (DISCLOSURE – I learned on the job as i became a business analyst).

2. Impatience to get to “working code”

I once became involved in a rather spiky dispute with a Project Manager on a new development project. From the very beginning of the project, it was clear that the PM was not a fan of Analysis at all. He was constantly pushing me to end Analysis and move to Design. When I moved to Design, he was pushing me to move to coding. In the process he engaged in some rather juvenile sniping, including quips like “you clearly don’t want to actually do any work on this project”.

The real underlying issue, as I soon realized, was that he saw the only useful deliverable of the project as code that appears to work. Nothing else mattered a damn as far as he was concerned. I never determined whether this was a result of his client stakeholders having the view that code was all that matters, since he never let me spend enough time with the client to form a view. He was definitely a controller.

This viewpoint, I have realized, is very common in a lot of IT delivery contexts. “Screw Analysis and Design, let’s just code” or “they’re paying for code, not documents” are common attitudes, made worse by the move to Agile and DevOps, which appears to many IT teams to eliminate All The Upfront Shit that they hate. Like requirements elicitation, analysis and planning. Many coders hate anything that gets in the way of coding.

The mindset of “let’s just code” may make developers happy, but it ensures that the ceiling on delivery quality is limited, since failure to understand the scope and depth of solution domains is precisely the sort of failure that causes projects to go way beyond budget and timescale, as the terrible truth dawns “shit, this is much more complicated than we thought”.

So What Do We Do?

Training in abstraction and conceptualization is not common, especially in the business analysis domain, which is where Requirements elicitation resides in a lot of sequential development organizations. Business Analysts are often selected on the basis that they are solution SMEs, not necessarily based on actual analysis skills. Process vs. Procedure is a fundamental conceptual lens that ought to be taught also. However, it also falls into the same blind spot as Requirements vs. Design, for the same reasons.

Training in these skills forms part of a process-focussed delivery organization, which values WHAT is done as much as HOW it is done. This is not common, in an era where the first response to cost-cutting demands is often the axing of process and QA teams, on the grounds that the projects can do all of the work. This usually leads to a long slow deterioration in delivery quality, which then requires at least as much time to repair.

Get it right upfront, by valuing processes and the skill of conceptualization, and you will be rewarded in the medium-term. You will also be able to impress the client. Clients tend to respond to IT vendors who have clearly done their analysis homework, as long as it is well-presented.

Facebooktwittergoogle_plusredditpinterestlinkedinmail
Facebooktwittergoogle_pluslinkedinrssyoutube
Healthprose pharmacy reviews