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:

http://leadingsnowflakes.com/

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:

“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

(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

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"

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  

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’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 ;))

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 :)

“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 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).