- About Environment, Products, Size, and People
- Consider Specialization First...
- ...And Generalization Second
- Widen People's Job Titles
- Cultivate Informal Leadership
- Watch Team Boundaries
- The Optimal Team Size Is 5 (Maybe)
- Functional Teams versus Cross-Functional Teams
- Two Design Principles
- Choose Your Organizational Style
- Turn Each Team into a Little Value Unit
- Move Stuff out to Separate Teams
- Move Stuff up to Separate Layers
- How Many Managers Does It Take to Change an Organization?
- Create a Hybrid Organization
- The Anarchy Is Dead, Long Live the Panarchy
- Have No Secrets
- Make Everything Visible
- Connect People
- Aim for Adaptability
- Summary
- Reflection and Action
This chapter is from the book
This chapter is from the book
This chapter is from the book
Widen People's Job Titles
In my job as chief information officer, I 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 was working on (while I wrote this) had four great people in it. One of them knew all about the API that we were developing. He decided what the interface looked like, how it was deployed, and how it was kept consistent over multiple releases. He was our leader when it came to our programming interfaces. The second person was our youngest team member. But he had proved himself as a promising architect. Our third team member knew all about social media and e-commerce. He was our leader when it came to online marketing and communication strategies. And finally, yours truly played the role of the Product Owner, making decisions about features and priorities, and keeping the others busy so they didn't get bored and started blowing things up.
Each of the members in our team was a leader. We played roles that matched our specialties, but they were not our job titles. We had no titles for Interface Programmers, Software Architects, Marketing Consultants, or Product Owners. In fact, we took over each other's roles whenever the need arose. (And this was 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 [Abran 2004]. 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 had 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.