I am about 3 months into my journey as a new software engineer. I work at a place where the bar is high for what it means to craft quality software. My peers are well-educated and highly disciplined engineers with many years of experience. Those conditions alone would be enough to cause someone new to wonder things like “Am I good enough to be here?” or “Will I be able to keep up?”

To top it off, however, I have the fact that my background in software is non-traditional. My degree is in music and I am self-taught in programming. You can probably imagine the kind of impostor syndrome that someone in my position might feel when surrounded by people who are so smart and credentialed.

The self-doubt could have been paralyzing. But, somehow it didn’t last very long at all.

So, how did that happen? How did the doubt give way to the enthusiasm to learn and grow that I mostly feel today? I made a list of 31 experiences that helped me embrace being new and non-traditional rather than fearing it. I studied the list and in it noticed three patterns, which I’ve formed into lessons, that I’d like to share with you.

To keep this post at a nice length, I kept the actual list out but you can view it here if you’d like to read about each experience. I cite related experiences in brackets throughout the post (e.g. [23]). Below are the three lessons that I gleaned from pondering the list and reflecting on each experience.

Be Vulnerable

Resist the urge to hide your ignorance. It is natural to want to appear invulnerable. You don’t want to look like you don’t know what you’re doing, right? I’ve observed, however, that any effort put toward appearing invulnerable is an effort that does not go toward overcoming your ignorance. It makes it much harder to learn and grow if you never let yourself feel safe.

An easy way to check that you’re in a safe place is to show some vulnerability. If someone asks you whether you understand something, try revealing that you may have gaps in your understanding [11]. If you find that your vulnerability is met with support and encouragement, you are among great people. You are in a prime environment to learn and grow.

Thankfully, the place I work makes it pretty easy to show vulnerability [1, 10, 15, 17, 18, 19]. It makes it much easier to show vulnerability when those around you do it, too, especially those in leadership positions [15, 17, 18, 19].

Value your relationships as much as your technical skills

When you’re ramping up, technical skills are important but they are only part of the equation. It’s easy to focus too narrowly on “what you know” and “what you can do” and neglect the benefits that come from connecting with your peers. I’ve experienced, however, that the greatest strides in ramping up are made once you’ve established a relationship with your team.

Many of the experiences that helped me feel more comfortable as a new engineer were not related to gaining or demonstrating technical skills [4, 5, 8]. Even the experiences that had some technical qualities about them [6, 27] were helpful to me not necessarily because they involved technical achievements but more so because they involved accomplishments I made with my team.

Overcoming your ignorance is a lifelong journey, so go at a pace that makes sense for you

It is a journey but you may sometimes feel the compulsion to treat it like a race. If you’re like me, you have a “things-to-learn” list that only seems to get longer and there never seems to be enough time in a day for crossing things off of it. But that is just a perception. If you carry that perception, you will find yourself rushing.

Rush for long enough and you start to appreciate just how long the trail really is. Rushing is tiring. Pause for a moment and realize that you have the rest of your career to cross things off that list. You need to find a pace that is sustainable for the long haul.

The right pace will be different for each person depending on their home situation, their personal goals, and their career goals. I have a family at home but I manage to find regular time for professional development because at this stage in my career, it is a high priority for me.

My current pace is 60–90 minutes every night or so after my family goes to bed. I spend this time either getting extra practice with the tools I use at work, playing with technologies that I’m just interested in, or reading books and blogs [31]. It’s only been about 3 months, but I can already tell that making this investment is like taking steps on the long trail toward overcoming my ignorance.

I’m fortunate that my employer regularly hosts events that promote continual learning [13, 21, 22, 23, 25]. It helps me remember to travel with patience when I see that my peers of all skill levels are traveling, too.

Final Thoughts

Despite the odds described in the intro, I come to work not fearing being new but actually relishing it. Many small but meaningful experiences have helped me go from “Am I good enough to be here?” to “I can learn, grow, and contribute here”.

If you are an experienced engineer or in a leadership position, I hope reading this will encourage you to foster an environment where vulnerability, strong relationships, and lifelong learning are encouraged. If you are at the beginning of your journey like I am, I hope you found something here that you can take back and apply to your own story. Thanks for reading!

Originally posted on blog.kalalau-cantrell.com.

Talented people rank having a ‘great culture’ highly when evaluating potential employers. It can serve as a useful barometer to whether they’ll be happy and supported to thrive in their role.

Successful businesses also understand that having a great culture leads to better performance, staff retention, and attracts top talent. However, you can’t buy great culture and neither is it sustainable to force it from the top-down, or via HR alone. The good news is that it doesn’t need to cost money and is genuinely attainable. The bad news is that it takes time, can’t be achieved alone, and isn’t easily quantifiable.

Building positive culture at the department or team level serves you well in reducing the impact of other challenges that may fall outside your influence. This is also where most people can make an impact, so I’ll focus on this in this article.

An indicator that good culture has been established within a team is when its members are motivated to seek new ways of improving culture themselves, forming a nice virtuous circle. However, this Promised Land can seem distant — so here are some pointers to start cultivating that mindset.

1. Give people freedom and they’ll innovate, impress, and surprise

Micro-management is unnecessary if you’ve hired the right people. Almost everyone wants to do a good job when they turn up to work each day — so let them.

As a manager, relinquishing control, visibility, and dare I say, some credit for a team’s actions can feel unnerving. But by ensuring those closest to the product have sufficient autonomy, workers become committed team members who are motivated to solve problems it’s possible you’re not even aware of. Seeing the achievements (and consequent recognition) of team members you’ve enabled to thrive brings a very wholesome satisfaction.

The importance of allowing people the freedom and time to think shouldn’t be underestimated.

2. Encourage broader thinking

Teams are more engaged if they’ve played a part in shaping their surroundings, processes, and the principles they advocate.

Making decisions on the team’s behalf, whether big or small, is likely to result in the team feeling less accountable for outcomes — be it quality, hitting deadlines, or customer satisfaction.

Where possible, distribute ownership or seek the team’s involvement in the following:

• The recruitment strategy and interview process
• Mentoring, irrespective of function / seniority
• Evolving any formalised processes the team adheres to
• Producing a Manifesto that outlines the teams North Star principles (perfect for hanging on the walls or an induction pack)

3. You succeed or you learn

A team inspired to be brave in trying new techniques and technologies (or setting themselves bold goals) can achieve successes that a cautious team can’t. Being part of a brave team brings an energy that’s hard to beat.

By definition being brave has a degree of risk attached that most teams will avoid unless it’s been acknowledged and accepted by some form of seniority. Gaining this acceptance can be easier if there’s confidence in a review process designed to draw learning from an incident and heed how to prevent the same or a similar incident reoccurring.

4. Sharing & transparency

At a business level, introducing a forum to share client feedback, sales performance, notable successes or failures can help form a Community and allow individuals to see how their personal efforts contribute to the success of the business.

This level of transparency might be uncomfortable when the business is underperforming, but if you’ve hired good, conscientious people, then holding back information may be more damaging. It can also help build empathy for an unpopular but necessary directive that requires the team to go against their preferred approach.

At a team level, encouraging members to share amongst themselves and shout about their achievements is also a great way for their efforts to be recognised. Possible forums are blogs and internal/external talks on challenges faced or newly acquired knowledge, or departmental updates.

5. Keep things fun

Employee happiness isn’t the top priority for most companies, but it’s worth remembering that ‘‘happy team members are productive team members’’. Besides, being serious all the time is exhausting for anyone.

Don’t fret when team members talk off-topic, encourage it even. Understanding each other’s personalities, motivation, and sense of humour will bond a team far beyond one that simply acknowledges each other’s R&R’s. It’ll make those unavoidable ‘difficult conversations’ far easier if they’ve developed a shared trust.

Other ways to achieve a happier environment include encouraging face-to-face communication, leaders being considered approachable, and team-wall space being seen as fair-game for Big Visible Charts, Team Manifesto’s, Definition of Done etc.

In conclusion, investing in team culture attracts and retains the talented people that are essential for your team or even business to thrive. Take a moment to consider if you’re doing enough to champion a positive culture in your team, and reassess the true cost of that action you know doesn’t put culture ‘front and centre’.

Written by Jamie Hollis - Developer, turned Scrum Master, turned Development Manager.

Developers are increasingly turning to microservices to build and modify individual components independently. Microservices are clearly beneficial from a technical standpoint, but before teams decide to implement microservices, they should consider how creating microservices will impact team culture.

This article offers advice and insights from CTO’s who have enjoyed the successes and endured the growing pains of implementing microservices, as well as guidance for how to smoothly integrate microservices into your team’s culture.

Rule # 1: You can’t build successful microservices without a successful team culture.

Back when I was working with Java developers, I remember there being a source of tension within the camp around who got to work on the newest and meatiest features. Our engineering leadership had decided that we would exclusively use Java to build all new microservices.

There were great reasons for this decision, but — as I will explain later — such a restrictive decision came with some consequences in terms of team morale. We learned an important lesson there: to the extent possible, communicating the “why” of a technical decision to the team can go a long way towards creating a culture where people are kept in the loop.

When it comes to organizing and managing a team around microservices, it’s always challenging to balance the mood, morale, and overall culture of your team. In most cases, the leadership needs to balance the risk of team members using new technology against the needs of the client and the business itself.

This dilemma, and many others like it, has led CTOs to ask themselves questions such as: How much freedom should I give my team when it comes to adopting new technologies? And perhaps even more importantly, how can I manage the overarching culture within my camp?

Give every team member a chance to thrive

When the engineering leaders mentioned above decided that Java was the best technology to use when building microservices, the decision was really best for the company. Java is performant, and many of the senior people on the team we well versed with it. So that’s why we went with Java. However, not everyone on the team had experience with Java.

The problem was, our team was split into two camps: the Java guys, and the JavaScript guys. As time went by, new and exciting projects came up, and we’d always reach for Java to get the job done. Before long, there was some annoyance within the JavaScript camp that crept up.

“Why do the Java guys always get to work on the exciting new projects, while we’re left to do the mundane front-end tasks like implementing third party analytics tools? We want a big, exciting project to work on, too!”

Like most rifts, it started out small but grew worse over time.

The lesson I took from that experience was to take your team’s expertise and favored technologies into account when choosing a de facto tech stack for your microservices, as well as when it comes to adjusting the level of freedom you give your team to pick and choose their tools.

Sure, you need to have some structure, but if you’re too restrictive — or worse yet, blind to the desire of people in your team to innovate with different technologies — you may have a rift of your own to manage.

So, evaluate your team closely, and come up with a plan that empowers everyone in your team. That way, every section of your team can get involved in major projects, without anyone feeling like they aren’t being given a chance to thrive.

Technology choices: stability vs flexibility

One of the biggest issues CTOs and developers have to wrestle with is how much technological freedom to allow developers.

Let’s say you hire a new junior developer. They may be excited about some brand new fresh off the press JavaScript framework. Almost too new.

That framework, while sporting some technical breakthroughs, may not have proven itself in production environments, and it most probably doesn’t have great support available. CTOs have the hard choice between okaying that move for the good of morale and excitement within the camp — or declining it to safeguard the needs of the company, to protect the company’s bottom line, and to keep the project stable as the deadline approaches.

The right answer depends on a lot of different factors, which also means there is no right answer.

Technological freedom

Some CTOs and founders fully embrace technological freedom and then allow things to settle naturally on a few technologies that work well when turning to deployment.

“We give our team and ourselves 100% freedom in considering technology choices. We eventually identified two or three technologies not to use in the end, primarily due to not wanting to complicate our deployment story,” said Benjamin Curtis, Co-founder of Honeybadger.

“In other words, we considered introducing new languages and new approaches into our tech stack when creating our microservices, and we actually did deploy a production microservice on a different stack at one point. [While we do generally] stick with technologies that we know in order to simply our ops stack, we periodically revisit that decision to see if potential performance or reliability benefits would be gained by adopting a new technology, but so far we haven’t made a change,” Curtis continued.

When I spoke with Stephen Blum, CTO at PubNub, he too expressed a similar view in favor of welcoming pretty much any technology that cuts the mustard:

“We’re totally open with it. We want to continue to push forward with new open source technologies that are available and we only have a couple constraints with the team that are very fair: must run in container environment and it has to be cost-effective,” Blum said.

High-freedom, High-responsibility

Freedom comes with a caveat though: if developers enjoy the fruits of freedom of technology choices, they also need to take ownership of making sure the build works.

During my interview with Sumo Logic CTO Christian Beedgen and Chief Architect Stefan Zier, they expanded on this topic. They added clout to the position that, if you’re going to give developers freedom to choose their technology, it has to come with a high level of responsibility attached.

“It’s really important that [whoever builds] the software takes full ownership for it. In other words, they not only build software, but they also run the software and remain responsible for the whole lifecycle,” they said.

They continued by explaining that a system that resembles a federal government system should be put into place to help keep those freedoms in check by heightening responsibility.

“[You need] a federal culture really. You’ve got to have a system where multiple, independent teams can come together towards the greater goal. That limits the independence of the units to some degree, as they have to agree that there is potentially a federal government of some sort. But within those smaller groups, they can make as many decisions on their own as they like within guidelines established on a higher level,” he said.

Decentralized, federal, or however you wish to frame it, certainly seems to be an attractive approach to structuring microservice teams. It’s an approach that gives each team and each team member the freedom they want — without giving anyone free reign to pull the entire project apart at the seams.

But not everyone agrees.

Restrict technology to simplify things

On the other hand, Darby Frey, Co-founder of Lead Honestly, takes a more restrictive approach to technology selection.

“At my last company, we had a lot of services and a fairly small team, and one of the main things that made it work, especially for the team size that we had, was that every app was the same. Every backend service was a Ruby app,” he explained.

Frey told me how this helped simplify the life of his team, as every service has, “the same testing framework, the same database backend, the same background job processing tool, etc. Everything was the same.”

At the same time, Frey is sympathetic to the concept of developers wanting to introduce a new language, admitting that he “loves the idea of trying new things”. However, he feels that the cons outweigh the pros.

“Having a polyglot architecture can increase the development and maintenance costs. If it’s just all the same, you can focus on business value and business features and not have to be super siloed in how your services operate. I don’t think everybody loves that decision, but at the end of the day when they have to fix something on a weekend or in the middle of the night, they appreciate it,” said Frey.

Centralized or decentralized organization

The way your team is structured is also going to impact your microservices engineering culture — for better, or worse.

For example, it’s common for software engineers to write the code before shipping it off to the operations team, who in turn deploy it to the servers. But when things break (and things always break!), an internal conflict occurs.

Because operation engineers don’t write the code themselves, they rarely understand problems when they first arise. As a result, they have to get in touch with those who did code it — the software engineers. So, right from the get-go, you’ve got a middleman relaying a message between the problem and the team that can fix that problem.

To add an extra level of complexity, because software engineers aren’t involved with operations, they often can’t fully appreciate how their code affects the overall operation of the platform. They only come to know of any issue when operations engineers complain about it. As you can see, this is a relationship that’s destined for constant conflict.

Decentralized = high-responsibility

One way to attack this problem is by following the lead of Netflix and Amazon, both of which favor decentralized governance. James Lewis and Martin Fowler, two software development thought leaders, laid out their thoughts via a lengthy blog post. According to them, decentralized governance is the way to go when it comes to microservice team organization.

“One of the consequences of centralized governance is the tendency to standardize on single technology platforms. Experience shows that this approach is constricting — not every problem is a nail and not every solution a hammer,” the article reads.

“Perhaps the apogee of decentralized governance is the ‘build it, run it’ ethos popularized by Amazon. Teams are responsible for all aspects of the software they build including operating the software 24/7,” it continues.

Netflix, Lewis and Fowler write, is another company pushing higher levels of responsibility on development teams. They hypothesize that, because they’ll be responsible and called upon should anything go wrong later down the line, more care will be taken during the development and testing stages to ensure each microservice is in ship shape.

“These ideas are about as far away from the traditional centralized governance model as it is possible to be,” they conclude.

Who’s getting paged on the weekends?

When considering centralized or decentralized culture, you should think about how that impacts your team members when problems inevitably crop up at inopportune times. You see, a decentralized system implies that each decentralized team takes responsibility for one service, or one set of services. But that too creates a problem: silos.

That’s one reason why Darby Frey, the Co-founder of Lead Honestly, isn’t a proponent of the concept of decentralized governance.

“The pattern of ‘a single team is responsible for a particular service’ is something you see a lot in microservice architectures. We don’t do that, for a couple of reasons. The primary business reason is that we want teams that are responsible not for specific code but for customer-facing features. A team might be responsible for order processing, so that will touch multiple code bases but the end result for the business is that there is one team that owns the whole thing end to end so there are fewer cracks for things to fall through,” Frey explained.

The other main reason, he continued, is that developers can take more ownership of the overall project:

“They can actually think about [the project] holistically,” said Frey.

Nathan Peck, Developer Advocate for Container Services at Amazon Web Services, explained this problem in more depth here. In essence, when you separate the software engineers and the operations engineers, you make life harder for your team whenever an issue arises with the code — which is bad news for end users, too.

Does decentralization need to lead to separation and siloization?

Peck goes on to explain that his solution lies in DevOps, a model aimed at tightening the feedback loop by bringing these two teams closer together. This strengthens team culture and communication in the process. Peck describes this as the, “you build it, you run it” approach.

However, that doesn’t mean teams have to get siloed or distanced away from partaking in certain tasks, as Frey suggests might happen.

“One of the most powerful approaches to decentralized governance is to build a mindset of ‘DevOps,’” Peck wrote. “[With this approach], engineers are involved in all parts of the software pipeline: writing code, building it, deploying the resulting product, and operating and monitoring it in production. The DevOps way contrasts with the older model of separating development teams from operations teams by having development teams ship code ‘over the wall’ to operations teams who were then responsible to run it and maintain it.”

DevOps, as Armory CTO Isaac Mosquera explained, is an agile software development framework and culture that’s gaining traction thanks to — well, pretty much everything that Peck said.

Interestingly, Mosquera feels that this approach actually flies in the face of Conway’s Law:

“Organizations which design systems … are constrained to produce designs which are copies of the communication structures of these organizations.” — M. Conway

“Instead of communication driving software design, now software architecture drives communication. Not only do teams operate and organize differently, but it requires a new set of tooling and process to support this type of architecture, i.e. DevOps,” Mosquera explained.

Chris McFadden, VP of Engineering at SparkPost, has an interesting example that might be worth following. At SparkPost, you’ll find decentralized governance — but you won’t find a one-team-per-service culture.

“The team that is developing these microservices started off as one team, but they’re now split up into three teams under the same larger group. Each team has some level of responsibility around certain domains and certain expertise, but the ownership of these services is not restricted to any one of these teams,” said McFadden.

This approach, McFadden explained, allows for any team to work on anything from new features to bug fixes to production issues relating to any of those services. There’s total flexibility, and not a silo in sight.

“It allows [the teams to be] a little more flexible both in terms of new product development as well, just because you’re not getting too restricted and that’s based on our size as a company and as an engineering team. We really need to retain some flexibility,” he continued.

However, size might matter here, as McFadden admitted that if SparkPost was a lot larger, “then it would make more sense to have a single, larger team own one of those microservices.”

“[It’s] better, I think, to have a little bit more broad responsibility for these services and it gives you a little more flexibility. At least that works for us at this time, where we are as an organization,” he said.

A successful microservices, engineering culture is a balancing act

When it comes to technology, freedom — with responsibility — looks to be the most rewarding path. Team members with differing technological preferences will come and go, while new challenges may require you to ditch the technologies that have previously served you well. Software development is constantly in flux, and so you’ll need to continually balance the needs of your team as new devices, technologies, and clients emerge.

As for structuring your teams, a decentralized, yet un-siloed approach that leverages DevOps and instills a “you build it, you run it” mentality seems to be popular, although other schools of thought do exist. As usual, you’re going to have to experiment to see what suits your team best.

Here’s a quick recap on how to ensure your team culture meshes well with a microservices architecture:

• Be sustainable, yet flexible: Balance sustainability without forgetting about flexibility and the need for your team to be innovative when the right opportunity comes along. However, there’s a distinct difference of opinion over how you should achieve that balance.
• Give equal opportunities: Don’t favor one section of your team over another. If you’re going to impose restrictions, make sure it’s not going to fundamentally alienate team members from the get-go. Think about how your product roadmap is shaping up and forecast how it will be built and who’s going to do the work.
• Structure your team to be agile, yet responsible: Decentralized governance and agile development is the flavor of the day for a good reason, but don’t forget to install a sense of responsibility within each team.

If you’ve enjoyed this article, please help it spread by clapping below! For more content like this, follow us on Twitter and subscribe to our blog.

And if you want to add a blog or CMS to your website without messing around with Wordpress, you should try Butter CMS. ButterCMS is a headless CMS that lets you build CMS-powered apps using any programming language including Ruby, Rails, Node.js, Python, ASP.NET, Flask, Django, Go, PHP, Laravel, Angular, React, Elixir, Phoenix, Meteor, Vue.js, and Gatsby.js

Those who work with me know that I’m always obsessing about performance. Words like: critical rendering path, bundle size and frames-per-second are a common thing around the office. But it’s all for a good reason.

Performance should be a first class citizen in software engineering.

Having a strong performance culture in your team can ensure that you mitigate — ahead of time — any risks associated with bad performance.

But why is it so important? And what are those risks?

Why performance matters

Remember that as web developers, our goal is to create the best possible experience for our users.

Performance is about usability.

There are many studies ([1], [2], [3]) that show a direct correlation between business goals and usability on the web.

A fast and snappy website can make the difference between success and failure when it comes to the relationship with your users.

Your fancy UI framework and architecture won’t matter at all if your website is perceived as slow and laggy. Not to mention the scenario in which users leave because they are waiting behind a spinner or a white screen.

53% of the users will close your website within 3 seconds if you don’t show any content.

Furthermore, performance is also a metric in mobile page ranking, according to Google.

Performance is about accessibility.

Let’s talk about the global market. Performance budgets are also important when it comes to the cost of data. How much does a user pay to visit your website?

You can find out using this website. Then you can ask yourself: “Am I willing to pay x cents to visit my website?” You might be surprised by your own answer.

Furthermore, there are countries where the vast majority of internet time is spent via mobile. So you have to take a mobile-first approach in optimizing performance.

By omitting this, you are rendering your product inaccessible for a lot of people!

Performance is about empathy

We have the tendency to see our work strictly through our own eyes. This is dangerous, as it leads to a superficial understanding of our users’ needs.

Not to mention our constant need to work on the cool stuff (new technology, state of the art frameworks, and so on) and ignore boring and tedious jobs.

Performance matters, and you have to work on optimizing it with empathy and selflessness in mind. But these qualities, unfortunately, don’t come by default in all working environments.

Plan for the worst

A colleague showed me an interesting scenario a few weeks ago. There’s a home decor website which is using some CMS system behind the scenes to manage data. Someone uploaded this image:

screenshot from Chrome Dev Tools

It’s 9.3 MegaBytes of data which takes roughly 7 seconds to load on an ultra fast Wi-Fi connection and on a MacBook Pro. Can you image how much time this would take on a mobile device? The answer is infinity! Because the mobile browser becomes unresponsive when you open the website.

Here’s the website if you’re curious, but please proceed with care as it will potentially block your browser!

We shouldn’t blame the user. They wanted to display a very detailed image of an assembly.

Coming back to the idea of understanding our users, we should always prepare for the worst scenarios when it comes to user created content.

As a developer, you are completely responsible for the way in which your users interact with your software.

When to optimize

There are two approaches to performance optimizations. Ben Schwarz summarizes the two approaches in his deck, The Critical Request.

Reactive (top) vs Proactive (bottom) approach to optimizing performance

On one end, we have the traditional: “Houston we have a problem!” approach. This is a highly reactive way of treating performance issues. I also like to call it the: “Oh shoot! Call in the consultant!” problem.

Not only is this costly for your business, but it can also be a great demotivator for the team. It can even lead to conflict when people are not connected with the goals of performance optimization.

On the other end, we have the proactive approach. You bake performance optimization into your software development process.

If you need to convince the business side to try the proactive approach, check out WPO stats. This is great resource with case studies that show the benefits of performance optimizations.

Once the approach is in place, it’s the team and the culture that solve the problems ahead of time, rather than the consultant who comes in to save the day. And done right, this can be a great motivator for the team.

But performance awareness doesn’t happen over night. You have to create the right context for people to be aware of the impact of what they do.

Measure and Act

Do you know how many users are landing on your site from mobile devices? How often are you testing in bad network conditions? How often do you take out a mid-range device, like a Moto G4, and start playing with your application?

These are all relevant scenarios that your users might encounter every day!

Know your user base, and know your device and browser usages. Good and relevant metrics are everything if you want to implement a performance culture.

Once you have the metrics, it’s time to establish the performance budgets.

Finally, time to act! Here are some tools and practices you can introduce into your regular work environment:

Step 1: Measure performance indicators

• Lighthouse is an amazing project and is available in Chrome Dev Tools. It will give you great insights into potential performance improvements. It will also give you some nice suggestions for SEO, Accessibility, and Best Practices.
• Webpagetest is great for keeping track of metrics and comparing waterfall charts before and after deploys. I can also recommend gtmetrix, a less known tool, with a very easy to use interface.

Step 2: Automate

• Add performance related build steps into your CI. bundlesize is a great package if you want to define some hard limits for your bundles.
• Build automated tests that will fail if loading times or other relevant metrics exceed certain thresholds. Puppeteer has direct access to the Chrome API so you can leverage that in your tests.

Step 3: Make it visual

• Everyone in the team should be aware of the impact of the code they write. Webpack bundle analyzer is a great way of visualizing what goes inside the output bundles. People might think twice before using a library which increases the overall size by 10%.
• import cost for VSCode will show you how much code you are adding to the project by using certain dependencies. Again, it’s all about making sure everyone is fully aware of the impact of what they do.

Step 4: Enforce and Empower

• You have to be ready to enforce strict rules within the organization. In our case, we created a performance checklist to be followed on each project.
• Make sure everyone in the team gets to work on the performance optimization tasks. You don’t want to have a single person that does that, because you get into the consultant scenario again. By splitting the tasks, everyone gets familiar with the context and with the different ways of preventing problems.

Building a performance oriented culture is a step by step process. And it’s a process of understanding the problems and acting on them.

One constant in the entire process is the need to educate people.

Performance optimization techniques are not complicated. But they need some technical background and a good understanding of how the web works.

Building on top of a solid foundation can help your team grasp even the most advanced techniques for speeding up your application.

In our case, we make sure web performance is part of the learning path for all engineers. We don’t just enforce a checklist. We make sure people have a good environment to learn the reasons behind the techniques.

_[Performance cheatsheet poster](https://github.com/FortechRomania/js-team-showcase/blob/master/how-we-work/performance/performance-cheatsheet.png" rel="noopener" target="blank" title=") in our office at Fortech

Performance as part of software quality

In the end, working on performance is the same as working on UX, security, or accessibility. It is part of the software quality that you offer.

At times, it might seem like extra effort for something that is not requested of you. Performance might not be part of your non-functional requirements, after all.

But coming back to the idea of responsibility, it is our duty to provide the best possible quality. And performance is one of the pillars of software quality.

If I were to sum up the path towards a performance culture, these are the key takeaways:

• Raise awareness, and build with empathy for the user
• Favour the proactive approach and deal with issues ahead of time
• Measure and act in a continuous loop
• Spread the knowledge and involve the entire team in the process
• Make it part of your software quality as an end goal

References

Since a lot of people ask for materials on web performance, here are a couple of places you can start from:

• Google Developers portal has great articles on performance optimization techniques
• perf-tooling.today offers a lot of great resources on web performance
• The Chrome DevTeam’s publication explores a lot of great ideas and case studies about improving the performance of popular websites.
• Check out our performance checklist on github and contribute with ideas!
• Also have a look at Smashing Magazine’s 2018 front-end performance checklist, it is really impressive!

I’m super curious to hear your thoughts on this. Is your team embracing a performance culture? What works for you? What doesn’t? Leave a comment and share if you enjoyed this article!

I recently left Space Ape Games after a won­der­ful year. I learnt a lot, and worked on some chal­leng­ing tech­ni­cal prob­lems.

Here are seven lessons that I learned from one of the most well-run companies I have encountered in my 13 year career.

Define what culture you want, and organize yourself to optimize towards achieving that culture

Lots of com­pa­nies talk about how great their cul­ture is, but few talk about what their cul­ture actually is. Worse yet, I sus­pect most end up with a cul­ture they don’t want, because the cul­ture grew organ­i­cal­ly and with­out guid­ance.

To this day, the Net­flix cul­ture deck from 2009 is still the one of the best things you can read about cul­ture.

Real com­pa­ny val­ues are the behav­iors and skills that we par­tic­u­lar­ly val­ue in fel­low employ­ees.

— Reed Hast­ings

Be clear about the culture you want to build from the start. These are the characteristics and skills that we value in each other at Space Ape:

Pas­sion­ate: you have a pas­sion for games, and you want to build games that are fun and engag­ing.

Cre­ative: you are not afraid to stray off the beat­en path and try some­thing new. You accept the risks that come with cre­ativ­i­ty. You won’t let fail­ures stop you from suc­ceed­ing.

Judge­ment: you make smart bets. You bal­ance the risks of cre­ativ­i­ty with method­i­cal analy­sis of the poten­tial rewards to make smart bets.

Depend­able: you are depend­able and trust­wor­thy. We believe in small, autonomous teams. For this to work, we need to be able to depend on every indi­vid­ual in the team.

Focus: when required, you can put aside per­son­al projects and focus on delivering the best game pos­si­ble.

Mas­tery: you are a mas­ter of your craft. You want to become the best ver­sion of your­self and are always look­ing for ways to improve.

Col­lab­o­ra­tive: you work well with oth­ers. You are will­ing to make sac­ri­fices and com­pro­mis­es for the greater good of the com­pa­ny. Game mak­ing is an inher­ent­ly cre­ative and col­lab­o­ra­tive process. We need peo­ple that can thrive in a col­lab­o­ra­tive envi­ron­ment.

Inclu­sive: you wel­come oth­ers for who they are. You treat oth­ers equal­ly and fair­ly, the same way that you expect to be treat­ed.

Reit­er­ate this vision regularly. We find that if it is not reiterated at least once every couple of months, then it starts to slip through the collective consciousness.

Make sure new employ­ees are imbued with your vision. And remind employees of their duty to main­tain your culture.

Culture lives and dies by the people you hire and fire

This shared under­stand­ing of cul­ture needs to filter through to every hir­ing deci­sion.

“Cul­ture fit” is often used to enforce exist­ing bias­es, especially when said culture is nev­er defined up front to begin with. Fortunately, this has nev­er been the case in any of the hir­ing com­mit­tees I have sat on. When­ev­er “cul­ture fit” is raised as a con­cern, you must give clear exam­ples from your inter­ac­tion with the inter­vie­wee.

At the same time, you shouldn’t hire some­one who might be detri­men­tal to your cul­ture — not even when you are des­per­ate for anoth­er pair of hands on deck!

The cost of a bad hire to your cul­ture is too great.

The founders also act as the van­guards for your cul­ture. They watch from afar, but they’re nev­er afraid to step in when they see the dan­ger signs. If a long time employ­ee starts to show signs of self-enti­tle­ment, then expect a gen­tle reminder about the company’s com­mit­ment to inclu­sion and fairness.

Even when you have built a great culture, you can’t afford to take it for granted. It’s the duty of everyone involved to keep that culture strong.

People are your most important product

This is true for most com­pa­nies, which is why it should be a no-brain­er to invest in the peo­ple and help them grow.

Offer train­ing bud­gets to every­one, and pro­vide man­agers with man­age­ment coach­es. The results will be well worth it.

Founders need to communicate the vision of the company openly, clearly, and frequently

Avoid impres­sive-sound­ing but vague mis­sion state­ments. Vague goals that do not define clear, action­able tar­gets are hard to fol­low and apply. Collaboration suf­fers when peo­ple do not have a shared under­stand­ing of the com­pa­ny vision.

Our founders reit­er­ate the com­pa­ny mis­sion at every quar­ter­ly com­pa­ny meet­ing. The rep­e­ti­tion has been impor­tant in rein­forc­ing the shared under­stand­ing of the goal. I recent­ly also saw Ryan Cald­beck, the CEO of Cir­cle­Up, say the same thing on Twit­ter.

Our mis­sion state­ment is “to build a top gross­ing mobile game by own­ing a genre.” Sim­ple, unglam­orous, but easy to under­stand.

Be honest about conflict of interest

Man­agers usu­al­ly have the best inten­tions when they set out per­son­al objectives for their charges. Every­one gets a set of objec­tives that align with the company’s goal. Where is the con­flict of inter­est?

What you might think when you set out personal objectives.

Things seldom work out as you expect, though. What usually hap­pens is that some projects will go more smooth­ly than oth­ers. At the same time, some projects deliv­er more val­ue to the com­pa­ny than oth­ers.

Nod if this sce­nario sounds famil­iar.

You’re work­ing on project X, and your end of year pay raise, bonus, and promotion hopes are all rid­ing on the suc­cess of project X.

A col­league is work­ing on project Y, and he needs you to work on some­thing to unblock his project. Project Y is more valu­able to the com­pa­ny, but help­ing this col­league means los­ing progress on project X.

What do you do?

Do you do the right thing by the com­pa­ny and help this col­league? In the process you might lose the pay raise, bonus, and pro­mo­tion that you have worked so hard for.

Or do you put his request in the back­log and focus on project X?

Hel­lo, con­flict of inter­est.

What actually happens when employees need to collaborate with one another, and often have to sacrifice their self-interest for the greater good of the company.

If you think this only hap­pens in poor­ly-run com­pa­nies, then you’re wrong. Even Google is not immune to this con­flict of inter­est, as is evi­dent in Michael Lynch’s arti­cle on why he quit Google.

Team­work requires will­ing sac­ri­fice.

In foot­ball, a “team play­er” car­ries the con­no­ta­tion of being will­ing to sac­ri­fice themselves for the team. Be it risk­ing injury in a 50–50 chal­lenge, or pass­ing to a team­mate who’s more like­ly to score.

How do you trans­late this to the work place? How do you encour­age peo­ple to make will­ing sac­ri­fices for the good of the com­pa­ny?

You have to start by being hon­est about this con­flict of inter­est.

Your employ­ees are not saints, they are flesh and blood with real world problems. What if they need the pay raise to start a fam­i­ly? And what’s wrong with want­i­ng career pro­gres­sion?

Employ­ees have every right to act in their best inter­est. It is your job as employ­er to cre­ate an envi­ron­ment where employ­ees are not penalized for mak­ing self-sac­ri­fice.

You can do this in sev­er­al ways.

The biggest, most effective way is to sep­a­rate per­son­al objec­tives and 360 reviews from performance and salary reviews.

Per­son­al objec­tives are for your per­son­al devel­op­ment only. Your man­ag­er can help you decide what areas to improve on, but the final deci­sion is yours. You’re encour­aged, but not required, to set per­son­al objec­tives.

360 reviews are also for you and you alone. You choose from whom you want feedback, and how to pro­ceed with the feed­back you receive.

The feed­back is anonymous, and only the man­ag­er of the review­er knows who delivered that feedback. This is main­ly to mit­i­gate any unnec­es­sary ten­sion from ill-considered feed­back.

Your man­ag­er and the founders are also there to help you process the feedback if you need their help.

Per­for­mance and salary reviews are based on what you actu­al­ly con­tributed, not some arbi­trary tar­gets that were set months ago.

For us, this unusu­al way of work­ing start­ed with a frank dis­cus­sion about this conflict of inter­est. It has been iter­at­ed upon over time and will con­tin­ue to evolve. It’s been such a fresh breath of air for me to work for a com­pa­ny that not only rec­og­nizes the prob­lem but active­ly seeks to tack­le it.

Marry creativity with ownership

Cul­ti­vate cre­ativ­i­ty from the whole com­pa­ny using game jams and hackathons. But remember that cre­ativ­i­ty needs to be guid­ed, and hypotheses need to be test­ed.

We use a creative funnel to guide ideas from hypothesis to production.

The game jams gen­er­ate ideas to feed the top of the funnel. Every­one can come up with ideas for new games. You have the own­er­ship and responsibility to pol­ish your idea and pitch it to the rest of the com­pa­ny.

Teams form organ­i­cal­ly around ideas that they’re excit­ed about and believe can be top-gross­ing. This is NOT a top-down deci­sion.

The founders are there to offer guid­ance and help with per­son­nel move­ment. Whilst your idea might be great, the founders can guide you on shap­ing the idea to fit your mis­sion.

Is it eco­nom­i­cal­ly fea­si­ble to build?

What is the mar­ket com­pe­ti­tion like? Is the genre sat­u­rat­ed with high qual­i­ty offer­ings already? Does this genre have top gross­ing poten­tial?

Do we have the tech­ni­cal exper­tise to build it? If not, how dif­fi­cult is it to hire someone with that exper­tise?

The teams that form around an idea focus on pro­to­typ­ing and iter­at­ing on the idea. The idea becomes a playable game, and the rest of the com­pa­ny then plays and pro­vides feed­back.

The team owns the idea, and is trust­ed with mak­ing the deci­sions to keep going or kill it if they no longer believe in it. Again, this is NOT a top-down deci­sion — the deci­sion is made within the team.

Which brings us to the next point.

Recognize that creativity requires mistakes

Cre­ativ­i­ty needs fail­ures to suc­ceed.

Being cre­ative and exper­i­ment­ing with new ideas means tak­ing on risks. If you don’t risk, you will not win big — at least not with­out the mar­ket­ing bud­get and brand that goes with estab­lished franchises.

To let teams take on risk, and to trust them to make the right deci­sion on the company’s behalf and kill a pro­to­type, is hard.

For this to hap­pen, you need an envi­ron­ment where employ­ees are not penalized for mak­ing sacrifices.

We do this by cre­at­ing a safe­ty net for jobs.

Your job is not tied to the pro­to­type. If a team decides to kill its idea, then the team mem­bers move into oth­er game teams, or they’ll stay togeth­er and pro­to­type anoth­er game idea.

To prove this approach works beyond our scale, con­sid­er Super­cell and Clash Royale. The team behind Clash Royale was work­ing on anoth­er idea before they came up with that one. The idea test­ed well in beta, it had good reten­tion and mon­e­ti­za­tion stats. But it was not great, cer­tain­ly not on par with Clash of Clans.

The team made the deci­sion to kill the idea because they believed they could do bet­ter. So they took the learn­ings from the previous game, iter­at­ed on the ideas fur­ther, and they cre­at­ed Clash Royale.

Rec­og­nize that peo­ple and their tal­ents are your great­est assets. Hire and keep great peo­ple rather than hiring for and keeping certain roles.

Conclusions

So there you have it. Seven things that I learned from my time at Space Ape Games.

What stood out most for me is that a company needs to have a clear identity — it needs to know who it wants to be, and it needs to orga­nize itself to become that com­pa­ny.

And while I love the ethos on small autonomous teams, and the flat hierarchy structure, it also has a downside: at this stage of my career, I am accus­tomed to hav­ing a wide range of respon­si­bil­i­ties, and I crave it.

As time went by, I felt that itch for more respon­si­bil­i­ty creep­ing back. When my old friend Bruno Tavares pitched me the idea of join­ing DAZN to work on all the great things they’re doing, it was hard to say no.

With a heavy heart, this is my farewell let­ter to Space Ape Games and the great peo­ple with­in. You guys are awesome! And I hope the lessons I’ve learned there help others as well.