9

How we develop great products at scale: Trainline Engineering People and Culture

 3 years ago
source link: https://engineering.thetrainline.com/how-we-develop-great-products-at-scale-trainline-engineering-people-and-culture-716543a10851
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
neoserver,ios ssh client

How we develop great products at scale: Trainline Engineering People and Culture

Image for post
Image for post

This is the first of a series of posts in which I explain how we work in the Engineering team at Trainline. This is Trainline’s way of developing software and covers processes and practices as well as underlying principles and, most importantly of all, our culture which underpins all of this.

It’s worth mentioning that everything we do here at Trainline stems from our company values:

  • Wow our customers (You’re awesome!)
  • Focus on impact
  • Blaze new trails
  • One team

It’s from these that our Trainline way of developing software has emerged and evolved over the last two years. This has been especially important in response to the rapid growth we have enjoyed and our need to continue working efficiently and effectively at a larger scale.

It’s worth pointing out that the way we do things is an ever-evolving process as we meet new and diverse challenges, so this series describes a snapshot in time. This can be seen as a definition of Trainline’s methods of being and doing Agile. And although our way can’t simply be cloned and applied identically elsewhere, I hope that you can take some good ideas from it, both concrete and conceptual. At the very least, it should provide you with some inspiration!

A few years ago, we were a much smaller operation than we are now and so, as Trainline’s Agile Coach, our rapid increase in size has presented me with an interesting challenge when it comes to the question of preserving Agility while growing. I had to think about all the cultural elements, too, because we definitely didn’t want to become a “robotic”, “mechanical” Agile house or lose sight of our values.

But it was clear that, as our team was growing, we needed to adapt, as our existing way of working would quickly become unmanageable. We had to develop new ways of working and fast!

Our way of developing software might be considered as an “operating model”, but such a term does a disservice to the richness of our approach. There is much more to it than the term “operating model” might imply.

So, I have broken down our principles for developing great software products at scale into four key areas, which I will talk about in turn in this series:

  1. People and Culture
  2. Processes
  3. Practices
  4. Documentation

This first blog post focuses on People and Culture…

People and Culture

Image for post
Image for post

COACHES OVER HEROES

Our approach to achieving great software development begins with great people. As well as aptitude, we put a heavy emphasis on attitude. We need to ensure that our engineers have the kind of interpersonal skills which help foster great collaboration and a culture of learning. This creates a virtuous and sustainable cycle where allow people to blaze new trails for themselves, based on great role models, to become the leaders of the future.

We, therefore, prioritise the focus on being one team over elevating the heroics of an individual. For us, the true heroes are those individuals who are excellent at nurturing, coaching and generous in sharing their knowledge with others.

WELLBEING

The wellbeing of our team is paramount. Everything that we do takes into account the morale of every member of our team, their opportunities for career growth and for participation in exciting challenges.

We want to make sure that everyone has a positive experience working here. The more experienced members of our team are expected to mentor those who are less experienced to give them a clear model and path to success.

Every month we conduct a “Mood Survey” which helps us make sure that we have a good idea of how everyone is feeling and we aim to take some concrete actions each month based on the results.

THE MENTORING COMMUNITY

The culture of nurture is growing and, last year, we created a Mentoring Community, which initially focused on graduate new starters and building a network of people around them who were able to identify with their specific needs. The Mentoring Community is now expanding to provide mentors or “buddies” for any member of the team.

WE FOSTER A CULTURE OF LEARNING

We believe that a culture of learning is essential to achieve excellence. Learning is therefore woven into everything we do. Learning is part and parcel of professional life rather than something “tacked on” in the form of sterile training sessions. We don’t want our team to remain static. Every piece of work should be a learning opportunity. Less experienced team members should be benefitting from those with greater experience. Those with domain expertise should be sharing that expertise rather than becoming a bottleneck. Here are some of the ways in which we foster our learning culture:

  • Pairing
  • Code reviews
  • Brown bags
  • Communities of Practice
  • Time for Innovation

WE TRUST EACH OTHER TO MAKE DECISIONS LOCALLY

We hire great people capable of making smart decisions. From a people perspective, this kind of empowerment is a key element of a healthy team. In addition, empowerment is a great enabler of agility; when decisions can be made without the need for bureaucracy and permission-seeking, everything goes faster. Needless to say, this trust comes with great responsibility. Every decision should be made on a sound basis the rationale for which, if necessary, can be clearly expressed.

WE HONOUR OUR RESPONSIBILITIES AND COMMITMENTS

We have clearly defined responsibilities for each role and each team in the form of a RASCI chart, which means that everyone knows what is expected of them and what to expect of others.

The person responsible for an activity will often be the person “driving” it. This means that others will often need to support the driver, but the driver is the one making sure an activity happens one way or another!

WE SUPPORT EACH OTHER WHEN NECESSARY

It is important to note that responsibilities of each role must be carried out regardless of whether or not a person dedicated to the role is available. This is particularly relevant for roles such as QA, Scrum Master or BA. The absence of a dedicated BA, for example, should not mean the absence of Business Analysis activities in a team.

WE WORK IN “HUMAN-SIZED” TEAMS

A “human-sized” team is one in which the number of people in the team is small enough that it is possible to maintain organisation through “organic” human social interactions; something which comes naturally to us all. This means that there is no need for a defined process of communication and requires the minimum of administrative overhead. This is because, with few people, the number of connections between all the nodes is small. As a team gets larger, the number of connections between nodes increases dramatically to a point where it is impossible to maintain lines of communication without some kind of formalised process.

CAREER LEVELS

In order to continue scaling successfully, we have introduced a new career level framework. With a smaller team, we used to be able to employ quite a flat structure, but this is no longer viable. By introducing career levels for all engineering roles, we have provided great clarity for our team in order of pursuing their chosen career path. The levels work hand-in-hand with objectives as well as the nurturing culture mentioned above: so, the more senior you are, the more onus there is on you to coach others and to develop your interpersonal skills.

MOTIVATION AND EMPLOYEE SATISFACTION

We understand that, to get the very best out of people, they must be motivated in the correct way. Our goal is to make Trainline a beacon of engineering excellence where, like other major tech companies, Engineers yearn to stay for a very long time. We pay close attention to employee and team wellbeing to make sure our team is feeling as happy and as motivated as possible, even under the most challenging circumstances. Here are some of the factors we think about:

Care: When we care about our work, we are happier and we do a better job. And we care when the work we are doing seems worthwhile and it is clear to us that we are making a clear impact on the outcome. Care is fundamental and it is important that we all have a key role to play and are not simply an anonymous cog.

But unfortunately, care does not scale easily! To help maintain a caring mindset at scale, this is one of the reasons that we insist on working in small, self-organising, cross-functional squads.

Image for post
Image for post
(left) Large “team”, anonymous cog — care factor: LOW; (right) Small, self-organising team

We pay attention to motivational psychology. Under what circumstances do we get the very best out of each other? Drawing from key psychological theory we value:

Short-term goals: long-term goals are important as well, but a short-term goal serves to focus your attention very sharply and to remove doubt about what needs prioritising right now. The crisper the goal, the better. If the goal is far off, it is better to have shorter-term goals on the way towards it. The hooks for this in Agile are clear. This is why having a sprint goal is so important to make sure the team has a compelling short-term goal to aim towards.

Constraints: “Necessity is the mother of invention” as the saying goes. Having a goal is highly motivating, but success in achieving it is jeopardised if no constraints are applied to it. A typical constraint is a timebox (eg: 1 week), a technological stipulation (eg: must have full test coverage) or financial (eg: must not cost more than X). The constraint provides the spark of creativity to make magic happen. Working within a framework such as Scrum provides clear constraints for a team.

Fast Feedback Loop: The more frequent the feedback the better! This is a key gamification principle. Game designers have found that feeding back progress to the player is an essential component of motivation. We are spoilt for choice in this area with our metrics dashboards, our analytics, product KPI’s and so forth. We also have daily stand-ups, demos and retrospectives, cycle times and velocity to provide us with lots of feedback on progress.

Autonomy and Self-Organisation: People tend to be more motivated when they have the autonomy to decide how to go about solving a problem. We aim to set a problem and leave a team to self-organise to find the best solution. Again, this is a key Agile tenet.

Challenge: People get better at things by stretching out of their comfort zone. As I mentioned above, we don’t want a single hero to do all the work, we would rather that the expert takes a more consultative role on any given problem and challenges others.

Purpose: People are more motivated when they understand the purpose behind what they have been asked to do. The company vision is widely and regularly communicated and translated into compelling goals for each team.

So, this is the way we think about People and Culture in Trainline Engineering. To find out more about the Trainline way of developing great software, check out part 2 of this series which takes a look at Process.

Haran Rasalingam is Trainline’s Agile Coach.


About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK