I’m no expert. There. I said it.
I’m not a developer, never will be, don’t want to be, but I have been around software projects for long enough to have absorbed plenty of information about how good software projects succeed and why bad software projects fail.
To me it seems that one word, and one word alone can have the single biggest impact on the success or failure of a software project – diligence.
[so we’re on the same page…]
Diligence is when [sic] “work is carried out in a careful and persistent manner” and in the context of software development and software development projects is probably most commonly understood to be present in the application of good patterns, practices and processes, or absent when such project elements are missing.
One of the great privileges of being a consultant is being able to dip in and out of client environments and witnessing, first hand, how organisations and organisational elements function giving the opportunity to be constantly filtering through the good and bad practices I see, growing in experience all the while.
I’ve recently been involved in a project which is exhibiting some really interesting “proof” around my so named “diligence theory” – showing failing where diligence is lacking and success where levels of diligence are high.
What is strikingly apparent from the outset at this particular client is that there is no consistency to how diligence is applied across the tiers of hierarchy, and how regardless of documented processes or best practice the application of diligence is, in most cases, down to the individual.
Key senior members of staff are exhibiting high levels of diligence in the context of providing wide-ranging macro thinking providing vision, options and the critical interface between the business “client” and the applications teams. The duty of care that these engaged solution owners have to the user community is being resourcefully and diligently managed with a great “all bets are on” mindset when discussions are in the conceptual or abstract space.
Conversely, other senior members of the team consistently exhibit traits and quirks often believed to be associated with technical folks including; inflexibility, (seemingly) chaotic thinking, empire building and negativity; all adding up to user community frustration which then orbits back to the tech group resulting in a “screw ’em!” attitude and reduced levels of caring thus pushing diligence onto the backseat.
This cyclical (as it most certainly is) problem seems to be a major cause of tech group/ user community friction with feedback suggesting that the users feel that the tech group “don’t care about our problems or needs except when it suits them” – this is probably as clear a proof that we could hope for of the value of diligence (in the context of people) in a software project.
Interestingly, the senior team members that exhibit this reduced diligence behaviour don’t seem to do so unilaterally – you can’t build that empire if you’re not (at least seemingly) caring about your team, right?!
I’m being a little fast and loose with how I define ‘middle management’ as what I am really defining is the ‘senior worker bee’ role (see below) which captures a raft of folks involved in team supervision or ‘senior’ technical roles.
The key exhibited behaviour in this group is probably most typical of ‘normal’ human behaviour; these folk are diligent if it suits or stands to benefit them. I’m not going to be as arbitrary as to assume that ‘benefit’ is solely selfish within this group. The smarter members of this group understand the type of benefit that only comes from ‘paying it forward’; those times where being diligent brings benefits in the future (decreased workload, kudos, increased productivity resulting from esprit de corps, etc.). The other members of this group simply behave as leaders who should not be leaders or worker bees in the wrong place at the wrong time.
Below the middle management tier, the exhibited behaviour is even more demarked with a wide range of attitudes from conscientious diligence all the way through to “beyond caring” with almost every possible interim step covered in one form or another.
Interestingly, there seems to be little correlation between age, experience, seniority or gender and how diligent the team members are. It’s seemingly down to either conscious personal choice; deliberate choices to be either slapdash, belligerent, combative, slack and whiny OR to be careful, cautious and methodical, or down to sub-conscious personality traits that drive individuals down diligent or slapdash routes because it’s in their nature, hard-wired into their approach.
It is, on most occasions, surprisingly simple to work out which camp each team member sleeps in.
The folks making the conscious decision to not exhibit diligence do so to their timetable, yo-yo’ing between states as they see fit. Sometimes delivering excellent output with a high level of care and attention, other times producing low quality work that has clearly been thrown together with little care or caution.
Those who (almost) permanently produce high quality work apply diligent thinking across their entire approach, often being those that produce the most written output, interact more frequently with their peers and mentors and enjoy interacting with the internal customer.
I’m not suggesting anything new here. No thesis bound postulation of a new theory of human interaction, I’m just noting my observations as I want to observe and learn from the exhibited behaviours I see in order to become better at what I do.
will I succeed? Who knows, but it will sure be interesting doing some people watching on the way…
More to follow…