Scaling your software becomes increasingly easier, but what about scaling your team?

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.


How Project Management tools kill more companies than any other SaaS out there

“If only we had an option to create sub-tasks and use templates, we’d be x10 more productive. We could build more features. We could win!” — Everyone, all the time.

Sadly, it’s all lies.

In the recent years, there is a huge blossom in the Project Management area: “This tool is great for implementing Kanban!”, or “This tool has a great intuitive UX!” and “Yea, but this tool actually follows the Lean Startup principles” are thrown into the air faster than you deploy code to production these days.

I call bullshit.

I believe that focusing your time around Project Management tools is a premature optimization and probably #1 killer of many startups. Why? In a single word: “Focus”. In two: “Wrong Focus”.

In order to build a great company, here is what you need:

  • Internal Purpose – Which kind of company are you trying to build? VC-backed? Small & Bootstrapped? Why does building this company matters so much to you? What are the core values you believe in? How would these values manifest in the way you hire people? 
  • External Purpose – Why does it matter to the world? Who do you help by building this product? Is it really valuable to them?
  • Communication & Trust – Do people feel comfortable sharing feedback and ideas? Do they understand the motivation behind the decisions made  in different parts of the company? Are you willing to argue and fight for you believe in? Are you willing to eventually let go and help the person in charge to succeed in executing upon her beliefs, even if they’re opposed to yours? Are different individuals in the company allow their peers to learn faster by enabling experimentation (via tools and teaching) rather than guarding against mistakes (via checklists and roles)?
  • Focus –  Are you saying “No!” enough times a day? Are you building momentum for the critical parts in your business? 
  • Alignment – Are you building an organization that aligns all individuals to a greater goal, instead of optimizing locally (team level)?
  • Hiring – Are you making sure that you don’t hire a “ninja” or a “hacker” that could not emotionally connect to the type of company you are trying to build? Are you hiring people who are better than you?

And here are some things you don’t really need:

  • Tasks hierarchy to the 5th level.
  • Gantt-like dependency visualization.
  •  Template-based for repetitive tasks.
  • 100% accurate Velocity tracking.
  • Single-click Gmail calendar integration.
  • A mobile app that also works on your iPhone 3GS and your iPad 1.


Project Management tools may help you to manage your work more smoothly, but the question is not how fast are you able to deliver things but how fast are you able to learn that you’re delivering the wrong things and make the adjustments.

These adjustments will never be driven by using a better tool. It’s about your attitude, your culture, your DNA.

“But hey, I thought that it’s all about Execution!” It’s not. Well, it’s not the “Execution” you’re referring to anyway. This mantra is so popular today because we tend to read articles covering the top companies out there: Facebook, Google, Dropbox, Amazon etc. These companies already have a solid definition of purpose. They figured out how to scale their communication and hiring. These companies thrived because they were able to focus on customers, growth or revenues over time. Most chances, you’re not there yet.

This doesn’t mean Project Management tools are bad or evil. You may want to invest more in them, when your foundations and product are solid. Just don’t let “imperfect” Project Management tools to be an excuse for a failed business.

It’s like blaming a poor relationship with your spouse due to a lack of decent calendar app for your iPhone.


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



Leading Snowflakes is live!

For those who don’t know, Leading Snowflakes is my first self-published eBook, taking everything I know about building a great engineering team and condensing it into a step-by-step guide.

I wrote this book to help Engineering Managers or aspiring managers become more effective at leading software engineers by improving their ability to retrospect, communicate, collaborate, delegate and inspire other people.

After a late night putting on the finishing touches, Leading Snowflakes is live:

A 20%-OFF discount on all three packages will be available for 24 hours (starting April 4th 2014, 8AM EST).


Here is what a few people are saying about it:

Leading Snowflakes

“When I first became a manager, I was hungry to learn as much as I could. If this book had existed back then, I would have bought 3 copies.”
Eli Goodman, former Director of Engineering at Etsy

“I am often in awe as I keep finding Leading Snowflakes addresses the exact challenges I face as a new manager. Reading this book lets me know I’m not alone and provides great perspective and tools to overcome these issues. Leading Snowflakes has definitely made me a better team leader!”
– Ohad Laufer, Engineering Manager at HP Software

“I had the honor to work with Oren for more than 3 years. He is one of those rare people that have an amazing sense to people and situations. Oren was blessed with the ability to analyze a situation, identify the weak spots, “re-factor” so it will work better in the next occasion and create a pragmatic tool so others will benefit from it as well. This is what his book is all about. I really love the “task list” at the end of each chapter.”
Shani Raba, Director of Engineering at Sears Israel

“I had both the pleasure and honor to review early versions of some of the Oren’s book chapters. What an inspiring reading it is! I wish I read this few years ago when I’ve just started to lead developers.
In every chapter Oren starts with the motivation usually based on his personal experience and a deep research of the modern leadership methods. The chapters conclude with clear steps that can be followed to implement what was just learned. This book is a must for both junior and experienced leader that cares about her teammates and wishes to constantly improve.”
Victor Trakhtenberg, Chief Architect, SupportSpace



Is GitHub’s self-assignment of tasks a myth?

I’ve been listening to Scott Chacon‘s great talk at Cultivate, and during that talk he was sharing how employees at GitHub get to pick their own tasks. They let people pick tasks using a very simple “decision algorithm”:


Crazy, eh? Or is it?

 As someone who’s never worked at the company with such freedom of choice in terms of task assignment, I cannot help but wonder how they handle the following scenarios:

1. Working on non-critical issues first: Say we’ve got 50 problems in our company’s backlog, ordered by priority, how do we make sure people will take the top problems that intersect with their interest? An effective organization, one may claim, would start with the most important problems, while at companies with a complete task assignment freedom, there is no guarantee that someone would not start with the 50th task.

2. What if there are important tasks with no intersection? What happens if there is an urgent task with a huge impact on the business which is simply not that interesting to the employees? Just remember the last time you had to integrate with some 3rd party vendor. The horror!

Should we force an assignment here or can we say “if it’s not interesting to our employees then we should probably not do it”?

It’s hard to imagine a situation where the company would not force a decision in this case.

3. What if we cannot eat our own dog food? Some of us are not working for companies in which the employee is actually a user of the product (GitHub employees are using their own tools all of the time). That makes it a bit harder, in comparison to GitHub, as there is no direct motivation to fix a bug or introduce a new capability.


“Let’s tell them what to do and motivate them with customers’ success (aka KPIs)”

Most companies, including the ones I’ve worked for so far, will assign the most urgent issues to their employees, by priority. Usually the Product Team (or CEO) will make sure the backlog will be prepared and prioritized to best serve the business needs. This makes it easier for each team, and team member, to pick the most urgent tasks and start with it. It reduces dramatically a situation of analysis-paralysis where employees do not really understand or sure what they need to work on and why. Then, we motivate our employees by looking at the metrics – did our effort just changed the KPI we were aiming for (say increased retention for the app)?

Using this paradigm, we couple employees’ motivation to customers’ happiness. The problem with this approach for the long run is that for most time, people would work on tasks here:

traditional-tasks-pickedWhile it makes a lot of business sense, it raises a lot of questions:

1. Motivation and retention of employees – What happens if you let employees work on important problems that the company has, but with almost zero intersection to the employees’ interest? We can always go to the basics – improving our skills – there is value in merely learning to write better code, design better products or any other craftsmanship in the company. Working on tasks which will improve our engineering skills but would also cost us days of pain, would make anyone reluctant to continue and grow in the company for the long term. As @rands said before – “Bored people quit”.

2. Branding (type of people you’d attract) – Joining a company known for a very clear hierarchy and certain way to assign tasks, may create a very specific impression for your values. An easy way to see it is to compare a traditional manager-assign-the-tasks company to a self-assignment company. Trying to judge from no internal knowledge, who do you believe have employees who are more self-managed? Where do you think people are more or less motivated? Can you explain why? What about the expectations each company has from their employees? Do you prefer to work at a place which demands decision making abilities?

Even if your gut feeling is incorrect, it is still a great way to understand the difference in “branding power” between these two paradigms. Certain kind of people would naturally be drawn to each company, and it is my belief that if I had to guess, higher-quality employees would love to join a company who trust them enough to make their own priority and calls.

3. Mentoring (which behavior do you want to cultivate) – We are what we do, not what we say. In a company where managers decide on the task order, how can we mentor anyone inside to make their own decisions? Is it okay to let them determine the priority of the tasks inside a feature but force them to implement the feature because it matters most to the business? What does it tell our employees when we trust them only to priorities and decide for the tactics without applying the same logic to the strategies?

I’m not sure there is a clear cut here. There shouldn’t be. Obviously, GitHub encountered many of these situations I’ve stated above and solved them, but it wasn’t covered during the talk (Scott, mind sharing a nice link to Quora or a blog post, pretty please? ;)). The team at Treehouse took the same path and described the entire process in a few blog posts. It’s pretty incredible and inspiring to see how they expect their employees to “sell” their ideas and projects internally. For me, it says a lot about the kind of employees they want to have and what it would be like working there.

I do believe that self-assignment is something that companies should actively strive to. Not as an end-goal, but rather as a metric or score to track. Treehouse’s example is great, as they started as a traditional organization and made the move while also kept writing about their lessons learned during that transition. This change forces hiring (and retaining) self-managed people, or at least people who want to become such and have a mentor to show them the way.

Scalable companies are ones which built autonomy and self-purpose into their DNA. Having self-managed employees with great sense of balancing their own passion with business’ needs, for me, sounds like a great way to assure employees retention while having business success.

What do you think? Do companies like GitHub and Treehouse make an exception to the rule, or is it the beginning for one of the biggest cultural changes we’re about to see in the next 5-10 years?

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


The leader’s anti-asshole list


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



Applying email marketing to impress potential hires


 Some quirky team of awesome engineers. Obviously.

Every time we are interviewing a candidate, may it be over the phone or in person, we invest significant time selling our team and company. We pull out our best story as we want them to get excited about joining us. We usually start by selling the company’s mission: “We’re changing the way [some-awesome-mission-statement-goes-here], by using [ridiculously-unique-technology]”. Then comes the PR quotes we got from TechCrunch, who invested in the company and why we’re going to be a 1 Billion Dollar business. Exciting!

But it never ends there.

Our team is even more amazing, so we continue to dazzle our poor candidate with some more information: “Three of our engineers are top contributors to [drop-cutting-edge-framework-name-here]! We have also [name], who helped creating [some-cool-monthly-meetup-group], and…”

The result: we say way too much, sometimes spending 30 minutes sharing information the candidate will never remember, yet we feel as if we missed out selling even more.

It’s not about us

“The interview is about the candidate, not about my team, my company or myself.” — It took me a lot of time to fully act upon this understanding.

I want them to get excited, but I know that many of them don’t have the attention span to process everything. They are nervous and tired, and I totally get it – interviewing is hard. Remember the time you were looking for a job? how many companies have you met? how many times you heard their pitch and completely forgot about it 5 minutes after the interview?

Focus on getting to know your interviewee.

Inspire them in “offline mode”

When I interview candidates today, I invest no more than 2-3 minutes in selling the company & team. In order to be effective, I’ve created a short “pitch” I memorized, so I could use it during phone-screening or in-person interview, without being afraid to forget something crucial.

Then, there is a little email marketing trick I’m using – I’ve got an email template ready, with awesome stories about the company & team:

  • A short paragraph about the company.
  • The best 2-3 articles about the company – can include a blog coverage, fund-raising or anything else that shows your unique strength.
  • A sentence about the hiring process – how many technical interviews, how many HR interviews, how long does it usually take to complete the process.
    • “While we are capable of moving very quickly during the hiring process, it usually includes 3 technical interviews in addition to some more of a “get to know you” and “culture fit” with our [HR/CEO]. If we believe there is a great fit on both sides, the entire process can be done in less than a week.”
  • List of the personal blogs of your teammates. Just make sure they are okay with sharing it.
  • If some of your teammates contribute to Open Source projects or regularly provide answers at StackOverflow and Quora, write it down:
    • “We believe in giving back, so here are a few open source projects we contribute to: [ … ].”
    • If you decide to choose StackOverflow or Quora, simply pick the best 2-3 answers and share those.
  • Hackathon projects are a great way to show your culture, so include a video to those as well, if you have any.
    • For example, in our latest hackathon at Commerce Sciences, we’ve built a Nerf Gun with a web interface, named “Hit The Geek” (Video)
  • If you have someone who is about to give a lecture, add “P.S. We have our own [employee name] giving a talk at [conference name + date]. You should come!”

An effective phone-screening process:

Having your email template ready, you can easily use it to save time while interviewing over the phone:

  • Introduce myself and do a 2-3 minute sell. At this stage, I’ve got my “short sell pitch” ready and memorized.
  • Explain that I’m going to send her some material on us – “Well, I could blabber for hours about us, but I don’t want to take too much of your time. I see that the email I’ve got is [some-email], is that correct? If you don’t mind, I’m going to send you an email right now with some information about the company and the team. It will include some of team’s blogs and contribution to various projects. This way, you can read more about us, and get to know us better, by looking at the things we do, in your own free time.”

That’s it. All the rest of the conversation can focus on the candidate – like it should.

The right balance at the right time

Using this email format has helped me focus on listening instead of talking. I leave it to the candidate to decide how much time to invest in reading the email. I try to make it as interesting as possible, so it would be obvious how strong the company and the team are. Also, you will win some bonus points as your candidates could see your passion and strength.

A good friend of mine shared her point of view to the impact of receiving this email, from the candidate’s standpoint:

I was on the other side of these phone calls for quite a few times, but I remember very little “selling pitches”. There were some, probably, many maybe, but they just flew by me. Maybe because I was a beginner. Having a pretty good interview run back then, and practically having the privilege of choice, I think something like a selling-pitch email would have made a world of difference in my case.

In the tough recruiting arena, it’s worth thinking outside of the box. You’re fighting to get these candidates, have you done everything you can to make them realize you’re something completely different and better?


P.S. did you check my latest side-projects? sign up to get some awesome tips for free!
1. SoftwareLeadWeekly — a free weekly email, for busy people who care about people, culture and leadership.
2. Leading Snowflakes — The Engineering Manager Handbook: practical tools and techniques for programmers who want to lead


What Dan Ariely can teach us about Software Development


Let me start with sharing an insight from Dan Ariely’s TED talk on “What makes us feel good about our work” (full list of insights from his talk can be found here):

The harder a project is, the prouder we feel about it

The Study: Ariely gave origami novices some paper and instructions to build a (pretty ugly) form. Those who did the origami project, as well as bystanders, were asked in the end how much they’d pay for the product. In a second trial, Ariely hid the instructions from some participants, resulting in a harder process — and an uglier product.

The Results: in the first experiment, the builders paid five times as much as those who just evaluated the product. In the second experiment, the lack of instructions exaggerated this difference: builders valued the ugly-but-difficult products even more highly than the easier, prettier ones, while observers valued them even less.

The Upshot: Our valuation of our own work is directly tied to the effort we’ve put in it. (Plus, we erroneously think that other people will ascribe the same value to our own work as we do).

How does it apply to Software Development?

How many times we spend years, pouring our heart and soul building software (our origami), only to find out that others are not finding it as valuable as we do?

If you read Ariely’s experiment, then you might understand by now that your developers completely fell in-love with their amazing architecture, that your operations team has a full-blown monitoring system that took months to build and that your product team has a yearly plan with at least 3 months of spec a head of time.

Here is the problem – what will happen when you’ll approach your team and ask them to throw away what they did and “pivot” to a new business? Are we too emotionally invested to see that we built a beautiful origami that no one will pay for?

Companies that fail to learn and adjust will eventually run out of money and people. This is why it’s so important to change the way we value our execution team, and set our expectations differently from what we used to.

Strive to build an organization which values learning over building

“Lean startup” created a huge impact that not enough existing companies fully understand and utilize. More specifically, not enough managers and leaders leverage the fact that “Lean methodologies” change the focus from just building things to building the right things, by asking these questions:

  1. Do we solve a real problem?
  2. Do we have customers who find our solution useful?
  3. Can we make enough money to make our solution a sustainable business?

Execution value should be equal to how fast we’re able to learn and adjust

As an execution team (i.e. everyone involved in releasing the product), our job is not only to appreciate well-crafted software, but also to understand if it makes sense to invest so much in every step of the way. We need to enable faster learning by breaking apart our solutions into smaller steps while measuring their need/usage as we release small deliveries to our customers.

Here are a few questions you should ask your execution team more often:

  1. Will we know when and how people hear about our solution?
  2. Will we be able to understand if and how they use our solution?
  3. Can we change things quickly enough to improve our solution (based on learning)?
  4. Can we measure the quality (usage) of our changes?
  5. Can we reduce amount of work and test for need earlier (think MVP)?

Using these questions to set context and priorities can help your execution team to be more passionate about problem they’re trying to solve, and the process they’re using to figure it out, as opposed to being passionate about their current implementation.

When you focus on the problem, it will be easier to change the solution.

Kris Gale (of Yammer) wrote it beautifully: “Embrace simplicity in your product and in your code. The value is in what gets used, not what gets built. “

P.S. did you check my latest side-projects?
1. SoftwareLeadWeekly — A free weekly email, for busy people who care about people, culture and leadership.
2. Leading Snowflakes — A practical guide for building, growing and mentoring teams.

Photo credit – TED


Team Lead – here is what your boss isn’t telling you, yet still expects of you


(discuss on Hacker News)

I believe that many team leaders feel constantly under fire because nobody tells them the entire story. They are too busy loading the ship with goods and pushing it forward, without thinking about their crew, their ship, or for that manner, the big blue ocean and the dangers in sailing to the unknown.

 Let me start with what your boss does tell you:

  1. You need to deliver results.
  2. You need to deliver on time.
  3. You need to communicate – raise flags, synchronize effort with other teams etc.

So you’re leaving your one-on-one meetings with your boss “checking” every one of the bullets above, yet, you feel as if you’re missing something. You’re exhausted.

It gets even worse.

If things are going well (for the company that is,) you are suddenly asked to hire more people. “Awesome, right?” your boss says; “Hell no!” you reply, “I’ve got so much on my plate. I don’t know how I could manage more people without completely losing it!”

It feels strange. You deliver great results on time, you are communicative and you love your teammates, so why do you feel out of control? Why cannot you relax?

There is an underlying expectation that nobody told you about – as a team lead, it is your job to enable your company’s scalability. [Tweet it!]

“Scalable Company” can align and adjust its team and goals without losing its unique culture (vision, values and people) in the process.

It means changing direction if the business doesn’t make sense anymore, without feeling resentment: “but I’ve invested so much time in it!” It means growing from a team of 15 to 50 without feeling pinned down: “oh gosh, it used to be fun working here. Now I need to write a 50-page document just to get something to move forward.”

Just like a scalable architecture – you can bring more users, enhance your product and the experience remains smooth. Many things happen under the hood to support it, but the end result remains the same.

Adjusting to a new reality means it will be different, but not necessarily “bad different.” It should feel as if you were already thinking about it and prepared a few plans to make it into a smooth(er) transition. There is nothing worse to a company than an ad-hoc growth without strategic planning in advance. It will only cause more panic.

Because most of us are not aware of this hidden expectation, we continue to work hard on our deliveries, but constantly fail when the company needs to adjust. “There was never enough time to prepare for it!” you surrender, mumbling “Nobody told me we need to change everything” as you exit the door. It’s too late by now.

It shouldn’t have to be this way.

In order to enable scalable companies, team leads have to proactively prepare for it:

1. Clear the way

That means detecting blockers and think of ways to remove them. Notice I didn’t say to actually remove it on your own necessarily. It’s based on the maturity of the team. It’s your job however, to monitor your team’s velocity, spot major issues and follow up on them.

2. Work on things that move the needle

Are you working on the right things? Do you help your company succeed? Do you believe in the direction your company is taking? Do you provide constructive feedback to your boss and colleagues? You better! Your teammates will feel it if you don’t. You can “hide” it for a few months, and justify dumb business decisions you do not agree with. Maybe you feel these decisions are dumb just because you didn’t have time to ask more questions? Eventually, your team expects you to push them, and if you don’t believe in your own words, people will stop trusting you.

3. Teach others how to ask critical questions

You can’t be everywhere. Assume two of your teammates are working closely with another team. Do you trust them to ask the right questions? For example: should we be ready for scale on day 1 or can we create a simple solution and monitor usage? Do we know how to test it? Do we know how to deploy it? What can go wrong? What will we do if it does go wrong? Do we know how to monitor it? What is our success metric for this feature? Can we break it into small milestones and reduce risk? Can we deliver value earlier?

 4. Make your people happy

Here is why – you are responsible for your team’s happiness because losing your people will slow you down to a point where the culture might be damaged.  And yes, you should make them happy for all of the other reasons you heard before. The alternative, if it wasn’t clear so far, can kill your company’s culture. It would be hard to recover from that.

5. Delegate as much as possible

Not only to free a couple of hours for “work time,” but also to distribute pressure and responsibilities. It shouldn’t be only up to you to handle everything. That means you will also need to let them fail. Yes I know, you think you can do it better than them, but can you teach them or is it a God’s gift? You need to give them time and encourage them when they are putting the effort.

6. Always have a plan for growth

You have to pretend as if your team is now two times bigger. Work backwards. Will the team continue to execute, or will it get stuck because you failed to scale yourself? Do you have team lead candidates that you started to mentor? Do you know how to mentor other team leads? Can someone help you with it? Can your technical leads support you in this transition? Did you tell them that?

7. Stay hands-on by working on non-critical features

You need to keep your edge so you can still teach others how to ask the right questions, help with priorities and solve complex conflicts, if needed (again, depends on team maturity level).


Next time you have a one-on-one session with your boss (or your peers,) ask for feedback on your “scalability skills.” You’d be surprise how it could reduce the amount of pressure on your shoulder.  It’s time to breathe again.

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 – jdhancock


Thanks Klarna IL!


It all began at Reversim Summit 2013, when Uri Nativ saw me wearing a t-shirt of SoftwareLeadWeekly:

Well, to be honest, I only printed a couple of t-shirts (no real budget) so I had none to give.

If you’d attend Uri’s talk about QA without QA, you will quickly know how unique and helpful he is. It didn’t take much time until he reached out, offering to print these t-shirts for me.

Oh, wow. Yes please!

Thanks to Uri and Michal Tirosh from Klarna Israel, SoftwareLeadWeekly got 30 t-shirts and over 200 laptop stickers to hand out. Their genuine care and passion to help was amazing – I exchanged around 30 emails with Michal, as she wanted to make sure everything will be perfect and to my satisfaction.

I felt humble and grateful to have them on my side. I still do.

Uri and Michal – Thank you!


Stop outsourcing your emotions at work

robots-optRobots: They look cool, but they don’t give a damn.

What if I would tell you that you are outsourcing one of the most powerful motivators at work, without even paying attention?

Do you remember the last time you got a gift at work for your birthday? Well, did one of your teammates actually make the effort of buying and picking it up or was it a “recommendation” passed to Human Resource department, who made it happen?

Looking back at the companies I’ve worked for, it seems that we somehow outsourced most of our ways to show our teammates we care about them. It was comfortable, so naturally, as the company grew, it became easier to outsource the “tedious work” of showing genuine interest and making the effort. A few other examples that come to mind:

  1. Welcoming new employees – do you personally introduce new employees to everyone else or do you let HR do it? Are you responsible for the workstation to be prepared or is it an “IT problem”? Do you prepare some kind of personal starter kit to WOW them on their first day at work?
  2. Life changing events (e.g. new baby, moving to a new apartment, getting a dog) –Do you let someone else send them the obvious “flowers & chocolates” combo?
  3. Holidays – are you writing a personal note to each teammate on New Year’s Eve or is there a generic gift that everyone gets?
  4. Fun days for the team – are you taking care of it by yourself or you wait for someone else to figure it all out for you?

I think we give up too quickly. We let someone else in the organization take care of our own people’s happiness.  Having a great HR department should assist and support you. They should nurture and celebrate it, but not own it completely. Their willingness to help should not make you lazy, sloppy or numb. It’s making the effort which counts most, not picking the best possible gift every time.

Why outsourcing your emotions will eventually kill your company –

When you let someone else take care of your employees, at best, you’ll create a bond between your employees and your company, as these gifts are usually company-wide and lacking real personal investment from you. When you take care of it yourself, you’ll create a bond with your people. Even better, if you involve your teammates, you will make connections between them, encouraging them to show interest in each other. In a world where people switch jobs every 2 years on average, the worst thing you can do is create the wrong kind of bond – “People leave managers (and teams), not their companies”.
San Antonio Spurs coach, Greg Popovich, gets it:

Yes, we’re disciplined with what we do. But that’s not enough. Relationships with people are what it’s all about. You have to make players realize you care about them. And they have to care about each other and be interested in each other. Then they start to feel a responsibility toward each other. Then they want to do for each other.


Do you also feel we have outsourced our emotions or do you see it differently? I would love to hear your thoughts, so please drop me a comment and discuss on Hacker News.

btw – are you passionate about culture and people? If so, check out my latest side-project, SoftwareLeadWeekly.


Photo credit: Ѕolo.