8 Lessons for First Time Managers

Tips for engineers taking up people management positions for the first time

I’ve been a team lead for two and a half years now and consider myself reasonably adept at it (still with a lot to learn, naturally). But at first it was a steep learning curve. Below are the top 8 things that come to mind when I think back at what I’ve learnt. I hope they can be helpful to engineers taking up people management positions for the first time.

Be Available And Approachable

One of the best compliments I received from someone I managed was that I was always available when they needed help. If you’re an individual contributor as well as a manager, there’s a balance to be had between being available on demand and getting your own work done. But, as a team lead, I think the balance should always be markedly tipped towards the former. Your first and foremost responsibility is to facilitate the success of your team members. This can be difficult — you may be feeling rushed, frustrated and anxious to get something done, but being a good leader means being able to put this all to one side and switch context when a team member asks for help.

The second part of this is being approachable. It’s no good being available if people feel they can’t approach you with a problem. You need your team members to feel safe in your company, whether they be delivering good news or bad news, coming to you with solutions or problems. Whatever the subject, you need to make your colleague feel like you’re on their side, you have their back and you want to help.

Context Switching

One of the benefits of being a manager is the variety of work it affords you. One minute you’re coding for a sprint task, the next you’re writing a job description, helping out a team member with their task or presenting a project update to upper management. This means a lot of context switching, sometimes just between different parts of a codebase, or sometimes between very different types of problems. Whilst blocking out times in your day/week for different types of activity is useful, inevitably you can never adhere to them strictly: meeting availability gets in the way, or a team member has an issue that needs addressing in a timely fashion. I found that the ease at which I could switch between different problems increased with practice. Nevertheless, you need to be prepared for a lot of context switching and account for the time it can take to get into the right mindset for a particular task.

Manager’s and Maker’s Schedules

Paul Graham of Y Combinator talks about the differences between manager’s and maker’s schedules. Managers typically split there day into hour long intervals. Makers on the other hand need longer units of time, usually half-days, to achieve their goals. As a developer, one hour is not nearly enough time to get into the right headspace, gather all the necessary context for the sprint task and then make meaningful progress on it.

If you’re a team lead and also an individual contributor, you’ll find that these two types of schedules clash. Where possible, I try to have one block for making in the morning and split my afternoon into hour long intervals for meetings. If on a given day I don’t have many meetings, I’ll try my best to clump all the ones I do have together, one after the other, to leave more uninterrupted time for making. Of course, this means you have to communicate your needs clearly to your managers or other project stakeholders who might be working on a manager’s schedule. Once they understand that having a meeting right in the middle of your maker’s time is a disaster for the velocity of the project, they’ll likely try to give you the uninterrupted time you need where possible.

Strong Opinions, Weakly Held

Your team is relying on you to make decisions in order to unblock them. In startups especially, we often have to make decisions when the information or context is incomplete, or the external environment is fast changing and the optimal or ‘correct’ answer is not obvious. In these situations, it can be tempting to delay making a decision or, worst still, communicate a decision ambiguously and without confidence — this is very uninspiring for your team.

The best way to deal with these situations, I believe, is by following the principle of ‘Strong Opinions, Weakly Held’. This was developed for the world of venture capitalism by technology forecaster Paul Saffo of the Palo Alto Institute for the Future. It has since become somewhat of a cliché in the startup world, but I think it still holds a lot of value when applied to leading software development teams.

When designing software, we often need to use our intuition to make an initial ‘best guess’ which we can use as a starting point to our investigations. We then use the learnings which come out of our investigations to iterate until we reach the optimal or ‘good enough’ solution.

To apply Saffo’s principle to this, we first make a hypothesis with the information we have available, thus forming our initial decision. We communicate this decision with conviction and unambiguously in order to give our team confidence and the motivation required to move forward and test the hypothesis. This is the ‘strong opinions’ part of the principle. ‘The weakly held’ part is about being open to contradictory evidence and opinions: When new information becomes available from our investigations or changing external factors we adjust our hypothesis and form the new decision. Having communicated a decision with conviction, we’ve also given the team something tangible to disagree with. The ensuing debate can be equally useful in informing the next iteration of the decision. For this to work, you need to foster a culture of constructive criticism and healthy disagreement within your team.

As well as allowing progress and the iterative search for an optimal solution, following the principle of ‘Strong Opinions, Weakly Held’ means you always have a decision on hand, when you need it, well informed by the currently available information. This can be useful when sprung upon by a project stakeholder.

Ameet Ranadive has written a great article on the principle here or you can read Paul Saffo’s original post on the subject.

Just Make a Decision

The other thing I learnt about decision making is that, in situations where the answer isn’t obvious, people like to avoid it. As the team lead, it falls to you to make decisions where others don’t want to. Often a team member will have all the same information you have, but they don’t want to be the one to make the call. There may be issues around empowerment at play here that need to be addressed, but sometimes it’s just because it’s easier and natural to defer to your manager who is ultimately accountable. Following the principle of ‘Strong Opinions, Weakly Held’, just make a decision and commit to it until new information becomes available.

Their success is theirs, their failure is yours

When things go wrong, you are accountable, and you should take the blame. That’s not to say that the individual doesn’t shoulder the responsibility; they do, but only internally, within the team. To everyone outside the team, the buck stops with you. In contrast, when your team members succeed, it’s important that they receive the recognition for this — recognition is a pillar of motivation. Of course, as a leader, behind closed doors, your success is measured by the success of the team. But you should go to lengths to ensure that any recognition directed at you filters through to the individual or the team as a whole.

Proactively look for recognition-worthy work

Someone who reports into you shouldn’t need to put a good piece of work right in front of your face in order to receive the recognition they deserve. You should be proactively scouting for good work and dishing out praise whenever you spot it.

I struggled with this at first because it felt patronising and almost arrogant. ‘What right do I have to tell someone whether their work is good or not?’. But it’s easy to underestimate the positive affect your praise will have on someone’s morale; keep in mind how you feel when you receive praise from your manager.

Be The Umbrella

Probably the most important job of a manager is shielding your team from any crap that rains down on it. You should be a barrier between the team and the rest of the organisation, particularly upper management. Whilst ensuring that the important information is transferred to your team, you must shield the team from:

• frequently changing requirements
• unrealistic deadlines
• unfair or unconstructive criticism

Push Back

The hardest lesson I had to learn early on was the importance of pushing back, and not just being a ‘yes’ man. Eager to please, I would be overly optimistic and over commit my team, not pushing back on unrealistic deadlines. This would inevitably end in failure to meet expectations and lead to poor morale amongst team members. Luckily I learned this lesson early and the guilt attached to my early failures has stayed with me as an important reminder.

Under Promise and Over Deliver

A previous manager of mine taught me to ‘under promise and over deliver’. That is, if you always over estimate the effort required you’ll often exceed expectations. Completing a sprint with all the stories achieved (or better still, having brought more into the sprint) not only gives the team a sense of accomplishment and reason to celebrate, but also pleasantly surprises any other stakeholders. No one feels good when you repeatedly miss targets.

Humans have an optimism bias — we tend to come up with estimates that assume the best case scenario. Consistently adding a multiplier to my estimates helps me to overcome this cognitive bias and facilitate team success. The multiplier you use has to be found through a process of trial and error and will be tied to the makeup of your team.

To summarize, be available, be approachable and be the shield. Above all, you should remember that as a manager, your foremost responsibility is to facilitate the success of your team members; in doing so, you will achieve success as a leader.