RSS Feed

Latest Entries


First time here?


Sunday
Feb102013

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.

Sunday
Feb032013

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:

Sunday
Feb032013

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.

--------------------

 

image

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 meetup.com, 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

Friday
Feb012013

Video: The Coaching Architect

A few days ago I gave a talk at the Architect Meetup here in Oslo. It was about the role of the architect, and how to become a coaching architect. I hope you enjoy this video.

 

If you want to join me for a two day workshop on elastic leadership, I am running a two day elastic workshop here in Oslo, on February 28-29 2013. For details just contact me. Or you can attend this workshop in London during April.

Wednesday
Jan162013

Elastic, Agile, Adaptive Leadership Workshop, January 31 2013, Oslo

This January, the 31st, I will be giving a two day Workshop for team leaders, architects, and scrum masters, titled Elastic, Agile, Adaptive Leadership.

If you’re interested in joining, please contact me directly (or email roy at osherove.com) so I can save you a seat. We need only two more people to finalize course registration. I’ll be happy to see one of my blog readers there!

 

In this 2 day workshop, 30% of the time is dedicated to exercises. we will cover:

  • The three basic stages of team abilities (Survival, Learning, Self Organization),
  • Elastic leadership concepts
  • The leader manifesto and reasoning
  • Influence forces and understanding why people do what they do
  • How to grow your team to be self organizing
  • Why most team's are not really ready to become agile yet (and what to do about it)
  • How to deal with difficult behavior in the team.
  • How to lead self organizing teams
  • Comparing elastic leadership with the cynefin framework and other frameworks.

Audience: Architects, Technical and non technical team leaders, scrum masters, soon-to-be leaders, project managers, senior developers, consultants. No experience in management needed, but at least one year experience working/leading in a software team.

This is based on my book “Notes to a Software Team Leader

This will be held at Bouvet Oslo HQ, with the cost of 11,900 NOK per person (includes food).

Again, f you’re interested in joining, please contact me directly (or email roy at osherove.com) so I can save you a seat.