Any technology business has to work out from a tech standpoint if
they want to be an innovator or follower in the IT industry. It isn't always a simple choice for technology leaders, some companies that become followers will
argue they have to do due diligence, they are hindered by internal bureaucracy, have the pressure of daily deliverables to worry about, so they can't afford
to be too "bleeding edge" all the time. The more pertinent question
is can they afford not to be leading the way?
Technology leaders
may believe that it is in their interest to play it safe, not rock the boat,
but in reality there is no such thing as safe. The IT industry is so fast
moving, that cracks will begin to appear in existing technology stacks over
time, if they aren't invested in, cared for, upgraded, or continuously improved
and automated. Standing still in IT will mean the tech that they are using will
become dated compared to competitors.
One point that
becomes apparent when I attend technology conferences and speak to some
companies is that they evidently don't have people passionate about technology
directing the company. If you look at the most successful companies
organisation structures they have a great mix of technical and business people
at the helm. So why do so many technology companies in particular have this
flaw and why are getting it so wrong?
To innovate and be
successful in the technology industry you need strong leadership at CTO, CIO,
Director and Head Of level, that really understand technology and are
passionate about continuously improving it, driving it forward, towards common
and agreed goals. The worst thing any company can do is not have a clear and
concise set of goals at senior management level, as it sends mixed messages to
the engineers on the ground that need to deliver on the vision. Engineers can
often become caught up in middle management politics which is exhausting for
all involved. One joined up message is important, organisations should avoid having departments that act like shadow governments that will pick fault in other teams processes and ways of working. This is a collaboration anti-pattern that will just cause conflict.
These technology
leadership positions in some companies are all too commonly made up of career
managers that may not necessarily have the best understanding of the
technology, who believe they have made it, hold a title and power so they are
above being challenged on the decisions they make or questioned. There are good
ones though, which I have had the pleasure to work with over the years.
Great technology
leaders listen to their staff they don't treat them as disposable commodities.
This is where the most common technology leadership faux pas lies, the power of
a technology leader lies in their people and engineering talent, a good leader
will know when to get out the way and let the team get on with it. Good
technology leaders see their job as giving the engineers an environment to
prosper and do their job, shielding them from internal politics and blockers.
CTO's, Directors
and Heads Of job is not about making low level technology decisions anymore,
the role of a technology leader is now more about inspiring a successful
culture in the business that allows engineers to innovate and deliver great
products to market. Technology leaders need to be open to being challenged, not
taking it as a slight, and improving ways of working based on constructive
feedback.
This of course
means they need to have a low ego, they will put the company’s interests at the
forefront, and not abuse the power they have or be easily offended. Command and
control models led by technology leaders is not the way modern companies should
be run, it is proven to fail. Tech leaders are in reality too detached from the
day to day solution to make accurate technology decisions so this needs to be
delegated.
The engineers the
tech leaders have hired should be making the low level technology decisions,
tech leaders instead need to focus on the culture, steering the company
objectives in the right direction and trusting the engineers to deliver the
results. This may be hard for some technology leaders who have come through the
engineering ranks, but they need to let go, trust those they have hired to do
their jobs and not micro-manage their staff.
For some technology leaders this means taking a step back, looking at what they are doing and
evolving too to adopt this new way of working. Like engineers, technology
leaders can learn too by looking at what others are doing in industry, so they
too can improve. However, this means actually being open to change and
listening, it shouldn't mean looking at what others are doing and using conformational
bias to validate what they are already doing. It isn't too late to change and
improve as no-one is perfect.
Moving towards an
agile approach is fundamentally important too. Milestone based approaches,
dictated by managers going in an offsite meeting is anti-agile and doesn't make
sense. 10 years ago that may have been acceptable but not today. The software
industry is so fast moving that the road map that is documented this month will
be out of date next month. This milestone approach should simply make way for
agile prototyping using spikes in sprints to evaluate tools and processes,
where engineers are trusted to try and test new solutions and show the business
value.
Not all prototyped
solutions will work, but some will and bring huge business value or speed up ways of working. If an idea
doesn't work as expected the engineering team and business will have at least learned a valuable lesson and the engineering team
will have improved as a result. The ask of technology leadership from engineers is that their
managers trust and support them to
make the correct technology decisions. This by no means doesn't mean their decisions can't be questioned or challenged using data.
The engineers on
the ground are normally the most qualified people to make this assessment, so
they should be empowered to do so. Management should know when to step aside,
this takes bravery though. Including engineers in the decision making
processes or even better delegating decision making is very hard for some technology leaders as they see this as power. My argument is that empowering people, is an even greater power.
It is vitally important
that any technology decision made by technology leaders or engineers needs to be backed
up by statistics, metrics, KPIs and data driven analysis. This is a common theme in
DevOps culture, using feedback loops and measuring results to dictate the best ways to continuously
improve the solution.
In the past
technology leaders would traditionally make technology decisions based on gut
feelings, instinct or even a whim. This really isn't acceptable today, as your
competitor will likely be using big data analytics or machine learning, which
should be shaping our business decisions and enabling us to become better
decision makers, everything must be data driven now.
If I was a betting
man I would bet on data over gut instinct every time. The value of data, stats
and measurement cannot be underestimated. In any industry there are the leaders
and the followers. The followers will wait until someone like Gartner says that
a technology is ready to use before even considering it, by then it is too late
as half the industry will have already adopted it.
Taking weeks or
months to deliberate over putting a solution in is frankly not acceptable, if
decision making is handed to engineering teams they can evaluate solutions
within a few weeks. Managers will take weeks, months or even years evaluating a
product or new technology, scared to put it into production encase it
breaks.
Bureaucratic IT
processes will outline rigid phases that need to be completed, such as a
requirements phase, analysis, with multiple word documents or PowerPoint slides
written before finally allowing an engineer to actually evaluate a new tool and
see if it proves its worth with real business use cases. Instead this could
have been prototyped in a week by an engineer in an agile spike and tested on a
subset of use cases using a real world examples to see if the solution was
viable.
My view on this is
that these bureaucratic processes are implemented by managers, to quell the
pace at which the world around them is moving. So they put in these processes
to make it more stagnant environment so they can control everything that is
going on, this is done out of fear. Put simply IT management don't need to
understand every fine grained detail, that is what they hire and should be
empowering and trusting their staff to do.
Engineers that
feel empowered are more likely to be happy and will do their best work, happy
staff will also encourage other good people to join the business, therefore
raising the benchmark and technical level of the engineers in a company. When
you hire good people they will bring good people with them. Poor managers or
technology leaders instead will micro-manage staff, hire people less clever
than themselves, create an unhappy toxic culture and ultimately the best people
will leave the business and move on to companies that empower and trust them.
In the fast paced
technology space it is imperative for technology leaders to be brave and
encourage innovation and not suppress it. If there are tools or new processes
are available that will improve a solution it is imperative that they are
implemented straight away. If you wait too long, then the value add or
competitive advantage of implementing the solution depreciates and your
competitors may implement it first.
The most
successful projects are normally when a collection of engineers are given
creative freedom to collaborate, share ideas and build something great
together, without having to deal with middle management in fighting and
corporate politics. This is DevOps in its truest form.
This is what the
DevOps movement is all about, engineers in reality want to work on interesting
projects, with cutting edge technologies that allow them to continually improve
and couldn't care less about company politics. It is probably true that what
most engineers want in life is to be left alone to get on with their job.
Gartner calls this mode 2, but they should simply call it the future.
