The Job Fair: On Choosing Teams

Background
Change is afoot in our business unit and one of the challenges we’re facing is finding a way to accommodate new product development with the existing teams we have.  In collaboration with the product team we decided to do a bit of a re-org and make 5 teams out of the 3 teams we currently have.

Inspiration: What is a Job Fair?  Why hold a Job Fair?
When the subject first came up in our BLT weekly meeting I sent the leadership team these podcasts from the McCarthy Show:

• Foundations of Mediocrity — Reorgs
• Foundations of Mediocrity — Reorgs (Part II)

In the podcasts, Michele and Jim McCarthy describe the motivation- numbing effect of traditional re-orgs at Microsoft, and what they did instead.  When faced with another re-org, instead of the usual sitting in endless rounds of meetings full of political battles, they organized a job fair.  If you’ve never been to a job fair, basically it is an event where companies set up brightly decorated information booths full of smiling recruiters, all trying to snap up talent.  There are job fairs at colleges and universities for new graduates as well as industry or sector specific job fairs.

The job fair the McCarthys organized took a similar format and delivered the results everyone was looking for.  As always their wisdom and approach is an inspiration to me.  There were a few key points they made that convinced us to use a job fair format for ourselves:

Transparency
This is one value that we share here and having a job fair would be a great way to uphold that value.  We would be transparent about the fact that new teams would be formed; what the teams would be working on; how many people each team would have; who the product owner, team lead, scrum master and ux for the team would be; how we would deal with conflicts over team choices.

During the actual job fair it was clear who was choosing which teams as their first and second choice.  Some people used that information to make their team decisions — either choosing teams that had people they liked to work with, or passing on teams that had people they knew they didn’t want to work with.

We prepared a confluence page before-hand with some anticipated Q&A, and asked everyone to add any additional questions in the days leading up to the kick-off.

Trust
This is another core value of ours, and again the Job Fair format does a good job of supporting it.  By using this format the message we wanted to send to the people was that we believe each person knows better than we do what they want to work on and with whom they want to work.  Rather than pushing names around an org chart in a closed meeting room, we believed the group could put themselves in teams with minimal interference from us.

Accountability
An added benefit of being able to choose your own team is that because the choice is yours, you now are accountable to the team to make it work.  It’s not so easy now to blame the other people on the team, or your manager for putting you on a team you don’t like.

Efficiency
Not counting the preparation before the job fair, the kick-off for the job fair where the POs presented their projects took 2 hours.  By the end of the first day about 90% of the people had made their decision.  By the next day the teams were fixed.

Product owners and team leads were available for more in depth discussions with people who wanted to find out more in order to make a decision.

Preparation

Our first challenge was getting agreement not only with the leadership team, but also the Product Owners as well as our HR business partner.  Getting buy-in from the POs was simple.  Our HR business partner expressed some concerns, mostly around expecting the unexpected.  In the end we decided to with our gut instinct that this would work.

Next we put together the team templates.  We included the following info:

• Product/Project name
• Product Owner name
• Team Lead name
• Scrum master name
• UX name
• # of devs required
• # of QA required
• any extra info about specialist knowledge; technology stack;

Team Template

We prepared a confluence page with some Q&A that we thought would be asked.  One week before the fair we emailed everyone announcing the event and pointing them to the confluence page.

The Day
We began the day with a half hour breakfast.  Some of the product owners were relatively new and had not yet met any of the team here so we thought it would be good to start with an ice breaker.

The kick-off began with an introduction from Gemma, our VP Engineering.  She again told people why we were doing this, what our expected outcome was, and general time constraints.

PO Presentation

Each product owner was given 20 minutes to present their products/projects.  Some used a PPT template that had the high level roadmap.  Some preferred to talk freestyle about what the project/product was about, what they saw the challenges being, how they liked to work, and most importantly what they didn’t know yet and needed help figuring out.  There was an opportunity for some Q&A after each product presentation.

Once all the presentations were done each person was given two post-its — one for their first choice and one for their second choice.  People were allowed to add their post-it to a team even if the number of other post-its exceeded the total.  We asked all the POs to make themselves available to answer any other questions people had about their projects.

Team Selection

Final Results
We held the fair on a Wednesday and our goal for the Job Fair was to have all the new team assignments finalized by the end of the same week.  By the end of day Wednesday all of the 1st choice post-its had been placed, and all but 2 of the 2nd choice post-its were placed as well.

The leadership team decided to do an initial processing of the results with the POs.  The majority of people got their first choice.  Before sharing the final teams with everyone the team leads spoke with the people who didn’t get their first choice and made sure they were ok with their team assignments.

Feedback
After the job fair we asked people to give us feedback so that we could learn what needed to be improved.  Here are some of the feedbacks we received:

Great idea of trusting the developers to pick their team! Giving employees this freedom and responsibility will lead to higher motivated employees. The new work award will not go to HR though, as they were afraid of the job fair…

Nice idea having POs showing their plans/ideas and let members to make their choice based on technical preferences, etc. Looking forward to see more of this ideas

Was really nice but I would love to see more technical talk and less product talk, a balance would be great as also developers can sell what you will be doing in the project in case you change

Retrospective
We unfortunately didn’t do a retrospective immediately after the job fair.  After the retro we found some areas to improve on:

1) Transparency: how we decide final assignments.  what are the new roles and dependencies for filling them.  what we know/don’t know

2) PO presentations: need for preparation, need to provide similar content.  need for tech perspective as well.

3) Timing: when is a good time to decide final assignments?  when should we hold the next job fair?  how much info do we need upfront to make it meaningful?

4) Choosing teams: only have two choices or ask people to rank all the projects in terms of preference?

Next Steps

Our next steps are to do another session to derive some action points from the open topics in the retrospective.  Additionally I’m hoping to spread the word about this to our other offices and offer to help facilitate a job fair for whoever needs it.

The BLT

Spoiler alert: this blog post isn’t about one of my favourite sandwiches (bacon, lettuce tomato) but i’m happy to include a picture of one nevertheless. 🙂

Source: Bon Appetit

The BLT is our homegrown acronym for the Barcelona Leadership Team.  We are  a small, and slowly growing group of team leads responsible for the Barcelona office.  As the number of people working in the office continues to grow our team is growing as well.

What’s a Team Lead?

As team leads responsible for different disciplines (engineering, ux, agile project management) some of our competencies overlap and some are specific to our area of expertise.  At the most basic level we’re responsible for the development of our respective areas, both in terms of people (hiring and people management — all that HR stuff included) but more importantly in terms of culture and values.

Team=Software

One of my big inspirations is the decades long work by Michele and Jim McCarthy around codifying a set of repeatable behaviours — Core Protocols — that contribute to high performing, results-driven teams.

In their introduction to their book “Software for Your Head”, one of the fundamental concepts is the idea that the quality of a piece of software is determined by the behaviour of the team building it.

The essence of the “Team = Software” philosophy is that the behavior of a team maps directly to the qualities of its product, and vice versa. If you want a product with certain characteristics, you must ensure that the team has those characteristics before the product’s development.

A second concept which builds upon this is that the team which is building the software is itself the product of the team who are managing them.

When applying the “Team = Software” philosophy, the team on one level is the product of the team at the next higher level. If the Level II team sees an undesirable trait in the Level I team, it must be an expression of or reflection of Level II teamwork and the Level II team members. This pattern applies to teams at all levels, right up through the corporate ranks.

With the BLT we’re trying to use this model to shape how we work as a team and what we actually work on.  The fact that we’re intentionally working as a team is still relatively new but already our orientation towards each other has acquired a stronger feeling of interdependence, shared trust, and collaboration.

What We are Working On

Here are a few of the things we are already doing and plan to do together as a team:

• Promote our shared value of trust not only with each other but with everyone on our teams. What this means in action is committing to give timely, non-judgemental feedback whenever we can.  (With the McCarthys this is very similar to the Protocol check and Intention check).  It also means we practice empathy with each other: suspending judgement and putting ourselves in the other person’s shoes so that we can better understand them.
• Pair-coaching.  In our weekly meetings we take turns retrospecting on difficult conversations/situations we have encountered on our respective teams.  Having a group of peers to bounce things off of and get a different viewpoint from helps all of us.  We are able to draw on the collective experience and strength of the team to improve ourselves.
• Share knowledge.  We frequently pass on information (articles, webinars, books, blog posts) to each other about relevant content that keeps us pushing for continual learning and improving.  For example, I shared this recent video with the team which for me did a pretty good job of encapsulating where we should be focusing our attention:
• Building our own backlog.  This is something we’ve just started so too early to really comment.  The idea is that just like each development team has a prioritised backlog, so should we.  We’re starting by collecting ideas for what could go on the backlog and then we’ll dot vote on the items we want to commit to, prioritise, and get rolling.  It would be great to make this transparent to our teams so that they can see what it is we’re focusing on

I’m really happy with how things are evolving with the BLT team.  For me it’s a relief to know that people have my back and that there are a group of people all committed to doing this team lead job right.  We’re learning as we go and we’ve given ourselves permission to make mistakes without blame.  I think it would be interesting to follow-up on how things are going in another six months to see if the BLT’s product accurately reflects our team.

Further Reading:

Software for Your Head.  By Michele and  Jim McCarthy

Leading Snowflakes: The Engineering Manager Handbook by Oren Ellenbogen

Live in Greatness: core protocols for shared vision

patience and decisiveness

Apply discipline to your thoughts when they become anxious over the outcome of a goal.  Impatience breeds anxiety, fear, discouragement and failure.  Patience creates confidence, decisiveness and a rational outlook, which eventually leads to success.

— Brian Adams

We had a team retrospective last week.  In the “Giving Flowers” part of the retro i received some flowers from my team mates for my patience with them.  It was a particularly difficult retro, and even some people decided to check-out.  For me it took a lot of energy to facilitate and at the end i was very tired.

While i was recalibrating my energy i wondered to myself if perhaps my patience is too much of a good thing.  the problem in this case was that certain members of the team had ended in a deadlock over a particular issue they were discussing, and neither side was prepared to budge.  i exercised great patience at the time, mostly observing what was happening, occasionally telling them what i was observing, but not unfortunately guiding them out of the deadlock.

timid, less emotionally stable leaders who fear upsetting anyone will let the debate drag on for weeks or months before selecting a compromised Frankenstein solution that both sides can merely tolerate. At the end of the year, the team is moderately satisfied with their moderate impact on a smattering of moderately important objectives. The team successfully achieves mediocrity, which is then reflected in the leader’s mediocre performance ratings.

Source: https://hbr.org/2013/10/just-make-a-decision-already/

I realise now that i missed the opportunity to be decisive.  To ask them to have the courage to actually face each other and talk about what wasn’t being talked about.  I imagine they may have needed a push from me to do so.  And that if in fact this had happened they may have been able to start seeing a way to work together.