A few days ago, Brian Chesky of AirBnB shared an email he wrote back in 2013 to his team called Don’t fuck up the Culture. At that point, AirBnB raised more than $120MM in funding.

It wasn’t “Don’t fuck up the servers” or “Don’t fuck up the revenues”.

One of the things I appreciate most in my profession as a Software Engineer is being able to break complexity into smaller, almost tangible parts. Figuring out these patterns of simplicity can not only produce beautiful solutions, but also introduce us to the building blocks of beautiful software.

These building blocks are now available for lease. They became a commodity. SaaS and PaaS solutions are available to cover everything from hosting, source code management, databases, backups, logging, monitoring, analytics, file serving, continuous deployment, auto-scaling etc. You name it, the *aaS has it.

In 2014, you can truly focus on your business.

Can you say the same about scaling your company? Is it radically easier today to scale a team of 5 employees to 50?

Sadly, the answer is no. Those technical blocks available for $9/month don’t cover anything related to why you decided to approach building a company in a certain way.

The question becomes then, what makes a team ready for hyper-growth?

The 5 traits of a scalable team

Building a scalable team means we can adjust our goals to meet new challenges as an execution unit, without losing our unique culture or our ability to deliver.

Just like scalable software architecture – Many things need to happen under the hood to support this growth, but the end result remains the same: a (relatively) smooth transition into a new state. Here are 5 traits I believe every team should possess in order to be ready for growth:

1. Alignment of vision

Scalable teams understand the context in which they operate and can emotionally connect to the grand vision of the company. They can define their own purpose and their role as a team inside that context, and measure themselves by it.

Misalignment of vision will lead to a dysfunctional team, one that cannot create continuous value to the company and sustain changes. When we don’t understand the problems our company is trying to solve, it’s easy to fall in-love with our immediate results. It’s easy to deflect or even point fingers when things move into a new direction, as we were never emotionally invested in it.

2. Alignment of core values

Scalable teams define and cherish core values they believe are fundamental to why they do things in a certain way. It can be regarding the way they communicate, the way they approach validating ideas and implementation, the level of assertiveness and ego they are willing to deal with, what they believe is right in terms of work/life balance, and the way they treat failures or celebrate success.

What if some people in the team don’t share the same core values? They will behave in contradiction to others’ “true self”. Over time, it would trigger a conflict which will undermine the entire team-dynamics we have been trying to build. Just imagine a team of people who believe in honest and open feedback while one of them believes it is not needed, and prefers quick decision making even if it means avoiding the team when making these decisions. Combine it with some ego, and you’ve got a ticking bomb waiting to explode.

3. Core values over individuals

Scalable teams understand that reaching an alignment with core values may lead to losing existing talent due to personal traits rather than technical ones.

Scalable teams don’t write it on walls or in their presentations, they act upon this belief.

Building a team which works well together requires long-term thinking and the patience to get there. Losing talent will always drastically hurt your short-term productivity; this is why we usually prefer to avoid reaching a decision. Every time that happens the team-dynamics will change, questioning the core values we picked as a team.

4. Self-balance

Scalable teams distribute both functional and growth responsibilities. As such, not only do people fully understand their own function in the team (e.g. front-end engineer) but also their responsibility and ownership (e.g. mentoring other engineers regarding front-end practices, conducting code-reviews in their area of expertise, enabling others to conduct code-reviews etc.)

Distributing responsibilities related to the team’s growth is crucial as it encourages autonomy and mastery for each team member: it helps technical leads to leave their comfort zone as sole executioners and challenges them to analyze, communicate and mitigate risks. It encourages making decisions based on the better good of the team. It creates healthy expectations of junior employees to practice their versatility over time, while distributing mentorship to other team members.

When people are given purpose (vision), autonomy (decision making and growth ownership) and mastery (functional ownership), they can reach decisions based on their expertise and what would fit best to the team’s values. They won’t rely on management to get decisions made.

5. Sense of accomplishment (aka “work hard, party hard!”)

Scalable teams celebrate their victories as they continue to improve and tackle obstacles. The only guaranteed outcome of completed work is generating more work. Without appreciation of effort and celebration of hard-earned victories there can be only burnout. Great teams do not allow themselves to get to that point.

Alright, but what can I do today to set the tone?

We have that implicit expectation (I’d say optimism bias) that people will know how to behave as the company grows. We delay early decisions that can shape our future culture, only to find out that delaying these decisions was actually equal to making a decision of “I don’t give a damn”.

Ron Ashkenas once wrote “You Can’t Dictate Culture — but You Can Influence It“. The first step in building a scalable team is becoming active in this process of iterating on the way you want to build your company.

We need to put the effort and influence it now, rather than waiting for it to magically emerge later.

Luckily, some great companies like Buffer, HubSpot and GitHub “open-sourced” their culture: Buffer called it “The Buffer Culture: Powered by Happiness“, HubSpot’s “Culture Code” and GitHub with their “Optimizing for happiness“.

So start by doing what engineers do best: fork these slides! Have a discussion with your team, steal some concepts and create your own version-0.1.

Then do what entrepreneurs do best: Share it with the world. Ask for feedback. Make it your own. Make it something you’ll be proud to pitch to new hires.

Finally, do what great companies do best: Iterate.

p.s. check out my latest side-project, SoftwareLeadWeekly – A free weekly email, for busy people who care about people, culture and leadership.

Part of our responsibilities as leaders, is to put our teammates first.

Dick Costolo, Twitter’s CEO, uses the term “The Leader’s Paradox” – As managers and leaders, we need to care deeply and thoroughly about our people, while not worrying about what they think about us.

We need to figure out a way to push our team towards the right direction. It means we need to be mature enough to contain the pain and disappointment when things aren’t going as expected. We need a way to break emotion from behaviors, so we could judge ourselves based on the outcome we’re looking for.

But before we can act as leaders, we have to understand both the power and risks of putting ourselves in our teammates’ shoes.

Empathy and sympathy

There is an important distinction between these states, one that you should be well-aware of.

Empathy is noticing someone else’s situation or perspective. It means that you get how they analyze the situation. It does not mean you agree with them, or share their feelings. It does not mean you have to solve their problems.

Sympathy is empathy plus feeling the same way as the other person. It’s more than noticing or agreeing with one’s perspective, it’s feeling as if we were that person.

Let’s say one of your teammates is not performing as expected. Empathy will put you in a place where you could analyze the situation from their side: maybe there is a misalignment of expectations; maybe someone or something else was failing them to get the job done on time; maybe they have hard time at home. Sympathy on the other hand, will trigger memories from your own past failures. You will find yourself justifying behaviors you normally wouldn’t, because you remember the pain of your own failures.

Sympathy might lead you to act as if you were the one to fail. This may increase the chances of you judging the situation from a subjective point of view. Your teammates expect you to always act from a place of empathy, not sympathy. To really excel at their work, they need your objective opinion.

The real danger of delaying feedback

We should be fully aware of what it really means every time we say “oh, she’s too busy right now, I’ll talk with her tomorrow” or “he’s having a hard time, it can wait”.

Every time we’re delaying hard calls or honest feedback, we make an active decision that our teammates could see and learn from. Not making a decision is equally important and explicit as making one. The fact that we delayed the conversation doesn’t mean the situation didn’t happen. On the contrary, it means it happened and we decided it wasn’t important enough to take an action.

What started as a “justified” call may become a part of our team’s DNA. Once it’s ingrained, eliminating this behavior will be much harder.

The anti-asshole checklist

In order to judge my own decisions, I had to create a simple way to see if I acted from a place of sympathy or empathy. While I hated the feeling of sharing “bad news”, I reminded myself that my teammates expect me to do my best to push them further.

Here are a few questions I’ve asked myself, after making a hard decision or sharing some harsh feedback:

• Did I show empathy? The simplest way to do it is to reflect the situation as we see it, e.g. “The feature wasn’t ready on time and we had to delay the entire release. I saw that it was hard for you to get the commitment and cooperation from the Product Team. I also understand that you weren’t the one to set the deadline.”
• Did I clarify my expectations? e.g. “I expect you to raise a flag earlier, if you believe that you’re not going to meet the deadline. I want to see you more communicative with the Product Team, even if I’m not available to solve it. Earlier sync with them could have reduced the chances of delay on their side. Finally, if you feel the deadlines are wrong, I expect you to ask for help and make sure I am aware of it.”
• Did I practice what I just preached? It is imperative to demonstrate leadership by practicing it. If we’re constantly late with our own tasks (or meetings), we can’t ask our teammates to keep their deadlines. If we’re bad with communicating dependencies with other teams, we can’t really expect that from them. If they see our own boss chasing after us for status updates, we can’t expect them to be active and create visibility into their own tasks.

If I answered “YES” to each and every one of these questions, then I knew I acted from a place of growth. It didn’t completely eliminate my asshole-like feeling, at least in the beginning, but it helped me to sleep well at night.

When we act based on our deepest beliefs for what’s right for our teammates, when we lead by being forthright and clear, then it’s easier to deal with the rest.

While you may feel as an asshole, judging your actions using these 3 questions will slowly reduce that feeling. You will feel more confident, as these decisions will represent your true self.

Interested in going deep into stuff like this — pragmatic ideas and frameworks to help you systematically get better as a manager — Then you’ll want to sign up to receive a free chapter of my upcoming book, Leading Snowflakes.

—-
photo credit: joelmontes

“Am I investing my full attention in my team’s deadlines at the expense of leading by example?”

Deadlines, by nature, create a powerful feedback loop, where you get rewards such as external recognition from your boss/peers and internal ones by removing a task from your To-Do list and going home feeling “productive”. Due to their visibility and ease of measurement, most managers prefer to invest their time in keeping deadlines, instead of exercising their leadership first. By entering the “deadlines loop”, it’s easy for your teammates to feel that you’re only pushing more work into the pipeline, rather than being someone they can actually follow and rely on. It’s a rhythm that is hard to break without intentionally taking steps to put your teammates first.

Even though you’ve got plenty to prove, one of the things that should be on your mind when you’re managing people is how you can engage them in a way that will make them respect you and earn their trust.

Start with setting the tone and lead by example

The idea is to gain trust by drawing on values your teammates will appreciate:

• Get to know your people better: Treat each feature and each task as an opportunity to learn something new about your teammates. Pair Programming and Code Review are great ways to check for coding style, provide feedback and have a discussion. Make sure your teammates include these tasks when setting a deadline for a feature. Use your time together to learn which parts drive them – is it the code? architecture? new language? performance tuning? the discussion itself? the product?
• Show them they can learn from you: Many times you’ll find yourself thinking “I could do it twice as fast” while asking for an estimation. It may be because you’ve got some expertise or (more often) you simply have a better ability to visualize the required work, thus better estimating the time it will take. Take this chance to do some pair programming: break it into tasks together (so s/he could learn from you) and my secret trick – create dependencies between the tasks, so you’ll be waiting for each other at the end (solve it by introducing interfaces and mockups so you could both work). This creates anticipation to prove to each other you can nail it. When the mockups are replaced with real code, you’ll have fun laughing if something breaks down, run mutual code-reviews and ship it together.
• Define what “beautiful code” and “beautiful documentation” means in your team’s context: There is nothing worse than having a “religious debate” while deadlines are keeping your team working around the clock. From my experience, you should prefer using business concepts such as “beautiful code makes it easy to add new features on top of it” versus “beautiful code has 95% code-coverage” or “beautiful code has up to 5 methods per class” (here is my definition, slides 32 and 34, use it for reference but always prefer your own). Next time you sit with one of your teammates, you could say “I think the design you made for the feature is awesome *and I want it to be super easy to add more features on top of it later on. I’m not sure if we need the abstraction you suggest at this point, I prefer to see 1 or 2 more usages before we’re adding abstraction layers. I’m afraid we will build something that will make it harder to add things as we move forward, just because we’re lacking more context and real use-cases. What do you think?” 

• Build expectations with your boss: One of the most underused tools available for you as a manager is your own boss. There is no one more passionate to see you succeed than him/her. Learn to explain why you prefer delaying a deadline and show the value you are hoping to gain – “I know that we should have completed this feature today, but I feel there is a great lesson here my teammates can learn and I want an extra day to do some retrospection and improve parts of the code. I believe it will improve their work in the long run“. Your manager, like you, has an interest in building a long-term A+ team. That means sometimes you will both need to sacrifice short-term wins. Having honest discussions with your boss, sharing your experience and asking for guidance can provide you the oxygen you need. My advice – ask your boss to tell you when s/he think you’re too focused on short-term deliveries. It will do wonders to your 1:1 sessions. 

• Self-retrospection is not a nice-to-have anymore: I’ve written before about building a framework for improving your management skills and I highly recommend setting a 1 hour recurring meeting in your calendar once a week just for you to reflect on your work (early morning of the last day in the week should be ideal). Use it to ask yourself again “am I too focused on my deadlines or am I building confidence within my team?”

What do you think? Got more tips about setting the right balance between short-term and long-term team building? Would love to hear from you!

* always replace “but” with “and”, a great tip from Bill Gross on How to give GREAT employee feedback

———————————–
If you enjoyed this post, I’d be humbled if you’d follow me on Twitter.
photo credit: Alan Cleaver

For some, the term “Proactive Leadership” means being aware of gaps, obstacles and faults before it becomes noticeable to others. The problem though, is that noticing a problem and even taking care of it, doesn’t mean you’re being perceived as proactive leader.

Let me explain – do you remember the last time your boss jumped by and said something like “you noticed that X is stuck right?” or “what are you going to do about Y?”.

“OF COURSE I DID!” you reply, “I’ve talked with Joe, and he’s taking care of it”.
This doesn’t feel like you were perceived as proactive leader right?

Proactive leadership is about being communicative when you spot these faults, as soon as they happen. So here is my secret trick – next time you see it coming, follow the “I’m on it” template:

TO: [relevant people: your boss, your peer, your teammates etc.]
Subject: Saw that [gap], I’m on it! (EOM)

For example:

To: myboss@mycompany.com
Subject: Saw that Joe left angry today, I’m on it! (EOM)

I tend to add EOM (“End of Message”) if it’s a short status update. If you feel that you’ve got more to add to this email, feel free to add to it, but never wait with the first email! It’s perfectly fine to use something like “Saw that [gap], I’m on it! More details to follow… (EOM)”.

Being communicative will reduce the need of your boss, peers and teammates to double-check everything with you. They will get custom to the ritual of “when shit happens, she’ll raise a flag”. This is how proactive leadership should be – being aware, communicative and setting the tone.

Now I pass it to you – which tricks are you using to let everyone know you’re in control?

p.s. check out my latest side-project, SoftwareLeadWeekly – A free weekly email, for busy people who care about people, culture and leadership.

———————————–
photo credit: TORLEY

In almost every management tool out there, there is a sophisticated roles and permissions system that allows you to pick what your developers / product manager / project manager can or cannot do with the system. “You can move a Feature to In Progress only if your Team Leader authorize it”, “Only product manager can create new Feature”, “Only Project Manager can start a new Sprint”. I see it happen sometimes also in source control tools “You can commit only after your Team Leader checked the ‘code review done’ checkbox” or “Only Team Leader can commit code”.

Again, this is an internal system being used inside the organization!

I think it’s a destructive and counterproductive approach. People will stop using tools that are making them less efficient. If I know that only my Team Leader can commit my code, I’ll probably commit once a week or once a month as I cannot sit and wait for him every 10-60 minutes that I normally commit. Same goes for management tools. People will not use the tool to its full potential, if they’ll need to send emails such “can you please create this feature for me?” or “can you please approve this feature so I could start working on it?” What’s the point? I can create tasks in my OneNote or excel file and keep moving from there.

This way, data becomes less relevant, less honest, less up to date. You should trust your people to act smart and train them to utilize tools better.

How do I recover from disasters?

two words – backup system. Usually it’s really simply to backup your data every X hours (or minutes) and rollback if disaster occurred. Your people will get better as they’ll practice more often, get feedback from you and adjust. This will prevent disasters from happening to begin with. Backup system should allow your teammates to practice often, this is their safety net. Don’t use roles and permissions to create virtual trust or avoid personal headaches. At the end of the day, it will cost you more.