The Engineering Manager

Since my November article on being in the details, I’ve had a few people ask me about the system that I use in order to do so. In my first book I went into great detail about how I manage information and stay organized. On reflection, my approach has evolved since then, so I thought it would be a good time to revisit the topic.

The system that you use to organize your activity becomes your mental model of how you do management. Therefore it should reflect how you work and how your company works, and produce the outputs that you need to be effective in your role.

This, of course, means that what works for me might not work for you, and vice versa, and that’s OK. The key is to have a system that you trust and that you use consistently to get the outcomes that you need.

At the time of writing, I’m in an engineering leadership position at Shopify, which is a fully remote company with a culture of minimal meetings and a preference for asynchronous communication. This clearly has an impact on how I work and how I manage information, especially when compared to my previous roles at companies with an office-based culture.

For example, I now no longer need to keep a notepad handy to jot down things as I’m walking around the office (I’m at home), nor do I get to exercise my preference of using wonderful, searchable, archivable email as my primary communication tool (everyone uses Slack instead; you can’t win them all).

Although my approach has evolved over the last few years, the fundamentals remain the same:

• Management of large organizations can quickly become overwhelming and messy if you don’t have some way of managing the information that you need to keep track of.
• Your memory does not have a large enough working set to reliably keep track of all the information that you should have close to hand. If you think it is, you’re likely unaware of the things that you’re forgetting.
• No matter how good the tools are that your company provides, having your own system that you trust and have complete ownership of is essential: it won’t disappear one day because the company decided to switch to a different tool.
• The system that you use should be simple and easy to use, otherwise you won’t use it.
• The system should also be flexible enough to adapt to your needs as they change. If one busy day blows your system out of the water and you become ineffective, then it’s not a good system in the first place.

This article will be about more than just the software tool that I use, even though it is central to it. Instead, I’ll focus on the way using this tool allows me to categorize the way that I work into tight loops of gathering, deciding, and executing. This is a mental model that I’ve found to be very effective in managing my day-to-day work, and enables me to keep the pace high for myself and my team.

This gather-decide-execute loop that I run has some similarities to other loops that exist in the world of strategy, such as the OODA loop. Similarly, good technology companies are ones that move through the build-measure-learn loop faster than their competitors. I’m trying to do the same thing, but with the information that I need to run my organization effectively.

Gathering: the inputs to your system

We’ll begin with the always-on process of gathering information. There’s a couple of maxims I find useful here:

• There’s a difference between information and knowledge. Information is raw data, while knowledge is information that has been processed and understood. I aim to build up a store of knowledge that I can use to make decisions, and this is done through active note-taking.
• Gathering information is an active and ongoing process. It’s not about letting things come to you, but instead, it’s about being in the details and actively seeking out the information that you need to do be effective. I pull on threads and I ask questions to learn more about the things that I need to know.

The main change in my approach in recent years is that I am now a heavy user of Logseq as my primary tool for both note-taking and task management. If you’ve not used second-brain software like Logseq, Obsidian or Roam Research before, it’s a bit like having a personal wiki that you can use to store all of your notes and tasks in a way that is easily searchable and linkable.

For example, you can reference pages in your notes like [[this]] and Logseq will automatically create a link to that page (and create it if it doesn’t exist), generating a network of information that you can navigate. Each page shows backlinks, so you can see all the other pages that reference it, and you can also see a graph view of all the pages and how they link together.

If you’ve not tried one of these tools, give them a go. They’re free.

I consider myself to be in gather mode all of the time. My job, like many others, involves being subject to a firehose of information via email, Slack, project management software, and (minimal) meetings. The way that I approach this is that I always have my Logseq window open on the right-hand side of my screen (by typing last fourth in Raycast), and I try to capture anything important that comes my way as soon as I see it. Similar to revising for an exam, the act of summarizing what I’m seeing and writing it down helps me to remember it better, even without searching for it.

I have a few key flows that I use to organize my notes:

• Logseq defaults to a daily journal page, which results in a new page being created for each day. I use this for freeform notes that I may never read again, but that I want to capture in the moment. This is more about the habit of note-taking for memorization than it is about creating a useful artifact.
• For things that I need to do, the neat thing about Logseq is that you can create TODO items that render with a checkbox. You can search for all of your TODO items across all of your notes for an adhoc task list, or even better, you can schedule them to appear later on a specific day (try /schedule to bring up the date picker, where you can also create repeating tasks).
• For more permanent notes, I have a page for my team and sub-teams, where I keep long-lived references to key dashboards, links to key documents like roadmaps, sub-pages for notable projects, and so on. This is the kind of information that I want to be able to find quickly, and that I want to be able to link to from other notes.
• I also use hashtags to categorize some of my notes for summarization later. A great use case for this was shown to me by my colleague Victor who uses a #highlight tag to generate weekly brag docs for his manager. You could use tagging for specific notes about particular projects (e.g. #widgetupgrade), or links to articles or papers you may want to browse later without saturating your to-do list (e.g. #toread), or making it easy to send out a weekly update to your team with things you’ve observed.

Aside from tools, I also have a few habits and behaviors that help me to gather information effectively:

• When interacting with others about a new or complex topic, I tend to summarize what I’ve heard back to them in my own words to make sure that I’ve understood it correctly. For example, “So what you’re saying is that we need to do X, Y, and Z in order to achieve A, B, and C?” Not only does this help me to understand the topic better, but it also can highlight where there are misunderstandings or gaps in what is being communicated. I’ll then capture this summary in my notes.
• I try to fight against a natural reduction in skepticism over time. When you’re new to a topic or a team you’re more likely to ask questions and challenge assumptions, but over time you can become more complacent. I’ve learned that not only does a healthy dose of skepticism help to keep you sharp, but it also helps to keep your team sharp too. If you’re always asking questions, then your team will be more likely to do the same. You can even ask these questions of yourself in your notes to keep exercising that muscle.
• I heavily use LLMs to expand my knowledge of topics as I read about them, and to act as a managerial rubber duck when I’m trying to work through a problem on my own. For example, when reviewing a project proposal or a design document, describing it in my notes helps me to understand it better, and then those notes can be used to have an LLM help me to refine my understanding further by generating questions or challenges to that approach. For example, GPT-4o is very good at reminding me of potential security concerns with ideas. I can then use this to inspire more critique. And don’t worry, Shopify provides us with internal LLMs that are safe to use with our data.

Deciding: gathering becomes actionable

The next step in the main activity loop is deciding what to do with the information that has been gathered. Being an effective manager is not just about having a lot of information, but using it to bring about greater change. Fundamentally, this is where you can add a ton of value.

As I write notes in my gathering phase throughout the day, I try to periodically review them to decide what to do with them. For each part of my notes, I ask myself:

• Is this purely a note that I’ve made to help me understand and remember? If so, I can probably leave it where it is.
• Is this information part of a larger project or initiative that I have distinct pages for? If so, I move it to that page.
• Is this information incomplete in some way, or do I not actually fully understand it? If so, I need to ask more questions or do more research. I’ll tag that note with a #question tag to remind myself to come back to it later. I also have a #research tag for things that I need to look up and read in more detail.
• Is this information something that I need to act on? If so, I’ll consider what needs to be done, and then convert it into a TODO item with a scheduled due date.

That’s all fine and well for formulating my own decisions explicitly about what to do next with my own work, but there is also the ability to make implicit decisions that improve the work of others.

How do you do that?

Well, a skill that I’ve been practicing is trying not to accept any information that I have entirely on face value, and instead see if I can insert myself as a critical thinker that can find improvements. What I mean by this is that I try to ask myself if there are any assumptions in the information that I’ve gathered that I can challenge, or if there are any questions that I can ask that might lead to a better outcome.

A good rule of thumb to judge your progress in a system like this is by measuring what proportion of your gathering turns into decisions and actions that you then take. If you act on a lot of information that you’re gathering, then you’ll find that you are tuned into the right things and that you’re adding value. If you’re not acting on much of what you’re gathering, then you’re probably not gathering the right things, or you’re not being critical enough in your decision-making.

Maybe this is best explained by example.

Let’s say that I am reading through a project proposal and making notes while I do so. This proposal is for a new feature that we want to build, which is a new widget that will be displayed on our website. It outlines a technical approach that the team wants to take, and the expected impact that it will have on our users.

There are two ways that I could approach this:

• I could treat this as purely a gathering exercise, and just note what this team is going to do and what they expect to happen. I could then move on to the next thing.
• I could proactively engage with the proposal, and see it as an opportunity to further my understanding of the project, be more sure that we are making the right decisions, and therefore add value for myself and the team. I could press on alternative design choices, ask for more detail on how this scales during peak traffic load, or I could go back to first principles in order to question anything that I consider to be an assumption.

The second approach is the one that should be aimed for. It’s actually something I do with my direct reports: when reviewing project proposals I list out my thinking process and questions in my notes, and try to challenge assumptions where I can. This almost always generates dialogue that leads to a better project outcome.

Even if you aren’t making an explicit decision, using your gathering phase as an opportunity to engage with the information, attempting to raise the bar for quality, brevity, and clarity makes you a more effective manager, and quite frankly, just makes work far more fun. Implicitly, this increase in engagement will lead to better decisions from those that you are interacting with since you know you are holding them accountable to a higher standard.

Executing: getting things done

The final part of the loop is executing on the decisions that you’ve made. Effectively this breaks down into two parts:

• Executing on the decisions and tasks that you’ve made for yourself.
• Ensuring that everything that you are accountable for via others is making progress.

The first part is fairly simple. If I have a discrete task that I need to do, then I’ll have made a TODO item for it in my notes, and I’ll have scheduled it for a specific day. Then it’s just a case of working through my to-do list, which is straightforward and doesn’t need much explanation.

The second part is more nuanced and less solvable with todos. As a senior manager, there are tons of conversations, decisions, and actions that are in flight at any one time that I need to be aware of. These can’t be captured as discrete Boolean tasks.

What I’ve been doing to ensure that I don’t drop the ball here is utilizing the tagging that we covered in the gathering phase. I have a #chase tag that I use to flag anything that needs to be kept in my working memory on a given day. This means that I can then search Logseq for all of the #chase items that I have, forming a different kind of to-do list that is more about keeping track of the things that I need to follow up on or monitor, rather than the things that I actually need to complete.

Examples of things that end up on my #chase list are:

• Actions that I’ve asked others to take, such as finding out information, having conversations, or getting consensus.
• Reminders to go and check on data each day to see how something in progressing, such as metrics after a new feature ships, or ongoing incidents.
• Escalations that we are waiting on a response for, such as a priority decision for another team, or a decision from a stakeholder.

These are all non-Boolean tasks; effectively it’s me periodically refreshing my mental cache. The chase list never really gets to zero, and nor should it. It grows and shrinks fairly organically. By separating out discrete TODO items from #chase items, I can aim for inbox zero on my to-dos but I can also keep a continual eye on the more complex and nuanced things that I need to be aware of.

I hope that this article has given you some insight into how I manage my day-to-day work, and how I use the gather-decide-execute loop to keep on top of things. If you run your day differently, I’d love to hear about it in the comments.

If you’re more interested in what a senior management role looks like in technology, then my latest book will be of interest to you. Become a Great Engineering Leader is available as a DRM-free eBook or in print from your favorite online bookstore.

And if you enjoy my writing every month, then a paid subscription via Substack is a way of supporting me to keep the caffeine flowing.

Until next time, happy note-taking!

Over the last few weeks, I’ve been taking some time to step back and think about what I’ve seen, felt, and learnt this year so I can share it with you. 2024 has been a wild ride.

Not since the smartphone boom period in 2007 have I seen so much change happening so quickly. We’ve seen the culture and growth of our companies changing due to the macroeconomic climate, a proliferation of LLM-based tools and technologies, and, fundamentally, as leaders, we’ve had to change how we think about our roles and our output.

What has held true in the last decade may not hold true in the next. Let’s take a look at each of these areas in turn.

Efficiency Is Key

Let’s start with culture. If there is one theme to highlight as we head into next year, it would be efficiency.

I have written before about the increasing need for managers to be in the details as we ride out this current macroeconomic period.

The economy is presently characterized by less cheap debt and investment being available, and the knock-on effect is that there is less growth and a more challenging environment for startups.

If you work for a bigger company, you will likely see headcount staying stable so that the balance sheet can be kept under control. People who leave may not get backfilled. Asking for more people to get things done is no longer a viable strategy.

For those who are in the initial half of their careers, this is a new experience. For over a decade we have been able to raise, borrow, and grow our way out of problems. Now, we need to be efficient as a primary goal.

But how long will this last?

Looking at the charts on layoffs.fyi, we can see that an increase in layoffs began in 2022 as we exited the COVID Zero Interest Rate Policy (ZIRP) period. The magnitude of these layoffs peaked in 2023, and they have been on a downward trend since.

It looks, dare I say, like we are back to “normal” levels of layoffs, and thus some level of stability seems to have been reached. Whatever large corrections that were needed to unwind the excesses of the ZIRP period have now seemingly been made.

However, this period of stability doesn’t mean that all of our books are balanced and we’re clear to start growing again. It is combined with an increase in interest rates and inflation, which means that the cost of capital is high. This means it is expensive to borrow, and institutional investors are investing less, unless you are in the red-hot AI space.

As such, many non-AI companies are entering a period of efficiency, where they are looking to optimize towards profitability. This involves seeing which levers they can pull (e.g., reprioritize, do less, or work smarter and/or harder) to make the revenue per employee go up, the costs go down, and cash reserves increase in order to give more runway to weather any further economic uncertainty.

For people who currently find themselves out of work, this is a tough time. It is especially tough for engineers that are at the start of their careers, as companies are tending to hire more experienced engineers who can hit the ground running and be more productive. Some companies are bucking the trend here, and I must make a shout-out to my employer for their excellent intern program. However, the trend is clear: companies are looking to hire fewer and more senior people in general.

For ambitious managers, especially those that had 5-year plans to become newly minted VPs, unfortunately, the game has changed. Whereas a few years back the play was to be at the right company at the right time in order to ride the wave of growth and take charge of increasingly large teams, being a successful manager now means being able to do more with less, keep talent density high by hiring the best and exiting the worst, and to provably be in the details whilst shipping fast and often.

In the current climate, which I see continuing into 2025, the best managers will be the ones that don’t need more people to get the job done. They are running small, highly focused orgs that are able to ship quickly and efficiently. Managers that are unable to prioritize and focus their teams will find themselves in a tough spot. Every engineer counts, and reinforcements are not coming.

This, of course, is both common sensical and a return to the roots of what it means to be a great software engineer: to turn ideas into code and then to use that code as the lever that moves the world. Expect a return of tropes around 10x engineers, founder mode, and a desire for a Musk-like mindset. Depending on your perspective, this may or may not be your cup of tea.

As the years go by, whatever is happening in the economy may change again, meaning we may see a return to growth and expansion. But for now, we need to leave peacetime leadership behind and put our wartime hats on: we need to be efficient. And we also need to ensure that we incentivize our teams to be efficient, too.

We need to enter 2025 thinking about:

• How can we ruthlessly deprioritize anything that isn’t essential, and how can we instill this mindset into every engineer on our teams? For example, does that refactor really have to happen now? What does it measurably improve? Also, is that feature really necessary? Can we sunset that service that no one uses so we have more time to focus on the things that matter instead?
• How can we ensure that we keep raising the performance bar so that our best people get better, and those that aren’t up to scratch are either coached up or out? Does our organization have a culture of high performance, or are we letting underperformance slide? And how much is that down to you as a leader? Are you avoiding the hard conversations?
• How can we put a key focus on productivity? Are we able to understand what the productivity of our teams is? Can we find ways to isolate bottlenecks in getting shit done and remove them? Questions you can ask include: What’s the average cycle time of a task? How long does it take to deploy to production? How long does it take to review a pull request? What is the average number of commits per week per engineer? Why is it like that?
• How can we ensure that we are using the best tools available to us right now? How many of our engineers are using AI to help them write code? If it’s hardly any, then why? Seems mad not to, right? And how much pair programming are we doing, especially remotely? What’s the average skill level of the team, and is it going upwards?

Not Letting Skepticism Turn Into Cynicism

If efficiency has been the cultural trend, then AI has been the technological trend of 2024. LLMs have become so ubiquitous so quickly that it almost feels clichéd to be writing about them, but then again, that ubiquity is exactly why I am writing about them.

LLMs have gone through the Gartner Hype Cycle so fast that I am unsure where we are on it anymore. If you’re not familiar with that model, it’s a plot of visibility against time that suggests that new technologies go through a cycle of hype, disillusionment, and then a gradual slope towards enlightenment and, finally, productivity.

If I had to place my own stance on LLMs on the Hype Cycle graph, it would be productivity. I have fully embraced them in my day-to-day life. My usage spans across:

• Using ChatGPT for general research and idea generation (e.g., last night I re-taught myself how derivatives work by having a conversation with it)
• Using Cursor to reignite my love of writing code by making it so easy to throw out ideas and see what sticks. With a new baby at home, my spare time is limited, but in 30 minutes I can get a lot done with Cursor by letting it handle common boilerplate and remembering syntax for me: I can focus on the interesting parts of the problem.
• Spending an increasing amount of time with Perplexity to search the web. I tend to use it over Google now. I love the conversational interface, how it cites its sources, and how I have the ability to continually ask more follow-on questions to broaden or narrow what I am searching for.

LLMs are a new layer of abstraction that talk directly to my inner geek teenager: they are cool, fun, feel like magic, and remind me of the near-unlimited promise of computing in the 90s.

They, of course, are not perfect. Or even deterministic!

But I am familiar enough with LLM models that I understand their limitations and can work with them: they may hallucinate, they may be biased, and I definitely need to cross-reference and double-check anything that I want to present elsewhere as a fact. However, I am far, far beyond the point where I would feel comfortable with them not being a part of my daily workflow. They are just too useful.

However, the same cannot be said for everyone in our industry. There is something about LLMs that has sparked a deep cycle of cynicism about AI in many people. Especially engineers.

Yes, training these models is insanely expensive. Yes, there are questions to ask about how the data used to train them was sourced. Yes, it may mean that the core of our jobs as software engineers is changing. And of course, I can understand that it can feel threatening to have models that can do things that we have spent our entire lives learning to do.

However, being deeply cynical about new technology is not a healthy place to be for you, your teams, or your company. Cynical people are just awful to work with. We are surrounded by an embarrassment of riches.

This is not the first time that a breakthrough has come along and flipped everything on its head. It also will not be the last time. The best engineers are the ones that are able to adapt to new technologies and use them to their advantage, whether that be increasing their productivity, finding new ways to solve problems, or even just having some fun with it.

We need to rekindle an excitement and optimism about the future of technology. Ideas need to represent play and possibility, not something to turn our noses up at because we don’t yet see the possibilities. Nothing is ever perfect when it first comes out, but that doesn’t mean that it won’t get better. And any idea that has potential will get better if it brings value to people.

I remember when the iPhone first came out, and I signed up for early access to the developer program, sometime in late 2007. After getting access in 2008 and signing an NDA, I was given access to some of the worst documentation I have ever used, and building my first apps in XCode and Objective-C was nothing short of insanely frustrating. I would lose days dealing with bugs that were not my fault.

And it wasn’t just struggling through poor documentation and occasionally broken build tooling: getting listed on the App Store included the need to spend several hours on an expensive transatlantic phone call with the IRS in Philadelphia to get a tax ID number even though I was a UK citizen. As a student, that phone bill was not fun.

But sticking with it despite the frustrations was also immensely rewarding: not only did I get to be on the frontier of a new technology and new set of skills, I got the chance to connect to a whole new community of developers and users that I would never have met otherwise. I made back that phone bill pretty quickly too.

And guess what? All of those issues we faced at the frontier are now ironed out and nonexistent. Today’s jank will be tomorrow’s polish. Humans make everything better with time. LLMs will be no different, and neither will the umpteen other technologies that will come along in the future. Stick with them, and we will be rewarded.

Be skeptical, but don’t be cynical. It has never been as good as it has been now to be a software engineer. And it’s only going to get better.

The Generational Divide

If you spent time with your family over the holidays, you may have noticed how the older folks amongst you may or may not have had technology leave them behind. You may have parents in their eighties who are just as comfortable with a smartphone as you are, or have relatives in their sixties who don’t even have an email address.

Getting left behind isn’t just something that happens to our parents. It can happen to us and our companies too. Take a look at yourself and your team and think about any growing divide in your skills, knowledge, and comfort with new technologies. Are you and your team building the frontier, keeping up with new developments, or are you being left behind?

The pace of change in technology is only going to increase. Are you working somewhere that moves fast enough to keep up with it?

Sure, you may have an engineer who considers themselves a software craftsperson and refuses to use AI to help them write code. But how much more productive could they be if they opened their mind a little and did? Have they even tried?

And, more importantly, which new competitor full of young engineers using Cursor will come along and blow you out of the water before next year is even over?

This divide doesn’t just apply to writing code either. If you are a manager, are you measuring yourself correctly against your output or incorrectly against your busyness?

For example:

• Is that manual process that you’re doing every week to crunch staff allocations through various spreadsheets actually something that software could do for you, or are you performing that manual process because it makes you feel useful? I see you…
• Have you experimented with using LLMs to help write first drafts of your documentation using your code as input?
• Have you thought of trying something like Graphite to do initial pull request reviews for your team? How much time could that save you?
• Are all of your engineers using Cursor or Copilot or similar? Have you measured the impact of them using these tools on their output, such as commits merged per week or cycle time? And is that a taboo subject in your organization? Why?

We opened this article talking about efficiency: we need to do more with less in 2025. We need to drive up the productivity of our teams, and we need to measure ourselves as managers on the impact per engineer that we have.

It just so happens that through AI we have a glut of new tools that can drive that number upwards. But we need to be willing to embrace these tools, even if they are not perfect, and even if it means that we need to continually rethink what it means to be a software engineer. Let go of the past.

We become better engineers by building, embracing, and furthering technology, moving ourselves up the stack of abstraction, allowing us to become far more productive than we ever thought possible. We need to be optimistic about the future of technology, not cynical. There is no better time to be alive.

What’s coming next is exciting. I am excited. If you are not, you might just find your company being left behind.

Onward. Happy new year.