Engineering Manager
An Engineering Manager (EM) will typically manage one team, of usually around 5-7 people. If you are an
individual contributor, it is sometimes tricky to get that first EM role, since companies will sometimes favour
hiring candidates who have managed people before.
In our level definition, EMs are tactical. They guide one team to ship their part of the whole. What that part of
the whole is will have typically been defined for them.
One strategy for getting your first EM role is to join a fast growing company as an IC with a view to converting,
ensuring that you practice and demonstrate skills that show you have suitability for leadership. This may
involve nominating yourself to lead projects, mentoring others, influencing decisions and continually building a
track record for shipping good quality software. If you’re not already working for a company where EM roles
become available regularly, then it’s much harder to progress as you’ll have to apply elsewhere.
This website goes into the EM role in detail (see the Management 101 and Levelling up sections), and I’ve
even written a book about it! So I won’t go into it further here. However, what’s important to know is that it’s
that crucial first rung on the management ladder where you can begin to gain the experience that you need to
consider moving upwards towards managing managers. Everyone’s gotta cut their teeth somewhere.
It’s worth mentioning that you may also see the Senior Engineering Manager job title. Typically this means
that somebody is managing one team, but has much more tenure and experience than an EM without the
Senior prefix. Larger companies may offer that progression step as a way of ensuring that EMs have more
opportunities for career growth that don’t immediately involve taking the plunge into Director, since that
requires more org chart movement. Additionally, for EMs that enjoy being able to mix technical contribution
and management, the EM to Senior EM career arc can be long-lasting and highly rewarding. They can grow
in influence, seniority and impact and still contribute code.
Director of Engineering
The Director of Engineering role is typically where you first begin to manage managers. I mentioned at the beginning of this article that I would explore what the role means at startups and at larger companies, however it’s rare to see Director of Engineering at start-ups, since it’s very much an artifact of middle management at medium to large companies.
In our level definition, Directors are operational. They coordinate and execute multiple efforts within a larger strategic goal. Typically they have more control over the how, but
the why has already been decided for them.
The role itself varies across companies. However, there are often some common threads in how it is defined as the next major progression step from EM:
•You begin to manage other managers. This means you can progress towards a reasonably sized org. Assuming that an EM may have 7 or so direct reports that are ICs, the
largest team that an EM could therefore manage is that same number. However, given that a Director manages managers, they could have 7 or so managers reporting to them,
each with their own team. That’s a lot more people to consider, steer and grow.
•You typically are accountable for an operational area. What this means is that you may find yourself with a comma after your job title, followed by some words that describe the
area that you own. For example, a Director of Engineering, Data Infrastructure could run multiple teams that build and maintain the core storage infrastructure of the application.
A Director of Engineering, Fizzbuzz could run an org consisting of all the engineering teams producing new features in the Fizzbuzz application, one of many applications in the
whole Foobar application suite.
•You step away from driving the vehicle. Whilst EMs usually continue to write code for their team – although typically less on the critical path – Directors of Engineering will
usually involve themselves much less, if at all, in committing code. Instead, their focus will be ensuring their teams are productive, coaching their managers, working on the
combined engineering roadmap for their area, and maximizing efficiency and collaboration. If we use Andy Grove’s management equation of the output of a manager = the output of
their team + the output of those they influence, it becomes clear that there are higher leverage activities than being in the weeds of an IDE and committing code. Instead, deciding
what to do and what not to do, connecting and sharing information with peers and delegating effectively through their teams will always result in more output.
So how does this role come about? I’ve often seen it happen in two ways.
The first is that it occurs naturally through growth. As a department hires more people, EMs begin to acquire more direct reports that they can effectively manage. Teams get too
big. Thus teams split, and the need for the org chart to maintain a logical grouping creates gaps for people to begin managing managers.
Although this presents a great opportunity, it’s important not to make yourself redundant if you happen to be the person getting promoted into the Director role. For example, if you
end up splitting an overly large team in two, promote an EM to run one of them and report to you first whilst you run the other one. This way you can gradually ease away from
driving the vehicle, which gives you a longer period of time in your comfort zone of running one team whilst delegating another to a new manager who will need ramping up.
The second way is that Director of Engineering roles at the biggest technology companies are an entry point for experienced external managers of managers to begin to establish
themselves in bigger companies. For example, someone who has experience of being a Director (but often above) at a medium-sized company may get recruited externally in order
to begin to scale a new initiative, or to provide stable engineering management for an acquired team that the larger company wants to retain and grow.
It’s not uncommon to see CTOs who have run departments of around 100 join big technology companies to run a smaller team with a plan to grow rapidly. From what I have
learned talking to contacts, Directors of Engineering at FAANG companies can run orgs in the hundreds of people, whereas VPs have thousands reporting up into them.
All of this sounds very exciting and important, but the step upwards to Director of Engineering is where an EM must firmly commit to management and coaching being their primary,
and often only, output. Trying to hang on to technical contributions causes conflicts of interest across their teams and is, most often, inefficient as per Andy Grove’s equation.
However, the good news is that excellent managers of managers are rare. If you are motivated to do it and successful at it, you are extremely hirable, and you can also make a real
difference in the working day of a substantial amount of people.
Typically a Director of Engineering will report to the VP Engineering, or perhaps a Senior Director of Engineering. The Senior prefix works in the same way as it does for EM. It
signposts tenure and experience.
VP Engineering
Ah, the VP level. Usually managing managers of managers. How meta! The size of the organization that a VP looks after very much depends upon the company that they work for.
We’ll look at two ways that a VP Engineering role manifests below.
In our level definition, VPs are strategic. They help define the why and with what we will achieve.
Thinking of the VP Engineering as a progression from Director, there are some common themes:
•Accountability for a particular part of strategy. Perhaps the VP Engineering is running the Platform division, which spans everything from data ingest, classification, storage and
APIs. Uptime, ease of access and speed of throughput are key, as tackled by tens of teams. Perhaps they are accountable for the organization that builds a product or suite of
products that turn over large portions of the entire company’s revenue. Either way, we’re talking about significant accountability and strategy that links closely to the company’s
direction.
•Spending time thinking about what and why, rather than how. Our Directors of Engineering may be spending their time operationally on how to build and maintain a significant
piece of application real estate, but VPs typically spend more time on what those pieces should be in the first place, and how they affect the company’s bottom line. They are often part
of the discussion around company and department strategy since it affects the direction of their organization. It’s a senior management job where VPs lean on their technical
knowledge to contribute to the conversation.
•Coaching and steering many people towards the future. What should the division be working on in 3, 6, 9, 12 months? What about potential trajectories for the next three years?
What would that look like in terms of resourcing and technology? How can they communicate that vision and coach their staff to bring their own teams along on the journey?
•Reporting to the CTO. This is worth a whole bullet point because it can either be brilliant or frustrating. At smaller companies a VP Engineering may be the process person when
compared to the hacker-in-chief CTO. This causes tension. At larger companies they may find themselves geographically distant to their manager and with many competing priorities
for each of their calendars. This makes it hard to get quality time together. The same strategy applies: the need to be self-starting, to be able to make key decisions with minimal
support, and to know how to fill the gaps that their manager either can’t or won’t want to focus their time on.
So how do you become a VP Engineering?
One way of doing it is by being the first engineering manager at a start-up. The VP Engineering is the counterbalance and compliment to the CTO during the early stages. They’ll be
the ones owning the delivery process, the performance of engineers, resourcing and prioritization of projects, hiring, and so on. The CTO will be leading the build of the product. If the
start-up is successful, it’s a great way to accelerate one’s career growth, but the experience can certainly be a trial by fire. Start-ups are not easy.
The other way is by building tenure as a Director of Engineering and creating a provable track record of operational excellence (i.e. making the trains run on time is natural to you)
whilst showing aptitude for creating and implementing strategic direction, in partnership with your VP and your peers. Think cross-department initiatives, efficiencies through building
systems for reuse, and being in tune with how best to invest time, money and people and get outcomes that benefit both Engineering (e.g. interesting, innovative, challenging work)
and the whole business (e.g. improving speed, reducing cost, or unlocking new products). Think of the Andy Grove equation again: increasingly impactful teams, increasingly impactful
influence on others.
If you have aspirations of being a VP Engineering at some of the largest technology companies in the world, then it’s worth mentioning that they rarely hire these roles externally. Due
to the domain knowledge, experience and trust required to do the role at FAANG (or equivalent) companies, you’re going to have to join lower down the management track and then
work your way up from there. I’ve spoken to FAANG recruiters who say that VP Engineers only ever join externally by doing that same role at other FAANG companies.
Like the EM and Director roles before, you can have a VP with the Senior prefix (SVP). You may even see Executive VP (EVP). Again, it signifies tenure, experience and remit, and
sometimes whether they are part of the company’s leadership team.
Your first day on the job
So, you’ve just begun your first day in a team lead position. Congratulations!
If you’ve arrived from outside the organization, you’re probably busy with induction meetings, getting your desk set up (erm, what’s the WiFi password?) and forgetting your pass for the third time when visiting the bathroom. If you’ve been
promoted internally, you may be beaming with pride, or you may be anxious about how your relationship is going to change with your peers. In fact, are you still allowed to hang out with Jim and Ana at the weekend now that you’re
managing them?
Depending on how much preparation time you’ve had, you may have a plan for your first week. However, for many new managers, it’s likely that you may not have a clear picture of what you should actually be doing with your time in this
role. What is your output? It used to be JIRA tickets and deploys to live, and now it’s… stuff. The truth is that no organization is the same in their approach to management. You may have had several bosses who acted in dramatically
different ways: maybe you had a quiet, sagely manager who was better at structured written communication compared to face to face exchanges; maybe you had a bouncing entrepreneurial manager who motivated valiantly but was a bit
scattershot, or maybe even a manager who was consistently never there at all (believe me, I’ve heard stories). What specifically should you be doing to be effective?
First, you need some structure. Let’s explore how to set up a framework in which you can succeed and create predictability within your working week.
Introduce yourself to your team.
In person, or at the very least, via video call if you have remote staff. Not primarily via email or Slack. You’ve probably already met some of your staff in the hiring process, but now’s the time to start building rapport.
1.Ask them to describe the team and what they’re working on.
2.Ask them what things are going well, and what could be improved.
You’ll begin to uncover all manner of information about your new team:
•Details of the current project(s) and how clear their objectives are
•Knowledge, or confusion (!) about who is accountable for particular decisions, such as the priority of work and the roadmap
•How they feel working at the company
•How they feel the team is perceived within the department and the company
•How enthusiastic they are about their current project, and what they like and dislike about it.
You can do this individually with each member of staff or, alternatively, you could book in some time with the whole team depending on your feel for the people and the workplace. You’ll find that lots of interesting issues and conflicts can
arise when people describe the current situation, ranging from communication to stress to interpersonal issues and beyond. These are great starting points for you to start contributing to making things better. Make sure you’re capturing all
of this.
Book in a weekly 1 to 1 with everyone in your team.
1 to 1s are the most important meetings that you have with your staff. They are the core, private, regular session that allows you and your staff to build rapport with each other by having frank and open conversations in a safe environment.
Give everyone at least an hour. This might seem like a long time, but most of the time it will easily be filled, especially as you get to know each other better. You may be entering into an organization where 1 to 1 meetings are part of the
culture, but if you’re not, ask your staff to try them out to see how they go. Run correctly, they are an essential process.
In order to prepare yourself for these 1 to 1s, you need to define a place for information to be recorded. So…
Create a private document for each person on your team, and share it with them.
A private document is a great way of recording what is discussed within your 1 to 1s, capturing actions that either your or your staff have to do, and jotting down discussion points as the week goes on, ahead of time. It’s useful to get into a
habit of jotting these notes as situations arise. As you get to know your staff, you’ll be able to more easily judge which issues to bring up immediately versus those to note down and defer to your to 1 for a focused chat in private.
The software you use may vary here, but my current company uses Google Drive, so I store these documents there and share them via their email address. You can leave comments and assign actions from documents on Drive too.
Book in a weekly 1 to 1 with your manager.
Don’t wait for this to come from the top down, do it from the bottom up. Repeat the process of creating a private document between you and your manager and use it in exactly the same way that you use it with your own staff. You may find
that your manager never looks at it, or prefers her own paper-based notes, but you can still prepare for your own meetings and capture actions.
Additionally, you may find that it’s useful to schedule this meeting at an impactful time. Slotting it in on a Monday allows the session to be forward-looking for the week ahead, and this can help cover off strategic points that you can
implement in the days to come. Meetings at the end of the week can be more retrospective considering the week has just passed. That’s entirely your call depending on how you like to operate.
Frame the current situation
Ask your manager where you can find the previous annual or mid-year reviews for all of your staff. Once you have them, read them so that you can work out how everyone on your team is doing. Are they performing well? Are they trying to
improve? Are there any pressing worries? What goals are they working towards, if any? These are great topics of conversation for your 1 to 1s.
Why are you doing all of this?
It’s simple: you’ve begun to implement the framework that you operate in as a manager:
•Frequent informal face to face interactions
•Regularly scheduled private catch-ups once a week
•Yearly, or more frequent, performance reviews
•Understanding the goals of your direct reports, so that you can facilitate them and help them grow.
Next time we’ll dig deeper into your first 1 to 1s and explore an exercise called Contracting, which is a great way to begin your relationship with your direct reports.
Contracting
Erm, so what should we talk about?
Just like meeting any human being for the first time, your first 1 to 1 can go in a multitude of different ways. You might be lucky enough to instantly gel with your direct report; the conversation flows and away you go. Equally, you might be
unlucky enough to both sit down, stare at each other and not really know what to say. Depending on people’s experience within their career and the current organization, their cultural background, and their personality in general, they
may approach this meeting in different ways.
If you have started your role in a new organization then you will not know your direct reports on a personal level yet, making it challenging to judge the right level of formality to bring into this meeting. You don’t want to be too serious as
you might cause alienation, but equally, being too jovial might come across as strange in particular workplaces. If you have been promoted from within your current organization then you may face further awkwardness as your
relationship is changing between yourself and some of your colleagues, especially if those colleagues have become close friends over years. Well, this is getting complicated already! What should you do?
Rather than risking getting off to the wrong start, there is a useful exercise to follow that allows both parties to openly talk about what they expect from one other and their wants and needs from the relationship. This exercise is called
contracting.
What is contracting?
Contracting is simply a set of questions that provoke a conversation about what is expected from you and your direct reports. These expectations come from both sides of the relationship, and the contracting exercise aims to create the
space for this to be talked about honestly and openly.
When sitting down in your first 1 to 1, explain that you’re going to do a short exercise to understand how best you can support that person as their manager. You can leave it until the meeting itself to reveal the questions, or you could
forward them to your direct reports ahead of time so that they can prepare. The choice is yours.
Let’s have a look at each of the questions. I’ve used these myself in contracting sessions and they only act to serve as a guide. You, of course, can change them to suit your needs.
1. What are the areas that you would like support with?
This is a broad question on purpose: it lets the other person think of potentially any area: for example, it could be with technical challenges, resolving difficult relationships with colleagues in their team, or even their self-confidence at
work.
Try your best to keep the thought bubble over their head at this point; resist the urge to suggest items yourself. Note down everything they say, but don’t offer any solutions yet. You can later turn these talking points into more lengthly
conversations at future 1 to 1s, thus building a thread of continuity through your meetings beyond status updates.
2. How would you like to receive feedback and support from me?
This is about working out how the other person likes to operate. There are a range of personality types, and it is important that the other party feels comfortable with how you interact with them.
You may notice a variety of responses here. One response could be that they don’t mind, which is usually not the case given more probing. If they are resistant to give a clear answer, try and frame the question with some examples. Let
them imagine, for example, that they were in a meeting, proposing something in front of the room on a whiteboard. Would they be more comfortable with you, their manager, calling them out on an inconsistency in front of the whole
room, or alternatively would they prefer you to tell them privately face to face afterward? Would they prefer your comments on a document they have shared face to face, or by email? Once you dig deeper, you may find that your direct
reports are all very different.
It is important that you find out the best ways to deliver your feedback and support so that you can have the greatest impact when doing so. Since you’ll want to have a relationship where direct and honest feedback is given at all times,
you’ll want to operate in the way that allows the feedback to land in the most impactful and humane way possible.
3. What could be a challenge of us working together?
Like the first question, it’s good to give them the airtime to think properly about this. They may have some first impressions of you that frame their interactions; for example, they may be a less confident public speaker and therefore be
afraid of challenging you publicly. Alternatively, your background could be in Javascript and theirs in Java, and they feel that you might not be able to offer much support in terms of their technical development. All of these concerns are
valid and now is your opportunity to discuss them in detail and develop some strategies. In the last example, one suggestion could be to delegate technical mentorship to a senior engineer of the same skillset.
4. How might we know if the support I’m offering isn’t going well?
If the relationship is taking a turn for the worse, then it’s good for both of you both to be aware of the signs. It could degrade in numerous ways. You could be frequently experiencing negative emotions from your interactions, or they
could not be benefiting from your particular coaching style.
If the situation was getting worse due to conflict, then this is an opportunity to explore how both of you react to a variety of negative emotions such as disappointment, frustration, and anger. One person may become furiously vocal in a
conflict situation whereas another may say very little but the issue is boiling inside. You should be aware of each other’s signs so you can spot them.
If your coaching and support are not working out, then it may be as simple as agreeing that it is OK to openly tell each other, and then further steps could be taken to improve the situation or for them to receive mentorship from
elsewhere in the organisation.
5. How confidential is the content of our meetings?
A number of sensitive issues may be raised during your meetings. For example, your direct report may say that her colleague’s performance has been getting worse over the quarter. However, how confidential do they consider this
information? Would they feel uncomfortable if you went and followed up directly with that information? Would they feel uncomfortable if they mentioned that the feedback came from them?
Running through some of these scenarios can help tease out the answers if they are unsure.
In summary
We’ve run through an exercise called contracting that can be used to break the ice, increase understanding, and set expectations between you and your direct reports. It’s useful to use when starting a new role, but it’s also useful to
revisit it with time since both of your needs will adapt and evolve.
In this article, we’ll focus on 1 to 1s, which provide a key opportunity every week (yes, every week) to engage with your staff on a deep, personal level. As a manager, you can have a tremendous impact on the performance and lives of your staff by doing them
mindfully and to a high standard. Simply doing them isn’t difficult, but doing them well is an area that requires consistent focus.
When and where
Cadence and regularity are key in these meetings. Book them in at the same time and place each week and commit to them. Do not move them unless absolutely necessary. Having a scheduled regular touchpoint with your direct reports brings a predictability into your
relationship and shows that you care about being there for them week in, week out.
It is critical that these meetings are done in a private room. Do not do them in a public area in the office, such as the breakout area or at their desks. This prevents any private conversation from occurring and may even make your direct report feel like you would rather
not hear it; you absolutely want to. The same observation is true for managers who take their 1 to 1s outside the building to a nearby coffee shop. As nice as it is from a social perspective, the lack of formality and privacy in the conversation is detrimental to the quality
of the conversation. After all, the meeting is about open and honest feedback and personal development; you owe it to each other to find a quiet, private place, rather than shouting over the top of the hissing milk wand.
The most important meeting with your staff
So, why are 1 to 1s so important?
Firstly, it is the one completely uninterrupted hour that your direct reports get to spend with you every week. In that time, neither of you are meant to be doing anything else; your primary purpose is to be present and to talk without distraction. Keep emails closed and
don’t get interrupted by phone calls. The private element of the meeting makes it the ideal opportunity each week to talk about performance and developmental issues and to give them a chance to speak in a way that they wouldn’t in the public office space, e.g. to
vent about a colleague who they had a conflict with, or raise their concerns about an ongoing project.
Secondly, this private space is where you build rapport and trust. It is critical that you are approachable as a manager, and building a transparent and trusting relationship through these meetings ensures that your staff will be encouraged to consistently be open with
you and feel safe approaching you if they are in need. Having a good relationship with a manager is a vital factor contributing towards happiness at work, and has often been reported in articles as the vital factor.
Thirdly, this is where you, as a manager, get to exercise your influence, which is exactly what your job is about. You can offer advice, opinions, coaching, and support in this meeting. You can nudge a variety of issues in a particular direction each week, and in the long
term, your staff and their projects will be on the right track. Irregular 1 to 1s, or a complete lack of them, can cause staff to drift in their focus and performance, creating a much more difficult situation to rectify in the future. This is especially true of performance issues
which, when left alone for too long, become nearly impossible to repair.
Prepare
In our previous articles, we advocated having a shared document between you and each direct report that is used for the 1 to 1s. With my own direct reports, I’ll typically jot down notes on what I’d like to cover as the week progresses. Depending on the person, this
may be anywhere between 0 and 10 items. Some of my staff do the same, but not all – some prefer to come with paper notes. That’s fine, but I still keep the shared document as my reference guide. I can use it in the future if I ever need reminding about what events
have occurred, and it is especially useful to review historically at performance review time.
When arriving at each 1 to 1, I’ve typically noted down a few points about the key project(s) they are working on so that I can get a brief update, included any information from the board or management meetings that they may find interesting, and occasionally there will
be a prompt for some coaching or career conversation. However, I’m not fussed if the meeting strays from this, since…
It’s their meeting, not yours
Despite the fact that this is your best chance to positively impact your staff each week, the paradoxical stance you must adopt is that the meeting is theirs, not yours. What this means is that you must “keep the thought bubble over their head” for as much of the
meeting as possible. Do this by asking leading questions, nudging the conversation in particular directions and most of all, by listening. It’s not your job to direct the conversation or pontificate in this meeting; it’s your job to absorb and guide.
Try and get your direct report to do 70% of the talking. If you feel like solving their problem for them, don’t. Ask another question and let them arrive at the conclusion themselves. This is an art that takes some practice, although some are naturally good at this with little
to no training.
Updates: the boring part
The administrative side of the meeting involves getting updates on key projects, asking how work is going, and so on. It’s very easy for you to just nod and listen, but it can be helpful to ask some questions to provoke discussion: “How could we complete that
exploration quicker?”, “Is that the correct technical approach?”, “Have you seen any open source software that could solve that problem for us?”. You may have absolutely no idea of the answers to any of these questions, but they work very well for stimulating
discussion.
It’s worth clarifying that your 1 to 1s are not primarily there for you to receive updates on projects. They would be very dull if that was the only reason that they were there. Derive enough about the current projects to report upwards and feel happy, but don’t insist on
every little detail. Keep most of the time in the meeting free to talk about personal development and wider coaching issues. You’ll both be happier for this.
Silence is golden
Time and time again you will find that if you let the conversation meander and if you stay relatively silent using subtle prompts, the best parts of the conversation are to be found. Get the updates over with and talk more broadly. Let your direct report discuss some
issues that happened in the week, and let the conversation tail off, sometimes to silence. It’s in these moments that the potent issues can be found: “…and that’s the issue, I guess: I just have no idea why that team isn’t helping us more.“
Once again, this is why it’s their meeting: let them dig into their mind and surface the things that really matter. They’ll know.
Their goals
It’s worth keeping in mind your direct report’s goals and frequently stimulating discussion around them. How are they getting on? These may be technical goals such as speeding up data processing in their service by 10X, or a personal goal such as being a more
confident public speaker. Ask whether they made any progress in the last week, and if not, how they could try to find some time in the next week to work on them. Checking back in on goals is additionally a great way to show that you are thinking of their development
and that you care.
Taking notes and assigning actions
Throughout the 1 to 1, it’s useful to be jotting down notes in the shared document and assigning actions. Review the actions at the end of the meeting. You can of course jot on paper or even keep things in your head, but I find that it’s easier to forget things and
transcribing later to the shared document creates more work. You could sit around a laptop together, or both have the document open on your separate screens. Depending on the AV setup in the room, you could display it on the computer there via HDMI, AirPlay or
similar. The point is that your notes are not a secret. They’re for both of you.
I typically use a bullet point format to arrange information, and any item in bold represents an action. Here’s a hypothetical 1 to 1 with Mary, who is not a real member of my staff:
1 to 1s
These notes become a wonderful historical reference as time passes. You can scan back over them when performance reviews are due to prompt yourself on what your staff been doing. You know that you can dump notes in there at any time, and you’ll have them in
front of you to talk about the next time that you meet.
In summary
If you haven’t done 1 to 1s before, then this may seem like a lot of work. But, with time, you will find that having such a variety of opinions of what is going on within your team gives you an excellent ability to make informed decisions more broadly and discover issues
before they become serious.
Feeling productive
Why do I feel like I get nothing done?
A common concern that I hear when talking to new managers is the feeling that they’re getting nothing done. There are so many interactions and tasks in flight any given time that it is almost impossible to focus properly. This feeling is especially common when a manager has spent a portion of their
career as a developer.
A lot has been written about how to keep developers productive. Often the essence of this writing is about arriving at and maintaining a state of flow for as long as possible, usually by arranging the day so that one can work uninterrupted. Doing this has tangible benefits: a developer’s productivity is
greatly increased by being in this flow state. Complex algorithms and infrastructure require a mental map of the problem to be constructed before progress can be made. Context switching and interruptions can destroy this mental map, resulting in it needing to be recreated before continuing.
In addition to individual developers arranging their time so that they can maintain flow, common processes in businesses also support this: for example, Scrum practices the “sprint” concept, where interruptions are kept to a minimum so that the committed work can be delivered.
However, as a new manager, you may be finding that no such protection exists for you! Constant streams of emails, Slack messages, face to face interruptions and meetings can leave you feeling that you’ve achieved nothing concrete at the end of each day. If you have previously reviewed your daily
output by something measurable such as lines of code written or bugs fixed, then it can feel like you’re spinning. How will you ever feel like you’re being productive?
Creating a process for yourself
Whereas you may have had your environment for performing at your optimum provided for you as a developer, you now need to create it for yourself as a manager. You need to have systems and processes that you can work within to make you feel like you are making progress amongst the chaos. I’ll
share with you some things that work for me. I’ll caveat these techniques with the fact that we are all very different and these techniques may not all be right for you. However, reading them may prompt you to create an equivalent system, and I will be happy just the same.
For me, the key to feeling productive is keeping as much information as possible, not in my head. This way I can rest easy that I have everything I need to remember written down somewhere, so I can operate in the present moment with as much calm as I can muster. I can systematically work through
my tasks in quiet periods and feel good about getting them done.
The tools of the trade
I use a handful of systems to organize myself. None are surprising, but I am fairly strict in how I gather and execute information.
The calendar
I live my day by my calendar. Every meeting has to be in there, or I’m not going. I let others know that if they want to request some time with me, they don’t really need to ask, they can just book some time in my calendar in the free spaces and I’ll be there. (Since this is the case, I block out an hour in
there for lunch each day.) Typically, I ask others to book meetings with me rather than the other way around. Given that all of the information that tells me where I need to be is captured here, I can rest easy knowing that I don’t have to remember. I have 10-minute reminders before the next meeting on
my laptop and on my phone. Other than that, I typically glance at it once in the morning to prepare my day. That preparation is done in…
The to-do list
I start each day with a prioritized to-do list, and I simply work through those tasks until they’re gone. I typically prioritize my list as the first thing that I do every morning when I get to the office. I don’t usually get interrupted at this time of the day, but if you’re in an organization where you’re unable to carve
out space, then you could get into the office 10 minutes earlier or quickly do it at home before you leave. (Yes, I know that’s an antipattern.)
The technique I use in the morning is to look at my calendar first, see what preparation I need to do ahead of time, and then feed this preparation into my to-do list. I’m not here to convince you to use certain software, but I have learned to trust Asana, which is free for individual use.
The killer feature for me is the ability to add recurring to-do items by date. This allows me to automate more. For example, I have my 1 to 1s with my direct reports at the same time each week, so I simply have a recurring task in Asana to do my preparation on the days in question. These tasks then
automatically appear in my to-do list when I open it on the morning of the meeting, greatly reducing my need to think about doing it explicitly. I just follow the lead that my past self provided to my present self.
Another excellent feature of Asana is hiding anything that isn’t marked for completion today. You can add a task, give it tomorrow’s date, then move it into the “Later” section which I always have collapsed away from view. It’ll pop back to the top automatically tomorrow morning. Less to see, less to think
about.
The place to capture information
Your to-do list is the place for quiet contemplation and thinking, but you still need somewhere to capture information informally. Throwing this information into your calendar or to-do list can make them muddled and stressful places. Instead, it’s good to have somewhere to jot notes that you can carry
around with you at any time. Then, later, in a quiet place, you can translate all of these notes into real to-do list items.
It doesn’t matter what tool you use, but it needs to be something that you always have access to, such as a notebook or mobile phone. I personally use Evernote on my phone to capture these messy thoughts, and then I delete the notes once I’ve translated them.
The email inbox
I tend to go through my emails in batches every few hours rather than having them open in front of me while I work; it’s too easy to get distracted my unread messages when they’re flashing on the screen. I work towards “inbox zero” by aggressively archiving everything that I’ve actioned or read. I can
still find these messages later if I need them, either my looking at the archive or by using the search functionality. The key point is that I don’t want emails staring at me unless I need to do something with them; this keeps my mind calmer. Another important point is that I do not use my email inbox as a
to-do list. If there is action to be taken then I move that to my to-do list and then I archive the email. Anything in my inbox either requires a response or is unread.
Wherever possible, I turn on email notifications for other pieces of messaging software, such as Slack. Doing this means I can treat my email as my primary hub of digital communication, and reduce the need for other systems to be kept open. Again, out of sight, out of mind.
An example of a day using this system
8.45: I sit down at my desk and I open Asana. Today already contains some recurring tasks, such as preparation for a weekly meeting and a 1 to 1. It also contains a daily reminder to go through my emails and check unread messages on Slack. I open my calendar and see what the day holds. I add a
few items as a result. I then prioritize the list by dragging the tasks into a different order. If I can tackle all of this today, I’ll feel accomplished.
9.00: I start going through my emails. Some require no response and get archived; they are purely bulletins. Others that do are replied to and then archived. Anything requiring action beyond a response, e.g. having a conversation with someone, goes into my to-do list in Asana. Then I archive the email.
9.15-12.00: I go about my morning. I have a couple of meetings where I take short notes in Evernote on my phone. I also note down some reminders to myself for later in the same place. When I get back to my desk, I enter these as to-do list tasks and reprioritize them in Asana and begin working
through actions.
12.45: I go through emails once more, archiving them as I go. I now have zero emails in my inbox.
13:00: Lunch.
13:50: I’m back at my desk for an hour before a weekly steering meeting that requires some preparation. This is the most important current task on my to-do list. I do that preparation now and then check my mail once more, answering a Slack direct message that I received an email notification for.
15.00: I’m in a meeting jotting down some rough notes in Evernote again.
16.00: I’m back at my desk and I translate these notes into tasks in Asana. These get labeled with tomorrow’s date, as they are not urgent. I put them into “Later” so that they disappear out of my sight until tomorrow morning. I then get my head down and get as many to do list items done as possible. I
want to finish my list by the end of the day.
17.30: They’re all done apart from one, which was the lowest priority anyway. Oh well, I’ll kick that to tomorrow by setting the date on it and kicking it into “Later” on Asana. My list for today is empty. I close the tab.
17.45: One more pass on emails, archiving as I go, and I have an empty inbox. Home time!
In summary
Management often means exposure to chaos, and I find having a system to manage my communication contributes greatly to my daily happiness on the job. Although all of this process may seem overly regimented, it serves a higher purpose: it greatly helps my own focus, increases my trust that I see
everything I need to, and contributes to the calmness of being under control and the satisfaction of making progress.
What system works for you?
The 4 key managerial activities
How should I best make use of my time?
In the previous post, we looked at some techniques that I find useful for keeping all of my information under control. Certainly, for the new manager, striving for a situation where each day has structure and feels more regimented is a positive place to start. However,
once that structure is in place, how should one engage in activities and conversations to best create a positive outcome for the business?
For this article, we’ll expand on 4 categories that were outlined in what I feel is the quintessential book on management: High Output Management by Andy Grove*. He uses these categories to frame the different types of interactions that happen in the workplace.
These are:
•Information gathering
•Decision making
•Nudging
•Being a role model
Information gathering
As you may have gathered (pun intended) from the previous articles, as a manager, the information base that you hold is critical. This is why I recommend having everything documented wherever possible: 1 to 1 notes, actions from meetings, a place to capture informal
information, and so on. Your knowledge base is what you use to understand the many activities of the business and fundamentally what you base your decisions on. Information gathering feeds this knowledge base.
It is worth noting that information can be gathered in many different places other than formal interactions and meetings. For example, you could be having a conversation at the coffee machine with your colleague, and then she mentions that her team is building a new
API. You realize that this is incredibly helpful for your own team, so you note it down. Weeks later, your Product Owner notifies the team that this particular feature arriving in another of the businesses’ products would be perfect for your own. You already know that an
API was written, so you make the connection between the teams.
Keep adding more information to your knowledge base. Always. Keep as little in your head as possible. Tools such as Google Drive and Evernote make this so much easier than it was 10 years ago, and they’re all free. For me, the simple act of writing things down also
commits them to my memory better than if I’d just made a mental note.
Decision making
This is one of the more obvious answers to the question “What does a manager do?” You can make decisions of all sizes. You could make a small decision as to grant a holiday request or not during a busy period of work, or you could make a large multi-million-pound
decision as to whether to migrate the entire infrastructure into the cloud or keep it within your own data center.
Always take decision making seriously. It is easy to forget that there are many in the business who do not have the power to make decisions, so you must always give them your full attention and take responsibility for the ramifications of making said decisions. Every
decision is an inflection point: should we hire Bob or Susan? Should we split the team into two teams? Should we refuse to begin estimating the work required for this project when the proposal for the product is so unclear? Decisions such as these may seem like they
are small in that moment, but extrapolated over time and bringing in the cost of the different outcomes, they are actually big decisions. Treat them as such.
Nudging
The concept of nudging is influencing a decision by contributing your own viewpoint to the discussion. For example, you may be involved in a discussion about whether to build or buy some particular software, and you make it clear how you feel about the situation. You
are not the decision maker, but you can influence the decision. Like decision making, nudging can occur for decisions of all sizes. You may put your viewpoint across about whether to book a meeting immediately or tomorrow, or equally state your case in a discussion as
to whether to open an office in the UK or abroad.
Try to view your daily interactions through the lens of nudging, and you’ll soon see that there are ample opportunities to broaden your influence on the organization, thus increasing your output as a manager.
Being a role model
Being a good manager is about walking the walk as well as talking the talk. The best way to demonstrate to your staff and your peers is to lead by example. Give talks, get involved in day-to-day discussions and contribute technically if you have the time and inclination.
Demonstrating the standards that you wish to see others perform to is the best way to create change: lead from the front. If you wish for your team to communicate better in person but you personally prefer to talk to them over email rather than face to face, then it’s
unlikely that the situation is going to improve with the rapidity you desire.
You can also be a role model for your department by making connections outside of your typical influence sphere. If you are in Engineering, for example, you may have regular check-ins with influential staff in other areas of the business, such as commercial. These
connections can give vital feedback, help you discuss ideas and issues, and identify stakeholders for future projects.
A day through a lens
Let’s have a look at a fairly typical day and see how we can categorize the interactions.
8:45: You sit down and prioritize your to-do list. You read your emails and unread Slack messages. Here you are information gathering.
9:00: You answer your emails. You contribute to various discussions with your viewpoint, which is nudging. You decide to make an offer to a candidate you interviewed yesterday. That’s decision making.
9:10: While in the kitchen and making a tea, you have a conversation with a colleague and learn what they’re working on. Information gathering. You share how your own team tackled a similar technical issue with a degree of success. You suggest taking a similar
approach. Nudging.
10:00: You attend a meeting to review a number of CVs that have come in over the last few days. You choose which to invite to a first interview. Decision making. You suggest to the CTO that it is a good idea to open the position out to more junior candidates now that
the local universities are a few months away from having large numbers of students graduate. Nudging.
11:00: You are in a 1 to 1 with a direct report. Lots of nudging but less decision making as ideally you want to steer them into making their own decisions. You learn a lot of things about what she has been working on this last week, and how the issues have
overcome. Information gathering. You offer some opinions of how problems might be tackled. Nudging.
12:00: Lunch. You gather some food, rather than information, at this point. However, you do have a conversation with a colleague whilst eating about his experiences using Jenkinsfiles, and your team has moved across to using these recently. You give some advice
about who to talk to. Nudging.
12:30: You catch a colleague in the breakout area who shipped some new functionality last week. You tell her that she did a brilliant job and that customers are really appreciative. You do this because you want your department to get better at delivering honest
feedback. Being a role model.
13:00: You go through your emails and messages, both information gathering and nudging. You have a decision to make about whether some work should be put into your team’s backlog or not. You decide that you need to talk more in person, so you set up a meeting
for later.
15:00: You have the meeting about the work. Your product owner describes how the work can make your own product more compelling, and you also know that you have the technical expertise to build it in such a way that other teams can use it too. You both decide to
take the work on because contributing to other teams as well as your own is a good example to set. Being a role model.
Managing upwards
Upwards?
Whilst we may typically think of the “management” part of being a manager as the relationship between yourself and those who report to you, it’s equally important to think about how to handle the relationship between you and your own manager. It’s critical to
your happiness in the workplace, your career growth, and ultimately your success, as they will be judging your performance. By putting a concerted effort into getting the best out of the relationship with your own manager, you can be happier, more impactful
and go further in your career.
As you begin to report higher up the org chart, you’ll naturally be dealing with people who are extremely busy. This is especially true if you are reporting to the CTO or CEO. Although you may report to someone who actively spends a scheduled portion of their
week thinking about your own career growth, with the increased messiness and ambiguity at the upper echelon of organizations, this will become increasingly unlikely. Instead, you should take your relationship with your manager into your own hands. Set the
agenda yourself and seek their advice, not the other way around.
Contracting again
Let’s start with first principles: perform the contracting exercise. We have gone into the contracting exercise in detail in a previous article, so do start there if you haven’t encountered it. If you are beginning a relationship with a new manager, then don’t wait for
them to do this exercise with you; ask them to do it. Additionally, don’t worry if you have already worked for a manager for a period of time; the contracting exercise is a great refresher.
During the contracting exercise, you can confirm how best to report on progress, get support (in both directions), and discuss how your personalities may support or collide with each other. By identifying this up front, many real conflicts can be prevented by
having this deeper understanding of how both of you operate.
How much communication?
Ask how much they need to know and when. I find it useful to get them to envision the following situations and see how they would best like to receive the information.
By which means, and how often, would they like to be informed of:
•Weekly and daily progress on projects that you are accountable for
•Something critically urgent happening (e.g. the entire app is down or someone wants to leave)
•Your staff’s performance, good or bad
•Administrative events such as your own sickness or needing to work from home
Some items they may not even need to know. I’ve reported to managers who like a constant flow of communication and those who prefer only to hear when something urgent happens, operating in the knowledge that all is under control unless notified
otherwise.
The medium of communication is important too. Some managers may like these conversations to happen face to face, 1 to 1s, or via email digests. If you are reporting to the CTO or another board member, their time may be scarce and regular face to face
catch-ups may be dramatically more effective than email or Slack. Or, the inverse could be true. Who knows without asking? Get this clear up front.
What makes them perform well?
Ask how your manager’s performance is being measured. Are they accountable for particular projects, or particular KPIs? How often are these checked and by whom? Are they accountable for a team or a division or an entire department of the business? Get
clear on how your success in your own job feeds into their success.
This is also an opportunity to explore how you can grow in your role. Are there other facets of your manager’s job that could, with time, be delegated to you so that you can continue to level up? Typical items here are hiring, departmental processes, steering
meetings and budgets. This discussion can produce a truly win-win situation: you can expand your own responsibility and impact on the business and they can have more time to focus on other aspects of their role that they enjoy more.
At some level, everyone is judged by delivering some project or initiative on time. A CTO will be judged by the output of the Engineering department. A team leader will be judged by the output of their team. However, are there other factors that they are being
measured against that you could indirectly contribute to? There may be a push to grow the department by 20% by the end of the year. There may be a concerted effort to save money on hosting costs. There may be diversity goals in hiring for the company as
a whole. See if you can contribute to these as part of your own role.
What is good performance?
In order to get a better idea of how they judge performance, ask them to identify the characteristics of a current top performer in the company. You can begin to understand the traits that they value in their organization.
Do they prefer staff who just get things done without needing steer, or do they prefer to be involved in decisions beforehand so they can oversee? Do they value those that communicate frequently about their work, or is no news good news? As a manager,
tapping into their vision for their organization can promote good discussion about how you too can contribute to fulfilling that vision.
The visibility of your work
Since your manager will be delivering your performance reviews, ask them the thought process that they go through when writing it. Do they primarily measure your performance on the frequency and quality of projects that you are delivering, or is that just part
of a greater picture including coaching and mentoring, the happiness of your team and success in hiring and retaining staff? By discovering this framework now, you can use it to frame your own activities in your role, and your own staff in theirs.
It is also key to ask how they measure this progress. Is it a mixture of shipped projects plus a subjective measure based on their view of your within the organization, or would they like you to keep track of your goals concretely so they can review them
regularly as the year goes on?
In summary
Managing upwards is not discussed as widely as managing your own direct reports. However, understanding this relationship is critical to your success. Many individuals in an organization can see the relationship as entirely one way; that the manager will
always create the best environment for the direct report to succeed so they can be a passive participant in it. I don’t think this is the best way to handle this relationship; it requires effort from both parties continually.
There can often be fundamental misunderstandings from both sides that can manifest in conflict, or even worse, in a bad performance review. Thus, in the same way as managing your own direct reports, it is also your responsibility to work on the relationship
with your own manager so that you can both ultimately succeed. Ask!
Delegation
So I’m getting someone else to do my work?
Delegation is very powerful.
Yet, for new managers, the process can feel really weird. A career spent as an individual contributor, where one is responsible for taking tasks and executing on them until they are finished, feels an entire galaxy away from this new
role where tasks are often delegated to someone else. It’s especially challenging for those with perfectionist qualities in their own work: how will you even know it’s being done right? As strange and uncomfortable as it first
appears, delegating is an absolutely essential tool for a manager. Mastering delegation, and thus building your team so that they can expertly carry out those delegated tasks, is the key to understanding and increasing your output.
Why is delegating so important?
Imagine starting your own small business. Let’s pretend that it’s a coffee shop. You have humble beginnings and a handful of customers. You’re able to take the orders, collect payment, make the drinks and serve them yourself.
This endeavor is going well, and you’ve managed to break even (well done!). Then, a favorable review in a national newspaper shines the spotlight on your little coffee shop. Visitors come in droves and you’re overwhelmed with no
additional staff. Now you can’t do this all by yourself. However, increased profits allow you to hire an additional member of staff who works the coffee machine, and you remain front of house, taking orders and payment and talking
to customers. It is your coffee shop, after all; the review was particularly fond of your charisma and passion for what you do. As the business does better, you hire another member of staff to take orders and payment. You turn your
focus to expanding the range of coffee beans the shop stocks, widening the selection of drinks that you serve, and beginning researching a menu of cakes and snacks. You spend more time orchestrating and less time turning the
cogs in the machine.
The coffee shop example is easy to understand: the coffee shop is still yours, however, you, as the owner, are able to free yourself up from the tasks that can be replicated by others with training, allowing you to make more
strategic decisions and plan for growth. This is exactly how management via delegation works, yet it is surprising how few technology managers grasp this concept!
How do I measure my output?
There is an equation that Andy Grove defined in High Output Management:
A manager’s output = the output of their organization + the output of the neighboring organizations under their influence.
It’s a very simple yet powerful way of understanding the essence of a manager’s job. Framing it in terms of our example above, your organization is the coffee shop. You, as the manager, are concerned with the quality of the
coffee, the number of coffees sold, the number of visitors and the revenue that it generates. It’s easy to understand, and you can imagine the different levers that can be pulled to increase profit, speed, and quality. But what does
equation mean for a manager in a knowledge-based industry such as software development?
It means that managers should stop measuring their output in how much work they, individually, get done each day. That’s not what a manager does as a core competency; that’s something for the individual contributors to worry
about. If you are a team leader, your organization is your team. If you are a VP, this is your division. If you are a CTO, it’s the whole department. As a manager, you need to be concerned with, and actively trying to increase the
output of, your own organization. You need to delegate effectively.
Delegating well
It’s worth highlighting that there are two things that delegation definitely is not.
Firstly, delegating is not a “fire and forget” activity. As Grove points out, it is not abdication. It’s not like receiving an email and then immediately forwarding it to someone else. You are accountable for all of the tasks that your
organization has to complete, regardless of whether you are doing them yourself or not. You are required to monitor the tasks being done and make sure that they are being completed to the quality that you expect. You can raise
this quality both technically and via inspiration: by coaching staff to become more skilled at activities, or by providing support and motivation to help them perform better.
Secondly, delegation is not micromanagement. You are required to use the right mix of instruction and coaching to get your direct reports to work independently. But how do you figure out the right amount?
Task Relevant Maturity
Each member of staff in your organization has a level of seniority in their area or as Grove describes it, “task-relevant maturity” (TRM). This is how skilled they are at getting tasks done to the required quality. Your approach to
delegating is dependent on this skill level. Grove presents three levels of TRM: low, medium and high.
Low TRM: Here you will delegate a task, but you will need to provide specific instructions on how it is done, often following the progress closely along the way. Skilled direct reports will not stay at this stage for very long. This stage
is also intensive on the manager’s time.
Medium TRM: Here, the direct report will understand how to do the task, so the manager’s focus isn’t about prescribing how to do it. Instead, the instructor role turns into a facilitator role: providing support, advice, and feedback as
the delegated task is being done, often with the requests for feedback being driven by the member of staff doing it.
High TRM: At this level, the direct report needs very little support. An up-front discussion to confirm the expected outcome is all that is required. A manager’s responsibility here is to set the bar high to coach the skilled direct report
to perform at the best of their ability.
High functioning teams
Given that direct reports have different levels of TRM, the manager’s responsibility is to instruct and then coach staff from low levels of TRM to high levels. A team full of high TRM staff can become almost hands-free for the
manager. It then follows that the manager can then increase the number of staff in their organization and thus increase their output.
TRM shows how important it is to have your senior staff placed within teams where they can raise the TRM of others through mentorship. An obvious example that comes to mind is pairing junior developers with senior developers.
In the long term, the junior developers will improve their skills and contribute more to the organization, and in turn will be able to coach other more junior staff. Everyone gets better together.
In summary
As a manager, you can only increase your own output so much: there are a set amount of hours in the day. However, your performance is measured on the output of your organization, not just your personal output. Therefore,
delegating tasks with sensitivity and skill is not only a way for your own output to increase, but it is a way for your organization to become more skilled and autonomous. Continued practice in delegation can open the doors for
further expansion of the organization that you lead. The CEO of a FTSE 500 company is a master delegator: she delegates her strategy to her whole organization.
Think about the TRM of your own organization. How could you increase it by delegating further?
Giving feedback
Easy, right?
The concept of giving feedback is simple to grasp: you want to let people know when they are doing a stellar job so that they can receive praise, and conversely, you want to let people know when they are not performing to your
standards so that you can begin to help them improve.
The truth is that giving feedback well is very difficult to do. It’s easy to see why giving negative feedback is tough: it might not land well, it might upset the other party; it essentially creates conflict. Yet, giving positive feedback can
also be challenging. It’s awkward telling people they’re amazing!
Mastering the art of giving feedback has a number of benefits. Your employees know where they stand, either as star performers or those that need to do better. Practiced regularly, it also strengthens the emotional bond between
you and your staff because giving honest feedback requires honesty and trust.
What happens when you don’t give good feedback
Let’s start with an example. Susan is leading a team of engineers, and something seems to be up with one of her staff, Ann. It seems that Ann just doesn’t seem to be giving it her all in recent weeks. She’s been turning up slightly
late every day, and a lot of the features that she’s worked on have had some gnarly bugs found in QA. Something’s not quite right.
In their next 1 to 1, Susan asks whether she’s OK as a way of trying to get her to open up about whatever is bothering her. “I’m doing fine” is Ann’s reply. The issue gets skirted this time. Fast forward to next week. Susan prods at
the situation a little more by asking how her feature is going, as a way of getting her to open up about the recent issues that were found in QA. “It’s just been complicated to develop” is Ann’s reply.
Weeks go by, and the situation is getting worse. Other members of the team have approached Susan because they are finding it increasingly frustrating to rely on Ann to deliver to the expected standard, and progress in the team is
slowing down as they move closer to their launch date.
In the next 1 to 1, Susan decides to ask whether Ann needs any additional support as she seems a bit under the weather. She uses this as a way to slowly steer towards the problem. “I’m OK, but I find working with the API difficult
sometimes”. Susan decides to pair Ann up with a mentor within the team so that she can pair program on the parts of the work that build on the API.
One week on, and Ann’s mentor, Robert, sends Susan a message. “I’m finding it really frustrating trying to pair program with Ann. She seems really distracted and doesn’t seem to want to learn.” Now you have your team looking
for answers.
As the end of the quarter approaches, Susan prepares Ann’s performance review. It isn’t great. She writes up all of the aspects of her role that haven’t been performed to the expected level, incorporating the feedback from the
team. She sends over the performance review ahead of the meeting. Ann turns up to the meeting looking distraught. Susan asks if she has read the feedback. Ann gets extremely angry. “If I wasn’t performing well enough, why
didn’t you tell me?”
People actually like feedback. Give it!
Good or bad, people want to hear how they’re doing. Get into the habit of giving good or bad feedback whenever you can. Your 1 to 1s are an obvious place to do this, but keeping it front of mind when having meetings or informal
interactions can uncover many more places to fit feedback in. Positive feedback can be given pretty much anywhere and to anyone: an informal chat around the coffee machine can become an opportunity to congratulate a
colleague on their recent feature launch and tell them how much you like it. However, frank and constructive criticism is best saved, initially, for those that you have a stronger and more open relationship with, such as your direct
reports, peers and manager. (Yes, your manager too!)
Your best performers will want consistent feedback that they are doing well and that you appreciate the effort that they are putting in. Similar to how superstars in the classroom can become frustrated at the disruptive children that
are getting all of the teacher’s negative attention, you will want to make sure that you are praising and pushing your stars to perform at the best of their ability. This will not only mean that they will be happier and feel appreciated,
but it will keep them contributing at a higher level.
For staff that require improvement, they absolutely need to know. In the previous example, Susan was not tackling the problem with Ann directly. Instead, she was trying to gently approach the issue from different angles, but with
little success; at review time, Ann was surprised that she had negative feedback. Instead, Susan should have been direct as early as possible. This can be challenging but becomes easier with experience.
Try to be direct, compassionate and open to solutions. Focus on the future improvement rather than dwelling for too long on past events.
1.Be direct: “Ann, I’d like to talk to you about your performance. I have noticed that recently it is not up to standard and one of your colleagues has also approached me about it.”
2.Be compassionate: “I really want you to be awesome in this role so that you are able to continue to level up in your career. You’re a very smart person, and I worry a lot if you’re not able to perform well.”
3.Be direct again: “If you’re unable to perform in your current role then we will have to look more formally at the options available for you. In the worst-case, this could be a conversation about whether this company is the right place
for you to be.”
4.Be open: “How can we identify and work on what you need to improve?”
Radical candor
Kim Scott’s excellent book Radical Candor distills the traits of giving good feedback into two simple categories: “Care Personally” and “Challenge Directly“. When these two traits are combined in the relationship between a
manager and their direct reports, the right atmosphere is in place to criticize, praise and push people to perform at a high level.
Being able to challenge directly requires an extremely high level of trust and emotional rapport between two people. Scott argues that the core of this trust is simply giving a damn, personally. Two people that care personally about
each other can challenge each other directly with positive consequences. Think of a sports coach. This also works in both directions, since the direct report should have a level of trust that allows them to care and challenge
upwards, as well.
The book is well worth reading. Kim is a smart author and has some great ideas.
Getting practice: an exercise
Here’s an exercise that you can try with your peer group. Depending on your organization, this will either be extremely positive or extremely awkward (shifting to positive, though, as people get more comfortable). One session I
Bringing yourself to work
Wow, this is so much more tiring than programming…
Those who manage others: have you ever had one of those days where you feel like work has completely sapped you of all of your emotional energy? Don’t worry, it’s not just you.
Being a manager exposes you to a rich spectrum of challenges at work. Of course, you still have the technical matters that come along with working at a technology company, and those are difficult enough at the best of times. Yet
now you have to care personally about the well-being of those in your team. When times are good and your team is performing well and enjoying their work, it’s hard to imagine your role being more fulfilling. When times are bad,
however, well… they’re really bad.
So let’s paint a picture of the bad times. In addition to being accountable for the delivery of a large, complex project that is overrunning, you know that Bob is really unhappy because he didn’t get a good pay rise in his end of year
review. However, this was totally out of your hands this time around; the budget is very tight. You’re uncertain as to whether he wants to quit and what that means for you finding a replacement. On top of that, Susan has disclosed
that she’s been having a terrible time at home because her partner is very ill. Also, Jack isn’t performing well and his stubbornness means he’s having trouble admitting it to himself, which is a barrier to his eventual improvement. To
put the icing on the proverbial cake, the company laid off 10% of staff two months ago because of fierce competition in the marketplace resulting in many lost deals that looked totally safe. Everyone, therefore, is understandably
nervous about their roles and the threat of further layoffs. As well as carrying this you’ve got your own stuff to deal with: pressure from above, below, and outside of work, your family at home.
How much should you care about everyone’s personal issues when deep down you’re really struggling to stay positive in your own mind?
It’s your job to care
You should care. Because that’s your job. Plain and simple. It’s very hard and it’s very emotional, but it’s a core principle of being a good manager. There is no other way to look at this particular situation. For your staff, you are their
rock, mentor, and confidante. Technical issues can be solved by studying literature, algorithms, and documentation, but personal issues can only be solved by being present and being human.
If you are reading this because you are thinking about becoming a manager, then this is often the part that you aren’t told about explicitly. You may read a job description and see that you will be responsible for delivering a key part
of the product with your team; making your staff perform at the best of their abilities; hiring the right people, and so on: all of these activities may make you imagine an army captain at the crest of a hill clutching a flag. However, in
reality, it’s not at all about machismo and whip-cracking. Fostering an environment in which people can thrive and be happy means understanding their personalities, what drives them, and being there for them through good times
and bad. This may sound like it has parallels to the job of a counselor, and I would argue that there are aspects of that comparison that are true; except you also need to get your staff to ship as well as making sure that they are
happy!
Bringing your whole self to work
The phrase “bringing your whole self to work” has become fairly prevalent, and for good reason: it encompasses what you have to do in order to build a trusting relationship with direct reports, which in turn means that they feel
comfortable and supported, which in turn means that you can have open, honest and challenging conversations, which in turn drives the best performance.
But what does it mean?
My own interpretation is that it highlights the parts of one’s personality that can be easy to leave at home: true emotions and weaknesses. I’ve experienced this equally in both men and women.
One may leave their emotional side at home because of a preconception that it could be deemed unprofessional to let particular sides of them show in the office. Common examples are negative emotions such as sadness, anger,
and frustration. However positive emotions sometimes suffer the same purposeful muting, such as overt happiness, joy, and silliness. It could be believed that the “professional” workplace is not where these should be exposed:
after all, we’re trying to be professionals, aren’t we? Yet, all of these emotions are part of us as humans and should not be suppressed. Instead, as managers, we should be understanding the character of our staff deeply enough to
create the environment in which they can truly be themselves without any part of their personality being absent. This is an environment in which they can thrive. Think about ways to have fun, to celebrate success, to get angry and
frustrated, to be OK with being sad and letting it show.
Weaknesses are also often left at home. Weaknesses are human. Nobody is perfect, and nobody is meant to be perfect. An environment that encourages people to hide weaknesses is an environment that stifles self-improvement.
It takes great confidence to admit to weaknesses: why would anyone want to expose that they are not as good at something as others, especially if they are on a high-performing team? Yet, by cultivating an environment in which
your staff can admit their weaknesses to you, and by openly sharing your own weaknesses with them, you can in turn influence a culture of mutual mentorship and teaching. An admission of a weakness is an opportunity for
learning and improvement, and it is enabled through building trust.
Trust enables performance
Despite the emotional toll, especially for the new manager, that caring deeply and personally can take, it is the foundation for enabling high performance. Staff that have a trusting environment and close relationships with their
manager and colleagues can be themselves and do their best work.
This trusting relationship allows for challenging and frank conversations. Talking about bad performance is not as difficult if there is trust and respect between the two parties. Without trust, bad performance may be the taboo
subject that goes unspoken for too long. With trust, it’s (almost) as easy to discuss as anything else, because the feedback comes from a caring place, rather than a hostile one.
Practice talking about weaknesses
An exercise that you can try with your staff in their 1 to 1s is to both discuss your weaknesses, but you go first. Pick a selection of your own weaknesses that you can put on the table and let them know how you feel about them, as
long as they are able to reveal at least one of theirs.
Here’s three of mine:
•Given that I am now spending almost all of my time managing a division, I do worry that my technical skills are weakening. For example, the toolkits to do machine learning have dramatically changed since I last did any hands-on
work. I continually worry that my technical skills are becoming irrelevant, and if I turn out to be a bad leader or I have a change of heart about my career, what is my fallback plan?
•I am often too fast at wanting to solve problems myself rather than waiting for consensus. I know that this can be seen as a strength, but I can step on the toes of others and make them feel bad.
•My obsession with speed means I can blaze a trail and forget about key details. This can be seen with stupid bugs in software I’ve written (fortunately others here are rewriting all of my code now…), or in the email thanking a team
that just went out where I missed someone’s name off. Again. It can be quite embarrassing.
Support groups
Performance reviews
It’s that time of year again…
Update: you can find this topic covered in much greater detail in my Book.
Let’s get one thing straight: nobody likes performance reviews. They’re essential yet unpleasant; a trip to the proverbial dentist. Yet, despite the unpleasantness, they’re the best opportunity that you have to push your top performers further and course-correct those that are underperforming. Use them well, and your staff will only get better. Use them badly, and
you’ll be in for some very awkward conversations.
I’ve been in many different performance reviews, on both sides of the table. In this article, I’ll outline what I like to do with my own direct reports. Most, if not all, use similar techniques with their own staff, so I’d like to think that these techniques have positive characteristics that are now being replicated elsewhere. None of the techniques are ingenious devices
that I have invented myself; I’ve mostly learned from experience, by having both positive and uncomfortable conversations with my own bosses and my own staff, and some come from a selection of books that I’ve read over the years. But, I digress. Let’s prepare.
Preparation
A performance review should be roughly an hour together in a private room. But what happens in preparation for the meeting? Good preparation is essential, both for you and your direct report. These review meetings carry lasting weight, so they deserve at least an hour of your time in planning for each of your staff. Being unprepared can result in you deliverin
a message that isn’t quite what you wanted, or missing the opportunity to give some very precise critique. Even worse, you might say something you regret or look like you have absolutely no idea about what they’ve been up to. Being unprepared can make your direct report feel neglected. They’ll wonder why you didn’t take the time for them. You only have a
few opportunities in the year to give reviews, so make sure that you bring your A-game both before and during the meeting.
This does have ramifications for your time. If you have 6 or 7 direct reports then we’re talking about almost a full day of preparation, which can be very hard to fit around other commitments and meetings. The bottom line is that this is the most important commitment, so everything else, within reason, moves out of the way.
Early confrontation
You should be writing your reviews so that they can be shared before the meeting. As the person on the receiving end of the review, it’s deeply unpleasant to turn up with no idea of the direction that the meeting is going to take, especially if it hasn’t been a stellar year for them. These meetings are not an occasion for a big reveal, and that’s true for both good
and bad news. Save that for the magician at the Christmas party.
It goes without saying that the bad reviews are much harder to stomach than the good ones. Delivery of critique, especially when there is a lot to criticize, can put people in a spin. By sharing what you’ve written for them beforehand you give your staff time to mentally prepare.
To frame why this is useful, consider the five stages that people tend to go through when receiving bad news:
1.Ignore
2.Deny
3.Blame others
4.Assume responsibility
5.Find a solution
Staff reading the document before the meeting have the chance to move through steps 1-4 in their own minds. This makes the meeting focus on step 5, which is a much more productive use of both of your time.
Getting feedback from others
I always incorporate at least two pieces of peer feedback per member of staff. For each person, I pick two key people that they work with, either inside or outside of their team, and then send an email asking for candid feedback on them. This gives you an opportunity to get skip-level feedback if you ask one of their direct reports, or peer feedback if you ask
someone else they work with in the organization.
Some people require very little guidance to write you a very long and detailed response, but some need prompting, especially if they haven’t done it before. The following questions can be a good place to start:
•How have you found working with this person over the time period?
•What are their main strengths that they bring to the organization?
•What do you think that they could improve upon?
•What’s your favourite memory of working with this person recently?
•Would you like to keep this feedback anonymous?
On that last bullet point: I always ask whether people would like to maintain anonymity. However, in my organization, I find that in most cases people don’t mind their name being attached. That’s a positive sign as it shows that people want to be accountable for their critique and feel comfortable doing so.
Who should write the review?
I’ve seen many organizations moving toward approaches where the staff write the majority of their own performance review themselves. I will make a controversial point here: this is very lazy.
I would hope that managers doing a good job could summarize the performance of their staff, and also outline some of their main achievements. Also, a self-review written by an underperforming member of staff about themselves will not be as negative as it needs to be, and that makes contradicting it even harder in the meeting. If they were wrong about their
own performance, then what was the point of them writing it all in the first place?
Instead, the review should have equal input from both the manager and the direct report. The focus for the direct report is to summarize their achievements and feelings about their performance over the period, and the manager should do the same. If there is conflict in the two summaries then that is an excellent talking point for the meeting: why didn’t they
know earlier?
My own approach to researching a performance review is like this:
•Review what the whole team has achieved in the time period since the last review.
•Review 1 to 1 notes for the period to pick out personal achievements, struggles, and themes that we discussed.
•Think hard about how they have been over the time period: were they mainly stressed, motivated, happy, neutral? Why?
•Think about the forthcoming time period. How would I really like that person to improve and excel? Are there upcoming projects they could contribute to? How do they want to grow for their own career goals to be met?
With this information to hand, I can begin writing the document.
Review document: a template
You may find that your workplace has a standard template, but here’s some sections that I like to use in mine:
•A summary of the main achievements for the period. (Looking backward)
•Areas to grow and develop over the next period. (Looking forward)
•A summary of peer feedback: either verbatim if they did not ask for anonymity, or paraphrased snippets if they did.
I typically write about 500-1000 words for each person. This may seem a lot, but it shows that I have taken the time and that I care about them. Under each section is space for the person to write their own additions in case there are things that I missed, or if they would like to make a rebuttal to anything that I have said. Sometimes I’m wrong.
Once I’m done, I’ll share it with them at least 1 day before the review with an attached note to take some quiet time and digest it, and to come to the meeting ready to talk it through.
The meeting itself
Before the meeting, check to see whether they’ve commented on anything you’ve written. Then, it’s time to become your best self and step through the meeting room door.
When it’s time to sit down, you should have plenty to talk about. Resist just reading through the document. You’ve both already done that. Instead, steer the conversation towards the positives, where you can dish out ample praise and thanks, and to the negatives, where you can discuss the situation and how to improve it.
Spend about 50% of the meeting looking backwards at the work that has been done, and 50% of it talking about the future. In the document, draft the goals that you both want to work towards in the coming period. This can be taken away for additional thought and then it can be signed off later.
If you’ve done all of the necessary preparation beforehand, these meetings typically go fairly well. However, sometimes that all goes out of the window and there are heated arguments or tears, or both. In these situations just listen and care for the person, but stick to the critique that you wrote. Offer your support to help them improve and grow, and let them
know that they’re reacting because they care, and you equally care about them doing well. Don’t be afraid to step out for a bit to give both of you some time. It’s hard on you as well.
Leave money out of it
When performance reviews are at the end of the year, they have another piece of pertinent information attached: salary increases. This complicates things.
I’ve had performance reviews that acted as the grand unveiling of my salary increase. I wholeheartedly recommend against doing this. As soon as compensation is on the brink of being revealed, people tend to not engage as well in the performance discussion, which is what these meetings are really about. In the lead up to the pay rise surprise, people will sit
there wondering when you’re going to tell them. As soon as you’ve told them, they’re either extremely happy and begin thinking about what they’re going to do with the extra money (a holiday in Spring? overpay the mortgage? invest more? start shopping in Waitrose?) or they’ll be seething because it’s not what they expected. All the while, the useful
conversation floats on by and doesn’t land.
Instead, inform people of their pay rises at another time. Don’t let money distract you from a focussed conversation around performance. Personally I inform staff about salary increases by email, again, so that it gives people time to digest. If anyone wants to discuss it further, then they’re invited to take some time with me whenever they want.
In summary
Performance reviews are really hard. But with preparation, they can become slightly less so. Frame them in your mind as your ideal forum to dish out in-depth praise and critique that will have a lasting impact on your staff. Your stars can leave feeling motivated and wanting to achieve even more, and those that need improvement can leave with knowledge of
how to do much better.
For all of the gigs that a manager does each year, performance reviews are your headline show. Rehearse, be calm, and it’ll be alright on the night. Good luck.
The two tracks of growth
How do we grow?
You have a responsibility to your staff to understand their career aspirations and facilitate their growth in the right direction. But what should they be aiming for, and who is accountable for making it happen?
There is often a stereotype within the technology industry that the only way that growth can occur is via promotion into roles that carry increased people management responsibilities. At best, this can produce excellent leaders who take their teams and companies to the next level. At worst, this can
alienate staff who aren’t naturally suited to this role, resulting in them becoming frustrated and leaving the company. Clearly, we don’t want the latter to happen.
I find it more helpful to think about two mutually exclusive tracks for those working in technology: the management track and the individual contributor track. Both are very different growth trajectories, carrying very different responsibilities. However, despite the differences, both can have an incredible
weight of influence at senior levels. They just do so via alternate means.
We’ll have a look at both of these tracks today.
The management track
The management track concerns itself with – unsurprisingly – people management. The management track begins, typically, by gaining line management responsibility for some individuals, usually by taking on a team lead role. In my current organization, the size of these teams can vary from 2 to 8
people, depending on the kind of work that the team does.
If you are a new manager with direct reports for the first time, then congratulations: you’ve just begun on the management track. In fact, most of the articles on this site describe in detail the many facets of this role so we won’t dwell on specifics.
As a manager, you’ll be concerned with increasing the speed and efficiency of the work that your organization (i.e. the part of the organization for which you are responsible for) delivers. But how do we measure the growth of an individual along that track? Andy Grove comes to the rescue (again) with
this succinct equation:
A manager’s output = the output of their organization + the output of the neighboring organizations under their influence.
Neat, huh?
The output of your organization
Looking at the equation, moving further up the management track is concerned with growing your team’s output and increasing your influence in your organization. Now, that’s interesting because it encompasses all those that report to you plus all those that you work with outside of your lines of
reporting.
A natural first step in growth is expanding the number of people, and hence direct reports, on your team. However, once teams get to a certain size, usually around seven, plus or minus two, the overhead of line managing all of those people becomes prohibitive. For example, allowing an hour a week
for 1 to 1s with each of your reports, that gives you almost a solid working day in those meetings every week, not including follow ups, day to day work and team meetings. Attention gets scattershot.
Growth in the management track beyond managing one team is to begin managing other team leads as well so that you have multiple teams reporting into you. If you have a small team, you can continue to lead it yourself in addition to managing other leads. You’ll want to make sure you have enough
to do; don’t make yourself redundant.
That’s the first half of the above equation covered: get more and more people and make sure that they perform really well. But what about the second half?
The output of neighboring organizations under your influence
Well, in addition to growing the size of your organization, you can also grow your influence in your company by sitting on steering meetings, contributing to strategic decisions, getting involved in hiring new staff, and so on. This half of the equation requires developing a feel for what is going on in your
company at any given time, and leaning forward and asking to contribute. In a later article, we’ll talk more about increasing your visibility at work.
The further an individual goes down the management track, the less time that individual has to get involved in the technical details. More emails and meetings, less code. This is an area of frequent tension for many engineers who have been promoted into management roles. I have seen engineers
move into management and then become extremely stressed that they cannot predictably get technical work done since they are frequently in meetings and being interrupted. Some begin to panic that their technical skills are not increasing as rapidly as before. This is why moving into this track
requires very careful consideration: it’s a different job being judged on very different criteria.
Managing one’s own time better may allow for some continued technical contribution, but I stress that there is also the need to let go of the way things were and fully embrace management: your own personal output is less important than the output of your team.
The individual contributor track
The individual contributor track, widely written about for many years, celebrates the engineers who want to hone their craft and become technical experts rather than going into management. Instead, it is a path where expertise and influence are the currency. A promotion from Junior to Intermediate (or
similar) into a Senior Engineer role over time is a clear sequence of steps along this track. Larger organizations have roles like Principal Engineer and Staff Engineer to further allow for progression and recognition for their most senior staff.
Although it doesn’t concern itself with management, progress along this track can still be looked at similarly to the equation above. The output of the individual is very clearly measured: they can work efficiently on complex tasks, often at an increasingly architectural level. They breeze through technical
issues and automate most tasks they encounter for the first time. They give crucial advice at the beginning of projects about how technical choices will factor into the cost of a product: from scaling to maintenance to the amount of time and risks involved in building it.
That’s the output of the individual covered, but what about the organization under their influence? For the engineer on this track, they can influence in a number of ways to show progression. For example, they could head up, or strongly steer, a self-organizing group in the company for their skill set
(e.g. the Scala group, or Hadoop group) and advise on developments and best practices. They could mentor and train other members of staff. They could review architectural plans for other teams that are not in their usual remit. They can advise on CapEx and OpEx spends through researching
different ways of building a new system. Their expertise ensures the right business decisions are made, which can result in the creation of a truly innovative new feature or product. Conversely, their analysis can stop a project from happening altogether, saving many years of wasted time and money.
Compensation
Ideally, there should be no glass ceilings in either track and no interdependencies. For a technology company, an extremely experienced individual contributor and extremely experienced manager both contribute at a high level. Thus, at a similar level of contribution, they should be rewarded similarly.
In the real world, this may not always be the case, and you can detect senior leadership bias here: a “pure” technology company may lean towards paying Staff Engineers higher than managers. A more corporate environment may value leadership over technical skills, and the higher ends of the
average pay bracket may favor those in management positions.
If you have easy access to the senior leadership in your company, then this is an interesting discussion to have with them. What do they value? Which skills are irreplaceable?
Moving between tracks
Many see the movement from the individual contributor track to the management track as a one-way street. I don’t think that this should be true at all. Until one has tried management, how can one be sure that it is right for them?
When promoting staff into a managerial role, a good approach is to set some goals with them over a fixed period of time. Then, after that period of time has passed, both the new manager and their own manager can mutually decide whether the role is working out. If it isn’t, they should be free to move
back to the individual contributor track, exactly where they were before. Likewise, managers who wish to move back to the individual contributor track should also be allowed to, assuming they have the correct technical skills.
This leads to an interesting discussion: how should pay be decided when moving from one track to the other? In my eyes, it depends on the value that the individual is contributing to the organization. If an experienced long-time manager wants to move back to the technical track but will take a long
time to become a net-positive contributor because of retraining, then I don’t think that it is unreasonable for them to take a pay cut if they are going to be dramatically overpaid compared to the rest of the team.
Conversations around trajectory
If you’ve not had these kinds of conversations about the two tracks with your staff, then it’s highly recommended to begin them as soon as you can. Having them explore their intentions early on means that you’re able to begin supporting them in moving towards their goals. Left undiscussed, your direct
reports may not know that there are opportunities to move both upwards (along the same track) and sideways (to a new track) within the current organization, and in the worst case, they may feel that the only way to do so is to get a new job.
I’d advise against going into a full career planning session with them immediately, but instead, begin to weave the conversation into your 1 to 1s. As a manager, what could you delegate to a member of staff interested in learning the ropes of management? This could be a mutually beneficial exercise.
Equally, could you begin a mentorship between a junior engineer interested in becoming a senior individual contributor with someone of similar stature in your department?
Attracting people to work for you
It’s not just the technology
It may be straightforward to look at the best companies of recent years and deduce that they succeeded due to having the best technology. There’s probably a lot of truth to that hypothesis. However, who created that technology? It was the people. The most
successful companies manage to attract, hire and keep the best people available. No matter how grand the vision of the founder is, without the right people, this vision will never become a reality.
As a manager, hiring is something that you’ll be doing a lot of. It sometimes can feel like a drag, especially when the interviews aren’t yielding any result. However, getting the right people into the company is essential from both a technical perspective and a cultural
perspective, so it deserves your careful attention and time. After all, since you are being judged by the output you delegate through your team, you need to make sure your team has top-notch people.
We’ll spend time looking at the actual hiring process in a future article, since to go through that process you’ll need people to have applied. The question is how do you get the best CVs through your door?
Generally speaking, there are four broadly different ways of attracting new people.
A potential candidate could be:
•An unknown direct applicant: they’ve found your job somehow, perhaps online. They like the look of it, and they’re now applying.
•Headhunted: they’ve been approached directly because of their skills and have been convinced to apply.
•A positively-affected direct applicant: They’ve had a good experience with your company (e.g. they’ve attended a community event, or worked in partnership with you, or could be a client), and have therefore become a direct applicant.
•A referral: a friend or ex-colleague (or both) of a current employee that has made a recommendation.
Let’s look at each of these routes into applying.
Direct applicants
These are the people who have found the role themselves, with little experience or knowledge of your company prior to doing so. Depending on the specificity and seniority of the description, you may get few or many applications. You might get lucky, you might not.
I’d recommend against relying on this as your only method of locating new talent.
Tech giants such as Google, Apple, and Facebook have ubiquity in the industry and are thus guaranteed a steady flow of applicants. People just know them, right? You may work for a less high profile company, or be at a tiny start-up stage, and may be struggling to
stand out. This is an increasingly difficult problem in the current market where the number of available jobs dramatically outweighs the number of highly talented job seekers. It’s an especially compounded problem in world-leading cities such as London, New York,
and San Francisco.
In order to increase the number of direct applicants, there are some levers that you can pull. Firstly, make sure that you’re writing good job descriptions. Steer clear of making them too audacious or silly: despite a start-up saying it wants to hire a “rock star”,
many, many people will be put off from applying due to this language. Keep them light-hearted, simple and professional. Make sure you focus on what the candidate can experience and learn by coming to work for you, rather than demanding a strict list of skills. This,
again, can put people off, and prevent more inexperienced but extremely talented candidates from applying. Unless it’s a specialist role, don’t expect all candidates to have used every technology you’re using. Instead, look for bright people who can adapt and are
excited about learning new things. It’s more intriguing to read that you will learn to work with petabytes of data, rather than expecting to be already experienced at working with petabytes of data. Don’t confuse what the job entails with what they are expected to have
as a pre-requisite.
Secondly, get your job out there on as many boards as possible. Typically, most global boards such as Stack Overflow cost money, so you’ll want to do your research on the prices to see if it’s worth your time. Also, check to see how many other similar roles are
posted on these sites to see if you stand a chance of people noticing. If you’re hiring for a specialist role, find others in that community and ask where the best place is to advertise. Specialists may all subscribe to a particular mailing list or forum. Posting to these
niche lists can sometimes be (nearly) free. There are also frequent threads on Hacker News asking who is hiring that can be posted to for free, but do make sure you post in such a way that fits in with the community frequenting the site: don’t be a spammer.
Headhunting and recruitment agencies
In order to accelerate the process of finding good candidates, you can approach a recruitment agency to widen your search and cross-reference it with the job seekers they already have on file. There are many recruitment agencies and their quality varies greatly.
Always get a recommendation, if possible. If you don’t have any colleagues to give you a recommendation, then take to Twitter and find people in your area (both geographically and via their skill set) to lead you in the right direction. Choose carefully, because
dealing with bad recruiters can be painful: each bad interview with a candidate who hasn’t been properly pre-screened wastes your time.
Don’t sign up with a recruitment firm before meeting them first. Ideally, meet them in person. By inviting them to your office they’ll be able to get a feel for the culture of your company. Get a list of what they believe their best candidates are at the moment and
understand their approach to finding people. Ask them frankly how many other similar companies they are working with, and how you can guarantee that you are going to see the CVs of the best candidates that they find.
Headhunting activities can be carried out by agencies also; some specialize in it. This method is especially useful for niche and very senior roles, as an agency will have a network for that niche to pull from. If you are thinking of having an agency head-hunt for you,
make sure they explain their process. These agencies are acting as an extension of your own company’s culture, so you want to make sure that potential candidates are being treated with respect; not being pestered. You can also take head-hunting into your own
hands, by having influential members of your own engineering staff personally get in touch with interesting-looking candidates at other companies.
Community outreach
A positive method of increasing the visibility of your company locally is by getting involved in community events and meet-ups. I’d advise against sponsoring conferences if you have a limited budget. Just having your name on the banner next to the stage doesn’t give
any guarantee that attendees will even notice, let alone think of applying. Instead, think about how can you do something impactful for your local community.
We have had great success in Brighton by helping organize Brighton Java. All it costs is a little bit of time, some drinks, snacks and our office space for one evening a month. Not only does this get local technologists into our office and meeting our staff, which is very
helpful for visibility and recruitment, it also helps us give something meaningful back to the community. If you are in a big city then it may be harder to devise a new meet-up that isn’t already catered for, but you can contact the organizers of other meet ups and offer
your office space, money for drinks and snacks, and staff to speak at the event. We have also had great success in hosting the Codebar initiative and offering mentorship through it.
Community outreach is not a quick-win solution to hiring. In fact, if you go into it with the primary purpose of hiring people, you are going to have a shallow experience and you may turn attendees away in the long term. Instead, go into outreach with the goal of giving
back to the local area and fostering the community. Recruitment is a side effect of the long game.
Referrals
If you’re hiring high-quality people, then it’s very likely that they’ll know other high-quality people too. Capitalize on this. Hiring known entities can have a very positive effect by sustaining the current culture: staff are unlikely to refer people that they didn’t enjoy
working with.
I wholeheartedly recommend a referral scheme for your staff. By offering a monetary incentive, your staff will more actively think about the best people that they’ve worked on over the years and get back in touch with them. Otherwise, it can be difficult to motivate
people to take the time to revisit old work relationships with those they are not close fiends with.
There is one aspect to warn against here: referrals can easily decrease diversity within an organization. Make sure that those interviewing are aware of whether a candidate is a referral, and if hired, be careful of their placement into teams. Too many referrals landing
in one team can create cliques and be detrimental to the wider department.
In summary
Doing interviews: the other side of the table
Let’s talk about the interview process
Tech company interviews have become the stuff of legend. Tales of impossible questions, nerve-wracking whiteboard coding, bizarre brain teasers, you name it: the Internet is full of examples of strange and wonderful experiences during interviews at leading technology companies.
In this article, we’ll explore some of the aspects of interviewing candidates that I feel are important. Some of these aspects have no definitive answer or best practice, but I’ll offer my own opinions on what I think works and what doesn’t. A lot has been written on the process of technical interviews from the side of the candidate. I’d like to explore what
it’s like to be on the interviewer’s side of the table, where you may need to define and run this process yourself.
Let’s start with the obvious stuff: why do we do interviews? Well, we’re looking to make a decision as to whether we would want to work with that particular person. Can they help our company succeed by bringing themselves and their skills into the organization? I divide what we, as a technology company, are looking for into three major facets:
technical skill, culture fit, and their suitability for the role that they applied for. How can we perform interviews so that we can find these characteristics out as quickly as possible, whilst leaving the candidate as happy as possible with the experience, regardless of the outcome?
How many interviews?
I’ve read horror stories of candidates wading through over ten interviews before being offered a job. This may be a luxury that larger companies with full candidate pipelines can afford, but my own experience of hiring candidates into smaller organizations, especially at the start-up or small business phase, is that candidates are often interviewing at
numerous companies – a number of which that could be more widely known than you – so having a fast and efficient interviewing process is beneficial to both the interviewee and the interviewers. It demonstrates that you’re efficient and, most importantly, that they are wanted.
When interviewing for niche or very senior roles, you may not want to follow a particular template. However, for most engineers at varying levels of experience, I have had success with an interview process consisting of two to three stages: two actual interviews and one optional take home test. The take home test is not given to all candidates; it’s used
when there is limited evidence of their coding ability (e.g. graduates; those who are unable to put lots of their work on Github; or those changing their primary programming language) or if we are on the fence about their ability.
Some companies do more, or less, interviews. I can’t vouch for the success of approaches that are wildly different to what I outline in this article. For example, Google and Facebook have been known to do intensive day-long sessions of about six interviews, but I do not have any data on whether this reduces the false-positive rate for quality compared
to the process that I am used to following. I do know they make candidates quite intimidated, however…
The structure that I have been using is as follows:
•1st interview: here, both parties are getting to know each other, and we are assessing cultural fit. The hiring manager is present here along with another person if they wish to bring them along. This is typically a member of staff on their team, or someone with a similar skillset from elsewhere in the organization.
•Optional take-home test: a fairly open-ended coding challenge that allows the candidate a number of different avenues to showcase their ability in a self-directed way.
•2nd interview: a technical deep dive with people who would be peers of the new hire. For example, if the hiring manager is the team lead, the 2nd interview would be with 2 of their engineers.
Let’s have a look at each of these interview stages in turn.
Interview 1: Getting to know you, and cultural fit
The first interview is where the candidate (usually) is the most nervous. One important thing to remember is that no matter the outcome of the interview process, even if the candidate is nowhere near experienced enough for the role, they should come away thinking that your company is a great place to work and that they would reapply again in the
future. I cannot stress this enough. Be nice. Interviews are not a place for you to show how clever you are. It should be the opposite.
In this interview, it’s good to stay broad and let the candidate do the talking. This uses a similar technique to the one discussed in our article about 1 to 1s: listen, nudge and absorb. Some good questions here are:
•Tell me about your current role and what you’re currently working on.
•How did you get into technology/computer science?
•What’s the most interesting piece of technology at your current company?
•What’s the project that you’ve been most proud of? What made it great?
•What’s the worst project you’ve worked on? Why was it the worst?
•What’s the most interesting open source project out there at the moment?
These questions are just a sample, but the idea remains the same: you want to allow the interviewee the space to talk and tell their story, allowing them the chance to put aside the nerves and let their true everyday selves show. Along the way, you’ll begin to get an idea of what motivates them: is it technology, people, business, or all three? Do they
enjoy being hands on or do they tend to delegate tasks to others? Are they well-read on the state of the art, or are they working at a company that has limited their technical choices? Are they aware of them at all?
I also like to try and assess their analytical brain: for example, if they mention that they worked on a file transfer application, probe deeper: what protocols were they adhering to? Did it support multiple concurrent connections? Did it have to deal with the out-of-order delivery of packets? How were the consistency of the transferred files checked?
Excellent candidates would have these thoughts whizzing through their brains while they were doing the project, even if they didn’t need to implement all of it.
At the end of the first interview, I assess the candidate around three areas:
•Technical knowledge: does this candidate impress with their technical prowess when their years of experience are factored in? Remember that seniority is not just years under the belt.
•Cultural fit: would I be happy sitting next to this candidate and working with them every day? Would I be equally happy grabbing lunch with them and talking about something other than work?
•Suitability for the role: do I feel that the current role is right for them? Are they too junior and therefore need more mentoring than we can offer right now, or are they too senior which means that there is a risk of them getting bored?
If those three areas are satisfied, then I use one final check: if the hiring committee was on the fence and I had to argue the case for this candidate with the CTO, which way would I think he or she would swing on their judgment? I find my gut feel is usually correct here. Imagine yourself presenting this candidate to your own manager or even your
CEO: would you argue their case if your own reputation depended on it?
Optional: take home test
Depending on the candidate, I’ve found it useful to give a take home programming test. Let me stress that we treat this as optional, as the need for it varies from candidate to candidate. If we are recruiting a very senior member of staff who is prolific on Github, then it’s unnecessary. The evidence is clear. However, if we don’t have a lot of evidence of
their coding ability, which is especially true of graduates or very junior candidates, then it can be helpful to see how they tackle it.
I won’t reveal exactly the coding challenges we use, but we don’t set ridiculous brain teasers that require intricate knowledge of bit-shifting. That’s not an accurate reflection of day-to-day work as an engineer at a SaaS company like ours. Instead, we have written a toy system that performs some basic functionality, and then specified a variety of
different ways that the system could be improved. For example, there is a list of new and improved functionality that could be added, a whole host of tests that could be made better, refactoring that could be done, and documentation that could be written. We let candidates know that they can take any of these areas to any level of depth that they like.
We’ve had some very novel submissions this way, and it doesn’t pigeonhole our successful candidates to be the ones best at solving advanced exercises in Knuth’s The Art Of Computer Programming. Our toy system performs some functionality that our real system does, which makes it much more interesting to the candidate as well.
Once they submit the coding challenge, we have it forwarded to an internal mailing list that our engineers monitor. They are encouraged to volunteer to review it and give positive and negative feedback and a recommendation as to whether they should proceed in the interview process. Those that do not proceed still get the feedback so they can
understand why we decided not to continue with their application. Again, candidates that fail at this stage should still feel that the company is fair and supportive, and they should feel that they could improve and reapply in the future.
Interview 2: let’s get technical
At the second interview stage, we invite two people who would be peers of the candidate in the organization. They can spend this interview getting deep technically and working out whether they would like to have the candidate working on their team. To add some continuity to the interview stages, if they have succeeded at a take-home test, then
beginning the interview by talking through it is a great way of making them feel comfortable (after all, they’ve already succeeded!) But, inevitably, you’ll need to do some technical exercises together.
At this point, the candidate has already had an opportunity to show you the kind of code that they write, either by completing the take-home exercise or by sharing their Github with you. The success of the technical interview isn’t hinging on them working out the correct answer for all of the problems that you set (although that’s nice also!), but instead,
you’re looking to see how they work on problems in person, and also how they communicate with others when doing so.
I would recommend either using a whiteboard or using an IDE of their choice on a computer, but these two workspaces are used for different types of interview question.
Firstly, whiteboards. There are many horror stories online. The nervousness of standing up in front of interviewers; accidentally leaning on the board and getting covered in ink; sweating so much that the pen rubs off; you name it, it’s happened. The truth is that whiteboards aren’t for everybody. They also suit a particular style of problem. For me, these
are questions that involve drawing an architectural diagram of a system, describing the steps of an algorithm, or writing in a loose pseudo code style. Expecting whiteboard code to be transcribed and then compiled successfully is missing the big picture of the exercise: understanding the candidate’s thinking process. I also encourage standing at the
whiteboard with the candidate and working with them by asking probing questions, rather than sitting there silently making notes while they have their back to you.
Good whiteboard questions could be:
•Imagine you’re building a chat application from scratch. What would the architecture of the system look like, and how would you build it?
•Imagine that you’re writing a Java method that is being given tweet objects in real-time. How could you keep track of the user that has tweeted the most?
Whiteboards are not where your engineers are going to be writing most of their code in their day job. If you want to do an in-depth coding exercise in person, then a good technique to use is pair programming on a computer, just like they would if they were working with you. Ask the candidate ahead of time what their OS and IDE preference is and get
the computer set up ahead of time. You can then spend some coding together. Even better, you could try and fix a real bug in your system. This will give good insight into how they think, work, use git (or similar) and organize themselves. Try and have some fun while doing it too.
Deciding whether to make an offer
Once both interviews have been done, you should have feedback from all of your interviewers. We have most recently been asking for a score of 1-4 along with written notes. All notes should be written in such a way that if they were revealed to the candidate they would learn how to improve rather than be offended. Keep in mind that in the
UK, candidates can request feedback via the Data Protection Act.
•1 – Definite no hire: The candidate was definitely not right for the role, or didn’t demonstrate the experience required.
•2 – Marginal no hire: The candidate may have been a consideration, but there were red flags during the interview that would result in us arguing against their application.
•3 – Marginal hire: The candidate performed suitably, but didn’t impress enough to make us instantly want to offer them the job, however, we would argue their case.
•4 – Definite hire: The candidate was excellent, and we would be silly not to hire them right now.
As an interviewer, there is an internal emotional conflict between being nice and doing what is right for the organization. When faced with this situation, you have to leave as much emotion at the door as possible. If you feel like you want to give a candidate an opportunity because their poor performance could have been due to nerves, but you know,
truly, that they are not meeting your standards, then you need to suppress that emotion and reject them. It is much easier to break bonds with a person at the interview stage than it is after you’ve hired them and are struggling on critical projects.
If the consensus averages on a high 3 or a 4, then go ahead and make that offer. If the average is a low three, then get together in a room and debate. Any lower than that and it’s a no. There are of course other factors such as the market conditions and the number of candidates that are, and are predicted to be, in the pipeline. It’s never easy: a
candidate with a few reservations may actually be the best you’ll see all year for that role. But how do you know? Well, you don’t. You can only make your best judgment at any particular moment in time. Good luck.
When people leave
Have you got a minute?
We’ve all been there.
For the first time in a while, you’re having a pretty good day. You’ve not had many interruptions and you’re making measurable progress on the things you need to be working on. All of a sudden, Alice, who’s one of your stars, walks towards your desk and makes eye contact whilst raising her eyebrows.
“Have you got a minute?”, she says. “Sure”, you reply, whilst leaving your chair and heading towards the nearest empty meeting room. You notice that something feels a bit odd. You wonder why. Then you enter the room following Alice and let the door click shut behind you. The air feels heavier than
usual.
“What’s up?”
“I… just wanted to let you know that I’ve been offered a role elsewhere. It seems like a great opportunity, so I’d like to tell you that I’m handing in my notice and I’ll be leaving.”
Your day isn’t going so well anymore.
How is that project going to get delivered without Alice? She was critical to getting the new infrastructure rolled out! How are Andy and Ben going to react as they get on so well with her? Will they follow her to this new place? How are you ever going to replace her? Why would she ever want to leave?
It happens
People are always going to leave. It’s normal and it sucks. It especially sucks if you’re a manager. Your output and performance is very much dependent on your team: you want to make sure that you’re staffed with great people since you know how hard it is to find talented folk, especially if you’re
operating with a limited budget.
These days, we can’t expect people to stay at their job indefinitely, especially in the technology industry. Depending on how much you’d like to believe this article, the average tenure at the top 10 technology companies is between 1-2 years (2017 data). My parents would certainly be shocked by that
statistic. My father’s last job before he retired had him doing 18 years of service. In this new world where everyone is always going to leave, how can we hope to make the best of the situation? How can we adjust our own expectations and feelings about people leaving to make the situation as painless
as possible?
Firstly, let’s embrace that previous sentence again. People are always going to leave. It’s normal and it sucks. Just read it a few times and let it sink in. As a manager, you are doomed to failure if you think that you are going to keep everyone in your current team indefinitely. You will only set your
expectations as such that you will feel terrible when someone does hand in their notice. Be comfortable with the fact that all of our careers are different and we are all motivated by varying aspects: challenge, location, comfort, working hours, programming languages and frameworks, friends, and new
opportunities to name but a few. They can all be conflicting forces in life decisions.
The best that you can do as a manager is make sure that people are leaving for positive change. Focus all of your attention on making sure that people aren’t leaving for bad reasons, and let them depart with amiability and your blessing.
Good reasons for leaving
Our lives are more connected, varied and challenging than they have ever been and this is especially true in the technology industry. There is more societal pressure on those at the start of their career to get the best experience they can get, no matter where it is. I see engineers bouncing between
companies and cities at intervals similar to those suggested above. You can’t hold people back.
Likewise, in an economy where house prices are continually rising, having just one person in a relationship working full time is much less likely, especially if both parties are in similar industries. There exists the two-body problem for academics, which highlights the struggle faced by a couple when trying
to find tenured academic work where they can still live together as a family. For technology and creative jobs, we are not limited as much by the lack of opportunities, but couples can face the tension between being able to do the job they really want and the location they want to live in. Our career drive
often throws a grenade under our natural human instinct to settle.
Those that you are managing are always assessing which other opportunities are out there. When faced with someone telling you that they are going to leave, you can be quick to get angry and think that your employee is giving you another problem to deal with, that they are ungrateful of their position,
that they’re just chasing money or prestige, or that they’re taking the easy way out of a hard year at the company. This is rarely the case. There are many legitimate reasons that people leave which show no malice towards you as their manager. For example:
•New opportunities: sometimes there is no room for an employee to be promoted any higher in your department so instead they’re going to do that role elsewhere, or they wish to join a company where there is more room for that role to be created, such as an early stage start-up in a phase of fast
growth. Additionally, they may have worked at your company for a long time and just fancy a change in surroundings and the type of work that they are doing. Maybe an opportunity has come up to work with their best friends. That’s totally natural, and it’s not your fault.
•Family: their partner may have been offered a job of a lifetime elsewhere and they need to relocate and find a new job nearby. They or their partner may have aging or sick parents and need to leave to offer the right level of care, especially if their family are not local. They may want their kids to go to a
particular school, perhaps because their child needs a particular education, either through learning or physical disabilities or maybe through academic brilliance. You can’t control these things, so just let them be.
•Compensation: sometimes they are in the right industry at the right time and get offered a life-changing compensation package elsewhere: the sort of package that could mean they could retire 10 years earlier, or that their partner could quit their job, take a year off and then start their own business.
That’s just the nature of a free market economy, and as hard as it is, just be happy for them. It’s a nice thing.
In these situations, you have not done anything wrong. There is a swirling and complex web of life outside of work that pulls and pushes people in a multitude of directions. Become the facilitator here. Focus on negotiating a date for them to leave, what sort of work and knowledge they need to hand over
and to whom, and on beginning recruitment for their replacement. Always offer a reference if needed, either formally or through a network like LinkedIn. Keep it amicable, because the industry is closely connected and you may just end up working with this person again in the future. Leave the door open
and the mat out.
Bad reasons for leaving
Sometimes, people leave for bad reasons. I am excluding them being let go because of bad performance because as a manager, that is a process that you have initiated and are driving through. The bad situations I refer to are the ones Andy Grove called “zingers”. What he was describing was the
situation where you are caught completely off-guard by someone handing in their notice, insofar that you know in retrospect you could have prevented it from happening. Often they have a similar root cause: a lack of open and honest communication from both parties which results in simmering issues
not being caught early. Some examples of these issues are below.
•Compensation: your direct report was unhappy with their end of year pay rise, yet they felt that they were unable to talk about it openly. They got continually more annoyed to the point that they answered that email from a headhunter and went for an interview elsewhere. You found out about this for
the first time when they had accepted the other job offer, giving you no opportunity to try and rectify this pay issue over time.
•Issues with coworkers: your direct report simply cannot stand one of the people on their team, and every day over the last six months has been immensely frustrating for them. They don’t have any issues with their coworker’s work; in fact, it’s very good. However, their personalities clash badly and
they didn’t want to raise it to you as they felt it was a personal issue rather than a professional one.
•Career progression: the notice is handed in because they have been offered a team lead role at another company. They cite that there were no opportunities for promotion in the department. However, you know that in a few months a new team will be starting and they would have been a good fit. You
didn’t even know they were interested in being a team lead!
•Lack of challenge or new work: they are very bored of writing code for the API, and would love to increase their skill on high-throughput data ingest. They didn’t feel like they could ask to move team, as they felt that they were employed for the role that they are currently doing. You, however, know
that they could have just asked to move team. Why didn’t they say anything? Why are you now holding their notice?
The root cause is the same: a lack of open and honest communication. Once somebody has accepted a job offer elsewhere, it becomes much harder for them to back out: it’s a tricky and embarrassing situation. Many of the other articles on this site beat the same drum: keep close, open and honest
relationships. Be interested in your team’s life outside work, in their emotions and their hopes; both for their life and their career. Many clues will surface that you can use to keep your staff happy. You might just prevent people from leaving.
Negotiation?
If someone has surprised you with their notice, then one tactic that you can use is to negotiate some changes to their role that might keep them at the company. These might be a change of team, an increase in pay, more flexible working hours, extra time to do personal projects, and so on. For good
leavers, negotiate all you like, however, if you have a good relationship with your direct report then you should probably have seen their notice coming: e.g. you knew about their life situation changing already, and your negotiation comes from a position of trying to help them more so that they are more
likely to stay with you.
For bad leavers, try to gauge how far gone they already are. My own advice here would be to exercise caution. They likely would have sat on their issue in silence for a long time, and whether you like it or not, their trust in you and the company may have eroded significantly. For the effort that you will
have to go through negotiating (i.e. removing an open headcount to create the budget to make a counter-offer, switching people around on teams at short notice to allow a team move to happen), you may end up in the same situation that you’re in again in the future. Mentally they may have already
changed job, and reengaging a disgruntled employee can be very difficult. It’s your call, but be careful. They are not quite the same person that you hired.
And you’re still there after all
Whether your staff are leaving for good or bad reasons, you’re still there, and that can feel upsetting in the same way that it does when you lose a friend. It can be easy to feel isolated, or betrayed, or that you’ve let someone down to the point that they have departed.
Remember that if they leave for good reasons, it’s not your fault. If it’s for bad reasons, then you’ve learned a lesson and you’ll do better in future with everyone else on your team. And if you’re still feeling low, confide in other managers in your organization. They’ll have been there before.
You have a duty to facilitate others towards their career happiness, even if that happiness is found elsewhere and without you. It’s hard, but you’ll be remembered as a good boss.