Ideas, Experiences & thoughts worth Sharing!!!
Category Archives: Effectiveness
Ok, I am coming back into this after rather a very long time. I have been thinking about starting to write for a while now, as it really helps you think and get clear on your head if you ask me. I do write a bit as part of my job, although mostly technical and content specific and this freedom of being able to write on anything is even more satisfying.
To the topic now, I was having this conversation this morning with one of my colleague and he asked me couple of interesting questions.
- What can you stop doing? (in the context of your job – to maximize time)
- What the best value an Architect can add?
While they both seem unrelated, there is a lot of synergy between these questions and they shape what we do on our day to day job. In my view if you answer question 2, you are answering question 1 regardless.
As an Architect (read as Solution, Data and in general IT Architect), the biggest value one can add is defining the need. The business (from top CxOs to bottom middle managers) generally comes to you as wish list. i.e. what they “think” as the requirement that will satisfy all their needs or solve their current problems. But if you are really good and able to understand the essence of the “ask or wish” in the context of the organisation, its business, underlying constraints (IT, operational, cost, risk, etc) – [see through the clutter and complexity] and able to come up with actual “need“, then you have already solved 80% of the problem. And in my nearly 20 years of experience, trust me, the need is usually very different or much smaller than the original ask.
This I believe is the biggest value the architects can add. So what you need to stop doing is taking the business wish list as a Gospel and turn the world upside down to solve it. As once you start on the wrong foot, the chances are you are multiplying the waste factor from then on.
So how do you know you have understood the problem and you have established the need. An Interesting thought that can support this here, – don’t know the source but I do remember and made a lot of impact in my life is “if you understand the problem, you should be able to articulate it in simple language under 30 seconds to anyone, failing that means you don’t any idea about what you are talking about”.
This however requires a holistic knowledge of business, (i.e. domain knowledge, how business works and its people), information being processed and churned in & out (data) and the technology in place to support and scale the above. And this comes with experience.
Some of the other techniques you can use to filter down waste from your downstream activities, you can adopt methodologies like critical chain (especially the network diagram/logic that maps the network activities), agile or recruit a bloody good project manager or scrum master who will ensure the effective usage of time & resources once he has been given the clear, concise business need and what need to be delivered.
It is a very short blog and more like rant rather!
Nothing gets me more annoyed than people answering “It depends…”
Especially when asked about what is your organization reference architecture? Associated principles, guidelines, recommendations, etc. To me it is one of the laziest answers and having no foresight whatsoever.
To start with, it depends on what? I mean what are the variables that control the decision making process? What are their ranges? What are the constraints that could influence these decisions? Considering the underlying infrastructure, have we done any benchmarking exercise and have recommendations so that not every project ends up doing the same thing over and over again? What are the limits of current systems, framework & infrastructure? How do you govern architecture compliance if all you have is “It depends” – especially in a multiple vendor scenario?
Some of the key problems in leaving decisions to individual projects (otherwise called “it depends” operating mode) are,
- Deviations from the organization level architecture strategy.
- The quality & effectiveness of a solution is left to the competency of an individual/team, despite having an architecture practice (or) capability.
- The by-product of the above two would be “Technical Debt”.
- Wasted effort in repeating items and worst still end up with different solutions each time
So what can you do?
No individual organization will need to solve endless spectrum of problems (to leave the solution until the problem arises). Depending the organization business, domain, capabilities, products, infrastructure, etc., the spectrum could well be defined from various dimensions. Some of the dimensions / variables could be,
- CRUD transaction volumes (low, med, high – sycn/async – consistency rqmt, etc),
- Rule engine ,
- Calculation engine,
- Integration models (p2p, pub/sub, req/response),
- User Interface models (web, mobile, desktop, apps, etc.)
- MI capture/report
- , could go on…
And based their values, and current capabilities status, have recommended solutions (templates/patterns/POCs) readily available, so that an individual projects could simply adopt them rather trying reinvent the wheel every time and worst still end up with completely different / inconsistent solution to a single problem.
One may question the need to solve or have a solution for a problem when it isn’t even arisen yet. That is the investment you make in order not to end up with the longer term problems stated above. The level of detail one need to go could be controlled depending on the likelihood of occurrence of a particular problem. For e.g. a small scale retail organization need not go all the way down to having a fully working Proof of concept for high volume, real-time information management. But could just define parameters on what would require such a solution so that when a project team encounters a requirement they know they need to build something new.
Over the years, I have had the opportunity to work with various organisation & stakeholders. I was lucky to have worked with some of the best and also the worst. You might think what one might gain when working with worst. It actually helps you identify the distinguishing factors that makes an organisation to what they are. If one has only worked and associated with best in class, streamlined organisation, it would be impossible to visualise what is missing and what were the reasons for some of the practices being followed. Well you might get in the long run, but having an opportunity first hand makes it huge learning and the ability to see how it thrives on challenges and issues while the other disintegrates and requires a reboot.
In my experience while it is clear that the senior leaders (Directors, VPs, CxOs) are key to set the strategies and cascade the organisation vision, mission into practical, achievable targets to the departments, a lot of the responsibility still lies in how effective the middle management actually are in implementing them. By middle management, I mean the department heads and program/project manages and how effective they are in terms of understanding the short & long term goals, setting out plans and utilising all available resources. Also they play major role in identifying and building new organisation capabilities in order to meet the objectives.
But in some of the organisation I have seen, the middle management ineffectiveness were apparent and although the impacts may not be visible at individual departments, when looking at the organisation as whole, it is proving to be disastrous. The ineffectiveness itself could be due to number of reasons and cannot all be attributed to the competency of the individuals who is playing the role. That is a separate subject and we can discuss that in another post. This post is specifically focuses on what the symptoms are to identify such scenario and likely impact it may create.
These are some of the symptoms to identify ineffectiveness.
Find a responsibility and hide behind
As the name suggests, they are happy doing routine jobs, they actively look for routine & mundane jobs and take ownership of doing them. For e.g.
- Filling forms & doing day-to-day paperwork required for things like on boarding new staff, granting & revoking access permissions, etc
- Taking ownership of circulating auto generated reports.
- Providing approvals for day to day tasks.
While some of these are essential, the main difference is in trying to hold onto them rather than looking at the long run and proactively automate or delegate them. If you can sense a bit of insecurity in these communications it is a good sign that the role is not adding required value to the organisation.
No Initiatives / Innovation
There is unlikely to be request for additional budget for any new initiatives and innovation will be close to NIL for individual department. Even if there are few, it might be just to meet the objectives rather than a whole hearted passionate effort.
Ego & Power struggle
There is likely to be a bit of tension between department leads resulting in lack of co-operation between them. The lack of co-operation will show in terms of pouncing on others mistakes while playing down (or quite) own mistakes, making very strict and impractical demands on other departments to meet own objectives, etc.
Conflict of interest
Individual’s job security will take precedence over organisation objectives / interests. This will result in lot of the effort going in showing their importance rather than actually helping organisation. For e.g. a potential error which could have been caught earlier would be left too late to get the maximum exposure before finding them out.
Unable to get the best out of Vendors
In situation like these the 3rd party vendors will usually hold upper hand rather than in-house department leads. The business (stakeholders) seem to have more trust in vendors rather than their own departments and its leads. This impacts the organisation very badly as it is unlikely to get the value out of the spending on vendors.
Poor or No decision support system
When there is a need for some of these departments work together to meeting an immediate & urgent business need, there is likely to be chaos. For e.g. if the business needs a report which requires provisioning a new server (IT), installing applications which are maintained by separate departments and creating and releasing a new report, this will likely result in,
- Out of control emails with most of the executives/stakeholders in the distribution list for every step of the journey.
- Dependency on key individual within the department to run the show.
- Involvement of senior leaders required to sort out basic issues. (statements like “I am happy to do it, provided x is happy to approve” – this is a killer. As a department head, one is expected to be expert and understanding impact of his actions and also the overall organisation objectives, and be able to make a judgement. When this fails, the obvious question raises need for the role itself?).
This is not a complete list but shows some of the dangerous symptoms and its effects. It is up to the senior leaders to look for these and align their organisations effectively in order to eradicate the root causes for these. I will try to list out some of the root causes for these and recommend corrective actions in subsequent posts.