I remember a time, many years ago, when I got my first grown-up developer job at a large enterprise company. Prior to that point, I’d worked as a jack-of-all-trades: designer, tester, and all-around cool-dude. However, in this instance, after I presented some work, I was reprimanded –
“Who gave you the requirements for this?”
“Uh, I came up with them myself?”
Manager: ಠ_ಠ
I’d never worked at a place big enough to need a business analyst before, so I didn’t even know what one was! Let alone the roles of project manager or business owner.
So, I thought I’d write up a brief guide for new developers on some of the people you might meet when you start at a larger company. Bear in mind that the lines between some of these roles can be blurry; the objective here is not to set down firm boundaries, but to at least give you a ballpark idea of what these people do – and more importantly, why you should listen to what they have to say.
Division of Labour
Everyone knows why companies divide up roles; truly omnidisciplanary talents are few and far between. Assigning responsibilities lets you combine individual talents to get a better team overall, and it prevents people from stepping on each others’ toes.
Broadly speaking, the various areas of responsibility can be divided into three categories: project-side, client-side and management. There tends to be overlap in these roles, but generally project-side jobs prioritize the actual work of creating the project’s output, while the client-side roles are focused on everything that requires the client’s input. Management, while generally swinging more toward the project-side, is focused on making sure that the project-side roles can keep doing their jobs. Let’s start with the most fundamental project-side role: the developer.
Developer
You are here. You are a machine that turns coffee and pizza into code and money. But are you junior, intermediate or senior?
Junior, Intermediate and Senior Developers
A lot of times these terms are just words, and there’s not an industry standard for the particular level someone is on. It’s not like someone can say, 3 years = intermediate, 5 years = senior, etc. The only thing that you can (probably) be sure of, is that you’ll start off as a junior.
If you’re looking to level-up to the next tier at your company, then it’s good to find out from your manager/senior what specific skills (technical or otherwise) are needed to progress.
Tech Lead
This person has ascended past being a mere developer and now knows “stuff” – lots of stuff. They will usually have knowledge across many parts of the development stack, earned through working on multiple projects. They help guide and train teams, and make technical decisions.
Designers
You’ll probably be familiar with these guys in one way or another. whether they’re graphic designers, user-experience designers, or any other role focused on making your team’s creation as attractive and user-friendly as possible. They’re the ones who tell the developers how the app should look and, more importantly, how the app’s navigation and work should flow.
Quality Assurance / Testers
These people are a developer’s worst nightmare! Your beautiful code that you spend hours crafting? They’ll break it within seconds, if it’s not up to scratch.
Seriously though, they will tirelessly run through the same scenarios that your users would, along with more esoteric edge cases. Any failures will be recording and retested, to make sure your product isn’t regressing. They may perform manual testing, or write automated test suites that run automatically.
Don’t overlook or belittle these guys. Sure, you’ll be incredibly frustrated with them sometimes, but they do it because they know that if they don’t catch the bugs before release, the customers will catch them after.
Business Analyst
These friendly folk are the bridge between developers and the customer. In the business world, with in-house developers, the customer is usually other parts of the business. So, as an aside, when you hear “the business wants feature X” it means “the other parts of the company want feature X”.
Back to business analysts, or BAs for short. They’ll take the high-level and often poorly-worded requirements from the customer/business, and translate them into clear and logical requirements that developers can implement.
For example, the business will provide a requirement that’s broad and abstract, such as “We think users need some way to log in if they’ve forgotten their password”. Business analysts will be able to convert that into lower-level, more specific requirements like:
- Add a Forgot Password link on the login page.
- Implement an email generator that will send out recovery emails to the user, from address forgotpassword@yourcompany.xyz
- The subject and body of this email should be…
- The token in the email should be valid for 60 minutes
- etc…
Conversely, the BA takes the the developers’ issues and objections, and translates them into the right metaphors, similes and non-technical explanations to explain the challenges of development to the client. For example, if the devs tell the BA that (for whatever reason) they can’t implement sufficiently secure tokenization without acquiring a larger data allocation from their cloud service provider, the BA can turn around and explain to the client that they need a bit more money to buy more data capacity.
Often the BA will work with developers to come up or tweak the requirements, especially to find out what tradeoffs might need to be made. Likewise they will work with the business to explain what is actually technically possible. In short, the BA’s job is to identify and negotiate the right balance between what the customer wants and what can actually be accomplished.
This can allow for Behaviour-driven development to take place. The BA/developers can write tests based on the specification, then use something like Cucumber to automatically run them and test that the implementation is correct.
Development Manager/ Head of Development
Despite the name, the Development Manager doesn’t necessarily have to be a developer in their own right, although it can help. The Development Manager acts as a team-specific or project-specific human resources manager, and normally they’ll handle the day-to-day HR aspects of the development team. This is probably the person you have to let know if you’re going to be away sick for the day. Things like hiring new developers, conducting performance reviews and making sure everyone in the development team generally gets along; these all fall under the Head of Development’s purview.
Project Manager
In broad terms, a project manager’s main responsibility is making sure a project is completed. The very close second and third responsibilities are that the projects is completed on time and on budget!
To make sure of this, the project manager will work on the project’s scope and determine the resources required. They may have to pull different BAs, developers and QA in from different projects to help out. If there aren’t enough staff available, then a project manager will work with the development manager to hire more staff and contractors.
Sometimes a project manager may also be the person that developers or others can turn to to ask business questions about the project. They will know who to track down or where to find specific answers. But other times, those questions will be handled by a product owner.
Product Owner
The product owner is a representative of the business, based in your team. They’ll be able to answer you (or the BA’s) questions about the business requirements – or find out who to ask. They can also report back to project managers about progress, who can then make resourcing decisions. You might end up with your team being managed, day to day, by a product owner.
Business Owner
If a product owner represents the business on your side of the fence, then the business owner represents the business on the business side. They know at a very macro level what the business want, and entrust the entire development team to deliver it.
Note that the business owner is not the actual owner of the company! Remembering back to my early days in the enterprise, I recall the time I first got to talk to the “business owner”. “Wow”, I thought, “this guy owns this whole company!”
Luckily I didn’t say anything stupid at the time, and many weeks later I cringed thinking about that.
Your Mileage May Vary
As I mentioned at the start, the differences between these roles can be vague. Sometimes I’ve had project managers who were more like product owners. In smaller companies, I’ve had product owners doing business analyst work. Often the project manager and the tech lead are one and the same. Perhaps most importantly, the names applied to these roles can vary widely; the tech lead can also be referred to as lead programmer or development lead. (Separate from the development manager, who can also be referred to as the programming manager!)
Plus there are a few roles I haven’t mentioned because they’re easier for developers to grasp conceptually (e.g. CTO, database admin or DBA, build master, devops, and so on) or people you don’t meet too often (solutions architect) or have roles that are even more company-specific (enterprise architect). If you meet with some of these people, a quick Google search or asking someone else in the company will give you an idea of what they do.
So take this advice with a grain or two of salt; it’s generally correct, and should give you a good introduction, but the way your company operates may differ.
As always, don’t be afraid to ask questions and find out more. We all had to start somewhere!