Analysts aren't managers

Continuing from my last blog, Managers who aren’t managers, I need to say a bit more about people who aren’t managers but get talked about managers.

This is a group of people who aren’t managers and wouldn’t consider themselves managers but programmers and testers consider to be managers. I’m thinking specifically about Business Analysts but there are others.

To a programmer, who rolls in at 10.30am wearing old jeans and a t-shirt to spend the whole day communing with a machine, well, a Business Analyst looks like a manager. The BA is smartly dressed, they meet “customers” and “stakeholders”, they write documents, they tend to keep business hours - because thats when the people they need to speak to are available!

OK, I’m pandering to the stereotypes but you get the message. In my experience a lot of programmers and testers wrongly consider Business Analysts to be Managers. They are not.

Interestingly if you hang around with Business Analysts and listen to them you will find that most of their concerns are the same as the programmers: not having enough time to do their job properly, being overloaded with work, not being listened to by their managers, and so on. But the two groups often end up antagonising each other.

What I’m getting at is this: there are a lot of people who are mistakenly thought of as “Managers” in a software organization.

This is important because when we start talking about self-managing teams and teams without managers these specialists often seen as part of the general problem with “managers.”

There may even be some people who are happy to make this mistake: some programmers I have know think they can do a better job than the business analysts or product manager they are working. Some of them may be right - they should switch professions. And a few of them would see these specialists wiped out at the same time as whip-cracking managers.

If we are to remove product managers just because these requirements specialists have the word “manager” in their title, and remove business analysts just because they dress smartly and go to lots of meetings, then why aren’t we removing JavaScript specialists too? For that matter database specialists and anyone who doesn’t write in the chosen language should go!

True, software development tends to work better when people are prepared to do what is needed - coding, testing, requirements gathering - rather than stand on demarcation lines and declare they won’t test because they are a programmer.

Staffing a team with people who have multiple skills, who are multi-functional and do what is needed to help the team is great. But…

It has its limits.

Few C++ programmers have the skills (or want) to code JavaScript and even fewer JavaScript programmers have the skills to code C++. The same is true when it comes to Testing, Business Analysis, Product Management and a host of other skill sets.

Just because someone’s skills set means they hold a job where they don’t code does not make them a manager.

Managers who are not managers

I’m continuing my theme of management from my January blog (“It takes an engineer to manage engineering”) we need to clear up some terminology.

I often hear form people at Agile conferences that we should get rid of managers but they offer up no definition of manager. Let me suggest that the title “manager” is thrown around quite lightly these days, its probably just title inflation but it causes a lot of confusion. When people say “get rid of managers” I think they are usually referring to “people managers” specifically “managers” who take on positions of authority over others.

The problem is an awful lot of “managers” aren’t managers in this sense. Putting the word “manager” into a job title has a habit of making it ill defined. The same is true in code, a “SecurityManager” class or “LogManager” tend to be a dumping ground for all sorts of vaguely related functionality. Those who truly manager often find their job is a lot of vaguely related bits and pieces, thats the nature of managing.

But the title a lot of the people we call “manager” could more accurately be called “Specialist”. So you might have a “Product Specialist” or a “Release Specialists”

We have Product Managers - they don’t manage people they “manage” products. That means they talk to customers, analyse the market and, after some magic, decide what to build into a product. Its become a bit of a catch-all role. These people could better be called “Product Specialist” or still “Product Analyst.”

The same goes for “Release Managers” who don’t manage people, they administer release processes and do release engineering. They might be better titled “Release Specialists”, “Release Engineer” or “Release Administrator.”

Then there is that vague role of “Iteration Manager” I know they don’t manage people and frankly I don’t know what they do. The role only seems to exist at ThoughtWorks and former clients of ThoughtWorks but I bet it could be better called “Iteration Specialist” or “Iteration Administrator.”

To put this graphically: we can think of the set of all the people called “manager”, of these a significant portion aren’t really managers, they just use the title “manager.”

Specialists like this exercise power and make decisions not because the organization has endowed them with power but because their specialist knowledge and skills makes them the best person to do so. (Well, thats the theory, I’ve know a few who exercise power because the organization has endowed them rather than because they are particularly knowledgeable or skilled.)

Correctly naming these roles would help. Alternatively it might also help to abolish title altogether. I’m told that at the old AT&T Bell Labs everyone had the title “Member of Technical Staff.”

Harmonising title - “Team Member” or “Engineer” - appeals to me, it would break down some of the demarcation lines which inhibit people from doing what needs doing.

However people like job titles because titles form part of their identity, it describes how they see themselves and adding “Manager” to the title makes it sound more important, ones career has advanced when one has “Manager” in the job title!

(I’ve blogged about identity before, in the dim and distant past, but the two entries stand up “Who are you? - identity and change” and “The Dog and Duck is closing”).

Titles help people mark out the area they work in and the tools they bring to the job. It indicates who they associate with. However it sometimes seems that people are more concerned about proving that people in their role can save the day (another old blog “What you need is a…”).

So in summary… it is complicated, the title “Manager” does not mean someone manages anyone, anything or has any authority. Once again, look beyond the label.

Podcast with about Business Analysts in Agile

Alex Papworth runs a Facebook group (closed) called “Be a Brilliant Business Analyst.” He recorded an interview with me a few weeks back which is now available online.

Agile and the Business Analyst role

I should also point BAs and aspiring BAs at Alex’s newsletter.

And it would be a miss of me not to mention the “Agile for Business Analysts” course I’m running with Learning Connexions next month.