Developers…Release your inner Business Analyst!
Whether you’re starting your career as a developer, a technologist who’s looking to grow your skill set and elevate yourself to that next level, or perhaps just someone who leads a team of techies – I hope you can take away a few gems from this article to apply into your role…
What I’ve experienced
Let me give you a whistle-stop tour of my journey over the past decade. Bear with me; there’s a point behind all this! I started back in 2021 by joining a graduate scheme where I had the opportunity to try out different roles within tech, working as a project manager, business analyst, QA, and a stint in operations. But it was my developer “rotation” where I started feeling at home. It also happened to be where I was first introduced to Salesforce!
One thing that really stuck with me was developing a genuine appreciation for every role within a team. What stood out the most, though, was realising it’s not just about writing or thinking about code! The very best developers I worked with were able to blur the lines of responsibility between their own and those of a Business Analyst. Instead of just taking a user story and building to it, they were curious about the “why.” They wanted to understand the bigger picture and the deeper context behind a requirement—how it all fits together and the value it brings to the end user. That inquisitiveness left a lasting impression on me and has been something I’ve applied throughout my career.
Why should you care?
Before we get into it, let me clarify what I mean by “responsibilities of a Business Analyst”. You may think of a BA as someone who liaises with stakeholders to gather requirements, map out business processes, or, more broadly, act as that intermediary between the business and technical teams. For me, a BA holds such a key role in any team, as they’re the ones with the answers… or at least someone who can help find them! They are the ones feeding the pipe – keeping that backlog in shape, working with stakeholders to prioritise upcoming work and most importantly, looking ahead at what areas of ambiguity need to be explored further to avoid that horrid “ooh that’s a bigger piece of work than we anticipated”.
I feel these responsibilities shouldn’t just fall on the BA but should be shared. Yes, an architect, tech lead, project lead, etc., will likely also have an eye on these things. Still, I think developers or those in a more “technical” role should feel empowered and encouraged to delve into these responsibilities. In agile methodology, the metaphor of a person being “t-shaped” is often used to describe someone who may have deep expertise in a particular area (for example, writing code) but also gains familiarity and fluency on adjacent topics. I truly feel this concept differentiates a good developer from a great one. It also gives those developers a springboard to elevate their careers, pursue more senior engineering roles, or shift into the architecture space.
How to make it happen?
If you’ve read this far, I hope this sounds of interest. Let’s look at what can help you to adopt or enhance some of these skills…
- Complaint Logging & Resolution: Structured workflows for logging, triaging, and escalating complaints, in line with FCA deadlines & SLAs.
- Quality Assurance & Compliance: Tools for real-time checking, QA scoring, and root cause analysis.
- Reporting & Insights: Dashboards and governance packs for FCA reporting and real-time decision-making.
1. Ask Contextual Questions
Why it helps:
Understanding the bigger picture starts with asking the right questions. It’s not just about what you’re building but why it’s being built and how it aligns with business goals.
How to apply it:
- In grooming or refinement sessions, ask questions like:
- “What problem are we solving?”
- “How will this impact the end user?”
- “What does success look like for this feature?”
- Don’t just stop at the immediate requirement—dig into dependencies, constraints, and long-term goals.
2. Shadow Stakeholder Meetings
Why it helps:
Direct exposure to stakeholders (product owners, business analysts, or end-users) provides clarity and removes second-hand interpretation.
How to apply it:
- Ask to sit in on meetings where requirements are being defined or discussed.
- Observe the concerns raised, the priorities set, and the language stakeholders use.
- Follow up with your BA or product owner to clarify anything you didn’t understand.
3. Document Your Understanding
Why it helps:
Understanding the bigger picture starts with asking the right questions. It’s not just about what you’re building but why it’s being built and how it aligns with business goals.
How to apply it:
- After a requirement discussion, summarise your understanding briefly and share it with the BA or team lead.
- Create a simple diagram or flowchart if the requirement is complex.
- Validate your assumptions before you start building
4. Pair with a Business Analyst or Product Owner
Why it helps:
Collaborative sessions help bridge the gap between technical execution and business intent.
How to apply it:
- Spend an hour pairing with your BA or product owner to go deeper into a requirement.
- Ask them about the rationale behind user stories.
- Observe how they prioritise tasks and interact with stakeholders.
5. Think Beyond the Ticket
Why it helps:
Focusing narrowly on one task limits your ability to see how it fits into the wider process.
How to apply it:
- After completing a task, ask: “How does this integrate with other features?” or “What happens next in this workflow?”
- If something feels unclear or redundant, flag it to your team or suggest improvements.
- Understand the downstream impact of your changes
Let’s wrap this up…
I hope you can take comfort in knowing that what you’ve read is nothing revolutionary or particularly difficult to implement. Taking the above tips and slowly incorporating them into your daily life will set you on your way to becoming a better developer.
Let me end by saying this: If you’re reading this thinking, “That’s great, but that’s not my job,” I get it. I’m not suggesting you max yourself out and start taking on the work of your peers. But I am highlighting the power of thinking beyond your own responsibilities as a developer and having an open mindset to solving a collective goal.
Becoming T-shaped is about breaking out of your technical comfort zone and building connections across roles. By staying curious, asking the right questions, and engaging with stakeholders, you’ll build better software and a better understanding of your craft.