Anatomy of a Software Company, Part 1

In this set of blog entires, I’ll be reviewing the typical set of roles in a software company,  and their areas of responsibility[1].  Of course, different companies will have different organizational structures and job definitions, and the actual human beings that inhabit the roles will often largely determine the scope of their responsibilities.   I’m sure that we’ve all seen examples of people who join a company, and through intelligence and hard work, really redefine their role in the organization.  These kinds of people, by the way, are typically the most fun to work with, as they push and prod, and work to improve things.

Before I dive in, two final notes. First, on scope — my experience and comments are relevant to software companies, where I’ve spent my career.  Organizations in different sectors may well be significantly different. Second, on accuracy – I am, by necessity, simplifying things. Real organizations are reflect the complexity of reality, and are often messier than the prototypical firms that I will end up describing here.

At the highest level, software companies are typically organized around 2 major groups, with three smaller functional teams, and one operational team.

The two largest groups, in terms of headcount are

• Development — sometimes called Engineering, or Product Development
• Sales

The three smaller groups are typically

• Marketing
• Professional Services
• Product Management

And, finally, there’s typically a centralized operational group, often called

• Finance – which often includes the legal team

Within each of these groups there are typically several functionally distinct teams –

• Sales
  • Salespeople
  • Sales Engineers

• Development
  • Engineering
  • Architecture
  • Quality Assurance / Testing

• Marketing
  • Product Marketing
  • Marketing Communications (MarComm)
  • Field Marketing
• Finance
  • Operations (the “back office”)
  • Legal (for contracts)

Product Management, an organization that I’ve spent numerous years working in, can live in different places in different organizations. The placement of the product management team is often one of the most important and impactful decisions in an organization.

Next up : Anatomy of a Software Company: Part 2: Org Structures

[1] Actually, my bigger goal is to explore the structure and operation of marketing organizations within software companies, but by necessity, I first need to put in place a foundational structure around the overall company.

 

Engineer’s Guide to the Software Business : What is Marketing?

One of my most frustrating conversations in recent memory occurred a couple years ago, when I was working in a combined product management & marketing role.  This was at a small company – about 70 employees – and I was, in fact, the *only* person responsible for product management and product marketing.  As is always the case with product management, my job was multi-faceted – with big chunks of my time dedicated to working with engineering, sales & customers, and business development partners.

I also, of course, was performing typical product marketing functions – developing and refining our product messaging, creating content (presentations, datasheets, whitepapers), as well as executing outbound activities such as webcasts.  (We had 2 other people responsible for marketing communications & field marketing, who I worked closely with).

Enough context…the conversation in question was with one of the lead engineers on the team, who, in her very direct way, asked me “what is it, exactly, that you do?”.  She was asking me with a combination of curiosity, humor, and antagonism ; she knew quite well that, as product manager, I set each release’s functionality, prioritized customer enhancements & bug fixes, and helped write the stories for the engineering iterations.  She was really asking about the aspects of my job that were not directly visible to her.

Even as a very technical (and very intelligent) engineer working in a company creating software development tools, she was not very well aware of how the business operated – the processes and requirements around marketing and sales, or the overall dynamics of the business. In her particular role (combined with her personality), she didn’t frequently interact with customers or sales, so as I began to explain “what I did”, I kept having to back up, and provide some context for her.  For example:

…

“I define the messaging for the product”

“What do you mean, messaging? Are you talking about middleware?”

“No, messaging…how we position the product”

“What do you mean, position?”

“Position the product in the market”

“What does that mean?”

“Uh, determine how we describe the product, what its most salient features and differentiators are, and explain what the technical and business benefits are.  And pricing.”

…

When our conversation was done, she departed with a blank look in her eyes. Clearly, I didn’t connect with her.  She had so little context that I kept having to define my terms, which led us into a conversational labyrinth from which we were unable to escape.

Hopefully, this blog series will help address these kinds of misalignments, in some fashion.

My next series of postings take us on a foundational journey:  Anatomy of a Software Company

 

Engineer’s Guide to the Software Business : Introduction

To me, one of the most interesting aspects of my career in the software business has to do with my progression across different functional areas in the business, at many different firms.  In my 20+ years (!) in this business, I’ve worked as a software engineer (8 years), technical software consultant (4 years), and product management/marketing (8 years), in both individual contributor and management roles.

This has given me perspective, and (I hope) some wisdom that I can share here.  As such, I’m kicking off this thread, in which I’ll explain the hows and whys of software companies, aimed at a technical audience.  Thinking back to my first few software engineering jobs, straight out of college, I had no idea how software businesses could or should have been run.  While I was very fortunate to have been hired into my first software engineering job by an amazing technical team lead, who provided excellent technical mentoring, I was not so lucky on the business and management side.  This context is something I learned over many years, at many different companies –by watching what did and didn’t work, and asking a lot of questions.  Along the way I formally augmented my knowledge by obtaining an MBA (while working full-time as a product manager, with a baby at home….I don’t think I slept for 2 years).

Hopefully this series will be illuminating and useful to people currently working in the software business, who want to be able to understand the complete business context of their workplace, be able to better contribute in a more meaningful way, and professionally learn and grow (how can you argue with that?)

 

IT – Business Alignment, Part 3: Requirements

Let’s continue our thread on IT-business alignment, which we succinctly defined as “IT providing the services the business needs, at a reasonable cost and a reasonable level of quality”. Putting aside a more detailed analysis of “reasonable” for another time, we can examine how a business can define what it needs from IT, so that IT can align itself to those needs.

Operationally, there are several characteristics by which the business can define what it needs from IT:
1. Service Uptime
2. Service Performance
3. Compliance
4. Responsiveness
5. Productivity

In this blog entry, I’ll briefly examine these, and in my next posting introduce some sample scenarios to make these concepts concrete.

Note that the first two of these refer to Services — framing what IT delivers as a service allows us to view things from the business’s perspective, rather than from a technical IT perspective.

Service Uptime – this is where, on a per-service basis, the business defines what uptime requirements it has – both MTBF (mean time between failures), and MTTR (mean time to repair). Different businesses will have different requirements here, for different services. For example, a hedge fund will have extreme uptime requirements for its trading systems during market hours, but be relaxed about uptime during non-trading hours.

Service Performance – again, on a per-service basis, the business will define performance requirements needed. Our hedge fund will likely want extremely rapid response time for its trading systems – and be willing to pay top dollar for it – while an insurance company’s claims processing system would likely be less performance-sensitive

Compliance – this has to do with ensuring that IT’s overall operations meet the standards that apply to it, whether due to externally imposed regulatory policies, or form internally imposed security or operational policies.

Responsiveness – how quickly can IT respond to the business’ requests, such as on-boarding a new employee, or provisioning a new server or network?

Productivity (which is related to cost) – how efficient is IT at its tasks? It is using the most effective tools and processes?

In the next posting, we’ll look at some sample companies, and explore how these characteristics might apply to them.

 

IT – Business Alignment, Part 2: A True Story

Early in my career I had a first-hand encounter with IT-business alignment, which I’ll share here as an interesting example of this often vague concept. I was working at a mid-sized manufacturing company that produced commercial and industrial lighting fixtures, as a software developer on the “platform engineering” team.  

Selling largely into the highly fragmented construction business, this manufacturer sold through a large group of independent agents, who we had equipped with PCs and modems, running our own custom-developed ordering software.  At the time I joined, this ordering software indirectly connected to our mainframe, which processed order requests during nightly batch runs, returning delivery time commitments to the agents the following day.

My primary project at this firm was a technically interesting one, involving the creation of a multi-threaded broker running on OS/2 (I’m dating myself here), which received incoming order requests from those remote PCs, dialing in via a bank of modems. The broker we developed was able to take these requests, relay them up to the mainframe, and within seconds, obtain the response and return it to the requesting client.  (Obviously, we worked closely with the mainframe programmers on this project).  Writing such a broker, which had to handle asynchronous communications both upstream and downstream, was a challenge for the entire team, and one that I learned a lot from.

After we completed this project the CIO of the firm thanked us, explaining how we had all been successful with our “real jobs — selling lighting fixtures”.  As a young software engineer, I must admit that I found this statement amusing. But, as the CIO explained to us, from a business perspective we had made a significant contribution – not just speeding up order processing time, but enabling the company to change the way its buyers operated.  Instead of requiring an overnight batch job (like our competitors did), this new immediate processing allowed buyers to be more responsive to their customers, and (in turn) generate more business for both us and themselves.

I’m sharing this not to suggest that we return to the days of dial-up, but to illustrate the kind of business impact that a technology investment can have. This truly was an example of IT-business alignment – IT building and operating something that delivered new value to the business, helping it thrive.  Do you have an example you’re willing to share here?

 

IT – Business Alignment, Part 1: Introduction

Recently, I was reading an IT vendor whitepaper which featured “IT-business alignment” as one of the promised benefits of this vendor’s solutions. Putting aside the details of which specific vendor made these vaporous promises (in a particularly vapid whitepaper, I might add), this experience did spark my thinking. Truly, what is IT-business alignment? What does this really, practically mean? It sounds nice, but, like many terms widely adopted, has ceased to carry any specific meaning.

Looking at it literally, we could simply define this term to mean that IT is aligned to the business…that it provides the IT services that the business needs, at reasonable cost, and with reasonable quality. Is that a satisfying definition? Can we declare victory and go home early? Clearly not – while this definition may sound nice, it’s crying out for further analysis – let’s not be intellectually lazy (at least not today!).

The real answer is that how IT best aligns itself with the business depends on the business, and the business’ requirements from IT – both of which are multi-dimensional, and which can vary dramatically across firms. In this series of postings, I’m going to explore this term, and show some concrete examples of IT-business alignment, which will hopefully be meaningful to both business and technical readers of column.

Like most things, it’s best illustrated with a story. In my next posting, I’ll relate a true story about real IT-business alignment from early in my career, when I was a software engineer.

 

Backup, and Backup the Backup

Despite my inherent frugality, I’ve finally signed up for a paid online data backup service for our home computer.  For less than five dollars a month, I’m now covered – all our files are regularly backed up, automatically – reliving me of any worry about losing treasured photos and videos.

What prompted this was the increasing frequency of erratic behavior in this computer, which, in addition to acting as our photo repository, my wife uses for her teaching. I do have an external hard drive (and DVDs), to which I backup files irregularly, but I finally decided that backing up online was the more sensible approach – a backup to my (local) backup as it were.

Are you backing up your files? Are you prepared for data loss? Is it worth the few dollars a month (some services are even free). I mention this not to endorse any specific service (note I didn’t name the one I chose), but rather to help people understand that there are easy and inexpensive solutions that can prevent huge headaches (or heartache).  So, don’t delay, backup your data!


 

Turning Off Microsoft Outlook

If only! Like many corporations, my employer has standardized on Outlook as our email/calendaring client, along with Exchange for the server side.  Unfortunately for myself and millions of other users, Outlook forces us to work in the way it wants to work, rather than the reverse.  How should Outlook change? O, let me count the ways:

• Perform active organization by project – of email threads and documents – and let me set the priority

I can’t count the number of times an important email reply has gotten lost in my Inbox, while if it had been automatically associated with the high priority project, it’d have been immediately visible. This feature alone would make me significantly more productive.  This very month, a moderate-priority document got delayed by a week-plus because of this.

• When I receive an email, I should be able, with one click, to set up a corresponding action, such as
  • Assign a tag to this email so it gets associated with a project.
  • Create a task so I am reminded to followup on this email
• When I send an email, I should be able, with one, click, to set up an expected action to occur in the future

Example: I send an email to a colleague asking her to review a document. I would like to set a reminder so that if I haven’t heard from her within 2 days, the system can automatically remind me to remind her.

• Help me keep my Inbox empty! As of this moment, I have 1,045 emails in my inbox. Yes, I get a lot of email, but there has GOT to be a better way of managing my work

For example, I should be able to easily triage email on the fly. In fact, Outlook should know, based on a subject line, how to triage an ongoing email thread for me.

Any other thoughts, readers, on ways in which Outlook impedes and frustrates you?
Why aren’t there any good Outlook supplements or replacements, which can work with Exchange servers?  It can’t be a purely technical issue, as the Novell Evolution client can connect with Exchange…

 

It’s a Matter of Perspective

Check out these two headlines I encountered yesterday, reporting on recently reported search engine market share data, from comScore:

• Silicon Alley Insider : “Bing’s First Month A Bust”  http://bit.ly/nAQKD
• CNN Money: “Bing gaining on Google and Yahoo” http://bit.ly/5wYXR

These are based on the same data!

The facts are that in its first month of operation, Bing increased Microsoft’s market share from 8.0% to 8.4%.
Google’s share was unchanged at 65%, while Yahoo! slipped from 20.1% to 19.6%.

I side with the “bust” perspective – a 0.4% increase for Microsoft is not anything to cheer about, considering how widely the Bing launch was covered.

I haven’t done any analysis of the historical data, but 0.4% seems awfully tiny to extrapolate a trend from. Time will tell, but a more accurate headline would have been “Bing Gains on Yahoo!, But Google Holds the Line”.

How do you think this should have read?

 

Back to Blogging

If I were truly concerned about engineering my online persona, I would back-date a posting to August 2008, and state that I was taking a sabbatical from this blog.

The reality is that work and family obligations (rightly, so, I must say!) took precedence here for the last 11 months. While I’m still as busy as ever, I do feel that I will now be able to devote a little regular time and effort into this, despite some aggressive and interesting projects at work. Time will tell!