You're on your way to the next level! Join the Kudos program to earn points and save your progress.
Level 1: Seed
25 / 150 points
1 badge earned
Challenges come and go, but your rewards stay with you. Do more to earn more!
What goes around comes around! Share the love by gifting kudos to your peers.
Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!
Join now to unlock these features and more
The Atlassian Community can help you and your team get more value out of Atlassian products and practices.
Twitter began with a sketch on a piece of paper. A status update. A site for people to share the latest happenings in their life.
Over the years, this evolved into a platform where people share things that are a part of their everyday life, as well as Breaking News.
As we saw ourselves growing across the world in different geographies and markets, being used by people of different languages, we had to scale out the service as well as the engineering teams to support that.
What happens if you don’t scale?
Twitter's Fail Whale
This image was drawn by an Australian artist and was used by Twitter.com when the service was down to show that we’d stuffed up – an example of something that happens when you don’t scale.
And this is something that happens when you do scale.
We reached this number shortly after the US Presidential Election.
And then the following August (2013) we facilitated almost 10 times the volume.
The rate and pace with which we were growing was why it was so important we were staying on top of the growth of the service and scaling the company as a result.
So how did we do this? Company Alignment – it all starts with a vision
You’ve got all these people, and you are managing to solve all of these technological problems around scaling the service, how do you scale the people?
It all starts with a vision. Our vision was Tahrir Square.
At Twitter, we wanted to foster and facilitate the communication, discussions and conversations that took place in Tahrir Square, around the whole world.
Our vision was to be the global town square.
We broke that vision down into our goals – our Objectives and Key Results (OKR’s)
The Objective = where do we want to go?
Key Results = how will we know when we’re getting there?
So when we looked at our company goals, we started right from the top, with our company objective/s, and below those company objective/s we had our Key Results.
This vision was so important because as we cascaded down and fed back up, we had alignment across the whole company – and of course the alignment is what packs power and effectiveness.
Structuring with Tools
The tools are what gave us the structure to enable us to change the behaviour across the organisation – and at scale, changing people’s behaviour very quickly in a manner of months was super important.
At Twitter, we used the following tools to do this;
JIRA, JIRA Agile, Script Runner, Confluence and the Confluence Presentation Macro
It was extremely importing for us to have consistency. The way we achieved this was through JIRA Agile, which allowed us to input all of the data in the same way, every time for every team.
Epic Issue Type
Each team will have their own agile board (Scrum board). Down the left hand side of that board (Epics column) is where teams are able to drag and re-order their Epics based on most valuable to least valuable Key Result.
Beyond the Epic and the ordering of that Epic, we had a special workflow.
A lot of the workflow that we had for our Engineering Teams at Twitter, involved a lot of automation. So what we did was create an entirely separate workflow just for the Epics.
Some of these included;
** One thing to note: the Resolved step changes the Epic Status field to Done and takes that Epic (Key Result) off the team’s board
A few key things to note here.
The Assignee was generally the Engineering Manager of the team responsible for delivering the Key Result and the Reporter is quite often the Product Manager or the Product Owner for that team.
The Key Results field was really important for us. It was the second part of that question “how will we know that we’re getting there” and that’s what we were looking at achieveing throughout the aurter.
This is where we looked at the incoming and the outgoing dependencies.
This visualisation of dependencies enabled us to have key discussions prior to the beginning of a quarter, if we could see that the thing we were depending on from another team in order to reach our Key Results, would not be delivered in time.
Having these links helped us align as a company and make sure that we are all on the same page.
Confluence was how we shared what was going on with the whole company.
We had pages for Company, Group and Team Goals. On the Company and Group level, the objectives and Key Results were laid out in predominantly text – there was no JIRA integration here.
As we got down to the Team level, we illustrated each of the major areas across the organisation, and the team’s within those.
When we got to the Team level, we created a page for every team’s goals, and that page pulled in the following things;
Setting up the JIRA Issues Macro in Confluence
Presentation Macro for Confluence
Throughout the quarter we had check-ins: what’s this team been up to and how are they progressing towards their goal?
This is where the Presentation Macro for Confluence came into play.
At Twitter, we had a Weekly Launch Meeting which gave every team the opportunity to present what they have been working on, demo their work and provide a status update to a higher level.
Here is an example of what it looks like in the Presentation macro mood. It is based on a Jira Issues Macro and the results out of Jira. This meant that any time you went into a presentation you were automatically getting the latest information.
Watch the full Summit 2013 talk: Collaborating Across an Enterprise
18 accepted answers