What if, as a Business Analyst, your approach to managing requirements could also apply to managing people? That’s an interesting proposition, right?
If you already have BA skills this makes the transition into a team leadership role easy. And as we’ll see, this management style is also well-suited to get the most out of the young knowledge workers filling up the modern entrepreneurial organization.
BAs Define the “What”, not the “How”
Business analysts are notedly responsible for defining requirements. Gathering, organizing, clarifying, documenting and validating the list of system requirements that need to be met for the solution to satisfy all stakeholders.
To do this, business analysts will focus on the “what” of the solution, not the “how”. This clarification means that the BA does not design the solution. Importantly, they’re leaving the implementation details to the developers, designers and technical experts.
That last word, “experts!” If the BA takes this task away from the people who are most passionate and most knowledgeable about it a few things happen – and none of them good. Obviously you’d be leaving your best talent unused, untapped, wasted, leaving your team short of fulfilling its potential. To steal a baseball analogy, you’d be stranding runners on base.
The less obvious pitfall is that you’d be indirectly announcing that their skills aren’t actually that important, that they can’t be trusted to come up with the solution on their own. You’d be taking a huge morale hit by doing that.
For example, imagine a retail store manager who wants to mobilize her sales reports. That’s the “what”, that’s your requirement!
These, however, are not your requirements:
- How the sales data is displayed – it’s up to your data visualization expert to plan the right charts and graphs
- But, your requirement might define which data points to display
- How the app is built – it’s up to your tech lead to recommend a native, hybrid, or mobile web/responsive solution based on the various constraints
- But, your requirement might say you only need to support Android tablets
- How the app knows which store to pull data for – whether the manager manually inputs their store, the store is associated to the manager in a config setting, or your app intelligently uses geolocation to identify the store, the BA doesn’t care
- But, your requirement might tell you to restrict store data to only the manager’s home store
Trust In Your Team
Just as the requirements manager leaves the solution detail decisions up to the designers and developers, the people manager leaves the decision about “how” to complete a task to the individual.
Leaving the activities up to the individual creates an environment of trust. After imitation, trust may be one of the sincerest forms of flattery.
As a manager you’re responsible for providing direction to your team members. Along with motivation, training, communication and decision making, leadership also includes circling your team around an end goal. But that’s where managing a knowledge worker stops, well short of micro-managing.
The business analyst approach to leadership tells the team “what” outcome they need to achieve and gives the ownership, creativity and responsibility of “how” to achieve that outcome to each person.
By ceding the “how” of the solution to the knowledge worker:
- Design details are left in the hands of the experts who are passionate about their field, active on forums, reading the latest texts and going to meetups to learn, learn, learn,
- Morale is boosted as knowledge workers feel empowered and trusted, and
- Brainstorming and debate are celebrated,
- Enabling your organization to foster more creativity, innovation, and in the end better results.
Why This Works For Knowledge Workers
An underlying assumption is that you have a team of knowledge workers.
Knowledge workers are smart. They’re innovative. They’re independent and self-motivated. They thrive in flat hierarchies, minimal politics, and solving the most complex business challenges.
Not only are knowledge workers capable of figuring out the “how” of the solution, they require it!
A constrained knowledge worker who can’t flex their mental muscles will quickly become frustrated while also losing their most important skillsets. This is the same as a top athlete who stops performing well without practicing, and practicing at the highest level.
Give Your Team a Safety Net
Of course this leadership model has its challenges. There are some instances and team members where you’ll need to modify your approach.
When Employees Want the “How”
Some employees DO want to know how you expect them to complete their task. Maybe they’re junior, full of raw talent that needs to be shaped and guided. Similarly, maybe your knowledge worker is growing into a new capability, such as a long-time web designer embarking on their first mobile app design project. Or perhaps there are unavoidable politics.
In these cases the most effective leaders recognize how much design freedom to give to their team.
When the Approach Isn’t What You Expected
The same way a business analyst needs to verify and validate their requirements, the business analyst approach to leadership requires checks and balances on the agreed upon outcome. In order to avoid missing the mark, build in milestones and outcome goals. Use this as an opportunity to lead by asking rather than telling.
If your developer is designing a component differently than you expected, don’t simply tell them this. Instead, ask what their approach is and ask how this gets them to the agreed upon outcome.
When the Outcome Is Unclear
Finally, make your outcomes clear, objective, measurable, unambiguous, and agreed upon by everyone. Again, the emphasis is on the outcome, not the activities and steps to get to the outcome.
The business analyst approach to leadership is becoming a more and more effective management model. With more entrepreneurial, knowledge-based workforces, the best leaders will use this style to maximize the effectiveness of their teams.