Know Thyself – Welcome to Mozilla TRIBE

TRIBETRIBE is a new Mozilla leadership program currently being built by Mozilla’s People team. The purpose of TRIBE is to transform the Mozilla culture by developing leadership skills across the project. (Modest, I know.) The focus of the initial session is on you – knowing your strengths, identifying your reactive tendencies, and understanding the ways in which you listen.

I completed TRIBE session 1 this week in Toronto. I have previously taken a good chunk of the IBM leadership and soft skills training course catalog. That is to say, I have a pretty good understanding of how this type of course is typically structured and delivered. (IBM courses are delivered by a number of different vendors.) TRIBE session 1 was something different. After the last two days I am left blown away by the extremely well put together material and delivery of this newly developed course.

The initial TRIBE session is a group experience but an individual journey. What I mean by that is that all of the members of this session participate in the same discussions and exercises and all have access to the same course materials. However, as this session focuses on you, your journey will be very personal and not one that will be replicated by anyone else in the program. Your takeaway thoughts and actions will be specific to you. You will succeed by building trusted allies in your course mates, who will equally rely on you for their own success. So, while I cannot tell you exactly what you will get out of this course, judging from the reactions of the people with whom I shared the last two days, I can tell you that this time looking inward will serve you well.

I have three suggestions for anyone who has signed up for TRIBE session 1:

  1. The strength finder assessment that you will complete before the course may not make sense to you initially. Don’t judge the strength finder assessment until after you have completed the initial TRIBE session.
  2. Before attending the session spend a few minutes thinking about the where you would like your career to be in 2-5 years.
  3. Before attending the session jot down the names of a few people who you admire and think would be valuable to you as mentors.

When something is well done acknowledgement and thanks are in order. As such, I want to thank Debbie and the People team for developing a truly excellent course offering. I also want to thank Kate Roeske (Red Carrot Leadership) and Athena Katsaros (IdeaTr!be) for doing a wonderful job facilitating our session this week.

As the purpose of TRIBE is to transform the Mozilla culture, TRIBE is open to all Mozillians. Course schedule and registration details can be found on the TRIBE wiki page.

Posted in mozilla | Tagged , , , , | 2 Comments

Mozilla Engineering/Platform Meeting Reboot

“congrats on drastically improving this meeting (IMHO) I am feeling greatly optimistic about mozilla all of a sudden”
- Brad Lassey (ref)

The Platform meeting has been in limbo for some time. Since taking the helm in February, I found it difficult to answer questions like: What is the purpose of this meeting? Who is the target audience? Why do we meet each week? After discussions in the meeting and on the Mozilla dev-platform mailing list, this week I made a mostly wholesale change and rebooted the meeting.

The Engineering Meeting

The name “Platform Meeting” is a holdover from the meeting’s origins. This meeting has long included updates from non platform teams such as the desktop front-end, mobile front-end, and stability teams. More recently, the meeting added updates from Firefox OS and Firefox Metro. This is really an engineering wide meeting so let’s call it the “Engineering Meeting”.

Meeting Purpose

One of my goals with this reboot was to be able to clearly articulate what this meeting was about. My working definition of the meeting’s purpose is:

The Engineering meeting is a weekly time to discuss the work of engineering teams and share information relevant to the day-to-day work of engineers.

Meeting Agenda

I restructured the meeting agenda around the meeting purpose. The meeting now focuses on engineering teams and the relevant information from engineering support teams. I have also asked each person responsible for an agenda item to update the wiki the day before the meeting so as to have a set agenda before the meeting starts.

Agenda

  1. Actions
    Action items from previous meetings.
  2. Hot Bugs
    Orange Factor, Stability, and other high priority bugs that are currently unowned or require help to make progress.
  3. The Need To Know
    Release related notices and schedule and upcoming system outages and upgrades.
  4. Key Issues
    Bigger topics and non team specific issues that are of interest to Engineering.
  5. Team Stand-ups
    A short (<2 min) update from each engineering team. No questions during the updates!
  6. Quality Programs
    An opportunity to hear about relevant updates from our Critsmash, Memshrink, Orange Factor, and Stability initiatives.
  7. Roundtable
    All other issues and any questions that come up over the course of the meeting.

Meeting Time

The meeting time remains unchanged. The Engineering Meeting is held Tuesdays, at 11am PT. Details about joining this public meeting are available on wikimo.

Meeting Notes

One of the requests that came from the dev-platform discussion was for improved meeting notes. I would like to know whether the changes that have been made to the meeting agenda have resulted in an improvement to the notes. If you read the notes, I would appreciate your input. Please comment on this post, post to dev-platform, or e-mail me privately. For your reference, here’s a link to this week’s notes.

Feedback From the First Meeting

The feedback after the first meeting was very positive. Here’s a sample from IRC:

“congrats on drastically improving this meeting (IMHO) I am feeling greatly optimistic about mozilla all of a sudden”
– Brad Lassey (ref)

“this is the change we needed”
– Doug Turner (ref)

“yeah i think i’m going to start coming to these regularly again”
– Jesse Ruderman (ref)

“this is exactly what I wanted to get out of this meeting”
– Daniel Veditz (ref)

“this meeting was very useful to me, learned several interesting things”
– Gavin Sharp (ref)

A Work In Progress

I consider the Engineering Meeting a work in progress. This meeting should continue to evolve to meet the needs of our engineering teams. Have an idea to improve the meeting? Please post to dev-platform or get in touch with me privately.

Posted in mozilla | Tagged , , | 11 Comments

May Open Web Open Mic Toronto: Call for Presenters

owomapr2013

What: Mozilla Open Web Open Mic
When: May 22, 6-9pm ET.
Where: Mozilla Toronto, 366 Adelaide St. W, 5th Floor

Mozilla Open Web Open Mic (OWOM) is back for May. Put on by the Mozilla Toronto community, OWOM features a science share exploration and lightening talks (5 min). April’s event had a great turnout (50-60 people) and included a variety of content from WEBVTT, to MakerFaire, to my talk Building for Mobile Web Compatibility.

The call is currently open for science share participants and speakers. Sign up at
https://mozillianstoronto.etherpad.mozilla.org/owom-may-2013

Interested in attending? Sign up now at
http://owommay2013.eventbrite.ca/#

Posted in mozilla | Tagged , ,

Challenge: Take horseplay on the road

Europtimum delivers Totoro

A couple of weeks ago, our friends at Europtimum responded to our horse gesture (timeline) with the delivery of a most excellent Totoro. For those of you unfamiliar with Totoro, my understanding is that it is a 1980′s Japanese animated cat. This particular manifestation is a cat like box, which the lovely people over at Europtimum made themselves and filled with an end of week snack consisting of candy necklaces, rockets and super balls. (Despite at least one person having never previously seen a superball, no one ate the superballs.) Needless to say, fun for the whole office.

TotoroMozilla and Europtimum have been having a fair amount of fun. However, our initial connection was simply location based – their office is on the fifth floor in the adjacent building. A small act of kindness to brighten the day of our neighbours has resulted in a wonderful series of back and forth with them that has brought smiles to both of our offices.

This latest bout of kindness got me thinking that it’s time to take horseplay on the road – that is, to spread the fun to others.

Here’s my challenge. Take a look out of your window and pick an office. Figure out who’s over there and then, quite out of the blue, send them a horse related product. (Bonus points for doing it in person!) Let’s see what sort of new relationships will form simply by taking a few minutes out of your day to do something nice for a group of strangers. The horse head that we sent is available on Amazon. Some other fun products might be a lucky horseshoe, a plush animal, or mane and tail.

To kick things off and break the international border, the Mozilla Toronto office has sent a horse head to our Mozilla colleagues in France to celebrate their new Paris office.

A bonne chance!

Note

Posted in mozilla | Tagged , , ,

Building for Mobile Web Compatibility

Last Wednesday’s Open Web Open Mic event at the Mozilla Toronto office was really great. 50-60 people from the Mozilla Toronto community gathered to discuss their projects via a science fair and a series of lightening talks. I had a good conversation about WebVTT with a group of Seneca students, learned about the upcoming Mini Maker Faire Toronto from Jenn Dodd, and discussed the use of What Can I Do For Mozilla for non coding work with Josh Matthews.

As this was an Open Web event, I took the opportunity to talk about Building for Mobile Web Compatibility.

Building for Mobile Web Compatibility title slide

The takeaways from this presentation are AVOID:

  • User Agent (UA) Detection
  • CSS Vendor Prefixes
  • Browser Specific Property/Feature Usage

Instead, PREFER:

  • Feature Detection and Media Queries
  • Web Standards

If you would like to see more, I have posted my slides on github.io.

Thank you to everyone who came out to this event and especially to Majken ‘Kensie’ Connor for pulling us all together.

Posted in mozilla | Tagged , , , , , | 2 Comments

Who are these managers and what do they do?

As the Mozilla project has grown so too has our management structure.  There are a number of people with various manager titles involved in the day-to-day operations of many Mozilla projects. You may know some of these people and have a sense of what they do. This post is to help clarify these positions so that you can better understand the value that people in these roles bring to the project and their relationship to your work.

There are four types of managers that I will discuss here: development managers, product managers, project/program managers, and release managers.

development managers

A development manager has responsibility for a development team, such as front-end, WebAPI, or performance. It is the development manager’s responsibility to guide the team’s work, balancing various requirements and the relative priorities. Development managers are people managers. This means that they are responsible for the professional growth of the people on their team and that of the team itself.  They serve as reviewers, mentors, and advisers. Many Mozilla development managers are very hands-on writing patches and providing code reviews.  Some people you may know in this role are Gavin Sharp, Andrew Overholt, and Taras Glek.

Takeaway, development managers:

  • are people managers
  • guide a development team’s work

product managers

Product managers are more removed from day-to-day development. They gather requirements for Mozilla products by reviewing market research and trends, following standards bodies like the W3C, and speaking with the engineering community. They have the challenging job of forecasting the requirements for our products based on their projected market needs 3, 6, 12, or more months into the future. Product managers provide strategic guidance for our development efforts through user and developer stories, use cases, and product roadmaps. They help with tough decisions about feature and product prioritization. Product managers spend their time looking at the big picture to ensure we can all see the forest for the trees. Some people you may know in this role are Asa Dotzler, Karen Rudnitski, and Chris Lee.

Takeaway, product managers:

  • gather requirements from stakeholders and create roadmaps
  • provide guidance and leadership to engineering

project/program managers

Project/program managers drive projects by managing project scope, schedule, and risk. They serve as a project steward and sounding board for stakeholder issues. Project managers coordinate work from various teams such as release engineering, product, user experience, support, quality assurance, press and pr, marketing, legal, privacy, WebDev, and IT. The result of working with these teams is that people in this role are typically well connected in the project. Unlike release managers, who, as I will discuss below, focus on individual releases, project managers focus on projects that may span multiple releases or multiple products. Many of the people at Mozilla who are in this role have strong technical backgrounds having come from the development organization at Mozilla or elsewhere.  Some people you may know in this role are Sheila Mooney, Caitlin Galimidi, and me.

Takeaway, project/program managers:

  • drive projects by managing scope, risk, and schedule
  • coordinate the work of many different teams

release managers

Release managers are similar in many ways to project managers except their focus is on individual Firefox releases. The release management team manages and coordinates release schedules for the Firefox desktop and mobile Release, Beta, Aurora and Nightly trains, as well as Firefox OS. They monitor and control our risk profile and its impact on our product quality. They chase down critical issues and manage chemspill releases (point releases for critical issues). They ensure that the process flows from code check-in, to build, test, and release. They triage and track bugs in current and upcoming releases and coordinate the resolution of external issues, such as those due to plug-ins and add-ons. Release managers have to balance the needs of the various Firefox stakeholders including engineering, release engineering, quality assurance, support, documentation, and IT. Some people you may know in this role are Alex Keybl, Lukas Blakk, and Bhavana Bajaj.

Takeaway, release managers:

  • drive Firefox releases
  • triage and track bugs and coordinate the resolution of external issues

working with your managers

If you have worked with people in these manager roles you may have noticed that some people seem to be doing aspects of multiple manager jobs. The descriptions of each role above are the core responsibilities of each group. These roles tend to bleed into one another to a certain extent. All of the people in these roles are leaders within the organization and each have skills that allow them to play multiple roles.

Now that you know more about these roles and the people in them, use them. Talk to your product manager if you want to understand more about the product requirements and priorities. Talk to your project manager if you are blocked, unclear about project scope or timeline, or need some other help with your project. Talk to your release manager if you have questions about the upcoming release or have critical work that you think should be brought to their attention. And talk to your development manager about your engineering work and your career.

Posted in mozilla | Tagged , , , , , | 11 Comments

No More Snappy Meetings and Other Changes from the Snappy Team

I want to summarize a few operational changes coming out of a team discussion during this week’s Snappy work week.

Snappy is a collection of mostly discreet sub-projects. For example, Paulo’s work to make downloads async does not overlap with Benoit’s work on the profiler or Vladan’s work on improving start-up. The changes listed below are based on suggestions from the Snappy team for ways to better support Snappy’s project structure, improve project predictability, and reduce meeting inefficiency.

Project definition and leadership

We are going to be more explicit with our project definitions by listing high level requirements. There is also now a stronger requirement to scope the project. This means spending time thinking through the project before starting to code.

We will also identify the key project team members and a project tech lead.

Project tech lead responsibilities

In addition to providing technical direction for a project, the project tech lead will be responsible for:

  • organizing and running project meetings
  • blogging biweekly about the project

No more Snappy meetings

In an attempt to make better use of our collective time, the Snappy meeting will be cancelled in favour of project specific meetings. The goal is to have shorter meetings that are more on point for the attendees.

Monthly performance program reviews

A new, monthly performance meeting will be established to review quarterly progress and discuss project delays. This meeting will also be an opportunity to discuss new project proposals and review overall performance goals.

Daily updates

Due to the increased time between larger project meetings (monthly instead of biweekly), we will try short, daily updates via IRC. We will experiment with statusbot for managing and logging daily updates and aggregate updates in Benjamin Smedberg’s weekly updates tool. The goal of daily updates is that each team member’s work should be visible. i.e. Managers and tech leads should not need to ask what you are currently doing. Each team member is responsible for pinging statusbot in the #perf channel daily.

Posted in mozilla | Tagged , , , | 4 Comments