Culture is a set of norms, implicit rules and values that a group of people live by. It entails what is right or wrong, acceptable or unacceptable in people’s behavior. Culture is a living, breathing thing, constantly changing and evolving. Wix Engineering is proud of its dev-centric culture. It puts us at an advantage in recruiting and retaining top developers.

As our company grows, we have to make sure we don’t lose our culture. Left unattended, it will turn into ‘null culture’. It’s what happens when no formal culture is put into place. It leaves people guessing what is socially acceptable and creates an impossible environment for those who guess wrong. It’s not the type of environment that makes employees want to stick around.

One of the ways in which we actively influence and strengthen our culture is through Kickstart, an onboarding course for junior server developers (a similar course exists for junior front-end developers).

There are more junior developers than there are senior ones yet; most juniors aren’t measured by how they influence a company’s culture. Instead of treating them like influencers and sending them out as agents of the culture a company wants, they end up learning whatever culture is around them, which is not necessarily the culture the company wanted to instill.

Because we understand the dramatic effects culture can have on our organization, Kickstart is produced with three elements in mind: professional training, culture, and psychological safety.

Professional training: the easy part

We help new employees learn practical skills so they can start contributing as soon as possible.

These skills are:

• Scala (our primary programming language)
• Common dev tools & frameworks (CI system, wix-framework, monitoring, etc)
• Dev methodologies (TDD, clean code, etc)
• Wix product & high level architecture
• Where to get help (documentation sources, people to talk to, information channels)

How we do professional training

Open specs

Deliberately open specifications for features encourage Kickstarters to ask questions and explore trade-offs. This is a recurring theme in the course.

Variety of learning materials and techniques

Online resources (not tailored), lectures and workshops given by company employees (tailored).

Personal mentorship

Design reviews, code reviews, and 1-on-1s for setting and following-up on Kickstarters’ personal goals. Read more about this here

Independent long term project

A ״nothing-to-production״ project.

Must haves:

• Simple and clear (but open-ended) product requirements
• Clear definition of done (what)
• Clear guidelines (how): Test first, small commits, deploy often
• Clear expectations and goals
• Challenge: Task should not be too easy — we want to provide a sense of accomplishment, task should not be too hard — as to prevent frustration

Culture: the (un)written rules of our organization

New employees come in with a load of questions, most of them not about technology at all. Some questions can be anticipated and have well-defined answers (usually around salary, ESPP and other legal factors). Other questions may not have an obvious answer or may have an answer that’s inconsistent throughout the organization. It is up to us to help new employees discover what questions to ask and where (and how) to get answers.

We invest time and resources into creating an environment of knowledge sharing and personal growth so everyone is informed and can work toward their goals.

Common questions include:

• When am I expected to show up / leave? How long is lunch time?
• How available do I need to be for production issues?
• How do I communicate with other developers? (Slack) How do I communicate with non-devs? (Hangouts)
• How do I get someone from another team to do something? (usually, a Jira ticket, sometimes personally following-up)
• Can I plan a vacation for 6 months from now?
• How do I make sure I don’t suck at my job?
• Stigma vs Reality: address rumors about your company

Techniques for unveiling culture elements

FAQ pages

FAQ pages, knowledge bases, readmes and cookbooks — these cover the well-defined questions and answers, anything with company policy.

Panels led by course staff

A panel with Kickstarters from previous cycles. Examples of questions asked:

• Describe your group / product / team. What are the main challenges you face in your role?
• How was your onboarding process after Kickstart? Were you assigned a buddy / mentor?
• How much did the course prepare you for working in your teams? How similar is the material to real work?
• Tell us about a bad experience you’ve had since joining the company
• Tell us about something you do at Wix that has nothing / little to do with your role
• Describe workflow, code review process in your teams

A panel with team leads. Examples of questions asked:

• What are the main challenges your team faces?
• What kind of tasks do the server devs on your team work on? Who do they work with? (PM? FED?)
• What is the onboarding process for a new team member?
• How do you define success for a new team member?
• What is the process a new task goes through from idea to production?
• How are code reviews done?

Informal Q&A

Impromptu and informal Q&A with several server guild members during meals, happy hours and coffee breaks.

Someones to ask the “stupid” questions

Course staff takes notice of terms that may be unfamiliar/unclear to Kickstarters and asks “stupid” questions.

Psychological safety: creating a safe space to learn

Psychological safety is ‘‘a sense of confidence that the team will not embarrass, reject or punish someone for speaking up, it describes a team climate characterized by interpersonal trust and mutual respect in which people are comfortable being themselves.’’ Edmondson, 1999.

Kickstarters come in from different backgrounds and experiences. We rely on feedback from Kickstarters to let us know if and when they don’t understand something or if they’re missing prerequisites for a subject we want to cover. This feedback loop cannot exist without them feeling safe enough to express themselves freely, without being judged.

Creating psychological safety

Course staff — managers, teammates, mentors, lecturers — need to communicate the following:

We are Inclusive

We try our best to make everyone feel included and important.

We acknowledge our faults

We are open: we disclose our mistakes and failures, and gain insights from them.

We ask for feedback

We explain that we make mistakes and need help. We encourage Kickstarters to ask for help, clarifications, feedback or information.

We are comfortable with mistakes

We are comfortable with the idea of failure. Mistakes are inevitable. We can fix what’s broken and learn from our failures. We share and discuss errors and failures.

We ask questions

We supply autonomy through questions. Kickstarters are pushed to think for themselves and to propose solutions.

And, most importantly,

We are accessible

In person, by text, Slack, Hangouts, phone call, carrier pigeon, whatever works.

Repeat, repeat, repeat: our entire staff — managers, teammates, mentors, lecturers — is on board and communicates these messages through both actions and words.

Strength in numbers

Developers coming into Kickstart have one clear advantage: they are part of a group, part of a team. Left alone, this team would create their own culture organically, and once the course ends, they would enter the greater fabric of Wix, and continue to affect our engineering culture in unexpected ways. In order to make sure we instill and strengthen the core values of Wix Engineering, teaching Wix’s tech stack and development methodologies must go hand in hand with setting the cultural narrative and establishing psychological safety.

Karen Cohen heads the Wix Kickstart program for server developers.

Originally published at karenmeep.github.io on July 14, 2017.