Figure out what leadership means
- to you
- to your team
- to your management
- to your company
- to your clients
(Not necessarily in this order)
Once you reconcile all these without compromise thats a career fulfilled.
Figure out what leadership means
(Not necessarily in this order)
Once you reconcile all these without compromise thats a career fulfilled.
Abstraction is a recurring theme in my work.
While it is second nature for some, most folks have too strong of a footing in concrete 😀
Everybody can do abstraction. It is a skill, it is a mental muscle that needs training. Applying it regularly to situations and using it purposefully is a different matter. A short, visual explanation on what I mean by applying abstraction purposefully.
The irony of explaining abstraction in an abstract manner is not lost on me. Future posts will include more concrete and practical points.
The story goes…
Business X has been using a software package for the last 20+ years to perform a critical, maybe even the most critical, function of the business.
20+ years ago this package used to be an off the shelf, install on an office PC, double-click to launch in Windows type of application. It probably looked rubbish but had a menu with 3+ levels to navigate dozens of screens with 20+ fields each to manipulate. There were only a few people that could learn and knew how to use it for some very specific tasks.
10+ years ago the vendor of that package found it easier – meaning no install, no update, no office PC – to put the same software on a bunch of servers and let users access it remotely (RDP).
Today many of these applications are still running businesses, mostly because they are cheap or because over time they became a monopoly.
Innovation at these vendors, and the businesses using them, would have stopped, if it wasn’t for a new movement.
Reluctantly, the vendors slowly added a new type of access – API – to their packages.
These dumb API-s would often look like an XML version of the screens they represent.
Business X realised they have a new option.
Rather than paying for an expensive 20+ years old application running remotely they can pay a lower fee for accessing the API.
Projects are in abundance making the transition – under the banner of Digital Transformation – from remote desktop Windows applications to web based, API led solutions.
There are so many ways these transformation projects go up in smoke.
One is where business X insists on rebuilding the same screen flow from the old desktop application.
Is this Digital Transformation? No.
Maybe modernisation? Hardly.
It is simply cost avoidance.
Tech Stack Bingo is when a business has a portfolio of, seemingly random, tech they acquired (sold to) over the years.
As the projects roll in, the needs mark a match with an existing tech.
The closer the match the better. They win if no tech lingers on without a project and nothing comes in needing a new tech – BINGO.
Some sorry businesses try to cheat their way by forcing some close enough tech on the project.
This is where disaster strikes. It happens more often than one would expect, for example:
The story goes…
The program – has lofty goals for transforming the way to do business, to catch up with challenger businesses (have not kept up with customer expectations).
The first few projects – identified and added to the project portfolio plan for the year.
As for the rest – there is no budget (only planning for the year), or no appetite (the sponsor may not be around next year).
The very first project – it must respond to the immediate problem (after all that’s how the program got the buy-in).
It must do that quickly – 1 month – therefore looking for a tactical solution (calling it MVP to make it sound less desperate).
The chosen technology/product must be future-proof and fit the strategic direction (cannot justify spend on throw away).
6 months later…
What has just happened?…
If tactical is aligned with strategic, it would not be called tactical, it would be called strategic.
The strategic choice product/technology may not be able to demonstrate value add for the entire program in a tactical (also the first) project.
The same features and functions for building strategic capabilities rarely, if ever, meet the criteria and constraints of legacy in a tactical build.
The person holding the P&L and sponsoring the project needs new, improved capabilities for the business to create value. A suitable IT solution and project could deliver the needs.
There is no interest in architecture, performance, documentation, choice of platform. It just needs to happen.
The team of individual contributors in delivery just want to get their code into production as fast as possible. This is particularly true for contractors and offshore delivery centres with economical rates measured on the speed of delivery.
They too have little interest in architecture, performance, documentation, platform.
Folks in the middle who are tasked to make it all sustainable – so the next project does not cost an arm and a leg, and does not take a lifetime to complete – are in an impossible position.
They do care about architecture, performance, documentation, platform, and more.
Many businesses have been practicing decades of waterfall shaped delivery. The projects are typically sized between 6 to 12 months, while parent programs can run much longer. A sizeable work upfront on requirements is rapidly followed by delivering, churning out code up to final delivery into production.
Meanwhile, governance bodies and design authorities are desperately trying to wedge themselves in between stages to provide some oversight and much needed guidance.
Now that everyone and their dog is pitching to be agile, a torrent of anti-patterns emerge from waterfalling into sprints expedited by doing away with plan, design and documentation.
Practically, entirely removing the opportunity for oversight and to work out sustainable solutions.
A worthy read on the struggles of business-IT alignment: Don’t become an Enterprise/IT Architect… by Gerben Wierda
What is the measure of an outcome in an organisation?
Is it a tick in the box?
Is it a business relevant metric?
Metrics are too often mistaken for a tick in the box.
Metrics are hard, measuring them is even harder.
Moving the needle on a metric that counts is an achievement.
Recognising people, teams, divisions, entire organisations for results is leadership.
A tick in the box has never delivered any real value.
A tick in a box has never transformed a business.
What kind of culture does giving credit for a ticking the box drive?
If your daily work involves ticking boxes, send a link to this article to your superiors.