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.


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


Team up: my presentation is available

Management and leadership is a topic near and dear to my heart. As such, I decided to invest some time and construct a lecture to help out current team leads and upper management to gain some outside view. This will hopefully gear up your thinking on the subject, opening your mind into new practices and new questions you should consider pondering.
Obviously, potential leaders will enjoy this presentation as well :)

If you want me to come and give this presentation at your place, please ping me. My email is on the right or reach me at @orenellenbogen (twitter)

Team Up:

Lately, it seems that process became trendier than core leadership skills. Agile, Scrum, Kanban stole the focus. 
BUT – it is leadership that fuels process adoption rather than process auto-magically fixing disfunction teams.

In this talk we’ll explore what went wrong in this process adoption race: from hiring or promoting the wrong people, avoid setting clear expectations from our leaders, to dropping lean practices due to lack of deep understanding (forgetting why we started to begin with).

The dark side is interesting to explore, but we are here for the bright light – we will bring the FOCUS back to how we want our leadership to look like. 
We’ll try to figure out how we want our leaders to look like in the "Agile era"


Subscribe to the new lnbogen feed (via feedburner)

2 months ago I switch to FeedBurner to track amount of readers of my blog. This helps me to understand if I’m living in a void Smile 

I recommend switching your current subscription to the new one by simply tracking the feed here: http://feeds.feedburner.com/lnbogen
I apologies for the inconvenience and appreciate your time reading my stream of thoughts.


I forgot to write down what I’m trying to learn

I’m writing for about 5 years now. I’ve spent numerous hours writing about coding, architecture and management. Some people liked it although my blog is yet another stream of words in a big pile of information called “the internet”.

The amazing fact is that my top post (by far, I’m talking about ~90% of my traffic) is about Visual Studio .Net 2005 Colors!
Yes, a single post, out of hundreds, about a niche topic, got all the spotlight. Frickin’ Lovely.

So like most startups, I’ve build->didn’t measure->didn’t learn->WTF? FAILED!

This year I’m trying to drive my effort by aiming for learning first (learn –> measure –> build): starting from what I want to test (my hypothesis) then to see if/how I can actually measure it and then to build it, or write about it. I’ll share my journey as I go, hoping you’ll find it interesting.

Happy 2011 everyone!



You probably meant to write mail but the keyboard fooled you; but hey! you can read about leadership, development and coding instead of reading your emails! What a win!

(I’m curious to see if you reached my blog because of this post, if you did – please “Like” this post. Viva la Google ;))


Lnbogen meets Facebook Like

Leaving a comment is considered a bigger commitment than just voting “Like” or “Recommend” on a post you feel is useful. I believe that such information, which posts you find interesting, is also useful to other readers. With this information, others can find more recommended posts, even though they don’t necessarily contain 50 comments.

This is why I added “Facebook Like Button” to my blog.
If you Like it, let me know :)


How User Stories were born

“Agile/Lean movement” and Scrum in particular, made short cycles a key factor in the process. May it be cycles of planning, cycles of development or cycles of releases, there was a big arrow pointing at *short cycles* to figure out how to get more accurate, more responsive, more productive faster.

Due to the short cycles, the Features or “Product Backlog Item”, sometimes, just didn’t fit in. “My 2 months Feature won’t enter our 2 weeks Sprint!”. Because Sprint is, wrongfully in my opinion, being highly tied to releases, it raised a need to allow breaking Feature to multiple Sprints. The question is “how to break it right?”.

User Stories came to offer a methodology to assist in this need. The idea is to detail the Feature in multiple end-to-end flows (which good Feature already detail) and implement them one by one instead of trying to implement the entire Feature at once. Because User Stories are subset of a Feature, in the same language as a Feature, it felt that these stories can replace Features and Sprint will contain them as smaller execution parts. This will obviously “solve” the mismatch of Feature size to Sprint size.

I claim that it didn’t solve anything at the core level. Even worse, my feeling is that User Stories introduced a dangerous abstraction, one that should be used carefully. More on it in my next post…


Delver beta is alive!

Delver is all about letting you to explore, research and (eventually) purchase products in a different way. Pushed and driven by what your network has to say, it will be easy for you to see what books your friends recommending, what kind of movies are hot or which camera you should buy next. You could publish polls, to get help from your friends on what to purchase, you can rate products and write reviews, you can create a catalog of items (“My ski trip to Italy”), create a gift catalog and share it with your other friends, recommend products to your friends and plenty more!

You’re more than welcome to check it out at http://delver.com/

We are still in “closed beta”, which means you need an *invite* to get in. Once you’re in, you can send invites to your friends and enjoy their feedback on items you’re interested at. If you want an invite, drop me a line with your email (or email me directly).