The Role of the Corporate Developer

01/05/2015 by Chris Toohey

Before we get started, let's define the "corporate developer". A "corporate developer" is an employee of the company's IT department who is tasked with individual assignments for various business units. They code, design, deploy, and maintain applications (and most often, the application platforms) that are used throughout the organization. They are also often forced to concede best practices and established development standards for the constant "the VP of Finance needs an Excel export of the [data from their application] from this past year to date" scenarios.

I submit that there are three "corporate developer" archetypes, and I urge you to be honest with yourself about which one best fits you today and make a decision about which of these you actually want to both personally and professionally identify you... because - and you'll have to trust me on this - the decision makers in your organization will identify you in exactly this way.

Those Who Don't Want It

This corporate developer is an expert with their given development platform(s). They know every application within the organization inside and out, and can quickly - and with absolute confidence - make a business logic change to in-production code to address whatever the ever-evolving organization demands.

They are often reluctant to deploy the latest releases of their platform for one or more of several reasons:

1. They do not know how the latest platform will work with their existing applications or services - core, in-house developed, and third-party/add-ons.

2. They are not familiar with the latest development techniques and/or languages presented with this new platform, and are too busy maintaining to read countless blog posts or whitepapers to get themselves to the point where they feel authoratative.

3. They "know better", but if they're the only one making changes, things like "documentation" and "maintenance windows" aren't really a high priority when they themselves are the only ones that'll ever read them.

4. They are perfectly content with their current knowledge and skillset and do not feel the need to invest personal time in learning.

Specifically on the topic of "learning", most often any development or platform-specific training is "on the job" training, and there never seems to be enough of a budget within the department to send them away for the week to an offsite class... and who would maintain these applications and services while they were away?!

These developers are often left out of the decision process, mostly because they already know what the answer will be: "Yeah, we should use [the platform that the developer knows]!". As a result are constantly left in the dark, the developer fearing a migration to a competing development platform.

It really doesn't help that those competing platforms appear to have every feature and function that your user community is begging for or outright complaining about their current solution not having. You tend to lose the fight with Marketing when the competition establishes that mission critical feature: "You mean I can get this on my phone, too?!"

Those Who Are Above It

This corporate developer is proud to consider themselves an absolute expert in bleeding edge technologies and methodologies not only on their core development platform(s) but every other platform out there. They bring an "outside world" perspective to every meeting and are often sought after for their guidance and insight on topics that are often well outside of the "corporate developer" job description.

They are often behind on their projects due to one or more of several reasons:

1. They are trying something they read about on a development site that is a "much more globally acceptable best practice" or otherwise "better" than the current way something is done using the platform(s) available.

2. In an attempt to showcase their abilities and prove "just what the platform is capable of", the developer introduced massive "feature creep" and extended the scope of work far beyond what was originally requested.

3. They are too busy being pulled into meeting after meeting with department heads and other VIPs to actually work on the project.

4. They are bored with the project, often due to a smaller scope or featureset than they are capable of developing.

These developers often cringe when their phone rings or complain when someone (that isn't a VIP) contacts them directly. If they're behind on the project, they even let the call from a VIP go to voicemail citing they "should be calling [my manager|the project manager|the helpdesk] instead of me directly!".

Eventually these developers - despite being absolutely amazing developers - become a management nightmare. They produce great work... when they produce. They spend more time in an R&D capacity than they do in a Development & Support role. Pretty soon the developer gets their wish and the phone stops ringing, but that's often because Marketing secretly hired a consulting firm to work on their project instead of "wasting time going 'in-house'."

Those Who Get It

This corporate developer has been a developer Who Didn't Want It and used to consider themselves Above It. It took some time, but they finally understand their role within the organization: it is their job to ease the work of others within the organization, to improve where able and appropriate but never to showcase their individual abilities, and to quickly and expertly address any issues that are keeping employees from effectively and efficiently doing their job.

They are often too busy:

1. Deploying and training employees on how to use their applications.

2. Establishing corporate development guidelines and standards, and ensuring that everything from application user interfaces and user experiences to code and architecture meet said standards.

3. Writing code designed for ease of maintenance and multi-purpose application wherever possible.

4. Learning and becoming an expert on the company's other technology platforms and IT investments both to learn integration points as well as what platform is best to address a given need in the organization.

5. Learning and becoming an expert on transferrable skills, industry standards and best practices, and at least enough about project management that you know when to add to and when to subtract from scope.

6. Keeping up to date on latest trends and how they will affect your corporate development guideline and standards.

These developers deliver, and it's the platform-agnostic and IT investment-minded approach that keeps the business units coming back and asking for them project after project. These developers have established themselves as the go-to people in the organization for solving a business problem or improving a given practice. They make management look great by always delivering and are supremely confident that as long as the company is around they will have a seat at the table.

So How Do You Rate?

If you're being honest, you see yourself in all three of these archetypes.

• You're proud of your ability to think outside of the box and confident that you have the skills to add functionality to a platform where the vendor dropped the ball... but you find yourself trying to "re-code the wheel" far too often.

• You often find that keeping on top of the latest features and capabilities of your platform - especially those that aren't "sexy" - is tedious.

• You're love for your platform of choice can exclude you from directional meetings even before the invites go out.

• You've been cheered for delivering. You've been cheered for over-delivering. You've been in your manager's office and in the hot seat for not making a deadline due to feature and scope creep (that you brought on or otherwise didn't manage).

We'll all been there. Hell, while writing this article it started to look more and more like a diary. We all slip into these archetypes, but it's absolutely critical to our individual success that we try to be someone who Gets It versus those who consider themselves Above It or simply Don't Want It.

Conclusion: The Role Of The Corporate Developer

In a word, the Role of the Corporate Developer is to enable. We're there to make other departments run smoothly and to ensure that the employee has the tools to do their job as efficiently and as effectively as possible.

If it means that we quickly crank-out an application using built-in functionality and Rapid Application Development practices natively available on the platform, that's our role.

If it means that we abandon the established standards and create something completely unqiue and "one-off" that extends the scope but ultimately delivers an enhanced experience that results in a more productive employee, that's our role.

And if it means that we look to other platforms, learn new techniques, and consult on the best way to solve business problems not born from personal preferences but research and facts, then that is absolutely our role.

So the challenge still stands:

I urge you to be honest with yourself about which one best fits you today and make a decision about which of these you actually want to both personally and professionally identify you.

If you're up for sharing, let us know in the comments below.