A promising young software professional recently asked me about the roles that exist between the customer and software engineers in a “typical” company. My initial reaction was to describe a cross-section of business analyst, product manager, and software architect roles. On later reflection, I realized that I was taking the basis of my own answer for granted. This post is for you, youngster! I will attempt to describe some of the organizational structures I have experienced, relative to where the developers typically reside.
I thought it would be good fun to separate these structures into company size, because a software engineer’s interaction with the rest of the company differs significantly based on that factor.
Company Size: Small, or Startup
The diagram below is my own interpretation of the small/startup senario. The blocks represent one or more people in a team. Customers are communicating from the hypothetical cloud on the left, to the organization on the right.
In a very small company, there is probably a minimal layer of management; there may or may not be a high level tech leader like a CTO; maybe there is only the founder or a CEO. The Development organization is probably very lean, with a mix of junior and senior developers. The Sales and Marketing team might be the same person; the Services/Support team may be similarly lean.
In a very small organization like this, customer input is probably going to enter the company through the Sales/Marketing/Services/Support people, and sometimes it may even come directly from the customer in the form of bug reports and so on. Unless someone is trained to do it, you will probably not be getting structured requirements in this kind of environment; the developers often have to dig in and understand customer requirements directly. It can be personally rewarding to work as a developer in such an environment, because you can get the gratifying feeling that customers actually value your work and appreciate what you do. This comes with risk, however! You might be building something that hasn’t been thought out very well without even realizing it, because it is highly likely that none of the involved people are trained in the craft of thinking problems through. More about this later.
Company Size: Medium
In a medium sized company (there is no hard and fast rule here, but say it is 100-500 employees), the organization is becoming slightly more complex. The Sales and Marketing functions will be separate (they are entirely different things, remember that!) The Service and Support organization may or may not be broken apart, depending on the needs of customers and the complexity of the domain. There is a heavier layer of management (probably a topic for a future blog post); the development organization is likely still lean. In my experience, medium sized organizations will fall into one of two camps, as illustrated below:
Medium Sized Company A
Medium sized company A has added a QA team, but has not realized that they have serious challenges controlling inputs into their development organization. Notably, they are missing the roles that my young colleague rightly guessed are involved in taking customer input and structuring it for entering the development lifecycle. As a developer in such a company, you are probably going to receive multiple requirements from multiple channels, and some of them will conflict, leaving you in the unenviable position of trying to resolve the conflicts yourself. You can probably tell this organization from simply looking at its products – they probably look like they were created by different companies. The company probably has very bug-filled software releases and a semi-satisfied customer base (Conway’s law at work). If you guessed that this company might be a frustrating place to work, you are probably correct.
Medium Sized Company B
Medium sized company B has also added QA, but has also added some important functions to their development organization: User Experience (UX), Product, and an Architect. Normally, the task of taking customer input and properly preparing it for development work encompasses all of these functions in varying degrees:
- A Product Management (not “project”, “product”!) team is usually responsible for ensuring that the needs of the market (as detected by Sales/Marketing/Service/Support) are being brought into the development lifecycle. A Product Manager may have some Business Analysts who are trained to study business requirements and express them in technical terms.
- A User Experience team is responsible for designing the product to ensure a great user interface and user journey, and sometimes to ensure consistency across a product portfolio.
- An Architect or architecture team is responsible for ensuring that the product is being built in accordance with best practices, meeting any applicable standards, performance goals, and so forth. These are normally the most senior or broadly skilled technical people in the development organization.
By adding these teams, Company B is investing in its own ability to execute intelligently and its product portfolio probably shows it. The company is better positioned to produce great software than Company A. As a developer in such a company, you will get the chance to think about problems before you solve them; this generally results in more well-thought out solutions. Working with a great product team and properly trained business analysts can be a great experience and results in a product that is night and day different from one produced without them. As an added treat, you may get to see and analyze your own work directly in front of a customer via user experience design processes. These can be great companies to work with.
Company Size: Large
In a large sized company (assume something like 500+ employees), all bets are off. The organization can be amazingly complicated, enough for a hundred blog posts like this. Here is one very simplistic interpretation:
In a large company, there will be a vastly larger number of teams, responsibilities, and organizational reporting lines. Particularly in an international company, you may never even meet your boss face to face – let alone the rest of your team. You may interact on a daily basis with a small cross-section of people from other teams:
- The Product person from the product team or Product Management Office (PMO) who is there to make sure the product is on track to be released with the rest of the portfolio.
- A Project Manager (not shown) who is probably helping manage day to day tasks; a Scrum Master (not shown) may be similarly involved.
- Architects may provide some requirements for your development team to satisfy.
- A QA representative from the QA organization may be embedded with your team to ensure that quality goals are met.
As a developer in a large company, you are literally a cog in a very large wheel. You may never interact with a customer at all, unless you are lucky enough to be in a consulting role or a trade show. As unappealing as that may sound on the surface, large companies have the benefit of large budgets, benefits, many different people and different expertise to work with, and an increased peace of mind that your job will not disappear tomorrow.
Summary
While no two companies are the same, having a basic understanding of how organizational structures work can help you make more informed decisions on where to best apply your skills. Eventually you may find that you naturally gravitate to specific types of organizations and away from others.