RSS Feed

Latest Entries

First time here?


Developing Critical Team Thinking

Borrowing a few terms from critical thinking, this is another map, or model, of how I feel I need to guide my teams. When do I feel like I have successful gotten my team where they could have been all along?

Here is a great quote from this PDF file on critical thinking:

From the cognitive scientist’s point of view, the mental activities that are typically called critical thinking are actually a subset of three types of thinking: reasoning, making judgments and decisions, and problem solving.

I say that critical thinking is a subset of these because we think in these ways all the time, but only sometimes in a critical way. Deciding to read this article, for example, is not critical thinking. But carefully weighing the evidence it presents in order to decide whether or not to believe what it says is.

Critical reasoning, decision making, and problem solving—which, for brevity’s sake, I will refer to as critical thinking—have three key features: effectiveness, novelty, and self-direction.

Critical thinking is effective in that it avoids common pitfalls, such as seeing only one side of an issue, discounting new evidence that disconfirms your ideas, reasoning from passion rather than logic, failing to support statements with evidence, and so on.

Critical thinking is novel in that you don’t simply remember a solution or a situation that is similar enough to guide you. For example, solving a complex but familiar physics problem by applying a multi-step algorithm isn’t critical thinking because you are really drawing on memory to solve the problem. But devising a new algorithm is critical thinking.

Critical thinking is self-directed in that the thinker must be calling the shots: We wouldn’t give a student much credit for critical thinking if the teacher were prompting each step he took.


the last part hit home on many levels about what it means to coach someone to learn a new skill.:

Critical thinking is self-directed in that the thinker must be calling the shots: We wouldn’t give a student much credit for critical thinking if the teacher were prompting each step he took.

Learning a new skill  means that they do not need you there to continue doing something. that you are no longer a bottleneck.

A self organized team is a self-directed team, as far as critical thinking is concerned. But we want our team to not only be self directed, but also effective, by avoiding common pitfalls as as discounting new ideas, seeing only one side of an issue, etc. Learning to be effective is to acquire a set of new skills, of each of these pitfalls, if they occur for members of the team.

A critical thinking team uses novel ideas, not always blindly applying templates to different problems, but always experimenting, and finding new, better ways, of doing new, or even the same things. there is always something new to be learned.

As I usually say, if everyone is too comfortable, you’re not learning anything. so something new has to jump into the equation in the form of a new experiment (‘what if we did no iterations for 3 months?’)


Elastic Leadership in Devops Survival Mode

This blog post from the devops guys, shows that the idea of “survival mode” or chaos can exist in many different places. and a command and control leadership can help buy valuable time that you can then use for learning. to quote :

Step 1. Kill the current fires, so sanity and actual thinking resume.

“When I took over the Operations of a high-volume UK website about 8 years ago I spend the first 3 weekend working fighting fires and troubleshooting Production issues.

My first action after that baptism of fire was to revoke access to production for all developers (over howls of protests). Availability and stability immediately went up. Deafening silence from Development – Invitations to beers from the Business owners.


Next step, get some friendly forces to help with the effort, if no one within has any idea what you are driving at:

Next step was to hire a build manager to take over the Build and Deployment automation, and a Release Manager to coordinate with the Business what was going into each release, when etc. End result – 99.98% availability, with more releases, being deployed within business hours without impacting the users, and a lower TCO. The Business was much happier, and so was the Development Manager, as he was losing far fewer developer-hours to fire-fighting Production issues, and hence the overall development velocity improved considerably. Win-Win.


Their view of survival mode Command and control:


Was that a DevOps anti-pattern? Did I create more silos? Probably… but in a fire-fight a battlefield commander doesn’t sit everyone down for a sharing circle on how they are going to address the mutual challenge of killing the other guy before he kills you. Sometimes a command & control model is the right one for the challenge you face (like getting some suppressing fire on the target while you radio in for some air support or artillery!).

The post goes on to talk about using the freed time for learning and getting better (in not so many words):

That said, once we had developed a measure of stability we did move partway to a more DevOps pattern – we had developers on-call 24×7 as 3rd line support, we virtualised our environment(s) and gave Developers more control over them, and we increased our use of automation.

Later on, the post mentions that organization influences (see ‘structural motivation - six forces) like different incentives, stopped the continuous learning from breaking up any new silos of knowledge.

overall, this is a very interesting read for me, as I can see many parallels in the ops word to the software world and the elastic leadership principles.


Feeling Stupid is Highly Recommended

So, to show you that the whole idea of taking risks and feeling stupid or frustrated is actually a good thing, because it's the only way to really learn a new skill, here are videos from my second day ever doing any kind of skiing. This is from a few hours ago:

this is from the first day


My muscles are still calling for help, but on the second day, things are much much better. I am happy I didn't give up trying, and I watched a lot of online videos on how to successfully get up after falling from skies. The first day was HELL. Second day - Not Hell, but a country side road with a view to hell very close by.


Two Day Leadership Workshop–London April 11-12

I would love to see you at my upcoming two day workshop in London. Place is limited to 20 participants.

The workshop is for architects, team leaders, and managers of software people.

The point? Learn how to make the things you believe in come true in your team. Understand why and how to influence works, and learn to harness it.

Most importantly, we discuss the role of a leader as a grower of the team, instead of just the guidance of it.

The following video gives the big idea:


12 Lessons Learned for a New Team Lead

This guest post is by Oren Ellenbogen. I’ve personally known Oren for a few years, and he is one of those people that you just know you will be seeing on the cover of some tech newspaper sometime in a a few years.

Oren is a Senior Developer at Commerce Sciences and Editor of SoftwareLeadWeekly.
Prior to Commerce Sciences, Oren served as Director of Engineering at Delver, where he was responsible for the development process, delivering kick-ass products and growing the next generation of team leads in his group. Oren likes talking with awesome, passionate people and hates people who call themselves "ninjas", unless they carry a sword.




During the years 2007-2011 I had the honor leading an incredible group of engineers, working at Delver. It started from leading a team of 3 engineers and grew to a group of 13, made of three smaller teams.

It was an amazing learning experience, probably the best one in my career. This post is my self-retrospection, trying to extract my lessons learned and put it on paper. Hopefully, sharing my experience could help you in your own journey as a team lead.


Write things down

Being promoted to a new role, having people under your responsibility, is a huge change. Suddenly, it is no longer about you but rather about your teammates. Many first-time leaders struggle to leave the "superstar" spot they're so comfortable with and make the required switch, helping their team jell together and fulfill their potential.

It's a long journey. it takes time crafting your people skills, figuring out how to prioritize between your company's needs and your teammates' needs, finding your own ways to keep your technical skills and deliveries.

My advice to you is write things down - end your day with writing 1-2 decisions you've made during that day that involved your new skills. Review these decisions once a week with yourself and in your 1:1 with your boss. Call it "code review for managers". use it as a framework to improve your management skills.

Show that you care - it's the little stuff that matters most

Little surprises can lead to a long lasting impact on your team, bigger than any salary increase or fat bonus. Make it your job to know your people better, understand what drives them and show them that you've noticed.

To fuel your creativity, think of framing a Let's Say You've Gone Back in Time poster for a new employee, just because you saw he likes this kind of humor on Facebook or his blog.

Imagine his first day at work, arriving to his workstation, looking above at the poster you've put there. Do you feel it?

At Commerce Sciences, where I currently work, we've got a little tradition welcoming new employees to our startup - the last person to join the company is responsible to create a "starter kit" for the next one to join. It's our little culture hack. It's the little things that make us proud to be part of something. Show your teammates that you care.


Be extra careful with cynicism

Cynicism is a dangerous killer in disguise for your team's culture. Don't get me wrong, sarcasm and cynicism are pretty much my entire jokes vocabulary, but I urge you to pay attention as it can quickly slide from having a good time to insulting someone else or demoralizing the entire team. Many first time team leads avoid dealing with cynicism because they are afraid of looking "uncool" or too uptight. I call Bullshit on that. Your teammates will appreciate you more for being a leader with strong opinion and real passion to create better culture. That's your responsibility, earn it!

Educate yourself about the things they like

This is a trick I learned along the way to better understand my teammates. Some of them loved JavaScript performance optimization, so I bought High Performance Javascript and read it on the weekends. Others enjoyed exploring service-oriented-architecture (SOA) so I found some awesome blogs (check Udi Dahan's blog) to get my weekly dose of that. Some were more about UI and UX, so I got a few more books (Don't Make Me Think is awesome). You get the pattern.

I am far from being an expert on these topics, but I can conduct an intelligent conversation, provide feedback, and help with prioritization. I used what I've learned to drive my teammates to take ownership of these topics they were so passionate about. Getting to know what drives them, being able to talk in their own language, helped me set clear expectations about deliveries and responsibilities. They knew I would go the extra mile for them.

Use productivity questions to drive code-reviews

I've always preferred using productivity questions to judge quality of code, simply because I've learned that we tend to put too much time and effort in the wrong places, building things no one would use to begin with. So, best-case scenario for every engineering team is to create code that will allow them to test as many directions as possible in the shortest given time.

My mental model when looking at code:
1.    How easy will it be add new features?
2.    How easy will it be to change existing features?
3.    How easy will it be for a new teammate to become productive?

Some examples:

  • Using the right amount of tests will help with every bullet above. Adding too much tests or the wrong kind of tests will damage both the first and second bullets. For example, too many integration tests instead of unit tests may make your tests break too often, if the flow tends to change a lot by adding more features.
  • Using complex architecture might help with (1) and sometimes (2) but will probably hurt (3), so there is an interesting balance to be thought of.

Using the questions above, makes the entire discussion around the productivity of the team and company instead of whether or not one should have 90% test-coverage or what is the right amount of code lines per class.

Develop your proactive voice

There are two kinds of people – those who will tell where they are standing only when someone else will ask for it ("pull") and those that will come to you when needed ("push").

It could be related to a progress made in some feature, maybe there is something or someone that holds them back or simply to share an interesting observation. I believe that being a great leader requires us to become proactive, to communicate before people ask for it.

Being communicative will reduce the need of your boss, peers and teammates to double-check everything with you. They will get accustomed 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. Oh, and there is my secret trick for Proactive Leadership you should also check out.

Send your teammates to events and encourage them to share

Joel Gascoigne has a great post called Your startup is a rocket ship, where he explains how to leverage your company to increase your employees reputation. This is exactly what great companies should strive to do in order to keep their talent level so high.

It's a classic win-win situation: your company gets to engage with highly talented candidates while your employees get to earn their reputation and impact their eco-system.

Open, check for interesting groups around your area that your teammates can learn from and contribute to, and encourage them to go. If they want to speak, help them to prepare, offer your help with building the presentation, ask them if they would be interested in presenting to the team before. Having your people out there will increase the chance of getting awesome candidates and will increase your teammates options in the market. Even if it sounds like a dangerous path ("I am scared of losing my best people!"), it will let your people know that you've got their back, that you put them first. If you want their true loyalty, you have to earn it from a place of trust and genuine care.


Do not try to fix everyone

Sometimes, you'll be tempted to change a behavior of someone in your team.

"He's young and a bit arrogant, but so incredibly smart! No one seems to enjoy working with him but I know that I can fix it".

Sounds familiar?
Every time you commit to help someone else grow, ask them to commit to be willing to make the effort first.

If someone has a bad attitude and no willingness to improve, it doesn't matter how brilliant or productive this individual is. In order to build a team, everyone has to be willing to find their own spot and enjoy being part of the team. Do not invest yourself and your team in people that don't give a damn. It might cost you with letting go of some great people, but will also set the tone for the rest of the team. Don't worry, you're building a team for the long-run and it will pay off.

Celebrate just as hard as you work

Focusing all your energy on getting stuff done just produces more stuff that needs to get done, and that’s a trap. Your teammates can easily keep their heads down and continue to work their ass off, but without explicitly sharing progress and celebrating it, you're adding a risk of losing your purpose.

Instead of enjoying those victories, every time you'll do something huge, you will treat it as a small step forward – "yea, we finally got to 10 customers, but we need to be at 10,000 so there is no time now to celebrate".

Take a minute, celebrate your achievement and take this opportunity to say how much you are proud of your team for the effort they did.

Avoid the local maxima

Don't try to compare yourself or limit yourself to the surroundings you're familiar with. If you don't know of anyone that is doing Test Driven Development, using Continuous Deployment or practicing Kanban, it doesn't mean that you shouldn't try it.

Some people will always call you naïve or optimistic for thinking you can do more than seems possible, but there is no way to get radically better other than pushing yourself out of your comfort zone.

Read about companies and individuals that drive you crazy with passion and admiration. Set your path reaching to your true potential, not the closest maxima, using your current skill set. If you seek to improve your teammates and lead them, it must begin with you first.

You're talking too much

As a previous superstar, you might feel the urge to keep everyone informed about your own capabilities, to prove exactly how smart you are. This is not a good idea.

As a new team lead, your job is to make *others* shine. People will not feel comfortable coming out of their shells, unless you will allow them to speak up, to own things, to become the voice of the team. Push them from behind and get out of the way.

Be awesome

Enough said.


If you found this post helpful, I'd be humbled if you'd follow me on twitter (@orenellenbogen), subscribe to my weekly newsletter with great articles about leadership and management and check out my blog.
photo credit: Angelo González

Page 1 ... 2 3 4 5 6 ... 32 Next 5 Entries »