LinkedIn | FaceBook | Twitter
In many organizations, there’s a push to save cost. “Cost” is an integral part of a profit-and-loss statement in the organization. Even if you work in a non-profit organization, cost control is central. Of course, you can take cost-control too far. You could, for instance, remove the shipping costs from your company, but if you happen to be an online retailer, removing the ability to ship your product would eventually doom your company. So there’s obviously a spectrum of necessary cost and wasteful costs.
People are a large part of the cost of any company - in some cases the highest cost. So it stands to reason that there’s a natural tension between paying well to find good people, and the need to lower the cost of those resources. In the rush to save costs, we’ve all seen people let go that really shouldn’t have been – and in other cases some folks stick around that need to go. How do you make those choices? Well, there are a lot of factors to consider, but if your firm has an IT focus, meaning that you sell software or develop software that is core to your organization’s business strategy, then certain positions can actually save or make you money – even when they are very expensive.
There are a few caveats here -
The first is that I’m assuming that every resource here is the best they can possibly be. By “best”, I mean that they know their craft inside and out, are recognized as an expert, and that they are continually improving themselves. Also, I realize there are lots of definitions for these roles, but I’m taking the minimalist approach. The role is what the title says.
The second caveat is that you actually have a team with these positions. You might have a smaller or different team that doesn’t include the position. And keep in mind, I’m talking development teams here. No mention of operations, like sysadmins or platform administrators, networking professionals, nothing like that.
The third caveat is that this is *my* list. You’ll probably have a different one, and good on you if you do. I’m not saying that you should make more or less money, that you’re not important, or that you’re not a good person. I’m sure you are. This list is strictly confined to making and saving money for an organization or company. If you disagree with my list, post your comments – with one requirement: include your logic.
On with the list. In descending order, the top five money makers for your IT development shop are:
Number Five: Developer
It stands to reason that a good developer is faster, makes less mistakes and is generally more efficient than a poor one. But the developer will also save money for the entire organization when the code they write runs faster, and with fewer errors. That means even after a software project is complete, the good developer saves you money every time their code runs.
Number Four: Tester
But code has errors. All code, from everyone. And studies show that every error that gets out with deployed code costs up to four times more to fix than having a tester catch it before it hits the field. So it follows that a tester – a really good one – has a bigger cost/profit impact than a good developer alone.
Number Three: Lead Developer
Software is complicated. Keeping a development team on track, and keeping the work “pipelined” is also a key to utilizing those developer and tester resources at as close to %100 as possible. Every dev or tester that sits around, or writes code that isn’t needed or eventually is thrown away, is a waste of resources. A good Lead Developer keeps that from happening. Oh, and don’t forget who hires those developers and testers and assembles them into a team. Done properly, the Lead Developer handles that, so they have a direct impact on the prior two positions, making them more valuable. When there’s no lead developer, a power vacuum forms and the loudest voices win. And heaven help you if you have the misfortune of an overbearing, micro-manager in one of the so-called “Agile” environments. You’ll lose good people faster than the U.S. Government spends money.
Number Two: Project Manager
Really? In some companies I’ve worked at, the Project Manager is not viewed as a more valuable resource than a lead developer, but if you think about it, they have an incredible impact on cost (and subsequently, profit). How many projects have you seen that were scoped incorrectly? If the organization had a good PM, they would have had a better estimate or work and schedule – and perhaps have made a choice to implement or not implement a feature. Both of those choices have vast cost implications. Make something you shouldn’t, and the whole thing is wasted, don’t make something you should, and you lose opportunity costs.
Add to the scope question the ability to properly lay out time and resources, and the PM can make or break the budget on not just one but multiple projects.
Number One: Architect
In many firms, the title “Architect” is sorely mis-used, handed out with little definition. What an architect should do is understand the business and mission of the organization, and thoroughly understand multiple technologies. I’ve seen lead devs play this role, and in my opinion that’s hard to pull off successfully. In some companies, the IT Director, CTO or even CIO act as the Architect, and in my mind those roles have too many HR and Budget duties to be effective as an Architect.
An Architect is a single role that is allowed to focus on the marriage between business and technology strategies. Even if they are a “Data Architect” or a “Software Architect”, they need to know security, hardware, networking, the Cloud, whatever. That’s their job – to “know”. All areas inter-mingle at this level.
So why does this knowledge make them the most important resource in an IT-centric company? Because innovation, market applications, and general business strategy are where the architect can have the most impact. Decisions for technology strategies affect every single person not only at the company, but shareholders and the public as well. If – and these are a big deal – they are valued, competent, can communicate that strategy and are listened to by leadership.
So, where does the integration with the Operations Engineering Teams fit in with this list? I would submit that for any IT Development Organization to be successful, that tight integration with Operations and the Operations Engineers is required and said Engineers should be feeding in to, if not directly part of the development organization as a whole. You can have a development team plan and scheme all you want, but if you don't at least keep Operations Teams in the loop in as far as what is planned, everything mentioned is doomed to failure.
Andrew - good point. Would you agree that a good Architect and Lead Developer would already do that?
Well, I would agree that a good Architect and a Lead Developer should have the appropriate skillset to facilitate some of that, (even more so in smaller shops) but I would say that Operations Engineering is a very different beast than Development and I could see some friction between teams if Architects and Lead Developers are given such powers in areas where they are not proficient. It seems to me that their time would be better spent focusing on the overall development effort and working with the folks that are experts in deployment and running systems. Having those Operations-Minded folks 'in' with the development teams, they can help the Architects and Lead Developers be realistic and more successful in making their plans reality. No?
Andrew - you're right. My point is that a "good" Architect will in fact seek the input of teams like Ops and Security and so on, early and often. When I was an architect, I served as an "information broker" many times keeping everyone in the loop and well integrated. In fact, it saved our bacon more than once.
Fair enough... however this seems different than in your list of just 'knowing' the tech. Knowing it, and knowing how to deploy and run it, are two different things... perhaps the list could be amended to make mention of or make use of engaging these teams, as you say, 'early and often?'
Andrew - you just did. :)
Thanks for the comments, and the discussion. Perhaps you could do a post on "The most Valuable Ops positions" in a similar vein?
That list is in ascending order, not descending :-s