The Dos and Don’ts of Tech Management

Avatar for Martijn Hoogeveen
By
Do's and don'ts in Tech Management
Likethumbsup(3)Dislikesthumbsdown(0)

For good tech management, keeping a sharp eye on the dos and don’ts of handling software projects is essential. In over 30 years of involvement in tech projects and business, I have seen a lot of projects going well. But even more, going south. So, let’s review the typical risks to avoid and approaches to embrace in tech management.

Lack of information analysis

When I did a postdoc information analysis in the 1980s, the core observation was that many IT projects failed miserably because of a complete lack of proper information analysis. Today, this observation is still as valid as ever.

Great information analysis requires a solid analysis of business requirements and continuous communication between the business, given its shifting needs and priorities, and the tech teams that produce solutions. Though the responsibility of good and constant requirement analysis is primarily a business responsibility, it needs embedding in the tech teams as well. Avoid situations where people point fingers and don’t take responsibility or claim sufficient ownership.

Great information analysis starts with understanding the business case and the derived business requirements. It continues with functional analysis, process and data flow insights, the development of a future-proof data model, user interface designs, and a technical architecture. All are to be discussed and proofed by the business owners before the work is started. Demos and prototypes can help to clarify functional and technical requirements.

Always avoid Big Bang approaches

New CTOs in startups or new tech management in corporates, like to “change everything” by developping their own “new system”. With dramatic big bang effects on the survival of respective startups or performance of respective organizations. Especially, SAP migrations are notorious for the big bang approach advised and followed. It means a key operational system is entirely replaced by a new system on a specific date. In the case of SAP, it’s typically about enterprise resource planning (ERP) systems, the beating heart of many commercial businesses. In the case of a global tech trader, this approach typically led to the loss of 30% of the revenues in the 12 months following a “successful” migration. Dramatic.

Why is this? Despite all requirement analysis, it always turns out that undocumented functionalities of the old system are overlooked. Missing these, often results in utter disaster. Warehouse management systems not being able to receive orders from the ERP system. Corrupted invoice processes. Just to name a few. It’s, of course, food for consultants. Because the moment the shit hits the fan, the management of the business panics. And consequently, there are no limits anymore to the budgets made available to resolve the shit. The disaster can be so big that it kills the victimized business or business line. This is, of course, a situation that management should try to avoid at all costs.

Although many external IT consultants will continue to say that a big bang is the only possible approach in case business systems are entangled, this is not true. Big monolithic solutions can be replaced in smaller steps by services or in even smaller steps by gradually migrating to a micro-services architecture (MSA). In the case of migrations of business-critical systems, the smaller the steps, the better it is. And, often faster and more efficient.

No relation between budget and success

The core of the IT productivity paradox is that many investments in tech don’t lead to productivity gains as expected. Unsurprisingly, scholars have observed over and over that there is often no clear relationship between IT budgets and productivity gains. Still, there are many examples of successful applications, and tech businesses wouldn’t have been possible without proper investments and serious budgets.

Because of this paradox, it’s always good to start small in case of new ideas. A few developers can create a minimum viable product (MVP): an app, a product, a system, a service, or a site. One great developer can typically produce a better MVP than a big team of lower-level professionals. And faster as well. Therefore, selecting the right people for a project or tech business is critical. Utterly critical in the early stages, and still very important in going concern situations.

Many successful tech businesses have started with a shoestring budget. Using open-source frameworks, low-cost hosting options, and sourcing experienced freelancers from popular outsourcing countries. By focusing on an MVP, bringing it to live quickly, and doing iterations with short time intervals, great things can be realized in months rather than years. In this way, entrepreneurs and business owners quickly learn if there is a market fit for their ideas. The setup is still nimble enough to allow for pivots or abandoning the project to switch attention to other ideas.

You can’t walk on one leg

Building a resilient business implies reducing dependencies. Dependencies on management, staff, suppliers, clients, countries, and the technologies used. Bad consultants will tell you to standardize on their platform. Or it is more efficient to outsource all IT jobs to a single provider. Or centralize everything in one tech department or platform. This monopolism creates a very dangerous dependency, which inevitably leads to laziness, abuse of power, inflexibility, and red tape situations that kill innovation and, eventually, put a business at risk.

For example, Amazon Cloud (AWS) was invented by an entirely separate team (from the Amazon core team) that focused on solving a fundamental tech flexibility issue. Everyone knows the success story. A good balance between core teams with more bureaucratic processes that run critical systems and other teams that focus on innovation is necessary. It is often the only way to secure the business’s future. In the same way, it is crucial not to work with just one external consultant, not just one hosting or cloud provider, and not just one tech stack. You need at least two legs to walk on. Only such an approach keeps the organization flexible. Speeds up the learning process and shortens the innovation cycle.

Don’t hold on to legacy code

It’s tempting to hold on to redundant legacy code. Because it runs efficiently, it is a kind of tiresome cleaner’s job to phase it out. But, keeping all redundant legacy systems running, often with completely overlapping functionalities with newer systems, eventually leads to an efficiency nightmare. It will gradually tie all available tech resources to maintenance, leaving less and less room for desperately needed innovation. Boundlessly increasing tech budgets to keep everything running, plus building new platforms, is never a sustainable approach.

It’s important to properly plan and focus on phasing out redundant or obsolete legacy platforms. Not only with ill free up IT resources. It will also stimulate innovation. The other systems and services in the ecosystem need to be improved to take over all functions of the old platform. As a rule of thumb, it is good tech management to allocate 30% of the tech budget to “maintenance”: phasing out or reworking old code.

Avoid fashions

Tech people are like ordinary people: they love and follow fashions. It can be about preferring Python over PhP or C# over JavaScript, or the other way around. Or about how cool it is to use Amazon Cloud (AWS) or Google Cloud, instead of more classic hosting providers. Sometimes it is good to follow a fashion. Because when developers dropped Perl for PhP, it became increasingly hard to still find Perl developers. But often it is risky to follow a fashion.

A developer might embrace a new development framework that is not mainstream yet, and risks to become a dead end over time. Another risk is that certain promoted tools or solutions are not fit for purpose for all required jobs. Developers tend to be a bit religious about the tools and environments they worked with or have created themselves. Cloud solutions can be sometimes 3-4 times more expensive than traditional hosting solutions and using these might effectively kill a business case. It is a job for management to critically balance risks, and to look at alternatives at every turn of the road. This can’t be fully delegated to tech staff given their inherent biases.

Methods are not holy

It is already long ago that waterfall methods were advocated for system development. Following multi-step procedures from requirement analysis to functional analysis and technical design to system development, led to projects with too long timelines. The major risk was that these projects fail because the initial requirements had changed when systems were finally delivered. Many other approaches tried to fix this, like rapid prototyping, agile, scrum, extreme development, lean development, dynamic system development, feature-driven, etc. Each of these have advantages or drawbacks.

Based on decades of system development experience, my conclusion is that it is important to be very pragmatic, and not religious about any development method. Try always to chop projects in small steps that lead to quick results: the creation of a minimal viable product or service, the update of a critical feature in an existing system, the development of a micro service replacing similar functionalities in multiple systems in an ecosystem, etc. Client or user documentation is important, sprint reports and sufficient inline documentation. But avoid too much overhead in documentation.

The business is in control

There are developers who intuitively create marvelous things. But there are tons of developers who produce nothing of value for a client or business if allowed to do whatever they like. If a business wants to succeed in meeting its objectives, it has to be in full control of its software development processes. Especially in case of critical infrastructure, it should never be left to a supplier or internal tech team to decide what product features or developments are prioritized over others.

Fully aligning business objectives with service roadmaps is critical. It helps to avoid wasting resources and unnecessary frustrations.


Subscribe to our newsletter and stay updated.
Loading

Leave a Reply

Your email address will not be published.

Icecat xml

Open Catalog Interface (OCI): Manual for Open Icecat XML and Full Icecat XML

This document describes the Icecat XML method of Icecat's Open Catalog Inte...
 November 3, 2019
 October 4, 2018
Manual

Manual for Icecat Live: Real-Time Product Data in Your App

Icecat Live is a (free) service that enables you to insert real-time produc...
 June 10, 2022
Manual for Icecat CSV Interface

Manual for Icecat CSV Interface

This document describes the manual for Icecat CSV interface (Comma-Separate...
 September 28, 2016
Manual

Manual for Open Icecat JSON Product Requests

JSON (JavaScript Object Notation) is an increasingly popular means of trans...
 September 17, 2018
Icecat Addons plugins

Icecat Add-ons include Magento, PrestaShop, Shopify, Magento, Google Shopping, Pimcore, Bol.com. NEW: Mirakl

Icecat has a huge list of integration partners, making it easy for clients ...
 November 24, 2022
 January 20, 2020
New Standard video thumbnail

Autheos video acquisition completed

July 21, Icecat and Autheos jointly a...
 September 7, 2021

Iceclog: Content Log New Ideas like a Free Vendor Central

“Iceclog” (Icecat content log) is the Icecat ...
 June 26, 2019
Manual

Manual Personalized Interface File and Catalog from Icecat

With Icecat, you can generate personalized or customized CSV or Excel files...
 May 3, 2022