There’s a rich history of engineering innovation and excellence at Flickr. The team has been involved in the development of specs and open standards, been an early adopter of technologies like NodeJS, and successfully migrated from Yahoo data centers to AWS in less than a year! 

Through all the years, there has been a sense of vision and principles on the team, but nothing formally documented.  We were inspired by Artsy and Amazon to create a team vision and guiding principles, and share those with the team, job candidates, and the public.

We hope that this document evolves with the team, and look forward to discussing it with future coworkers!

Flickr Engineering Team Vision

Flickr Engineering exists to design, build, and maintain software that enables the global community of photography enthusiasts to find inspiration, connect, and share. We succeed by building a culture of innovation, being generous with providing and soliciting feedback, embracing and sharing our strengths, and delivering consistently, reliably, and predictably.

Flickr Engineering Guiding Principles

1. Psychological Safety

You and your coworkers are the most important element of the engineering organization. To learn, grow, and be productive as an engineer, you must feel safe at work. Everyone at Flickr Engineering, especially those in leadership positions, are responsible for fostering a psychologically safe work environment.

Ways to do that will include:

• Admitting and discussing mistakes
• Framing work as a learning experience
• Ensuring communication and teamwork is inclusive and respectful
• Growing a team comprised of individuals across various diverse backgrounds
• Engaging in continuous feedback and praise to coworkers
• Modeling open and respectful communication
• Sharing knowledge and opportunities to help each other level up

Further Reading:

• • What Does Compassion have to do With Coding
  • What it Feels Like to Work in a Supportive Environment for Female Engineers
  • Building Better Software by Building Better Teams
  • High-Performing Teams Need Psychological Safety. Here’s How to Create It
  • Psychological Safety, Risk Tolerance and High Functioning Software Teams

2. Incremental Revolution

Introduce new technologies slowly and incrementally. Avoid re-writes. Build tools to allow hybrids of different types of technology when possible. Sometimes you need to make a big leap, but aim to approach them incrementally.

Explore bleeding-edge technologies on projects with an end-date that can become safely classed “done.” These can be used to inform decisions on long-running projects. Run spike projects when trying to settle between technology trade-offs.

Examples include:

• Developing or adapting code to macro-services 
• Avoid creating more stacks to support, by not anticipating the scale of the work involved

3. Own Your Dependencies

Take the dependencies which fit your problem and make them better. If there’s no perfect match, take a 90% fit and contribute back to get it to 100%.

We use dependencies to save re-inventing, but it doesn’t mean our responsibility stops at installing it. Security patches, updates, roadmap changes are all vital to be aware of and tracked.

Our goal will be to feel like we can influence the design and execution of all the components in our apps. Aim to be a trusted contributor to the communities surrounding your work, communicate clearly and publicly, and be empathetic to the priorities of others.

Examples:

• Node modules for NodeJS projects

4. Done Means Done

Being responsible for your code extends beyond delivery date. Done being done means feeling confident that you’ve protected your changes with tests, ensured deployment works, and feel confident in your tools for measuring.

When something is done, it doesn’t mean that you’ll never need to go back to it, but that going back to it is a new project. It’s done.

5. Build for 10x

Technology choices should strive to be optimal while avoiding over-engineering. When designing systems or evaluating scalability and performance, we aim for today’s decisions to withstand 10x the traffic, data, or scale. Flickr is big and we can’t always anticipate the way a feature of a system will be used, especially as things evolve, but scale has always increased. This realistic horizon helps us balance the need to move quickly with the sometimes-competing need to invest in infrastructure and architecture. It also recognizes that solutions are expected to evolve and be replaced.

• Further Reading
  • Migrations: the sole scalable fix to tech debt
  • Productivity in the age of hypergrowth.

6. Appreciate What Came Before

We respect our predecessors and the decisions they made. We can’t always know the context, constraints, or reasons for a decision, so we’ll give them the benefit of the doubt.

We appreciate the value of working systems and the lessons they embody. We understand that many problems are not essentially new.

We learn together from mistakes, and appreciate it as an experience that helps us grow.