# Roles And Jobs For An Organization Of Team Workers

## Job-Automons Vs Thinking Human Beings
The team, and the act of teaming, are both concepts that allow people to organize in a way that is human and delivers results. It is a way to create space where people can not only get things done, but a space where they can learn from one another. An avenue where we can grow beyond the confines of a narrowly defined set of activities.

### The Industrial Approach to Jobs Are Not Meant For the Living
Traditional organizations contain a lot of machinery that gets in the way of effective teaming. A big, and pointless obstacle is the definition of the jobs we get hired for and the roles we take on. The standard, tried and true approach for most organizations is to give everyone a highly defined job description. To make sure everyone has their role defined to an exact level of detail. To hold each and every person to a set of very hard accountabilities. The idea is that if we define what everyone is signing up for up front, then it becomes much easier to work together as we scale up. Everyone has clear and specific instructions, and everyone knows what to expect of everyone else. Sounds great doesn't it?

Not if we want living, thinking beings to thrive through teamwork. Not if we want people to exhibit any semblance of dynamism in their place of work. Not if we want people to adapt to change and solve problems in new and novel ways. Ways that your organization's leaders won't be able to anticipate. Certainly ways that your human resources department won't think of.

### Something About a Job-Automon
In an environment of constant change, such new and novel work is always happening. But your people are not thinking about how to organize around this new and novel work. People are focused on doing their job, according to it's exact definition. Or else they are focused on doing what you tell them to. No less, but no more as well. People are behaving as *job-automons*! A job-automon does their work according to the letter of their job definition. A job definition that was out of date the moment it was written. A job definition that most certainly will not be of much use for that new and novel work coming your way.

Job-automons fail to deliver on outcomes that require adapting to change. Things get stuck in the cracks between all those individual instructions we have defined. When this happens things get missed. Organizational failure happens. A familiar follow up is all the people involved in the mishap participate in what is often referred to as blamestorming, a rapid oscillation between avoiding taking any personal responsibility, and trying to pinpoint the guilty party.

Creative, and motivated people don't like the box prescriptive roles put them in. Often when I ask such people of what they think about their job, their role or their position in their organization, I hear a common refrain. Rigidity, constraint, lack of empowerment. Even fear of failure.

In an age where we need to attract and nurture passion and creativity we need to do everything we can to eliminate the trappings of a bureaucracy that has long outlived it's usefulness. If we want to create an environment where people focus on constant learning and continually adapting to create value we need to discard antiquated notions of jobs and roles. We need to avoid adversarial style discussions of accountability and expectation. We need to refrain from approaches that start with us getting told what we can and cannot do.

### The Instructions of a Job-Automon

Employment in many organization comes with a job. A job that has a very specific definition. This job definition is used to describe :

- The role you play (typically one role)
- The accountability you have
- The (very specific) boundaries that demarcate your responsibility
- How you progress to the next level of your career
- The level and number of people that report into you

This documentation will be largely static, and changed infrequently.

Let's take an example:

**Business System Analyst I**
- *A "Business System Analyst I" works under general supervision to identify gaps between business objectives and systems scope.*
- *The analyst is responsible for working with both business and technology to make sure requirements are clear, accurate, and well understood.*
- *The analyst will facilitate various requirements collection workshops, and is accountable for eliciting business needs for all stakeholders*.
- *The analyst documents these requirements and reviews them with Developers and Testers. The analysts reports into a "Business System Analyst II".*

This type of job description put's the focus on individual effort rather than the interactions across individuals. It starts with and ends with an individual's functional duties. Remember, when our people have an unduly narrow specialization, we end up with lots of hand-offs across people. Work tends to be performed in a highly serialized manner, with individuals working in mini (or maxi) silos. These hand offs create waste, cause rework, and they impede learning. We face constant bottlenecks.

Job definitions like these also seem to be perpetually out of date. You are guaranteed your job title is never in sync with you are doing, or what you should be doing. People are always asking for permission to get something done, permission they often don't get. After a while people stop caring and they stop asking.

Now some will say bad/pointless job definitions are no big deal. Serious people just ignore that stuff right? Committed folks skirt the inanity of it all and just get the work done right? In some cases, yes they do. Certainly I always did. But I also ended up ignoring the good rules as well as the dumb rules. And I got into all kinds of trouble as a result. Rule breaking, and organizational disrespect is a poor antidote to a non-sensical management system. How about we try a different approach to jobs and roles, one that removes a lot of unnecessary nonsense?

## The Sports Team: A Metaphor for Thinking About Jobs

So first, a metaphor. Many will say that the sports team is not always a great metaphor for a team of knowledge workers. While there are dragons when we make this type of comparison, if you bear with me I think I'll be able to provide some useful insight.

#### 6 Year Old Soccer Team (Hockey, for us Canadians)


*Wheee! I'm creating value! (eventually)*

Who out there has watched their kids play a team sport at a young age? It is certainly a sight to behold, and it is a lot of fun. Some other truths..

- No one knows how/when to participate
- No one is taking accountability outside of coaches and referees
- Everyone is interfering with each other
- It's well suited to small groups of adults
- Teams do score! (eventually)

How many of us have felt like we were working in an organizational *six year old soccer game?* Some evidence you are in a 6 year old soccer game include:

- everyone shows up to every meeting
- everyone is consulted on every decision
- people come and go at random
- lots of overlapping and conflicting effort
- no ownership of outcomes

#### Table Top


*Now this is what I call expert value creation...*

Who out there worked for an organization where management got serious about putting some rigor back into the organization? Likely you ended up with...

- Individuals ending up with very specific job functions accountable to a very specific task
- A much tighter org hierarchy, with well though out spans of control at every level
- Lots of documented processes, that no one really understands, or follows
- No one is taking ownership of the end goal, outside of the most senior leaders
- Jobs and roles are hard coded, no one changes their role
- The puck is constantly getting stuck in the corner, metaphorically landing in the gaps between people's job descriptions, where overburdened leaders have to pick it up

How many of us have felt like we were working in an organization where we felt like a *tabletop piece?* Some evidence you are in a tabletop game include:

- You are told not do something because it is someone else's job
- No one takes initiative to improve things, because it is the responsibility of some other department
- You need approvals from higher up the hierarchy to get anything done
- You get things done by flying under the radar, and begging for forgiveness rather than asking for permission
- Lots of departmental protectionism, blamestorming

#### True Team


*You mean we can succeed and have fun?*

Watching a professional team, or even a team of committed amateurs is an entirely different experience.

- Team members have positions, but position changes based on the play
- The team outcomes trump any concept of role or position
- Interactions between team members trump individual accountability

Most of us actually have solid experience working in this type of organization, even if it's an organization that is outside the workspace. Some evidence you are on a *True Team* include:

- You don't check if something is in your job description before helping
- You proactively seek advice and help from people more knowledgeable than you before trying something new
- You focus on getting to the outcome, not creating deliverables
- Specialists and specialization exists, but specialists train and mentor others on the team and level them up
- Leaders step in to help when required and get out of the way the rest of the time

## Let The Team Decide Who Does What

In the modern age, we want to encourage people to play more than one role. We want them to play to score rather than just playing to a position. We want to remove roadblocks that interfere with people stepping outside of their job function. We want to increase the opportunities to provide value, and increase the opportunity to learn how to add value. The easiest way to encourage a new mode of thinking is to simply empower the team to determine what jobs and roles mean to them. Let them determine how to share responsibilities. Encourage the team to make roles and interactions a part of their discussions on how to improve as a team.

### Role Churn At The Billing Lab
*The billing lab was a bit of an anomaly when compared to many of the other agile teams that had formed in Scotiabank's Payments Group. For one, it's sheer scope was pretty significant. The goal of the billing lab was to deploy a consolidated billing system for it's diverse range of cash management products across a wide range of customer segments. The goal was to manage pricing of products, including deal related discounts, tracking of all charges, invoicing, etc. All of it in one system. The job was made complex for a number of reasons. Many business deals were managed through bespoke agreements and one-off contracts. A single product could span a litany of systems thanks to a history of building separate systems to handle unique requirements for larger customers.*

*Coming up with a solution required a large cast of business, system and data experts that spanned this ecosystem of arcane deals, legacy systems, and manual processes. The very size of the team led to some significant churn as people tried to figure out how best to work with one another. This issue was felt all the way up the more senior members of the lab who felt like they were bumping into each other.*

*Margaret Walczyk, the tech lead in the billing lab at the time, recounts her experience.*

*"Being in the billing lab felt really chaotic in those early days, people were getting their backs up. I felt like I had to play peacemaker many times a day. And I was suffering a similar issue with the other "leaders" in the lab. There I was, the technical lead, with a project owner, and a couple of seasoned architects. We had a small cast of product owners and a few scrum masters, all trying to "manage" a team of 30+ folks. It felt like we were overriding each other frequently, which negatively impacted others in the lab. It was a bit of a mess."*

*At first, some of upper management (VP level) wanted to resolve the situation by handing down roles, responsibilities, and accountabilities that were distinct for each role. However, our team and others in upper management knew this wasn't the answer. Despite our problems we were able to make progress and come to some good decisions. We didn't want to be told how to work.*

*The team suggested a different idea. We took a stab at coming up with our own answer. We started with our leadership group and facilitated an exercise where each person listed the skills that each each of us brought according to our role. We found there were a few unique things that really belonged to only one role. For instance I really focused on getting the right technical skills into the lab. The product experts focused on customer facing decisions, and our PMO representative helped us with the budgeting and financing processes, getting our business case signed off, and funding approved.*


*But there was a lot more overlap in terms of what we all wanted to bring to the table. We found we made significant progress by categorizing this overlap:*
- *Core skills: things that we identified as foundational to the one role*
- *Adjacent skills: things that we felt were core to our role but also core to other roles*
- *Peripheral skills: things that we could do in a pinch, and maybe even wanted to learn how to to do.*

*This approach was facilitated in waves by the entire team, with everyone getting a chance to illustrate what they felt were their core, adjacent, and peripheral skills and behaviors. This approach made clearer the things the team could rely on others to complete, but more importantly it became clear where the overlap was. Where the team would need to collaborate to get something done, or where they would need to agree on who do a piece of work in a more dynamic fashion.*

*Perhaps most importantly, according to Margaret, outside of a few mandated responsibilities, i.e. the budget had to be managed by someone from the PMO, it was the team who managed this approach. The result was higher trust. Not only did team members trust each other more, but the executives trusted the people in the lab. This was made obvious, when fewer executives dropped in to check up on the team and by the fact that the billing lab stopped generating endless executive powerpoint updates. "We got to show progress through working software" which was a huge win for Margaret.*

## And Now For Something A Little More Formal
As organizations grow larger, say many teams, many teams of teams, 100s if not 1000s of employees, it may make sense to experiment with a bit more formalism than the "every team figures it out for themselves" approach. There are advantages to getting clarity on some foundational behaviors we want to see when someone is performing a sales lead role, developer, financial analyst, call center agent, product manager, or whatever. The trick is to avoid ending up with:
- The **one job spec to rule them** all! Everyone is bound to the definition of this job
- **Lots of narrowly defined jobs**, a job for every function you can imagine!
- Jobs are focused on defining **individual contributions**, often to eye glazing levels of detail

With conscious effort we can model our jobs in a way that is more conducive to a living, breathing work place:
- **Fewer job definitions**, a lot less of them
- Jobs are a **loose container for a collection of roles**, roles that **overlap across jobs**
- Describe roles by paying attention to **team oriented behaviors**, painting a picture of how **roles overlap** and how **one can move across roles**
- Any competency model that we develop is based on the idea that people need **both breadth and depth** a concept known as **T-skilling**

### Getting to Role Clarity at Provincial Treasury Bank

A short while ago, a Provincial Treasury Bank's digital guild wanted to increase the clarity of roles with their organization. Leaders within the digital group wanted to put some structures in place to make it easier for team members to appreciate the skills and behaviors that would help them progress their careers within Provincial Treasury Bank's digital group.

Michelle Kimoff, who at the time was the the Director of Digital Strategy at PTB Financial, was hearing several concerns from people across many of the squads. People felt that that Provincial Treasury Bank could do more when it came to bringing clarity to people's work and role in the organization.

*"The digital group had been taking advantage of agile concepts for several years. The pace of tech change became quite high, and was frequent. This brought about great benefits, but also some challenges. Some felt like they lost what was expected of them, many felt it was unclear in terms of how to grow their career at PTB. Am I stuck doing back end work, or can I enable others? We wanted to provide something to employees that would help them understand how they could move their careers forward. We also wanted to provide some of our more delivery focused people with a career path outside of moving into people management. That there were other paths. So we came up with a kind of treasure map that employees could use as a kind of guide for people to move and grow. For example, a developer may progress by becoming more of a full stack developer, or a tech practices coach, or an architect, or move into product or delivery roles. As a side benefit we wanted a way to show the more traditional parts of the organization outside of digital how skills rich our delivery professionals needed to be in order to justify the kind of pay these type of roles demanded in the market."*

Will Davis, a consultant at Agile By Design, was tasked to work with Michelle. Anonymous and the rest of the digital guild to put together a "role clarity" framework to help people navigate some of these issues.

*"When I was first asked to help Provincial Treasury Bank on the Role Clarity Framework, I remember being both a little excited and a little trepidatious. I've seen organizations do this kind of role definition work before, and frankly the output tends to not be that great. I have seen some role work that is embarrassingly bad in some cases, and downright toxic and counter productive at worst. There are a lot of enterprise leaders out there that seem to think that we can define roles and responsibilites using the same rigid mindset and approach that we did in the old waterfall days, but replace it with agile jargon. If we do that we don't really change anything.*

As Will started to engage with various members of squads within PTB, he encountered some very typical issues. Some team members were complaining that they felt overtly tied to the role they were playing. Others felt that the pathway to progressing in their career was not as clear as it could be. Many felt it was hard to change to a new path, if one so desired. Will was also troubled by the amount of old school thinking about jobs and roles he encountered. It appeared that some did not want to take on things that fell out of the scope of their job. Others were wary of stepping on other peoples toes. Most troubling, was the number of people that would indicate they didn't know what their role actually was.

## Constraint: Coarse Grained Jobs Comprised of Many Overlapping Roles

Stated fully,

Organizing Constraint 5: Design Job specifications so that people can play many different roles

### Less Jobs

One thing we can do to avoid the pitfalls of strictly defined job descriptions is to simply have less job definitions than we ordinarily see in an organization, a lot less of these job definitions. Since we have less of them, we can make those jobs expansive, with lots of options. Job definitions can provide for lots of different kinds of work. Take this principle to it's extreme and you end up with organizations that only have one Job definition, employee.

Valve, a video gaming company in the US, is the maker of wildely successful game franchises such as Half-Life, Portal and the social-distribution network, Steam. While they are a privately held company, they claim their profitability per employee is higher than Google, Amazon, or Microsoft. With over 360 employees, there are no official jobs defined. Or really, they have one job defined, someone who has a job at Valve. You are hired because they trust you to add value based on your skills and experience, and they trust you to figure out how to work with others to do so.

Organizations getting started with this approach may take a slightly more gentle approach than Valve, perhaps three, four, or maybe five job descriptions. Each job would have a very wide scope of responsibility, within an over arching functional category.

*Figuring out the jobs for Provincial Treasury Bank's digital group was pretty easy, according to Will.*

*"PTB Digital were a delivery organization. Their mandate was to build and improve on Provincial Treasury Bank's digital channel so that customers could bank online with the best possible experience. So when it came right down to it we started with just jobs:*
- *Engineers, were people that performed the creation and operations of our technology solutions.*
- *Product, were the people who focused on achieving market success with our technology solutions, including supporting customers.*
- *Delivery, were people who were there to support the other jobs. They would do what ever it took to keep things moving, including facilitating, communicating and visualizing the delivery of working software.*

*And that was it. Every one could fit into into those three jobs. Every possible permutation of what people could do to create value could be slotted into one these three jobs. I wanted to empower people to flesh out the details in terms of level, behaviours, roles, etc.. But I wanted official job titles to be limited to those three."*


### Lots Of Roles

Jobs are really just containers that house a lot of the different types of work that one can do as as part of that job. One option is to define all the roles that could be considered within the scope of the job in question. It is a good idea to keep these role fairly small and detailed. Figuring out the roles was where the real work was at PTB

Michelle talks about the need to moving from jobs to roles.
*"Your job doesn't define the work you do. On paper you might be a developer, but back - end vs front end, vs lead. We wanted something that allowed you to pull on whatever skills you had to perform the role that you were able to play. More progressive organizations have work boards, where people choose their role every day. Maybe we couldn't get all the way there in our more hierarchical org, but we wanted to get at least part way there.

*"So our approach was a kind of snake and ladders for roles, only with no bad moves. People needed to look at all the roles and skills the organization needed, and say I know what I am currently doing. I have looked at my skills, and see the needs in my squad, in my tribe, both vertically, in terms of people leadership , professional skills , etc. You own it rather than relying on a manager to tell me what it is going to take to get to the next level. You can map out you career your way."*

*"At Provincial Treasury Bank Digital, we wanted to make sure that the roles we included in each job were fairly fine grained."* recounts Will.

*"The idea was that by keeping roles small, it would become easier for someone to take on a new role. If a team needed a certain role that didn't exist on the team, we wanted the first question to be could someone on the team learn how to do this? Did someone on the team want to learn this? We wanted people In Provincial Treasury Bank digital to feel like they could pick up a role, if it needed picking up. We didn't want moving to a different role to be part of some laborious HR process. For instance, some roles we might find in the **Product** job include User Experience Designer, Business Analyst, Functional Tester, Product Owner, Research and Analytics, Design Thinker, etc. These roles all required a mix of business domain knowledge, analytical thinking, good facilitation, and a bit of creativity. While each role had it's own technical aspects, we felt that someone who was good at one of these had the potential to be good at any of them."*


We can add clarity to these roles by fleshing what a role does in the context of team dynamics and interactions with others. Feel free to describe roles in terms of behaviors that overlap with behaviors found in other roles. Finally we need to empower teams so that they define and refine any standard definition of jobs and roles needed to meet the context of the team. Dynamism must trump consistency!

Michelle recounts how empowering volunteers from squads to shape the various roles wasa a key part of the approach.
*"Our success at PTB Digital came from the fact that we brought in a lot members from our agile squads to contribute to the work. At PTB we tend to talk about co-creation in the abstract, but I feel we really lived that principle when coming up with our role clarity work. The teams really focused on the level of definition that would be helpful. This might have taken longer than if management and consultants cooked something up in a room, but the result was that people felt OK with it, and not just slapped in the face with something."

"*Back in my old Deloitte consulting days I did a lot of competency modeling and job description writing, squirreled away in a back room at a client's head office. While the work was helpful for some, it didn't put any power to leaders and the employees to make meaningful decisions. The work became out of date by the time we built it. Some could argue that roles like a Branch Manager or Customer Service Rep may not change a lot. But in digital, things change must faster, and traditional models just don't keep up."

Will recounts those early acts of co-creation.
*"the first thing we did was make it as easy as possible for anyone in the digital group to tear down our work in an act of creative destruction. We created a wall of sticky notes with fundamental behaviors. We had behaviors for every role we could imagine. We deliberately left the role mapping on the wall. We then asked team members from across the digital group to self identify with behaviors, group behaviors into roles, and discuss where roles overlapped and how one could play a different role."*

Roles and their behaviors for a team are best identified by the people who are part of that team. Required behavior can and will change based on the emerging needs of the team. It is critical that individual teams be able to tweak, and even end up changing the model as necessary to come up with the set of jobs, roles, and behaviors that fit their context. Again, teams need to self-organize to determine what team member plays which role. None of this is a one and done discussion, but something that is often revisited as part of team level planning and review sessions.


The behaviors, roles and jobs that came from consolidating the output of all these workshops wasn't necessarily groundbreaking or novel, but the approach solidified buy-in. It provided an opportunity for people to be educated on both the consulting and Provincial Treasury Bank side.


## From Job-Automons To Human Beings

So let's take a look at our previous job-automon example we defined at the beginning of this chapter. Remember that Analyst job description that just made you want to cry? Let's see if we can describe the job a little bit differently. First of all we will change the job title to something a lot more broad, lets call the job *Business Specialist.*

**Business Specialist**
- *The business specialist brings ownership, structured thinking, facilitation, and communication, with a focus on aligning on the business objectives of the team.*
- *The business specialist collaborates with business stakeholders to validate that the work of the team is accomplishing business objectives.*
- *The business specialist will work closely with other team members to clarify and validate that the work of the team meets business needs.*
- *The business specialist facilitates workshops with the rest of the team and business stakeholders.*
- *The business specialist will often engage closely with real users to gather insight and feedback.*

*The business specialist can play any of the following roles as befits their experience and knowledge:*
- *Analyst (documenting required functionality)*
- *Tester (validating functionality)*
- *Domain subject matter expert (providing expertise on functionality)*
- *Product owner (prioritizing functionality and determining business fit)*

*Depending on their aptitude and interest, a business specialist may start to focus on user experience or facilitating customer insight as a design thinker. The entire team is expected to collaborate and collectively identify the roles that the business specialist can take in order to serve the team's goals.*

See the difference here? Again, this job description is broad, it provides options, and it is described from the perspective of interactions and engagements with others.

## Constraint: Grow Helicopter-Shaped People
Previously we talked about how we more than just cross-functional teams, i.e. a team of diverse individuals. We want cross functional *individuals* inside of our cross functional teams. We want people learning, growing, and expanding their skills. As people become more senior we want them to expand their expertise at a reasonable level across a number of other knowledge areas. Yes we want them to gain deep knowledge in one or two disciplines, areas of deep expertise, but this should not come at the expense of broadening their skill base.

We want domain experts to get cursory knowledge outside their core domain of expertise.

We want delivery professionals such as testers or analysts to gain experience across the entire life cycle.

We want developers to be able to contribute code across the full stack.

We want product people to work in operations, and operational folks to learn how to define and improve product features.

In other words, we want to encourage the development of *T-Shaped People*. Your knowledge literally expands deep and wide, like a T. Perhaps a better description is *helicopter shaped people*. We want people to go wide in a number of directions. Your depth of expertise still matters, but it's real value comes from educating others on how to apply it. Mastery is really about pairing, mentoring, and teaching others to apply your domain. The narrow roles and wide job approach lends itself to the development of T-shaped people, but it is really just one blade of the helicopter. We want to encourage people to expand across all the blades.


*Michelle discusses Helicopter helicopter skilling at Provincial Treasury Bank.
"It was important for PTB Digital to move to this idea, but it was tricky putting this thinking on paper, we talk about roles, but what about the stack? What about the business domain? It was important to understand where depth was needed, vs what areas needed more breadth. As things evolve we have found we needed more people to have breadth for things like making changes to our core banking platform, vs everyone being super deep on area."*

*After Michelle and team felt they had a good taxonomy for jobs and potential adjacent roles people could move into, they asked squad members to come together and co-create the skills each job would need. This filled out a set of job specific helicopter blades, in effect defining helicopter for each job. A self assessment tool was built where people in digital could define how they wanted to expand their role, skill sets, and other capabilities. Managers were trained on the approach and coached to advocate for their people in their learning and growth objectives. This is allowing people to define personalized career path to grow into the areas that drive their personal interest. *

*The feedback received was very positive. Some people even indicated that the dialogue and attention to people's growth had motivated them to be a part of Provincial Treasury Bank like never before. But there were also challenes according to Michelle.
"Self-assessments can be terrifying for people unless they how they are going to be used. Unless you have trust people can literally freak out. We had to spend some time getting people's trust that this was for people's betterment and not something to be used against them, We started by being really transparent about the outcomes. We found a group of eager cohorts and dived in, taking the plunge to use it for positive things. It proved to be a simple way to get a baseline, and a simple way way to keep it. In the end it led to more work that people wanted to do, to more training. *

## Constraint: Define Interactions across Fine Grained Roles Not Wide Jobs with Separated Duties
Borrowing a page from the User Experience world, one approach we can borrow is the use of personas, specifically *Role Personas*. We will describe personas in terms of how this role collaborates with others. Stories of how one could decide to take on this role. Stories of how to move to other roles.

Below is an example role persona from Provincial Treasury Bank's role clarity framework. *"The Agile Delivery Lead"* contains some pretty specific behaviors grounded in Kanban and lean thinking. This made sense for their context and where the organization wanted to go. Again, the needs of your organization will be different.

*The Agile Delivery Lead:*

*When team member(s) play this role, they work with the team to help balance demand with team capacity, using the simplest team structure that minimizes hand-offs within and across teams. They facilitate the design and operation of the system of work, running workshops with the team to agree on workflow, work policies, work types, services, cadences and events. They are passionate about using a systematic approach to improving the team’s ability to identify and resolve impediments and bottlenecks. To this effect an Agile Delivery Lead, promotes visually managing the flow of work, using pull, and limiting work in progress. The Agile Delivery Lead collaborates with the entire team to enable continuous improvement of the system of work, using lightweight but empirical approaches. He helps align teams with the stakeholders by supporting the team in their use of long-term planning using techniques such as relative sizing, throughput accounting, and flow metrics.*


*The Agile Delivery Lead can step in and help out the team in any way the team needs them to. For instance they could leverage their experience to help the team complete stories by pitching in as an Analyst and Tester. It is very common for Agile Delivery Leads to act as a Servant Leader, using situational awareness and empathy to focus on the growth and well-being of their team. As Agile Delivery Leads master the full breadth and depth of agile delivery, they can play an Agile Coach role. As Agile Delivery Leads gain more and more domain knowledge, they often start engaging and interacting with business stakeholders, getting user feedback, and facilitating business direction, moving into a product owner role.*

Note that almost all behavior is described in terms of *collaborations with others*. This is important. If we can't describe jobs and roles in terms of our interactions, than we should not write them in the first place.

Taking the time to describe a role does not mean we want a person to play only one role, or that we want a role to be only played by one person.

### A Brief Note on the Importance of Context
Remember the Provincial Treasury Bank example is Provincial Treasury Bank's solution, and not some normative solution that is assumed to "correct" for your technology business. Many product focused organizations would be more comfortable with only two jobs, product and engineering, with delivery responsibilities being allocated across these two jobs. I have also seen another variant that pulls out Operations into its own distinct pillar. Depending on the domain, you may have domain expertise that is so specialized that you create a separate job for it, i.e. credit risk or actuary.

## Some General Role Advice For Agile Teams

Many of us have a hard time stepping away from our need for highly prescribed roles and jobs with strict accountabilities. Most of the official methods and frameworks out there don't help, including most Agile methods. Scrum and Safe are rife with language that treats certain roles, for instance the scrum master and product owner as sacrosanct. The idea that the accountability for business value belongs to one person, and not the entire team, may make sense for some contexts, like when a team is getting started. But there are situations where product ownership is better served by being a team accountability. Being religious about any role is the opposite of what self organization looks like. The good news is that there is some very straigt forward things organizations can do to take cautious first steps along the path to more cross functional people. Below is some general advice for delivery teams are trying to lean away from being a team of siloed specialists. The advice is pertinent to roles you would see in software development setting, but with a little imagination can be applied to other contexts as well.

### Analysts And Testers
Most IT organizations stuck in the last centuries mental model treat functional analysts, i.e. the people who collect requirements, and functional testers, i.e. the people who test requirements, as a completely separate group of people. Different skill sets, different management structures, different artifacts, etc.

If you want to demonstrably increase the effectiveness of your ability to deliver new software based applications, there is no easier things to do than to abolish this artificial distinction. The person who specified how a piece of functionality should work is the best poised to test that functionality. In every case where I coached a team to try this out, productivity sky rocketed and morale improved. We avoided the messy hand off between analysts and testers. We eliminated the the overhead of reconciling requirements artifacts with testing artifacts, as well as all the defects that came from when they invariably fell out of sync.

Create one job function for both testers and analysts, use one artifact to track functional specifications, favouring testable requirements. Have analysts teach testers to deal with ambiguity, have testers teach analyst to communicate with specificity. The first step is to invite any analyst or tester that wants to step outside of their box to do so, and provide those eager adopters some initial support in the way of training and coaching. Illustrate that is is a stepping stone along the career path towards Product Ownership.

It is worth pointing out that testing specialist can exist in a more agile setting, and that they can provide a lot of value. It's just that there are less of them than you would find in a traditional organization. A lot less of them. Testers in an agile world are obsessed with ensuring that agile teams are test infected. They are enablers that teach others how to work with a test driven mindset. They tend to bring a combination of deep testing experience along with the technical chops to test deep inside a solution using automation. Their mandate is not to test, but to raise testing capability of teams.


### Team Delivery Lead
Call them scrum masters, team leads what ever, but many who are in agile style teams benefit from some dedicated leadership support. Perhaps the biggest miss is sourcing team lead from people who have historically played the project manager role in a traditional setting, and then assuming these people will thrive in this new role. Perhaps after a three day certification course. Project managers often struggle when playing a team leadership role in an agile team. This is because PMs have been brought up on a methodological diet of command and control, certainty, and specificity. They have been trained to "own" the plan. They have been told to manage all risks, issues, and dependencies. They are tasked with creating planning artifacts that are dependency magnets, coupling what, when, and who into one big tangled mess (otherwise known as the Gantt Chart). The results are plans that are prone to error, and just plain fragile. The classic PM is expected to be the gate keeper of information, steward of who is doing what.

Some folks are taught one way, but are innately different, and have very little trouble making the move from management to self organizing. But many do not make the transition so easily. In the agile world, we lead others by supporting them. We don't own the plan, we facilitate the team creating it. We don't manage the status, we help the team make the status as visible as possible. We don't own the information, we enable the team to make the information as radically transparent as they can.

The mindset from being at the top of the team, i.e. the team manager, to the bottom of the team, i.e. the leader who serves the team is a profound one. And the tools an agile team uses to plan and track progress look nothing like the tools a PM uses to do the same. Backlogs, story maps, visual kanban flow, throughput and lead time metrics, blockers and impediments management all do not feel like gantt charts, raid logs, or red/yellow/green statuses. They are born of a different mindset. Agile team leaders require a higher level of both domain and technical understanding than many PMs posses. Team leads do not need to come equipped with this understanding ahead of time, but they need to willing and able to pick it up and learn over time. An Agile lead will step in and help where ever they are needed. This could include helping with story exploration or story testing, with facilitating improvement sessions, or going as deep as required to solve a particularly nasty problem. This is no longer a role of coordination, it is about being a core, contributing team member.

A lot of good team leadership comes down to coaching, you want to team to learn how to self organize. When it comes down to it, the job of a delivery lead is to make oneself obsolete, to help the team grow beyond the need for a single team leader.

Everyone should be provided the chance to make the transition, including the PMs in your organization. I have seen some amazing PMs move from manager to servant leader. But be wary that PM experience can comes with just as many liabilities, as perceived benefits. People with no PM background can have an easier path moving into the role. PMs will need very specific support if they are going to effectively make the transition.


### Developers
Developers in traditional organizations can often end up being way to specialized. Back end developers, front end developers, back end SOA developers, back end data developers, back end noSql data developers, arghhhh.

Yes the world of software and application development is rife with opportunities to specialize, and it can take a long time to really become an expert in a particular platform, paradigm or toolset. And boy it sure can be a PITA to have to pick up a new language just when you are hitting your stride in the current tech stack. Again, the benefits of specialization is often over estimated, and the drawbacks often minimized. Agility is better served when most of your folks tend towards have reasonable proficiency across the full stack, or most of the stack. More full stack developers mean less hand offs, less information loss. By all means have some experts on hand for each technology on your stack, and have them be ready to jump in and pair on issues that require such deep expertise. But keep your developers learning and growing, in the long run they will thank you.

Speaking of learning, encourage developers to become software craftspeople. So many developers, especially in the world of big IT, have not been given the space required to master the fundamentals necessary to build solid, well factored solutions. SOLID principles, test driven development, domain driven design, pairing and refactoring are all practices that bring a sense of mastery to the development profession. Give your developers the chance to learn them.

Also encourage your developers to dabble across the flow of work. Developers make great testers. They can make great analysts. They often know more about how the business *actually* works than anyone else. The business logic is unambiguously in the code after all.

As developers progress into architects, don't allow them to become diagramists, i.e. ivory tower architects that have lost touch with how things work. Ask senior technical people to keep one hand in the code, and ensure they stay relevant.


**Product Owners**
Thanks in part to the prevalence of scrum, many view the product owner as a mandatory role in all agile teams. A single person accountable "for maximizing the value of the product" resulting from the work of the Team. Better stated is that product owners support the team so they are able to self-organize in a way that "maximizes the value of the product delivered. Like delivery leads, product owner are at their most effective when they exhibit servant leadership. Product ownership is too important not to be a team sport. Many agile teams fall into the seductive trap that product ownership, and all the difficult stakeholder interactions it requires, is something best abstracted away from the team, and in the hands of one individual. Given all the noise that comes from poor business stakeholder engagement with technology delivery professionals, it is understandable why a team would want to avoid what may seem like pointless politics and distractions. But the answer to dealing with dysfunctionality isn't to hide from it. It is to solve it. A productive team that cannot cut through organizational turmoil is still an ineffective team. A nice agile mantra we often hear is that if something hurts do it more often. Get closer to it. Teams owning the problems that come with truly owning a product is a crucial step in the journey towards greater self organization.

Because of the need for a Product Owner to be accountable for value, they are often sourced from outside of the technology parts of the organization. Operations, support functions, product management, customer segment groups, are all candidates. There is nothing inherently wrong with this thinking. But be wary that many people in these areas of the organization will posses the right business domain knowledge, they will not have experience in directing the growth of new product capabilities. Quantifying value, validating effectiveness, negotiating priority, structured thinking, design thinking, defining strategic roadmaps, having tough conversations, all are capabilities that can be completely new to the person playing the product owner role. Especially in an agile setting. Expect new product owners to require support in the way of teaching, coaching, and mentoring

**Other Roles**
Given how I have talked about your stereotypical IT roles in such great length, I wanted to share some common observations I have witnessed when helping team in other areas of the organization. Think marketing, finance, product management, HR, compliance, you name it. Here are some things to think about when considering the jobs and roles in your teams.
- Historically we had one way to demarcate responsibility and assign work. It was through the org chart. This has led to people's roles being way too specialized. With the advent of visual backlogs where we assign work to teams, we can now widen most peoples jobs to include more roles, more skills, more everything. Flatten your specialist model, encourage pairing to grow expertise.
- Align teams around goals, around missions, around higher objectives. Consider making the higher outcome the job.
- Assume people have a much higher capacity for learning than you think they do. If you are going to mandate anything, mandate that people are constantly growing. Get your teams to mob, pair, or otherwise swarm so that everyone gets a better understanding of what is required to deliver value end to end.

### In Summary

- Jobs in the traditional organization are *over specialized, specified*, and are a *poor fit for the collaboration and dynamism* required to succeed in an uncertain world
- Think of jobs like a *professional sport team,* we need both *expertise* and *pinch hitting* in order to succeed!
- Design jobs so that we can encourage people to *play many different roles*, defined around behaviors that *focus on collaborating* with other roles to achieve valuable outcomes
- Moving to a more dynamic job model can be done *incrementally*