There’s new tech, new ways of doing stuff, new platforms, new toys – but the debate regarding specializing or sticking to a jack-of-all-trades style is still ongoing. Now, before anyone gets excited, I’m not here to put it to bed – I’m here to add more oil to the fire. 

Just kidding – I simply believe that the perspective is way too simplistic than the reality. Of course, there’s the need for both, and yes, sometimes techies, leaders, and tech leaders can do both, depending on the project. There is no such thing as one-size-fits-all in the world of technology.  

As I’ve been in this line of work as a BA for more than a decade now, I also have experience as a Product and Project Manager, and I think it’s time I shared my two cents on the matter. I will not preach, nor give you a recipe for success – I’ll just write about what I’ve learned in the world of tech, regarding that title above.  

No more, no less. 

Delegating Responsibilities

Point for jacks. Delegating responsibilities is something that’s easier if you know what you’re getting yourself into as a team leader or a project manager. No, I’m not talking about just having some idea of how the project will go, with estimates and everything. I’m talking about having a good grasp on how much of an effort your team will need to put in to get the project over the line. 

Specializing in a few technologies or programming languages is all fine, and yes, that experience and knowledge will surely help, but imagine a team leader who knows the core problems of a project and is able to assess them better. 

As a BA, you don’t really have a lot of delegation to do, you’re in a way just running point, but as a product and project manager, it’s crucial.  

Knowing How to Approach Problems

Approaching IT problems is all about perspectives, and the more diverse your skill set, the easier it will be to see the pain points of a project. This isn’t just about planning and execution; this is also about setting up the project in which your team can be not just effective, but also learn and connect. 

I’ve learned things I never thought I’d have the chance to use, but you’d be amazed how something you consider irrelevant or impractical can actually be your rescue when facing complex problems. 

Furthermore, this helps add another dimension to the way you’re leading teams, and helps with delegating! Sure, knowing the core of the matter and having a sense of it is always nice, but why not use this knowledge and put it to something like nurturing. You can measure out your approach – go with passive listening and guide your team with questions, or you can engage and guide by doing. The correct way? Take a look at your team, and you’ll know – what they need and how they work will give you the answer right away. 

Working as a BA, product manager, and sometimes project manager, this can be achieved if one is ready to walk that thin line between having a front-row view of the project, and looking at it from the side – a mix of objectivity and subjectivity. 

Leading By Example

Autonomy in teams is something that’s desired, of course, but teams have leaders for a reason, as sometimes they have to step in and guide when someone hits a snag.
There isn’t one way to do this, and the key to figuring out the core of the problem is balance – being decisive, but not dismissive. 

Having your own MO is always nice – you know how things go, how they should be done, and you feel in control, right? But think of this – leading by example is not just about showing the best way something can be done, it’s about stirring debates, enabling team members to share ideas and engage in processes – which all can contribute to better product development and deployment.
Blindly following established processes can really spell doom for a project, and can actually hurt team dynamics and relationships.
See what works, don’t just decide before you listened and tried – adapt, improvise, overcome!


I know, I know, it’s something that’s talked about a lot. But I’m here to talk about the flexibility towards clients. Agile is a methodology that is applied to teams working on the project, but can it be applied to clients? Yes, and to a great extent. 

Sometimes, behind a project you have one client, and sometimes there are multiple stakeholders. All this can present a challenge, as there are multiple ideas about how to conceptualize and execute the development process, and sometimes these can be conflicting. For this, specializing comes to the rescue. 

Having something as a specialty can help you not just with understanding the project and envisaging it, but also help you convey your messages and recommendations to the client. Simple, short explanations that will help the client understand what you’re trying to achieve, and visualize your proposed changes and additions. 

And at the core of this lies the relationship you form with your clients – sometimes you might click, at other times you’ll need to engage: ask questions, ask explanations – whatever it takes for you to get a better understanding where the client is coming from. 

Mutual understanding lies at the heart of client satisfaction. 


We have this idea that methods, concepts, and MOs should become simpler, more concrete, and more fixed in a way – and it’s time we worked on changing that and accepting the looming reality: flexibility in methods and approach is what will drive efficiency, innovation, and success in the world of technology. 

My advice to all the BAs, project and product managers out there, and the ones aspiring to be that one day: stick to what you know, but don’t forget the following – anyone you meet knows something you don’t, and sometimes that knowledge can be the thing that makes a breakthrough in your projects! 

Erin Traeger

Business Analyst