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.


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


How To Use Your Unfair Advantage To Create an Unforgettable First Day For New Hires


Let’s say that you’ve just hired Emma, one of the most talented [title goes here] on the face of the planet! How cool is that, right?!

If you’re like most of us, you’ve probably prepared a powerful (mac)laptop and a gigantic, cinema-size screen waiting for her arrival. But you didn’t stop there, haven’t you? You smart, devilish-fox…

You also came up with one or two tasks she can do on her first day at work, maybe even considered to let her press the BIG RED button and deploy her work to production. Anything you can do to make her feel frighteningly productive, eh? Nodding your head?

I’m sorry to burst your bubble, but you’re doing it wrong.

People want to connect with people, not with todo lists

Even though feeling productive is a strong emotion, it is also a short-lived one. In order to create a long lasting emotion, a real WOW effect, you have to create a personal bond.

Research has shown that a person’s mood can be affected even by 3 degrees of separation from people they don’t even know. That’s right, t-h-r-e-e. Do you remember feeling utterly ecstatic because a task of a user-story of a feature smiled at your direction? Nope? Nothing? Bingo!

It’s time to pull out your secret weapon.


 AirBnB’s secret weapon


Do you remember the slide of which investors drool on? The one with those smiling faces of people trying to have fun and build things? “Our Team”, you refer to it (others may call it holy-f$ck-what-a-bunch-of-geeks), and this, my friend, is your unfair advantage.

Ever wondered how you can use this handsome bunch of people to create an unforgettable first day at work for your new employees?

“Your job is to bring down the walls”

I really like the way Roy Klein, our newest secret weapon at Commerce Sciences, puts it –

You’re job at the first week is to bring down the walls and let new teammates talk and get to know the team. If they’re good, they’ll be effective anyway, so don’t worry so much about it. Find ways to make them connect. Eat lunch out every day together, play some Team Fortress 2. Whatever works!

Some ideas to get your brain ticking, your heart pumping and your face doing some funky stuff

Make them smile

To fuel your creativity, let me share a personal story. Five years ago, after getting a super talented engineer to agree joining the team at Delver, I wanted to make sure he’ll have an awesome first day.

I was so excited to have him with us that my mind was spinning like crazy, figuring out how to make it a memorable first day.

About a week before he joined, I saw on Facebook that he raved about Let’s Say You’ve Gone Back in Time poster. “Ahh!”, I thought, “I can purchase it and have it framed!” This is exactly what I did, having it hang above his workstation, waiting for his arrival.

Ask your team to be creative, to go crazy, to give away some loovvvvve

If you know that your new guy or gal enjoy playing a game, say Startcraft 2, maybe you can buy a miniature and place it on their table, with a little note “We’ve got your back! Attack!” Or, if your new hire is a part of distributed team, send them a barber shop quartet to sing her a song.

It’s time to pull some Nicki Minaj craziness to show them you were waiting for them!

Make it a company tradition

We have a little tradition, where the last person to join the company is responsible to create a “starter kit” for the next one to join. No rules, no guidelines, just your creativity, time and effort. It’s something that started before I joined, and it blew my mind on my first day at work. What a day!

8 months ago, when Omri joined the company, it was my turn to prepare something for him. Luckily, I had the chance to sit with him for lunch before his official arrival. We had an interesting discussion about our shared interests and how we’re both fascinated by “brain hacks” – figuring out how our brain works and how we could utilize it better. I remembered a great book I read called Your Brain: The Missing Manual and thought to myself that it would be a great welcome gift to give him. I knew that 5 years from now, when Omri opens this book and re-reads my dedication on the first page, he’ll remember his first day with us. It wasn’t much of a starter kit (yes, we had his working station ready as well ;)), but it was something I thought he would appreciate. I hoped it would make his first day with us memorable.

When our latest teammate, Roy, joined us, it was Omri’s turn to prepare an awesome starter kit. I forgot to mention that Omri is our marketing hero and by far the most creative dude on the team. The box you see at the top of this post was made by Omri, and was waiting on the table for Roy when he arrived. It was filled with jokes, coffee capsules, nerf-gun ammo (don’t ask) and above all, Omri’s personality.

Passionate about #culture and #people?

Check out my latest side-project, SoftwareLeadWeekly.

Your turn!

Do you have a story you can share about how you WOW-ed your new teammates? I’d love to hear from you in the comments.


Teammates First Deadlines Second

“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


My secret trick for Proactive Leadership

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:

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


Why using roles and permissions internally? Trust died?

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.


Sprint Planning versus Version Planning

Should you start with planning your sprints and then see how it fits your versions? Maybe start with versions and understand how your sprints look like? Maybe planning versions by themselves is enough? How do you start?

Decouple external planning from internal planning

External value (features your customers will enjoy) moves the organization. It is why you get paid. No one will pay for “let these kids develop for fun only”, this is why open source projects were born, for developers to write some code that may or may not be used by others. Versions are communicated out to your customers, named in a language your customers can understand “in version 1.0 we will allow our customers to upload their profile image” rather “we will integrate jQuery and develop highly scalable upload mechanism over Amazon Cloud”.

Internal value (features your organization will enjoy) keeps the organization fully operational, doing its best over time. It is usually not communicated out (your customers don’t really care if you’re using C# 4.0 or C# 3.0) and not named in customer’s lingo.

Versions are more tangible

Most of us stick to planning versions and our sprints actually look the same as our versions. We’re results oriented and we want to please our customers. Moreover, no external power is actively pushing us toward internal value.

Sometimes internal value > external value

If you’re strictly results oriented, you might produce great results but only for short, unpredictable periods. Sometimes you’ll need to delay customer’s value to handle broken “machine” in your factory. Your customers won’t like this delay, but they will understand it if you’ll offer tradeoffs and communicate “we are fixing internal machine to keep our high level of production steady”. They will prefer stable producing rather than insane, poor quality or unpredictable results.

Use Sprints to prioritize internal value with external value

Maybe you can devote 5% of the sprint to maintain your ability to produce fast? Maybe 10%? Maybe 1%? It’s really up to you to figure out what you want to push every sprint. Be careful of dismissing internal value, it’s your role to actively push for it.

How do I start?

I prefer to set some goals for my sprint first: (a) is there an internal value I want to push? (b) Are there people in my team that I want to push by leading features? (c) What is my team availability for this sprint?

With this in mind, I’m starting to plan my versions for the sprint and next one, making sure I understand perfectly what should enter the sprint and when. This is the first time I validate my plans. If the planned versions fully occupying my sprint (or even more than that), I raise a flag and trying to figure out if something can be shifted without causing damage. If not, and I have some “buffer”, it leaves me with understanding how much of my internal value I can push inside the sprint, alongside external value. This is the second time I validate my plans. Did I manage to push my goals to the sprint while producing external value? If I notice there is a big need for internal value that cannot wait, I will try to understand alternatives with our product team and supply tradeoffs.

Then, all is left is to organize when should each feature start/end and making sure external value (versions) are released on time while internal value is keep moving. Keep your head above the water, plan to last.


Should you allow changes during Sprint?

Sprint is a planning unit, keeping it stable during that time allows a pretended piece of mind for the developers from marketing/product ever-changing demands. So it feels anyway. We developers signed up a virtual contract with our product teams saying “we will be Agile enough to allow you to change your mind every 1-3 weeks, but don’t disturb us during that time! We want to work, not wasting our time on talks!”.

Does it make sense to you? Is this the true notion behind Agile? Would it be acceptable for a great business?

Well, it makes sense only if you think that waste is more valuable than your attention. Delaying smart decisions or cutting off bad ones after 2 weeks, 2 days or even 2 minutes is simply counterproductive. If you know that a feature selected for the sprint became a waste due to priority change, why should you move forward with it? why throwing the problem to the other side of the fence: “well, my product team should have been wiser with their priorities. We’ll do it anyway just to teach them a lesson so they won’t do it for next sprint!”

Priorities tend to change. It happens constantly. Don’t panic, be open-minded and make sure your team leaders can handle priority shift. It’s perfectly okay to say no, but make sure it’s a “reasonable no”. If you see it does make sense to move out some features and move in some others, do it with care, offer tradeoffs (“this change might mean we won’t be able to release the version on time, let’s delay it in 2 days”) and make sure motivation passes to your team. Your teammates need to realize that providing organized waste is plain dumb; they also need to trust you doing these changes with full attention, clarifying tradeoffs and setting expectations. Practice your agility!