MacGyver Skills: The Software Project Survival Strategy for Technical Leads

If you don’t happen to know about the American TV show back in the 80’s staring Richard Dean Anderson called MacGyver it’s about a guy who creates unconventional solution to problems on the fly. Consulting software projects often contain surprise challenges that come up during implementation that were not foreseen in advance. Depending on how significant these challenges are it could mean the difference between success and failure. Having the ability to create solutions around unexpected situations and hurdles is one of the most valuable skills you can have a technical lead.

The Reality of Incumbent Heterogeneous Platforms and Corporate Policies

One thing that I’m always watching for on enterprise projects are the integration requirements and what platforms the customer current has that my team will need to deal with during delivery. Integration is one of the more misunderstood and complex aspects of enterprise projects. Often, we underestimate the integration efforts necessary when it comes to heterogenous platforms that the project team has no previous experience using.

I once had a project where there were 10 known integrations going in and before it was over there was over 100 integrations. It also didn’t help that the sales team had told the customer everything would be complete in a 3-month time period. Granted, you can blame the estimation effort for the big gap, but you must appreciate the challenge of pretending we know everything in advance. Part of the reason integrations are challenging is the project team must not only learn the platform while also completing the integration work as well. This is even more challenging when dealing with legacy technologies that require special client installs, operate on other operating systems like Unix, Linux or mainframes or don’t provide a convenient interface. Part of the challenges that happen for integration work is when the team is hung up in creating the plumbing of the platform just so they can write the integration itself. Many in-house systems for example, typically have no or poor documentation and don’t even expose an API requiring reading and manipulate database tables directly.

Corporate policies are always another consideration often left out of project estimates. We tend to find these things out after the fact because project stakeholders are often unaware of the policies that will impact backend work. The overhead of elevation and testing requirements can dramatically decrease the effective output of a team. Some companies have such a stringent overhead of checklists and steps for elevating code that it can take a month before a deployment to upper environments can happen.  I had a customer once that had such a complex elevation process that I personally wrote code to automate some of the process because it was taking so long for the team to perform manually and was killing our output.

The Importance of Fast Learning and Intellectual Zone Defense

One skill I had to learn a long time ago when I was an independent consultant is learning a new technology fast. This is easier when it’s a mainstream platform, but much more challenging when it’s something more obscure. If you’re going to handle interfacing with unforeseen platforms and technologies, you must be quick in figuring out how they work otherwise your dead. Software projects usually have a fast pace schedule and spending “extra time” that wasn’t projected in the project estimate doesn’t remove the need to do it.

Intellectual zone defense is the practice of doing research in other platforms and technologies that aren’t within your typically wheel house. Many Dynamics developers often stay very focused on the skillsets revolving around the Dynamics platform, but often have very little knowledge about other platforms. While I may not go in depth in other platforms, I try to stay at least conversationally aware of common platforms that I’ve come across in my travels. The one thing that I hate as a technical lead is to walk into a project and come across a new platform that I know nothing about. This feels very dangerous to me because if I don’t know anything about the platform then most likely whoever estimated the project doesn’t know it either. In my travels around these fortune 500 companies I’ve always tried to pick the brain of their architects to gain an understanding of the technical portfolio. What you’ll often find is a combination of Windows, Unix and Mainframe platforms in use spanning many versions. Sometimes you’ll come across IT shops that have competing Java and .NET platforms. For better or worse in these kinds of shops whoever holds the prized IT data tends to run the show. In mainframe shops this means we must deal with them on their terms and they’ll most likely be using Java and IBM platforms like IBM MQ and WebSphere. These are the realities of the game we play on enterprise projects and we must adapt to survive.

Creative Strategies Help Save Projects

I once worked with a project stakeholder who had to bend to the demands senior leadership with what we considered extreme goals that needed to be met in a short timeframe. We had discussed some options that I was not in favor of because I felt it wasn’t the right way to do things that would be good long term. To paraphrase his statement to me he said that we always want to implement the ideal architecture, but most often we must use the architecture that will keep us employed today. The business stakeholder was saying that while implementing the ideal architecture was better in the long term, if we didn’t take a detour now there may not be a project at all later. This conversation had a lasting impact on my implementation thought process because he gave me the reality of a business stakeholder’s perspective that I hadn’t truly considered. Success is almost never a straight line and sometimes we have to be able to bend around obstacles to make it to the finish line. This means we sometimes need to handle unconventional problems with unconventional solutions. It was from this conversation that I formalized my concept of the compromise architecture strategy.

The compromise architecture strategy is the concept of realizing that suboptimal project conditions sometimes demand solutions that focus on visible results for the sake of survival. This usually means we must come up with a development strategy that provides the necessary political capital to business stakeholders at the expense of some technical debt. They key here is you must be deliberate in your implementation strategy knowing that you’re emphasizing short term benefits with the expectation of extra refactoring work efforts in the future. When these kinds of scenarios come up, I always try to emphasize that if we incur forms of technical debt that we should do so with the undertaking that it needs to be paid at some point in the future. The other thing that I do when I’m playing a technical lead role is keep track of the technical debt so that everyone is clear about what it is and the effort to address it. Some forms of technical debt can remain in the system for longer periods, but others need to be handled fast else it will cause what I like to refer to as an “unfavorable business event”. The thing that happens often on project is no one tracks the technical debt and it becomes a time bomb waiting to explode on whoever happens to be involved with the project at that time.


The main point that I want you to come away with in this article is if you want to survive in the software project consulting world you have to constantly be ready to adapt and conquer face unforeseen challenges. I’ve only really had one project that I would classify as a straight-line win with no real challenges and that was a small proof of concept with a very collaborative business stakeholders and subject matter experts. On every project I’m carefully waiting for Murphy’s Law lurking around every corner to punch me and my project teams in the face. I’ve come to expect it and constantly contemplate what if scenarios. Coming up with design patterns and templates with generalized platform knowledge is one way I combat the unknown of project delivery. This is the reason I love to have project teams made up of techno-functional consultants. I’ve found that the teams who have more techno-functional members were able to adapt significantly faster to project circumstances than teams that had single skill focused members. These techno-functional resources were also more willing to take on new tasks they weren’t used to performing. In a perfect world we would always be given the team that covers every necessary skillset, but I’m still waiting to see that happen in practice.

As a technical lead, architect or someone who wants to play those roles one day my advice to you is be a consistent learner. Try to be the best at the role you play and gain the empathy that you’ll need when you lead others, but don’t be a one skill person. I think the best technical leads are the ones who have great technical comprehension, but also have a combination of functional and architectural mindsets.

Categories: Career, Project Delivery


%d bloggers like this: