lnbogen.com Open in urlscan Pro
199.16.172.107 Public Scan

Back to summary

Submitted URL:
http://lnbogen.com/
Effective URL:
https://lnbogen.com/
Submission: On September 19 via manual (September 19th 2022, 8:19:29 pm UTC) from US — Scanned from DE

Form analysis
0 forms found in the DOM

Text Content

Skip to content
* Home
* Book

Twitter Email LinkedIn

OREN ELLENBOGEN'S BLOG

ENTREPRENEURSHIP, MANAGEMENT, CODING AND MONKEY TRICKS.

May 18, 2014 by Oren Ellenbogen on Management

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.

April 14, 2014 by Oren Ellenbogen on Agile, Culture, Startups

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.

April 4, 2014 by Oren Ellenbogen on Uncategorized

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:

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

“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

October 23, 2013 by Oren Ellenbogen on Culture, Uncategorized

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:

While 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.

October 12, 2013 by Oren Ellenbogen on Management

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

August 10, 2013 by Oren Ellenbogen on Interviews, Management, Startups

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

July 3, 2013 by Oren Ellenbogen on Culture, Management, Startups

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

June 5, 2013 by Oren Ellenbogen on Uncategorized

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

June 1, 2013 by Oren Ellenbogen on Life

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!

May 2, 2013 by Oren Ellenbogen on Culture

STOP OUTSOURCING YOUR EMOTIONS AT WORK

Robots: 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.

Older Posts →
Page 1 of 26

POPULAR

Are we too emotionally invested to see that we built a beautiful product that no
one will pay for? We can learn a lot from Dan Ariely

If you lead people, here is what your boss really expects of you

If you already understand that Software Development is actually about Culture
and People, you'll really enjoy:

Software Lead Weekly - A free weekly email, for busy people who care about
people, culture and leadership.

ABOUT ME

My name is Oren Ellenbogen, an engineer with a unique passion for people and
culture.

Engineer at Commerce Sciences, Author of Leading Snowflakes, Curator at
SoftwareLeadWeekly, Explorer of Company DNA.

I enjoy writing about startups, leadership, culture, people and process.

You can reach me at oren.ellenbogen@gmail.com

FEEDBURNER RSS

lnbogen.com Open in urlscan Pro 199.16.172.107 Public Scan

Form analysis 0 forms found in the DOM

Text Content

lnbogen.com Open in urlscan Pro
199.16.172.107 Public Scan

Form analysis
0 forms found in the DOM