In my last post, I tried to emphasize the business aspect of the technical lead role in enterprise software development. You may be a technical genius, but if you have no interest in business you should redirect any ambitions you have for technical leadership and perhaps pursue a specialist role of some sort. You can’t divorce business objectives from any decisions you make as a technical leader.
I originally intended to get into technical design and development best practices with this post. But before I talk about what they are, I want discuss why they are important. In discussing best practices, I doubt seriously that I will enlighten anyone with something they haven’t already heard at least once before. However, it would seem their importance is not appreciated by many who choose to ignore them.
There are actually at least two business domains that you must concern yourself with as a technical lead. The first and most obvious is the business (or line of business/division) you are serving – your client. The second is the IT organization. IT can quickly degrade from a positive investment to a negative expense if the IT organization is not run as a business of its own. Running IT as a business is a current mandate of any CIOs worth their salt. Unfortunately, the business objectives of the IT organization are often discounted or disregarded by project teams. The majority of the team will be narrowly focused on the current project, or even more narrowly, on the current feature/deadline/milestone/etc. However, a good technical lead will keep IT business objectives in the forefront and balanced against the client’s business objectives.
It is the pursuit of IT business objectives that has cultivated the current array of software development best practices. Like any business, at the most basic level, IT organizations aim to maximize their production while minimizing costs. The majority of best practices for software development process and technique were developed in pursuit of these goals. The current industry focus on agile methodologies, design patterns, test-driven development, and continuous integration (among other development techniques) has emerged through the pursuit of these objectives by hundreds of industry experts. It is the consensus of the most qualified and experienced people in our industry that following these practices provides the best chance of executing projects predictably and efficiently while minimizing the long-term costs of operating, maintaining, and enhancing the systems we develop.
Re-read the second half of the sentence above, starting with “while…”. It is not just about meeting deadlines. The initial development cost for most enterprise systems is dwarfed by the long-term costs. Yet many technical leaders will easily and regularly make decisions in the interest of short-term goals and priorities without consideration of the long-term impact. For some, now is always more important than later. But that is often the wrong choice.
Let’s use an example. Assume you’re buying a custom-built car. You are given the choice to drive off with it today and get 10 miles per gallon or wait a couple weeks and get 40 miles per gallon. All else being equal, what would you choose? What if having it today meant you would have to leave it in the shop for a few weeks each time you need an oil change? Or a few months each time you need new tires? What if you had to pay $200 an hour for each technician that worked on your car during those weeks? Seems like a pretty easy business decision – to me, anyway.
Of course, the real world isn’t quite so simple. Missing a deadline can have significant business costs and implications, as well. But the point is all business factors must be considered – long term and short term – for both the client and the IT organization. Even business and IT managers can loose sight of this. A good technical lead will aggressively defend doing the right thing for the business – even when the business occasionally doesn’t see it. In the end, you will gain respect and credibility whether they followed your guidance or not.
Okay, I’m hung up on this business stuff and still haven’t discussed anything truly technical yet. That’s because in my experience mentoring technical leads, this is by far their biggest obstacle. They have already proven their technical aptitude and ability to meet deadlines, or they wouldn’t have been promoted to a lead role. (Yes, I know… that’s not always the case.) But for many of them, being a technical lead just means more authority. For the most part, they’ll continue doing what they were doing before, but they’ll get to make decisions on their own and tell a few others what to do. Many will think industry best practices are just hype and won’t take the time to learn them. They will continue to keep their business blinders on and will make decisions based on personal interest, the path of least resistance, or serving the crisis of the moment. With that mindset; they will inevitably fail. Or, worse yet, the business will fail.
If done right, the technical lead role comes with a huge amount of additional responsibility and a small amount of additional authority. You may be one of the few that knows better than the majority of experts in our industry. I’m certainly not. And if you aren’t, you will be best served by learning and embracing the current industry best practices. In my next post, I’ll discuss some of those practices.