In my job as Chief Information Officer I have sometimes clashed with HR people over the chaotic growth of job titles in some parts of the organization. For business units as small as 10 people I saw never-ending streams of job titles flying by, like Content Developer, Content Manager, Web Editor, Web Designer, Interaction Designer, Front-end Designer, Front-end Developer, Web Manager, and Front-end Manager. I’m sure Interaction Developer had slipped in there somewhere as well. What was the use of all these different titles? I have no idea. And neither did the ones involved. I repeatedly told people that having fewer job titles is better. And all those developers and designers could have been called Esteemed Employee, as far as I’m concerned.
The team I’m working on has four great people in it. One of them knows all about the API that we have been developing. He decides what the interface looks like, how it is deployed, and how it is kept consistent over multiple releases. He is our leader when it comes to our programming interfaces. The second person is our youngest team member. But he has already proved himself as a promising architect. It won’t surprise me if he soon takes the lead in that area. Our third team member knows all about social media and e-commerce. He is our leader when it comes to on-line marketing and communication strategies. And finally, yours truly plays the role of the Product Owner, making decisions about features and priorities, and keeping the others busy so they don’t get bored and start blowing things up.
Each of the members in our team is a leader. We play roles that match our specialties, but they are not our job titles. We have no formal titles for Interface Programmers, Software Architects, Marketing Consultants or Product Owners. In fact, we take over each other’s roles whenever the need arises. (And this is a real necessity with me traveling up and down between conferences around the world.)
For improved organizational adaptability I believe it helps not to lock up responsibilities in job titles. Instead, you need to keep those titles as widely applicable as possible. People’s official job titles don’t change easily (sometimes only once every few years); therefore it is wise to decouple job titles from day-to-day responsibilities. For example, the title Software Engineer gives you more freedom in moving responsibilities around than the title Information Analyst. Even when someone asks to be called an Information Analyst, tell her that her contract will say Software Engineer, and that Information Analyst will be her role. For now.
The wide job titles can be used as formal boundaries for the informal roles. For example, the job of a Software Engineer can include anything ranging from design, development, and testing, to project management and support. Therefore, a Software Engineer in your organization might be allowed to pick up a diverse bunch of roles like Programmer, Tester, Support Engineer, and Business Analyst. But no person with a job title outside the boundary of Software Engineer (like Account Manager or System Administrator) would ever be given such roles.
Flexibility of people is exactly the reason why Scrum calls everyone simply a “Team Member.” It underlines the requirement that people feel a responsibility to do anything needed to ship their product, no matter their official job titles. Nobody should be able to say “I won’t do that. It’s not my job.” If releasing a successful product involves cleaning your customer’s keyboard, then cleaning keyboards is your job. Some organizations even go as far as to have just the title “Associate” for everyone in the company. It teaches people to be flexible while getting things done.
Note that the idea of widening job titles actively supports the concept of generalizing specialists. People should specialize in something, but they must be flexible enough not to claim exclusive job titles in support of their specialization. Such specialist job titles would mean responsibilities get locked into the title, and into the person. And that’s not what you want in an adaptable organization.
What you want is a small set of job titles, and perhaps a few guidelines on which informal roles go with which titles. Any initiatives that tend to increase the number of job titles in the organization, and requests to formalize roles and responsibilities, should be nipped in the bud.
For years my job title has been CIO, which is a great title because the letters can stand for almost anything. (Depending on the context the “I” has stood for Information, Ideation, Imagination, Innovation, Inspiration, Insubordination, Interaction, Intimidation, Illustration, and Idolization.) But the things I’ve specialized in, and the projects I did, often had nothing to do with my title. It was just stuff that had to be done.
(image by the thirty third)
This article will be part of the book Management 3.0: Leading Agile Developers, Developing Agile Leaders. You can follow its progress here.
Twitter - 
Subscribe - 
Newsletter - 
LinkedIn - 
SlideShare
| Latest, greatest and favoritest posts:
The Nonsense of Leadership (Princes and Priests) Some Day Kanban Will Fail 75% of the Time Managing Risk vs. Managing Yourself |
