Commando Coding - Leading a development team in a non-IT environment: First Contact
The first part of this series can be found here.
In the fictional world of bad 80’s war movies, the plot often starts with a crisis that needs to be averted. All attempts to take out an enemy threat has failed. Then some smart officer has a brainwave - why don’t we try something different? Enter - a band of misfits. To continue with the analogy that has been tortured to within an inch of its life in the first part of this series, founding an in-house development team in a non-IT company feels a lot like the start of that grade-b movie.
Conventional companies are often reluctant to deviate from what they know. A lot of corporate IT solutions have always involved throwing money at the problem - often in the shape of “enterprise software”. This has enabled certain enterprise software vendors to feed fat off the tears and broken dreams of users who have to deal with overbloated, clunky software that takes ages to learn because it is trying to be all things to all men.
Naturally, not all business process or automation problems fit neatly into the box that commercial software provides. Sometimes, there is that nagging inefficiency that falls in the cracks between tedious manual processing and monolithic enterprise solutions. It is in that liminal space of bespoke problems that the battle-hardened band of software developers can storm in to save the day.
Let us take the case study of the purely hypothetical guy we mentioned in part 1, you know, the guy that works for an Oil & Gas company. Let's call him Higgs. Using this case study we will walk through the steps necessary to build a functional dev team in any corporate environment.
Identify the problem
A few years back, Higgs was happily managing the network/systems/cloud infrastructure for his company when a colleague came to him with a problem she had. She had created a document numbering scheme for all documents generated within the enterprise. The scheme incorporated information about the document such as department, type of document, location, and so on, into a unique string for each document. Since there was no commercial software that exactly fit this workflow, she had had to manually generate, assign, and keep track of these document numbers - dozens of them per day. They both saw that this was a good case for building a custom platform that the end-users themselves could use to generate the valid document numbers.
Drawing battle plans
It was obvious to the two collaborators that for the project to work, they needed to get a few vital things right. Firstly, they needed to come up with a working prototype at close to zero cost. They also needed to show the software improved user productivity enough to convince management to allocate more resources to an in-house dev team. Lastly, the software needed to dovetail smoothly with the users’ current workflows and expectations.
Recommended by LinkedIn
To meet the defined criteria the software needed to
They knew they had their work cut out for them. It was time to tie the greasy bandanas and put on the face paint.
Beta is better
The first things to set up were the software design methodology and collaborative tools for the team. Higgs decided on implementing a modified version of the Google Design Sprint which is “a five-day process for answering critical business questions through design, prototyping, and testing ideas with customers”. The sprint consisted of the IT team and the document control team as the client.
The next stage was to develop the prototype from the design sprint into a functioning product. The prototype front end was built with Angular, a javascript-based single-page web application framework and backend logic with NodeJS. The application hosting, database, object storage, authentication mechanisms were provided by the Google Firebase and Azure cloud platforms.
Leveraging open web technologies such as Angular and NodeJS as well as cloud platforms like Google and Azure that provide free usage tiers, enabled the development team to stay within the objective of a no-cost application. It also ensured that users could access the service on any device with a browser from anywhere in the world - this was vital for a company with offices across three continents.
In a few weeks, the platform was ready. It was now time to slap the tag “BETA” on it and unleash it on the unsuspecting users of XYZ Petroleum Co.
How did the launch go? Were the users happy? Did the product solve the problem it set out to solve? Was management impressed? Or was Higgs cast into the outer darkness for wasting everybody’s time? All these questions and more will be answered in the next enthralling instalment (hey, stop rolling your eyes) of the series.
Until next time.
Higgs, hey! Welldone