Lessons from inexperience: learning from idealism and your previous managers
Lessons from inexperience?
It’s just been announced to the company that I’ve been successful in my application to become a Lead Developer. Is this a good time to write an article on how to be an excellent Lead Dev? On first thought, that might sound like an odd (or indeed arrogant) idea. But bear with me…
I can’t claim to be excellent at a job that I’ve not even started yet. But I can bring two things to the party: First, I’m still chock-full of idealism about why I want to be a Lead Dev and all the cool things I’m going to do in the new role. Pretty soon, I’ll be faced with the inevitable compromises, time pressures and whatnot. But right now, I can dream big and get away with it. And second, I’m new enough to remember what it was like to be in the shoes of the people I’ll be line-managing, so I can bring thoughts from that side of the fence too.
All this does come with a risk, though. I’m outlining my vision for the ideal me – the perfect Lead Dev that I want to become. And I’m not going to make it to those lofty heights in a hurry. So I’m going to need to ask for forgiveness from my team (and company) for the many times when I’ll fail to live up to the picture I’m painting here. But at least they’ll all have an obvious start point for any 360-degree reviews of my performance!
So what do I want to do?
Leading a team
One of my previous line-managers (hi, Colin!) taught me an important lesson about running a team – it’s less about “Do this” and more about “What’s stopping you doing this?” As the book “Scaling Up” puts it: “Don’t demotivate, dehassle”. Here’s their background to that idea:
The best managers are less concerned about motivating their people and more concerned about NOT demotivating them. They consider it their job to prevent the hassles that block their team’s performance. Such demotivators are usually related to issues with people or process.
I want to be one of those managers.
Another previous line-manager (hi, John!) taught me another lesson: Provide focussed technical mentoring. Of course I had a conference and training budget, but I also had regular time with John where we looked at the technology I was trying to master and what my knowledge gaps were. John then suggested specific, targeted activities to fill those gaps. And I bet he learnt something in teaching me, too.
One reason I applied for the Lead Dev job is because I’m aware of my knowledge gaps and this job is a good way of being exposed to situations that will force me to fill them. But there’s another important reason for acknowledging that I don’t know everything: So long as I don’t try to know everything, I’m going to rely on the knowledge, skills and interests of my team. And so long as I do that, they’re going to have opportunities to grow and shine. I don’t want to be a one-man band (although strapping cymbals to my knees does sound kind of fun).
I mentioned my team’s interests. When planning work or making decisions, I want to think about my team’s interests, ideas, knowledge gaps, learning. I’d want someone in management to consider all those things when thinking about me, after all! I’ve got lots of interests and it would be really interesting if some of those could be brought to bear on work. I’ve got loads of ideas, and not enough time to do them all myself. And of course I have knowledge gaps and need to learn.
Oh, and I got a bit excited in my interview about gamification. I want to help encourage my team to play their part in moving us forward, and gamification seems like it could really help here. Or perhaps I’m just grabbing any excuse to bring ideas from all my favourite computer games into office life. I hope the rest of the team like Monkey Island as much as I do!
(Seriously, though, I’d want to build any gamification around media that my team are actually into. This could be a good way of getting to know them better, as well.)
Working with others in the business
The classic Computer Science textbook “Structure and Interpretation of Computer Programs” includes this line: “The programs we use to conjure processes are like a sorcerer’s spells.” Now, in some ways, that’s pretty cool. It sums up a lot of the fun of development.
But, in my opinion, that idea stops being cool when it escapes the dev team. If non-developers think that development is like magic, there will be problems. Because that idea leads to another idea – that only developers can understand the world of software-creation. That prevents other disciplines from getting sufficiently involved in the development process. As a Lead Developer, I’d like to enable client-facing and management staff to bring their perspectives to bear on technical decisions. Plus, this wider understanding of our technological approaches could be brought to bear on winning new work from clients, and getting involved in that sounds fun!
I’d like to push for knowledge-sharing among different development disciplines too - I don’t want “silos” separating our PHP developers from our node developers, for example.
Remembering my time as a non-lead dev gives “Lead Dev Me” a great incentive to address the problems that come when support teams aren’t given proper project handover or are lacking in training in a specific technology. For me as a developer, that meant more time fire-fighting on legacy projects and less time coding cool new stuff, so who wouldn’t want to sort that out?! That’s one reason I’m keen to improve training for and handover to Support. It’ll make the Support team’s life better, and make my developers’ lives better too!
As a developer, I also saw potential for us to improve how we work with other teams, not just Support. There are lots of examples, but one is particularly pertinent. When I first started working at White October, I was really excited by the fantastic stuff we do in terms of Design and UX. But, as a developer under pressure on a real project, it can be all-too-easy to slip into an us-and-them mindset: I just want my awesome code to be merged; doesn’t it look okay already!?
That’s a really bad attitude for me to have, even if only occasionally. So as a Lead Dev I want to use this opportunity for self-improvement to drive wider improvement too: I see this flaw in myself – I need a better approach to Design and UX, even when time is tight on a project. Obviously I need to change, but a bad mindset like that doesn’t come out of nowhere - I’m hoping that I can improve the way Design and Dev work together more generally, to prevent situations arising which can lead anyone else into that unhelpful way of thinking. You could draw parallels there with the Dev-Tester relationship, but I’ll save that as an exercise for the reader…
All the cool things
A final thing that new-job idealism brings to play is an overly-optimistic belief that all the things that excite me about development can somehow be incorporated into my new role and team.
On first reading, that probably sounds hopelessly naive. But bear with me. The things that excite me - stuff like accessibility, doing Test-Driven Development better, learning more about UX – are exciting for a reason. These things have advantages other than the fact that I like them. And it’s sometimes important to stop being constrained by thinking about what fits with current ways of working or current technologies you use, and just dream big! Don’t do this every day (you’ll never get any regular work done), but do it sometimes!
What about you?
Enough about me, what about you? Here are some questions to ask yourself:
- Can you remember why you wanted to become a Lead Dev in the first place? How are you doing at putting those hopes into practice?
- Can you remember a great line-manager you had in the past? What could they teach you in your role now?
- How are you doing at helping non-developers connect with the work that your team does? And are you taking opportunities to learn from non-developers yourself?
- Do any of the things you’re personally not so good at give you an idea for wider process improvements? How can you help prevent others making the kind of mistakes you make?
- What does your utopian tech team or project team look like? Could you take a step in that direction?
- What does the perfect Lead Developer look like? What’s the next step for you in becoming that person?
Allow yourself to be idealistic now and then. Remember why you went for this job in the first place. Think back to what it was like to be managed by someone like you. Don’t beat yourself up about your failings, and don’t get too frustrated about problematic process, but use both of these things as a chance to make things better. Good luck!
About the author
Sam Partington is head of the Backend Engineering Team at White October. He is involved in developing Symfony2-based sites, in supporting and line-managing other backend-focussed developers, and in providing strategic input into White October’s technical decisions at all levels. Sam has a strong commitment to social and environmental justice (he’s chair of Global Justice Oxford), loves cycling and likes to take any opportunity to practise reading and speaking German.
