A surprising truth about technical leadership hit me like a bus a few months ago. Why? Because I thought that leadership skill is not a big deal. Always with less or more ease I was able to lead my colleagues to try new things or my students to embrace certain principles. But at some point when I changed the environment I started hitting walls and that made me think more about this subject.
How did it happen? I thought I know this stuff ?! Well … leading up happened. My colleague told me that leading down the hierarchy or across your level is totally different than leading up (it doesn’t matter whether it’s formal or not). So why I’ve never noticed it before? As long as you deal with at least a bit open-minded people you won’t see the difference.
I will address each challenge, but first two reads that can help you with this problem:
- Driving Technical Change by Terrence Ryan – He discusses number of patterns skeptics fall into and how to deal with them.
- Software Craftsmanship Professionalism Pragmatism Pride by Sandro Mancuso – He follows up on above reading and adds a lot (I will publish review of this one as it’s the best read I’ve had for a long time)
It’s when you have to convince or lead your manager, architect, team leader or a person who has a lot of influence (for example because he or she works in the company for 15 years). There are two cases here. The first one is when you’re dealing with people you can reason with, the other when you deal with skeptics or irrational ones.
When you deal with reasonable people the discussion often goes like this:
She\He: Well, I understand but I think you didn’t take into account …
You: Ow, yes thats true, do you see how we can mitigate it ?
She\He: Well maybe we could … Is it feasible solution?
You: We could but it will entail drop in quality, why don’t we …
You see what I’m doing there. You should be prepared for discussions like this. Establish trust by gaining expertise and being consistent with your words. Good news here, as long as you’re sticking to facts and you demonstrate your expertise, you’ll be all right.
The second case is when you have to deal with “the time crunched”, “the boss”, “irrational” or “the ivory-tower architect”. Both Terrence Ryan and Sandro Mancuso give some tips on how to deal with those kinds of people. I encourage you to try both reads. I would also add two more types “Expert beginner” and “Monty Python architect”. I guess you catch my drift and I don’t have to elaborate here :).
I will give you a good advice here. It may happen you won’t “win them” and you won’t “win with them”. If despite your effort there are no results over longer period of time, just redirect your efforts. Look around you, maybe there is a software craftsman in disguise nearby, waiting to be unveiled. Or maybe there are other architects, managers or leaders that you can reason with. At the end of the day, trying to convince the irrational is a waste of your passion and mental reserves .
Oh my my, so much can be done in this area, I don’t even know were to start. You will find skeptics among your colleagues. Do not focus too much on them. Remember that it’s always better to focus on those who want to listen and engage.
Lunch with conference
I find it the simplest way as it doesn’t require much preparation. Select good video from a conference (nowadays there are so many good conferences like QCon, YOW and NDC), book conference room with projector during the lunch break and send invitation to everybody. People often bring their own lunches so the only difference for them will be listening to conference video instead of spending time in lunch room. Sometimes video is enough to spark people’s interest in certain technologies or in watching even more conference videos. Even if it will not change much, they will learn something new.
Do not focus on those who are not joining you. It’s about those who are attending. Do it for them.
For this activity you need someone to prepare presentation. Same drill as above : book a room during lunch break and invite everybody. You can prepare first session yourself. Try convince your peers to prepare the next one. Session may be about something new or something well established. It can be about principles, design, architecture or specific technology. Or something simple, some good idea or practice you introduced in one of your projects and not everybody knows about. Or maybe even about something totally not related to your work like “Molten salt rectors”. It doesn’t really matter. It’s about building culture of learning.
MOOC study group
MOOC = Massive open online courses.
We will attempt it at my company for the first time, but I already think it’s a really good idea.
Select a good course like Programming Languages from University of Washington. Then tell everybody that you will take it and encourage others to join you. Meet every week for an hour or two to discuss course and assignments. If it’s related to you’re job ask manager if you can spend one hour from your working hours and add one hour from your personal time. This hour or two every week is just to discuss material and address biggest challenges. Obviously everybody will have to more time then this.
Try those sites:
The variation would be to do a training from http://www.pluralsight.com/
Group Pet Project
Once you find a few people who want to learn more and try new things, you can start group pet project. Choose something that you all want to work on. Maybe branch some company project and try grow it using totally different set of tools. Maybe choose open source project and fork it. Even if in the end you won’t contribute back to the original project it still has a learning value. This kind of activity is most engaging and at the same time demanding.
The good thing about it is that you can address several things at the same time: technology, process and skill base. Try running this project using kanban, test driven development or domain driven development, using different set of tools and maybe even with different architecture.
Make sure that everybody learns something. In the end it’s not about building product it’s about having fun, learning and gaining skills. Don’t be too skeptical about people’s ideas or too selective about what you want to accomplish. Let them try things that they have never tried in real project.
At my place we started such garoup project by branching one of the modules. Assumption is that we want evolve it to make use of CQRS and nosql databases. I will follow up on this project as it seems it will be not only a lot of fun but also hell of the learning experience.
Think also about running:
- group discussions
- switching projects for an iteration
- switching projects for a few hours (pair programming)
- group code reviews
- hands-on coding sessions
Sandro Mancuso describes this activities in his book Software Craftsmanship Professionalism Pragmatism Pride in chapter 14 Driving Technical Change.
For leading down all above apply. Additionally you can use you authority to back your position. But it’s best to lead by example, not by intimidation. See also my post regarding technical leadership as I’m providing some tips how to mentor youngsters.