Onboarding, right and wrong ways to do it

Something I came across a long time ago, but still brilliant:

My friend Peter started working at EvilEmpireSoft on the same Monday that I started at Geekaplex. That Friday, over beers, he told me that he had spent most of his first week waiting for his laptop to show up. When it finally showed up, it had an outdated version of the development environment installed which couldn't compile the code he was supposed to be working on. On top of that, Outlook was misconfigured and wouldn't even think about connecting to the mail server. He spent an afternoon figuring out the configuration only to discover that his email account hadn't been activated yet! "It's as if they were surprised when I showed up for work on Monday. Maybe they forgot that they hired me? I spent the first morning waiting in HR until someone was available to give me paperwork to fill out. After that," he went on, "I spent the afternoon wandering around looking for an empty cube to claim."

I felt bad for Peter, and I was almost embarrassed at how different my first week had gone. My office was just down the hall from my boss's. There was no mistaking that it was mine, as my name was on the plaque next to the door. Inside, I found a shinny new ThinkPad with a docking station and a pair of flat-screen monitors. The drawers in the desk were filled with new pens, pencils, paper, a stapler, and even a box of freshly printed business cards. My boss sat down with me and walked me through my first week, pointing out the various meetings and training sessions that were already on my calendar. There was even a welcome email from the president of the company waiting in my in-box.

"Wow!" Said Peter, "You're like a VIP over there! I feel like most folks don't know I exist, and if they do, they are just hoping that I won't bother them. It really sucks. EvilEmpireSoft seemed so cool and together when I interviewed, but now I'm wondering how they get anything done. They aren't the elite, well-oiled organization that I imagined them to be. I feel like I made a big mistake accepting their offer."

What a big difference attention to detail and a little preparation made. By simply taking the time to provision my office, my boss sent me a strong positive message about the company, and how much they valued me. Additionally, by making sure that I had all the tools I needed to be productive, they let me know that they expected me to be productive. I felt like Geekaplex had it together, and that they would expect me to have it together as well. I felt welcomed and challenged.

Originally posted here:
blog.technicalmanagementinstitute.com/

Value, productivity and metrics

This is a response that I made to Ravikumar Mohandes on the Software Engineering Productivity forum of LinkedIn, on the topic "How do you measure (software) engineering productivity?". Ravikumar wrote:

Ultimately productivity has to be defined in terms of the dollar value created. Organizations or groups that can map their contribution to a project to the company’s bottom-line are usually found to be highly productive.

In other words, measure a group's productivity by the profits generated and the business opportunities created.

You can find the whole thread (114 comments) on LinkedIn, and there was much to-ing and fro-ing about the value or otherwise in software metrics being used to measure, well, pretty much anything. There was a very heated debate with Capers Jones (a consultant who sells information to clients based upon metrics that he's been collecting for many years) arguing very strongly for metrics, and several others (myself included) arguing against. That part of the conversation by-the-by, I'd like to highlight my response to Ravikumar, as the statement:

"Productivity should be defined in terms of the dollar value created"

is accepted as a god-given truth in most business and project management circles (at least in my experience), and whilst I think that the merit in this is generally accepted in the manufacturing world, things are very different in the software world, and this is something that is often overlooked.

So without further ado, my response:

---
The problem is that you are now in the realm of accountancy, and as any decent accountant will tell you, there are many different ways of measuring profit, and even a simple to measure "revenue minus cost of sale" may not be a very good measure of "value to the business".

Leaving aside for a moment the selection bias present in the choosing of "profit" as a measure (it is possible for a business to be bankrupt even if profitable, as cash-flow is often more important, for instance), it turns out that the two components of the measure: 'revenue' and 'cost of sale' are actually a bit more difficult to measure than you might at first imagine. For example:

Revenue - do you only count the money that the customer pays you up front? Do you count any service agreement amount? How is this amortised over the duration of the service agreement? All up front? Evenly over the course of the contract? Only accounted for on contract completion? Discounted over time on a risk-profiled basis? Are you taking into account TVM coefficients? What about repeat work? (as the cost of acquiring a new customer is often many times higher than selling to an existing customer) are you factoring in the value-add that producing a high-quality project will have in getting repeat business? If so then how are you calculating this? How do you measure quality and customer satisfaction? Over what time period is it necessary to wait for a customer to make another order in order that it is counted as a 'repeat sale' and hence factored into the calculation of business value for the previous project, rather than a new project? ...

Cost of sale - Are pre-sales activities factored into cost-of-sale? Are general business expenses factored into cost of sale (e.g. business rates, payroll cost etc.)? If they are, then how are the CapEx and OpEx split between different projects? Evenly per project? Proportional to final value? If so then how is final value calculated? If you have projects that re-use components from other projects (and this may be learning and knowledge, rather than hard code for instance e.g. product training), then how is this accounted for in your cost-of-sale calculation? If this is a sale into an existing customer, how much of the cost-of-sale value is accounted for as being due to the successful outcome of a previous sale, and therefore shared between the projects? If not, then how do you compensate for the artificial inflation of 'first sale' project costs? Are we taking into account taxes? (i.e. difference between EBITDA and NOPAT) If NOPAT then if a project spans accountancy periods, how do you determine which period it is included in in order to determine what it's tax liabilities are? ...

This is just skimming the surface of what corporate accountants deal with every day. The reality is that 'profit' can mean pretty much whatever you want it to mean, and every answer to every question above affects how it is determined, and how your projects will stack up against one another. The reality of running a business is that you can never truly know the exact state of the accounts until the business is wound up, everything else is surrounded by guesstimates (e.g. deal closure rates), assumptions (e.g. tax banding by operating profit on next fiscal year's books) and fudge factors (e.g. payment default rates and average invoice payment delay).

My message here is really: "think very very carefully before suggesting metrics like 'profit', because although they seem simple to calculate to the lay observer, the reality is very very different".