When I joined a major telecom provider four years ago, the future of the business, and my career for that matter, looked good.
I came on as an information specialist, tasked with providing the organization guidance and enhanced capabilities for Documentum and their intranets. Within a few months, I was managing the entire information management organization, which included Documentum Inc., Vantive for software defect tracking, all the incarnations of intranets and extranets, and the enterprise systems and Oracle databases that support them.
I was also asked to manage the Release Engineering group, which had lost all of its members in a single week to attractive offers from competitors. I hired a project manager to assist me in managing the wide variety of projects assigned to my team of 16 database and Web developers, system architects and release engineers. I also had on staff a process engineer who helped define and document our processes for compliance with ISO 9000 and TL 9000.
Within that first year, we began to witness the unraveling of the entire tech sector. Not only were the telecoms imploding, but the very core and livelihood of technology professionals was at risk as well. Our first round of layoffs was indeed difficult, but seemed a blip on the radar. We assumed we would do this once and be done with it.
For me, it was an eye-opener and a harsh lesson in management; I had never sat someone in my office, handed over a package and informed them they were out on the street — much less several people in one day. Within a few more months, we were asked again to give up more head count.
And this exercise continued several more times. It included more and more of my staff, my bosses several layers up and, eventually — and more than once — the entire senior management, including the replacement of the general managers no less than four times. The future was bleak indeed.
Down but not out
As our numbers dwindled and the forecast for the outside became even more dismal, those who remained began doing more with less. We had no choice. The entire infrastructure for information rested on our ability to manage and ensure its stability and reliability.
My organization now comprises myself and one other senior developer, and we support far more than two people should be asked. While we first and foremost must maintain the integrity and reliability of our information systems, we are also expected to continue the development work we used to do with many more people.
One tact we took as a matter of survival was to become more visible rather than less. While others around us were hiding behind their desks keeping their heads low, we showed up at meetings and planning sessions, got ourselves invited to gatherings of the senior staff, became more plugged into the business and processes surrounding us. We got ourselves on senior management’s radar.
More and more, management was asking us to help solve problems at all levels, to develop lean and fast tools that would answer business needs that spoke directly to defined business goals.
We leveraged our existing tools to their greatest capability. With budgets literally gone, we looked more closely at what we had and made that work more intimately with the business. We began developing a large body of Web-based tools with which we could tap into the databases that collected all this invaluable information, and delivered that data in the context of the different business units. We gave them the information they needed in the way they needed to see it.
Quickly, we also became expert at modifying existing systems and their installed clients. (We used to have on staff people to support this activity.) We began scavenging for systems from groups that had inventory, installing Linux as an alternative to Unix and, in general, worked with other groups to get the things we needed.
Using what we’ve got
In addition to our support and programming work, we were responsible for support desk tickets to assist the end-user community. We tried to make logical division in the workflow, while also joining together on projects to teach each other and fill in the gaps in our respective knowledge.
Where we could, we encouraged our own innovation. This not only included digging in and learning new technologies and languages, such as Java and XML; it also meant working with other teams to discover the quickest and most cost-effective means to solving a problem.
Often we find ourselves using very basic Unix or Perl or shell commands within Web programming wrappers to deliver a fast and adequate business tool. No bells and whistles — just the information required in a useable, meaningful and consistent format. In all these tools, we provide the option to download the raw data into Excel, because it was understood that that was how management preferred to view and manipulate data sets.
Perhaps most importantly, we learned to listen to the business. By going to meetings and increasing our visibility, we were increasing our knowledge of the business and, in that process, discovering the gaps in the knowledge of senior management. We developed systems to manage the complicated and difficult task of software patch releases, interfaces to manage the incredible amount of hardware inventory, dashboards for senior management showing metrics that illustrate how we measure against what we said we were going to do, and a wide range of tools that spoke directly to running the business.
We helped tie databases from different divisions to our own. We helped manage the information requirements for offshore contractors. We migrated other business units to using our tools rather than implementing their own. We implemented complimentary tools to existing ones, like developing board testing and scheduling tools as modules on top of the hardware inventory tool. We designed Web interfaces with Oracle backends to support tasks and information that were being manually captured and manipulated using Excel.
The questions always were: Does this directly help run the business? Does this provide enough value to warrant a week’s worth of our time? Does this fit and help drive the process that currently exists in practice?
Listen on the inside; watch on the outside
Listening intently to the business made us recognize not only the value but the necessity of remaining flexible. With each change in management came a new set of information requirements. Whether we agreed with the decisions being made was irrelevant. (In fact, we try to keep our heads above and clear of complaining, conjecture and gossip.)
We had to acknowledge that senior management had information to run the business to which we had no access — so how could we make judgments? Besides, our mission remained clear: provide business tools that help run the business. Period.
We kept our eyes open to those outside the company to see how others were solving problems. While other companies were decrying the inability to buy new systems and technologies (the new big enterprise systems, the hot ticket, the system du jour), we were developing lightweight, quickly modifiable and supportable tools that cost nothing but our time.
While we didn’t actually use their code, the open-source community provided us a lot of ideas on developing quick, Web-based tools to manage a given situation or problem. We were careful to manage our code in a way that made it modular so that code written for one application could be easily ported to another.
Things appear to have settled down for the time. While we have outsourced an awful lot of development and sustaining engineering work to India (the topic of another discussion perhaps). We have managed to survive and even prosper in a most difficult atmosphere. Our jobs are not only as secure as can be expected, but we actually carry forward a sense of satisfaction that we are helping the business and not just hoping to avoid the next cuts.
The survival lessons we learned will make us better tuned to provide even more value when times are good. They are also lessons that can be applied to overall project management, and not just within the technology sector.