Things I was unprepared for as a lead developer

I've been a lead developer for 2 years. It has been quite a ride and there were a lot of things I was unprepared for. I've always been a software engineer, mostly involved with the actual code. People tell me I have a very natural way of leading, which is probably why I was asked for the job. However, I never before considered what it takes to lead an entire team of engineers. I wish I had more preparation beforehand. So to give you, the reader, a head start, these are the topics I was unprepared for, so you can hopefully be a better leader than I was. Mind you, I didn't fail on all aspects, but most caught up with in me at one point in time.

Way less developing

Although this might or might not seem obvious, the simple fact is that a role as leader requires you to have more of an overview and less of an in-depth knowledge about what’s going on. I didn’t realize this until I was a couple of months into the job, which made me always struggle with wanting to know more about the in-depth problems and not having the time to do that. I had less hands-on time with code, but people still looked up to me to provide answers or insights to very specific problems they had. Way too late I learned to harness the knowledge of the entire team instead of trying to be the know-it-all. Knowing who had specific knowledge about what part of the system was much more valuable in my role and took a lot less time to achieve. It was a lot less fun than diving heads-first into the code though.

Delegating

Because of the limited time I now had, I had to delegate way more than I was initially comfortable with. Asking someone to do something you know he/she is not comfortable with or doesn’t want to do is hard enough. Asking while actually telling is even harder, because it requires a certain level of empathy to make the right approach. Because I loved doing the work I had always done so much, it was also not very easy to let somebody else handle it now. I wanted control over what was happening and how it was happening. Sadly, I soon figured out that it’s not doable to maintain both control and get everything in a sprint done. I had to let it go.

Financial management / budgeting

The financial sides of things don’t often interest me much. However, as I was now responsible for a team of people, leading them to wherever it was we needed to go, money was suddenly a big issue. I was in charge of how much we would spend as a team and responsible for how much value we would add to the company in return. The closest thing to any experience with finances that I had were at home, doing some bookkeeping, but even that I didn’t do much and was happy to let somebody else handle for me. That was not enough this time around though. There were a couple of things that I had to manage: - Licenses we used - Third party contractors - Handle expense claims - Vacation days - Salaries (raises and salaries of new hires)

Specially the licenses (Zend server, Oracle) and the third party contractors were mostly a bore. Every month the bills would have to be checked to see if all the billed hours were actually spend and if the licenses were still complete. I managed to automate a lot of these things through the use of Excel and Jira, but it would still take a good whole day a month.

Hiring / Firing people

Which brings me to another interesting point: hiring (and firing) people. I was very lucky to never have to fire someone in person. There was a time when the company didn’t perform so well and a bunch of people were let go, but that entire group of people were managed by my manager. I did have to hire people and in the current market that was a very hard task. Especially so when the company in question is not a sexy startup, nor is the stuff they’re working on amazeballs, nor is the market that they’re in one that attracts a lot of people. It took me a lot of time interviewing people and even offering them a job (with a pretty good offer, mind you) only for them to choose another company. This is of course how the market works and I don’t blame anyone for pursuing the jobs they dream of. But it took up a lot of time with little benefit. In the end, I think I was not nearly focussed enough! I spend so much time with the interviews and so little time in actually bringing in the right people that it was a very frustrating, tedious and, in the end, unsatisfying process. Later on, I saw how more focus on bringing in new people and lining them up for shorter interviews can have a lot of benefit.

Culture building

Whenever you’re the leader of a group of people, you also cultivate the culture of that same group of people. It is often said that culture is that which you do or do not allow to happen. In that regard I was wildly unprepared. Although I was used to a bit of leadership and was not afraid to speak my mind whenever something was done that I though inappropriate, this was mostly from the comfortable spot as a peer or with a group of leaders backing me up. In this case, I didn’t feel like I had a group of other leaders backing me up, they were all busy building culture in their own teams. Neither was I one of the peers in the team, I was their leader. They looked up to me for leadership and that also meant defining what was and what was not allowed. Of course, this is easy when somebody makes a remark that couldn’t pass or does wildly inappropriate acts such as coming in late and/or leaving very early. The hard part was when this coming late and going early was done for a good reason, such as a sick spouse or child. Making the right choices every time a team member asked for something other than the usual (such as time off), I had to make a choice if I was to allow this. Not only that, I had to see how this would affect the entire team and how I would handle that effect. Sometimes this was easy: being open and transparent with a team really helps in creating understanding for both the team and you as a leader and the position you are in. Sometimes it was hard though, in such times where deadlines had to be met and team members were disgruntled with each other. It’s hard to both build a culture of positive sharing, honesty and transparency when faced with stress and a lot of negative emotions.

Motivating

Stress, deadlines, negative emotions, set backs and other negative events are a part of life. I’m usually a glass half-full kind of person, but when met with the overwhelming feelings of an entire team, I found it hard to keep my head up and still try being the motivating leader that I want to be. If a retrospective is just one remark away from turning into a full-blown he-said she-said blame-game, I found it not enough to just be a kind and positive person anymore. I needed to draw strength from the other positive things in my life or I would be unable to bend this one negative thing around. This is also what I found hardest in the end. I was doing something I didn’t really love, in a way I didn’t think was good enough and it overshadowed a lot of positive events in my life. That made it so much harder to draw strength from those events to battle negativity in the team. Luckily, it wasn’t always this bad, but I was woefully unprepared for the amount of motivating I had to do.

Mentoring

As a good leader, I consider it my duty to not only keep the team running as smooth as possible, but also to help them grow beyond themselves. One of the things I was very unprepared for was mentoring. I feel like I have a natural tendency to listen to people and to help them grow, so I could wing it on the spot, but I would’ve liked to have had more experience with it. Thinking about it now, I always though mentoring was something that was done from top to bottom. Managers would mentor each other and they would mentor their teams. In the real world, this is not necessary how it works. I think experience with mentoring others earlier in my career would prepare me more for the leadership position. Initiatives such as PHP Mentoring can help a lot in this regard.

Feedback (inc. 360 degrees)

Next to mentoring others, I underestimated the power of reflecting on oneself and feedback from others. I was always in touch with both techniques, but failed to see that the leadership role was so much more demanding (specially in the beginning) that it was not enough to ask for feedback after a year, nor was it enough to look back in retrospect to my own acts after quite a while. Giving and receiving feedback was not really embedded into the culture of the company except for once a year. This was not enough to make it a habit or a useful tool. Looking back now, I should have asked for feedback way earlier, even before I landed in the leadership role.

Planning

Depending on the role, the leader is often the first to be asked “when is it done?” or “is there any time to do X?”. I had previously provided lots of input for those kind of questions, but was never put on the spot by a C-level manager to answer the question. Making a “resource” planning (hate that term, people are not resources) to see when developers where available to work on a project was not something I had ever done before, so I was uncomfortable estimating if we could take on another project. I later learned to trust more on the team to create a planning and to decide if they had enough time left. I also learned that there’s often a question behind the initial question. Learning what that question is often gives more breathing room when it comes down to the resource planning.

People skills

Although the job title might read “lead developer”, the biggest part of the job is dealing with people. Although I’ve always been in touch with my abilities to talk to people and I don’t shy away from any human interaction, I realized this way too late. In the beginning I focused too much on the development part and the frustration when I didn’t have enough time to do that. I learned that being able to take the time to sit down with someone to really understand their problem, however simple or insignificant it might seem, was a lot more valuable than the short-sighted development insight I was gaining otherwise.

Lead by example

When in a leading position, a position with (more) power and (more) responsibilities, one has to figure out what kind of leader one is. I’ve always been more of a fan of the bottoms-up leadership model as I think shouting down from an ivory tower doesn’t work very well. Also, I like how being a leader is not like being a boss, but more like being an enabler, enabling growth and creating opportunities for people. However, it might sometimes be a lot easier to just be the person who divides the work that has to be done and go back to your own work. Being an inspiring leader/enabler requires constant work and attention. I often felt like I could’ve done more to help my team grow or create opportunities to learn more. Most of those times I let myself be distracted by deadlines and stress.

Sickness / personal problems

Just a couple of days in on the job, people suddenly wanted to talk to me about sickness, their personal problems, vacation days, being stuck in their jobs, etc. A lot of these problems could be met with a healthy dose of common sense, but the stories I sometimes heard really stuck with me. I was really unprepared for any of these stories. I started to make the problems my own and instead of taking proper distance, I let my empathy get the upper hand. Being the person that I am, I started to process these problems unconsciencely during my sleep and dreamed about them. This even led to a mild form of sleep deprivation at which point I had to actively take distance. Although I really felt like helping people with their problems, I couldn’t be the superhero they needed. All I could be was a listening ear and perhaps make it a little easier for them to be a part of the team. This was a harsh lesson for me though.

KPIs/objectives/goals

Another thing with mentoring and leading a team is pushing them forward. Within the company we used goals and KPIs for that and it seemed like good techniques to use. However, it quickly started to get real hard to align both personal and company goals. When a team member really wants to learn DDD, but the company is not even sure about continuing the product, it gets really hard to make that goal happen. If a big part of the yearly review are the set goals and KPIs at the beginning of the year, this is something to take into account! As a developer I often didn’t see (or want to see, or wasn’t allowed to see) the bigger goals the company set. I now see that my manager always found a way to align both goals and how hard a job that is. It means lots of lobbying for that one project and adjusting goals if they turned out to be impossible to reach.

Public speaking

One thing I didn’t realize is that being a leader also means that it often comes down to not only address your own team, but other teams or the entire company as well. Presenting plans for the next quarter or showing the progress the team made or explaining very technical matter in a non-technical way comes with the job. Luckily I had already dipped my toes into speaking at conferences. Organizing AmsterdamPHP also definitely helped me with this. Although these engagements would've been great opportunities for team members to grow, often times a certain amount of pressure behind having to deliver a certain message in order to get a GO on a project was required. I quickly had to learn that it wasn’t about how beautiful the slide deck was, but about the message and there were no second chances here.

Go forth and improve

Now that I've told you the pitfalls I encountered and the things I did not expect would hit me, I hope you can take these learnings and can proactively prepare yourself, so you won't make the same mistakes if you're ever in the same position.


I camp, You camp, We camp at WeCamp15!

Coming to WeCamp this year was a no-brainer, after my experiences last year. My write-up sparked some worry with my coach Mike van Riel (among others) because none of what I wrote about was visible at the surface. But I believe that the most important bit of the article might have been snowed under:

This joy, even though I don't mention it again, was prevalent throughout the entire week. It was the largest part of my experience there, but also the most unsurprising part of what went on.

This was absolutely true of this year also. Plus, I believe that everyone had the emotions I described at some level. Exploring them gives you insight to where you can improve yourself to become a better dev-human.

So, let's dive into this year's WeCamp, shall we?

The first thing I need to tell you is that this year, I was not a participant. They asked me to coach a team which brought a whole new level of insecurity with it. I wasn't worried that I could not get through the week - I've run my own company for ten years after all - but my main worry was:

how to give my team the same deep experience as I had last year??

The WeCamp organization did take these fears into account. They had a coach-of-coaches in place (Jeremy "Coach" Coates) so no one would fall into a situation that was too much to handle. His input at various levels of the event was invaluable, and I really hope the coach-of-coaches remains part of the concept of WeCamp.

So, how did it turn out?

Well, my worry was not needed. I got a team of eager participants, all of which very much involved in self-reflection and self-improvement. Connecting with them was no problem at all. There where completely different goals set by individual members and yet, before the week was over, they had communicated their goals to each other. I mean way beyond the superficial goals one states to a bunch of strangers on the first day. Deeply personal fears like impostor syndrome and such. They made sure each of the team members met their goals and looked into themselves and opened up to be able to grow.

One of the other coaches said that there where not just five coaches on the island, but 25. This was true as far as I can tell. It was absolutely true in my team, where they all took a part of the job and spread their knowledge. Or pushed a team member to greater heights. That, I think, is my biggest source of pride.

What did my team end up building?

The team came up with a project to help people with idea's gather feedback in a very early stage, to know if they are on the right track. At first I could tell there was a teammember who was at WeCamp last year, because the project's scope was limited to realistic proportions. This ended up being a bit demotivating, because what can you actually build in four days? But after an additional brainstorm session the energy returned and a better product evolved.

A lot of effort was put into protecting the potential users of the system - to focus on the positive emotions involved in bringing ideas into reality. Their core values where:

  • Let a person express an idea in as many different formats as possible.
  • Let a response to an idea revolve around emotions instead of a scale of boring numbers.
  • Provide information about the type of audience that is positive about an idea.

In essence, I think they where solving their own issues because adding your input to a project is exactly the same scary thing. They discovered that their project was feeding their own creativity.

What did I get out of it?

Well, being a coach I had to resist "steering" the team. In four short days, I fought putting in my ideas and my way of doing things and still witnessed a team come together with the ability to build great things. Their level of commitment and communication was amazing - and this I will take away with me to my own company. I could be more of a coach and less of a boss (or, as they like to call me: blocking issue) and still make great things happen. Or rather let great things happen.

The question the organization of WeCamp wanted answered most of all is "Why would anyone go to WeCamp next year". Well, I've got some bad news for them. I can't answer that - at least not for anyone. But to the question "Why would I go to WeCamp next year", I can quite simply say:

WeCamp has been the single most important catalyst of my personal and professional growth. Twice.

See you all next year!

PS: I'd like this to be an open invitation to my fellow WeCamp15'ers: please provide feedback, if you have any.


When you are stuck

Are you also a person who gets stuck in coding for a lot of time?

You have this good idea you want to work out and it seems fairly simple. You guestimate to finish it within a week, but when you start working on your little idea you find yourself getting stuck on a technical issue before you know. This has happened to me many times and still happens quite often. It can happen to anyone, not just when starting a new project, but also when you're working in a team and doing some bug fixing.

That feeling of "why can't i just finish this like any other programmer?"... or "Why is it taking me so long?". I get this uncomfortable feeling and it makes me quite stressed out. Since this happened to me again last week I started thinking to myself:

  • How can I avoid getting stressed out every time I run into trouble?
  • What options do I have to solve my problems?

So here are some thoughts I came up with in the brainstorm session with myself.

Naturally, the easiest way to handle this type of situation when you get stuck in a code problem is to ask the community for help. And very often you get good answers and feedback. But I figured that there's a stage before that: you don't want to go always straight away asking for help before you have tried to solve the issue yourself.

When you are stuck in a piece of code or you're troubleshooting ask yourself the following questions:

  • Go back to the basics: do I understand the problem? What issue am I trying to solve? Is the description of the problem clear to me? Very often I find myself deep in the code and then I figure that I really don't understand the problem and I have to take a step back asking myself: "what is actually the problem?". If you don't know the problem, you obviously can't figure out a solution.
  • Which information am I missing? Do I understand what the desired situation should be? How should the software behave?
  • What do I need to get to the solution? Which information am I missing? And more important: how can I find out what I am missing and who could possibly help me with it.

And last, on a more technical note: when dealing with error messages, ask yourself Do I really understand this error message? Very often I found out later that I did not really understand the error message. Reading properly and going back to the code to try and understand the error message will help a lot.

If you really can't figure out yourself how to solve the issue

If you really can't figure out how to solve the issue there are great resources on the net of people or platforms who are willing to and could help you. I will not mention an endless list but rather a few that have really helped me in the past few years:

  • Stackoverflow
  • Various chat rooms on IRC such as #zftalk and ##php
  • A very interesting (non free option would be) Codementor. This is a brilliant platform where you can find your mentor who could help you with your challenges.
  • A rather new option is to see if there are slack usergroups which specialize in your field.

Let me end with a great lesson I learned. Very often when you look at a problem you get stuck because you look at the whole picture. Aww i don't know how to get this feature working. The lesson is, break it down into very little steps because frequently you miss one little detail. There was just one small issue which you didn't get and therefore was not able to finish the task. So try and break down your problem into smaller issues. That will help you isolate the error and solve it.

Happy Coding!