I’ve had the pleasure of working in IT twice in my career these last 25 years. Both times were short stints as I came to my senses rather quickly. I love IT and what they do to help enable the business, but I hated being there. Each time I left the building running as fast as I could, screaming from the top of my lungs with joy, vowing I’d never do it again. There is just something about being in the development ranks within IT that is night and day when compared to working in similar positions for a commercial software company. I would say that if you work as a software development professional within IT you should run, not walk, to a commercial software company to see how the other half lives. You’ll never feel better. Here are just a few reasons off the top of my head:
• You are a cost to the business vs. a revenue generator
Let’s face it, in IT you are a cost. A cost the business hates and often considers a tax. It cannot fathom the value it receives for the allocation $ that are an uncontrollable line item in their cost centers. They know in their heart of hearts that if they were given those $ directly and hired their own technologists they’d get far more done, quicker, better, cheaper.
The reality is that you are not the primary force behind the product that is being sold to generate revenue for your company. The real stars of the show are the product folks—they are at the center of the business universe. You are simply a cost that helps the back office work more efficiently. You are seen as the annoying gum on the bottom of the business’ shoes. You are a cost that needs to be controlled and reduced.
In commercial software the roles are reversed. The technology is the product and is the revenue generator for the business. What you create is what is valued by all organizations across the entire business. Yes, you may even be considered kings in some of these elite software organizations. There is an IT group where you work, but they are the allocation on even your own cost centers as they work in the background to help the back office flow smoothly.
• You don’t really have a customer
In IT your customer is really difficult if not impossible to identify. Often it is any business user with an opinion, right or wrong, timely or Johnny-come-lately. As a technology professional you are also set up for failure as you don’t have a Product Manager or true Product Owner. In IT you might be lucky enough to have a business partner who is supposed to be the voice of the customer, but in reality you find that they don’t speak as a single unified voice. You find that they simply represent an opinion and that opinion really doesn’t carry much weight beyond perhaps their own group or department. When trying to map their perfect world on to other departments when it is time to do a rollout you find that they lived in a fantasy land. Their fault? Of course not; you built the solution and you spent/wasted their money doing so!
In commercial software it is really easy to identify your customer. They are the ones who reach in to their wallets and pay for your products as well as any subscription or maintenance fees year after year. By the time they reach for their wallets they are eager to consume what it is you are providing. If they continue to pay for your solution it is because they are truly delighted by the products you have provided them. When creating your product you have the strength of a Product Management team and Product Owners who truly represent the collective voice of the market and the customer. They know that they cannot please everybody, and that everybody’s individual opinion or request isn’t a show-stopper. They know that they have to create the best solution for the masses and not just for Bob or Sally down the hall. They know that part of their full time job is the juggling of conflicting input and at the end of the day making the call as to what is the right thing to build for your business to prosper.
• You live in the land of customization
In IT you are always building a customized solution or modifying something in to a customized solution. Let’s face it, your business users are the amazing experts at their own home-grown back office business processes. It is your job to make sure that your software is customized to match that industry best practice process that Bob and Sally invented while hunkered in their bunkers each day. As an aside I must admit I laugh each time I see how many tens to hundreds of millions of dollars were wasted on a failed ERP implementation. Often the culprit was all of the customizations that either broke the solution or didn’t scale beyond the pilot deployment group. How many times would the implementation have succeeded at a dramatically lower cost had the solution been rolled out vanilla, with Bob and Sally either been trained how to do their jobs differently (or replaced with Tom and Mary who were not locked in to their home-grown process)? This is the life of an IT software development team—building and customizing to whatever spec Bob and Sally demand regardless if it is the right answer or not.
In the commercial software space you are creating a solution that is intended for a broad audience out of the gate. Where there are customizations, you have enabled those either through self-service configuration screens and options or through open APIs and Web Services. Your solution isn’t intended to simply automate what Bob and Sally invented, it is to bring to them a best in class answer that leverages the best practices that you have seen across an entire industry. It is to take what is more efficient and free their time up to do other things for their business. It is to delight them with these better ways of doing things vs. doing it their particular way.
• You work on single event projects vs. products
As a software developer or QA professional within IT you are often working on single “fire-and-forget” projects. The business sees these as one-off efforts that will help solve a particular problem the business has in its back office workflow. When funded, these very rarely contain any funding for future sustainment work. The assumption that is often made is that if the solution needs any updates, they’ll just go out and get funding down the road for another project to do that work. That or IT will simply “eat” the costs. Another strategy employed is to try to “get the world” while you work on this current project. Where they do fund sustainment it is often with only a skeleton crew who is doomed to triaging every conflicting input from rather opinionated end users. Who knew Bob and Sally had relatives?
As an IT resource working on fire and forget projects you are also considered to be a fungible resource. Have an extra 3 hours on Thursday? Go work with Team W and knock out one of their stories for them even though you never heard of the project before vs. refactoring something in your current project. Context? Who needs time for gaining knowledge or context switching? You just pump code or QA it, right? You are simply a nomad who wonders from project to project, being summoned for your domain knowledge on a past project you worked on over five years ago and are expected to have instant recall. You are expected to help without impacting your current project.
In commercial software you are normally working on products vs. one-off projects. These are solutions that have a lifecycle and multiple versions. In their releases and even in their Agile sprints the teams and management are aware that they need time for new features, time to refactor old code, and/or time to do sustainment work on features already in customers’ hands. They know that they cannot shove everything in to the current release and that they have future release to do something even better, based on real customer feedback vs. trying to guess everything right the first time. They know that they can use multiple releases to phase in major architectural changes or a major feature that is “turned on” a release or two downstream when it is ready for consumption. These product teams are a highly collaborative unit who continuously ratchet up their best practices.
• Time tracking
In IT the business doesn’t trust you. They think you are a group that is overfunded and constantly under deliver. Because they wonder what you do all day they make you track your time. If they don’t make you track it, then the CIO does so because he/she has to justify how you spend your time to their untrusting business partners. I even worked at one place once where you had to account for every 10 minutes of your time on a timecard and they paid auditors to walk the halls to ensure that each and every timecard was up to date vs. something you filled out at the last minute on Friday.
In commercial software, if you track your time it isn’t because the business doesn’t trust you. It is to help become better estimators over time. It is to help understand what your true capacity is such that they can help you. Quite a different dynamic at play.
• Fixed bid projects with open ended requirements
In IT you participate in a very crazy yearly budgeting process. The business wants something automated and attempts to create a project to make them more efficient at something. As such they ask IT leaders to “name that tune” very early in the process often based on nothing more than a concept. Of course the $ and hours quoted are too high and they don’t believe you as you cannot prove it’ll really cost that much (due to their own vagueness in what it is they want). They squeeze you until the stone drips blood and then they run off to secure funding. If they receive the funding it was less than even your bargain basement estimate. Once the project is underway you find out that the go-cart they received funding for needs to sleep 6, have a bathroom, running water, electrical, WiFi, and can tow a boat. You argue that the requirements are changing and will cost more in time and money. They argue back that nothing has changed: you always knew they were funding a vehicle. Go figure…
The other thing that can happen in IT is, because of how projects are funded, they know they only have you held captive for a fixed amount of time. In a world where sustainment costs are often not modeled the belief is that if you don’t make your 1.0 release the equivalent of a 3.0 that they’ll never see you again and they will never get those future downstream features and enhancements funded. It is also the opportunity while you are being held hostage to sneak in any tag along hitchhiker features they can think of. Of course none of this was taken in to account or budgeted for, but then again they are paying you too much for this project so you just need to suck it up.
In commercial software the organization knows that you only have four levers: scope, quality, budget, time. You also know that quality should really have a fixed position (something rarely taken for granted in IT) and that budget and time are often linked. That leaves scope as the main or only lever that can be moved. Because you have a Product Management team that understands the market, has modeled the competitive landscape, knows what customers want to pay for, and has modeled the revenue stream they know how to prioritize what needs to come first. They know what needs to be gold plated and where something else needs to simply be a checkbox. These ninjas ensure the teams are working on the right things for the right reasons. They may not like the trade-offs due to your technical team’s capacity during a release, but unlike IT business partners they don’t always try to play the victim. They may push you, but they are not constantly trying to cram 25 pounds of potatoes in to the 5 pound sack that was funded. Why? In commercial software they go down with the ship right along with you whereas in IT they can fire shots in to the boat without care as they are standing on the dock.
• Elusive ROI calculations
In IT trying to get a project funded is next to impossible. Quite honestly the business has a very hard time coming up with any form of ROI calculations that justify the funding of any technology effort. One of the primary reasons for this is the business has no problem looking at ROI when it comes to IT cost savings (after all you are a tax that needs to be reduced), but it really wrestles with ROI that involves signing up to their own operational savings and efficiencies. Good luck trying to get many business sponsors to model how much more productive the business can be with this solution in place, how many fewer people would be required, or how it can save money in the future by reducing their own departmental budget needs. Go figure…
In commercial software the ROI is pretty simple to calculate given the technology is the product that is sold to customers. Depending on the maturity of the product, it needs to generate between 7 and 10x in revenue over the cost of developing and maintaining that technology each and every year. Why that high of a multiple? It is simply the inverse of its expense plus a margin when compared to the rest of the company: R&D is an expense and what it creates has to also cover sales, marketing, finance, HR, operations, and some margin for the company. In professional services organizations the return is a much lower target (sometimes even as low as 1.3x). It is much easier to run the numbers backwards even when looking at individual product feature enhancement requests in commercial software than in IT. You want to delight your customers, but at the end of the day you can only do so if you are still in business. This fact of basic survival keeps the math pretty simple.
• Lousy pay
Whether software development talent in IT wants to admit it or not, there is a caste system. At the end of the day you most likely make less than your counterparts at commercial software companies. This is for several reasons. The first of which is commercial software companies strive to hire tier 1 talent; they want their people to be so good at what they do that they indeed command the 75th percentile or hirer in compensation. They are looking for folks who have computer science degrees and years of experience being on successful commercial software teams. Those folks who work at commercial software companies on these teams really don’t apply for similar software jobs within IT. They love working on teams who create products that delight their customers day in and day out and tend to go to other commercial software companies.
Because IT is a cost center relegated to the operations of the business it is often looked at as a group where costs must be tightly controlled. If this means taking knowledge experts and trying to teach them how to code, then so be it. If it means hiring people in the lower quartiles of compensation, then so be it. It is also a group where commercial software development talent really doesn’t apply for these positions; why would they?
• Stale talent with too much specialization
In commercial software folks tend to move around much more, perhaps every 3 to 5 years. Those who work at startups tend to move around even more so as business models more often that not fail regardless of how good the technology is (the case of building the wrong thing well). That said, because commercial software development talent moves around more than their IT counterparts they are exposed to numerous best practices. They also tend to stay plugged in to technical communities, user groups, and forums as they are great networks to leverage when it is time to land their next job.
In bloated IT organizations you also have the issue where job specialization actually harms individuals and their resumes vs. helps them. In IT, for example, you may have very distinct job descriptions for Data Modelers vs. those who create Data Definitions for relational databases, manage databases, create SQL, optimize SQL, create Extraction Transformation and Load (ETL) jobs, and who code and test transactions to those databases. That over specialization in IT limits their ability to apply for and succeed in commercial software jobs.
In commercial software those same eight separate job descriptions in IT could easily be covered by one or two Sr. SQL Database Engineers. In commercial software there is specialization, but knowledge workers end up having broader skills even within a specialization.
• The business hates you for other reasons too
Here’s a dirty little secret: In IT as a software development professional you often make more than many in the business do, which fries many of them. This simple dynamic of knowledge worker supply and demand and the value placed on technical talent often drives your counterparts in the business nuts as you estimate projects for them. I’ve even seen it drive professionals in service organizations such as finance and HR bonkers and they should know better. Many believe that by being in IT you are simply doing back office work; how is it possible that your folks may make more than many of theirs do? They believe that product people should make more; in their eyes it just isn’t fair.
In a commercial software company this underlying resentment against the cost of technical talent just doesn’t exist. Because the software development teams are responsible for creating the products that the company sells you just don’t find it amongst business partners and other functional groups. If it is there, it isn’t out in the open as a festering wound like it is in IT.
Quite the list, no? Don’t believe what I’m saying? Simply ask somebody who has worked in both types of industries. I’ve only sampled some of the differences off the top of my head—there are many, many more. I’ll let those who feel like commenting add what they’ve observed.
So, are you currently working in IT as a software development professional? There is nothing wrong with that and your business really needs your technical talent whether they think so or not. You should take pride in the value that you add to the business each and every day. That said, if you are feeling underappreciated, there is an entire commercial software industry that gets what it is you do, why you love to do it, and it truly does value you. It may be difficult to break out of IT and join the commercial software development ranks, but if you can you’ll be glad you did. I’m glad I’m back!
One of the best articles I’ve ever read on this topic. Cory House pens a great piece on why, as developers, writing clean code really matters. In one section he compares developers to authors and makes the assertion that each line of code one writes is likely to be read 10 or more times by others during its lifetime. That’s probably 9x more than this blog! ;O) Enjoy the article here… It is a gem…
What did we do before Google came around to remind us of all the great events in history? I am glad they called out today was the 150th anniversary of Abraham Lincoln’s famous Gettysburg Address, but am disappointed at the same time they chose not to have a Google Doodle for such a historic event. That said, here is what Google shared: “150 years ago a 2-minute speech shaped a nation“. A lesson in how such few words, when penned and delivered by a master orator, can have such a huge impact…
In the last few days the #firstinternship tag has become one of the hot, trending tags on Twitter. I remember my first internship quite well as it is how I got my first real start in computers. I was between my freshman and sophomore year in high school and instead of going to summer school, I decided to volunteer to teach teachers how to program in BASIC so they could create computer assisted instruction courses for their students. It was a blast. That lead to my first official internship with the high school my sophomore year being the proctor of their Data General Eclipse and Nova mini computers. From there I went on to create football scouting programs that year to allow our coaches to have up to date software predictions on what types of plays competing teams tended to run in various situations based on how they played their previous games to date. I think I even snuck in a computer dating program in on the side for the seniors that first year, but we won’t go there.
Internships—paid internships mind you—are such an important part of helping young minds find themselves and to identify what their career passions may be. Before doing this I was convinced that I wanted to be an architect and design buildings and civil engineering structures (this before the days of Computer Assisted Design software). Within a few short months of my first internship, doing something totally unrelated to architecture, my destiny was changed forever, and here I am today…
Do you have a “first internship” story? Please share it in the blog comments.
Does your Agile Team actively try to recruit and hire at least one intern a year? If so, please share your success stories as well. I’ve found internships to be one of the greatest gifts a manager can give—not only to the student, but to their team as well…
When I was a newly minted manager Symantec sent me to a Communication for Results class 3 times. Yes 3 times since as a propeller head and newly minted manger it just wasn’t sinking in. After the 3rd time I finally got it. It is a communications template for having difficult conversations with employees and/or business partners where a behavior needs to change. I’ve used it for 20 years with great results… It goes like this:
1) I’ve noticed that <behavior>.
2) It may be because <excuse>.
3) The impact it is having is <short list of impacts>.
4) It makes me feel <feelings>.
5) Let’s talk about this <some later date>.
Some psychologist way smarter than me figured out that this format for difficult conversations worked better than just about any other methodology. Being an engineer, I asked why the format was what it was. Here is what they shared:
1) “I’ve noticed that <behavior>” calls out the behavior that needs to be fixed/resolved. It states the problem that needs to be solved with what the employee is doing wrong that needs to be fixed or changed.
2) “It may be because <excuse>” hands them an excuse such that they are not thinking of a comeback and, while thinking, no longer listening to the rest of what you have to say. It also shows them that you have empathy to think through why this might be going on and that you care about what is going on with them vs. simply being an evil manager.
3) “The impact it is having is <short list of impacts>” lists the factual negative impacts of their behaviors on the team, project, etc. These are the things that will be better once they change the behavior you are calling out. Should be a short list and not a laundry list. You don’t want them to quit listening and to go on the defensive. You also want to be able to finish the 5 step formula of what it is you want to articulate before they jump in–make the list too long and it doesn’t work as they feel attacked and against the ropes.
4) “It makes me feel <feelings>” is an easy way to take the person out of the mental state of wanting to argue with the impacts you just listed. It helps to de-escalate or disarm the encounter. Your feelings are your own and nothing they do or say can change how you feel. Most people realize this as a futile exercise.
5) “Let’s talk about this <some later date>” allows the person to not feel threatened or cornered. It lets them know that they don’t have to think on their toes and try to defend themselves immediately. Coupled with the free excuse you provided early it defuses what could sometimes be an ugly situation. It also gives the person time to reflect on what you said. To think about the behavior, the free excuse you handed them, and the impacts (they may or may not care how it makes you feel). It gives them time for all of this to sink in.
The end goal of this formula for difficult conversations is to have a productive conversation. Resist their temptation to have that conversation now though.. They really do need that reflection time. Have it later. If that later conversation goes down a rat hole and doesn’t lead to productive results in an acknowledgement or a plan to change that behavior then retreat back to the formula.
At the end of the day the employee will either work with you to change that behavior or they will not. If they don’t then you can have a conversation just about that unwillingness to change. Finally, you have all the bullets you need for a Performance Improvement Plan.
Example: Morning Ralph. I’ve noticed that you haven’t been making it to our morning standups. It may be because something has changed at home and you’ve had to take care of things and have not been able to make the time. The problem though is this is the one time where the team gets together to share what they need from each other in terms of help and assistance for the rest of the day and with you not available, nobody can coordinate with you. This means that their stories are impacted as they cannot get with you for the help they need and you haven’t been as productive as you can be because you are not able to coordinate their help. This makes me feel that I cannot rely on you to help the team make its goals and commitments. It makes me agitated that I have to coordinate things later in the day that should have been taken care of at the standup. Let’s talk about this tomorrow afternoon as I’d like to know your thoughts on how we could possibly resolve.
Give it a try…see if, as a manager, it helps you have difficult conversations with your employees vs. avoiding them.
I love Agile. I also love Performance Objectives and Management By Objectives.
There was a product manager (a position often found in commercial software companies and not in IT) that I knew once who was the product owner for an Agile team. In this role this person was responsible for the what and the why whereas the team was responsible for the how. That said they couldn’t make a decision if their life depended on it. It was always “well maybe we could do this” and “well maybe we could do that.” I swear, if they were standing in the street and a loaded tractor trailer rig was barreling down on them full speed from blocks away they would have analyzed all of the possible moves and potential outcomes, but at the end of the day they would have wasted all their time vs. just getting out of the way. I’m serious. One would think the agile thing to do would be to get out of the way, then upon reflection in a retrospective (after they achieved their goal) decide if they would have done so differently with even better results next time. Not so in this person’s case.
The problem for this team is that they never had any story cards to work on. There just weren’t any. There were just so many unexplored options that had to be considered and evaluated by this product owner. On the flip side it did make it really easy to groom the backlog…there were no stories to groom. Time would slip by with the team doing busy sustainment work vs. actually working on new product capabilities. Marketing, Sales, and Management were not too happy about the situation as they wanted new, meaningful product releases that lived up to the hype of what was promised to them in various meetings earlier in the year. There was a lot of finger pointing back and forth as commitments were missed, but at the end of the day the development team was always hung out to dry. After catching the blame one too many times the team finally revolted, self-nominated their own product owner to act as a proxy, and simply leveraged the product manager for input.
There was another case of a different product manager who as the product owner for an Agile team who had a very similar problem, but they had no issue when it came to making decisions. They made lots of decisions; tons of them every day, but most of them revisiting previous decisions. Not only would they think “well maybe we could do this” and “well maybe we could do that”, but they insisted on taking the development team along with them for the ride. Every idea was a story and this product owner would insist on even interrupting the sprints to change the stories out from underneath the development team as they were working on them to try the other alternative. I know Agile is designed to embrace change, but the healthiest change is scheduled for future sprints (one should never really ruin the cadence of the team by messing with the current sprint in flight). That said this product owner would shout from the rooftops “Agile is supposed to allow me to change my mind and you are not being Agile if I cannot change what the team is doing whenever I want; we might as well go back to waterfall!”
In this case the development team just thrashed as it constantly reworked code over and over and over again. They couldn’t even try to spin it as “refactoring” as they were in a constant state of rewriting what had already been done. As you can guess a similar blame game came in to play near the end of the project: the development team had an innate inability to make its commitments to the business.
In both cases these product owners were experts at always throwing the development team under the bus for missed schedules and commitments. They felt that they were playing their roles and were therefore doing their jobs.
So what does this have to do with Performance Objectives?
My issue, quite frankly, was that everybody’s top job should have been to deliver high quality products on time that delight customers. Period. Doing so should have been the shared performance objective for the product owner, scrum master, and all the team members.
It wasn’t that the development teams were not making their commitments; it was that the Agile teams were not. Let’s rephrase this: If the development group isn’t making their commitments then the product owners should share in missing that shared commitment as well. Had the product managers also had this shared objective as part of their own performance objectives then everybody might have worked together much better.
As many of you look at 2nd half of the year and are revisiting your performance objectives for the second half, let’s make sure that everybody is a pig and nobody is a chicken.
Don’t know what I’m talking about? Go to Google and type “Agile pigs and chickens” and enjoy. Wikipedia has a quick recap: http://en.wikipedia.org/wiki/The_Chicken_and_the_Pig
About this series: I love Agile; I also hate Agile. I love how it can free teams to truly delight customers while delivering high quality products on time. I hate how Agile zealots can use the Tower of Agile Babble to confuse the heck out of teams trying Agile on for size. My goal is to help new teams actually embrace and become Agile without having to learn all of the pomp and circumstance in one big fat swallow.