I've gone from individual contributor to manager to director, and the most consistent mistake I see is people treating management as the "next rung" instead of a fundamentally different job. We treat someone's ability to manage others as a reflection of their worth, yet we rarely teach what management actually requires. That gap does real damage — both to the people who take the role for the wrong reasons and to the people who end up reporting to them.

When someone asks me whether they should become a manager, I ask if they want responsibility for outcomes you don't directly control, or are they looking for validation, stability, or a raise? Those are not the same thing. At 18F, managers weren't paid more than individual contributors. That stripped away the usual incentives and made intent visible very quickly. The people who stepped into management because they cared about others' growth thrived or wanted to take the next path on their career progression. There are pros and cons to a relatively “flat” org structure like this, but I found it useful.

In one of my early jobs, I had a senior director who trusted me with leading an org-wide project. Not only was I put in charge, they invited me to leadership meetings and let me speak.  That experience shaped my career in ways I could not have anticipated at the time. Someone with positional authority chose to see me, pulled me into the conversation, and made my perspective matter. That's the job. Being seen often equates with being invited, and managers who understand this spend their energy opening doors, not guarding them can develop talent.

Deciding to give up everyday responsibility on design choices is not an easy one. I miss front-line delivery work and might choose it in my next role. There’s nothing like actually working on the problems in front of you, rather than just triaging or dealing with escalations. I’ve had front-end designers worry about losing their craft, and they're right to. You will write less code.

If your identity is tightly bound to being the person who solves the hardest technical problem, management will feel like erosion. The increasing number of “player-coach” roles that let designers keep designing while managing are the best of both worlds, but it takes a mindset to both focus on delivering artifacts while also coaching someone who may or may not be on your same project.

A few years ago, I took over coaching a new high school tennis team. Early into my tenure, I would notice the players looking at me for validation during crucial moments of the match. This didn’t happen with my old teams, but I realized what I needed to do. One of the things I emphasize through the pre-season and our practices is trust. Not just from me, but the entire coaching staff. I want the players to understand that they’ve been given the tools to make decisions out on the court. Sometimes, they’ll make the right ones. Other times, it won’t work, but by reminding them that they get to make the call because you’re the one seeing the ball is a lesson that transcends sports. As a director, I want my managers to instill this into their teams and same for individual contributors, because it’s crucial that people learn it for themselves. Few things are more rewarding than seeing someone grow into their craft and having a hand in that.

It's also worth saying plainly: you can grow without managing people. Leadership is not synonymous with line management. I've met outstanding principal designers who influence direction, mentor deeply, and carry real organizational weight without ever owning performance reviews. Some of my favorite designers are professionals I knew we could trust with almost any task in their toolbox; folks that delight clients and their colleagues alike. With senior designers and principals, my question is just ensuring they’re staying engaged and challenged by the work. Coaching and mentoring are non-managerial ways for them to contribute without having to “manage” someone.

On the flip side, I've watched senior designers become the glue — mentoring, stabilizing, unblocking — and then stall because none of that work was owned or legible. If you don't claim authority somewhere, the organization will take the value and flatten the role. This can be one of the ways that elevating into a leadership role can be a way to build yourself into a growth role in a company where you’ve spent a long time. It’s also where considering opportunities elsewhere are a chance to reframe how people see you; new jobs with a different title can give you a chance to reinvent yourself.

If you're considering management, be honest with yourself. If what energizes you is coaching, advocating, and shaping how work happens beyond your own hands, then management can be deeply rewarding. If what energizes you is making things and being close to the work, protect that instinct. The field needs senior practitioners just as much as it needs good managers.

Dear {'{Boss}'},

I have found a new design course called Mindful Design that I believe will completely transform our ability to produce design that actually works well for our users/customers. The course doesn't teach hacks and deceptive patterns, but instead teaches us how the human brain actually works, so our design skills will evolve to work with people, rather than against them. I think that will benefit us all in the long term.

I also think the course will be useful for our front-end developers because the instructor, Scott Riley, covers practical design skills from scratch. Our developers are not designers, but having a broader understanding of practical design and how the human brain works will improve their skillset and output a lot. It’ll also help them work more effectively and efficiently with our designers, who themselves, will always benefit from re-learning the fundamentals too.

The course has nearly 20 hours of video content and around 15-30 hours of practical exercises. I thought doing those exercises as a team will be an efficient way for us all to skill up at the same time. The course is written off the back of a really successful book, also called Mindful Design, which has helped countless teams already, including the BBC, Stanford, GitLab and Zeroheight.

If you would like to look over all the course curriculum you can find it here. Certificates are also available upon completion of the course should we want them, along with LinkedIn certifications.

I am asking that we allocate some of our training budget for this course if possible. Bulk discounts are available, should we want the team to go through this together.

Thanks!

{'{Your Name}'}

If you are a boss reading this, investing in your staff’s training is really valuable in both improving your company’s output, but also making your staff feel rightly valued, supported and invested in. It’s something I don’t even hesitate to do for the staff that work here. Staff training spend is also tax-deductible and often incentivised in various countries.

If you have any questions about bulk licences or anything related to Mindful Design, we’re ready to help at support@piccalil.li.

Check out Mindful Design

After 20+ years, the things that have the most effect on my day-to-day aren’t that I learned how to model my OOP systems using UML or know what a Monad is. Instead, it’s a bunch of (sometimes pithy) statements that fall under the umbrella of “programming principles”.

Now, there are many, many programming principles out there. Some are more like “laws” that describe how systems and people behave (like Hofstadter’s law: It always takes longer than you expect, even when you take into account Hofstadter’s law.) and while those are useful in broader contexts, I don’t find them that actionable when I want to write “good code”.

In this article, I go over the rules-of-thumb that help me write better code as I’m writing code. They don’t require me to write out my entire system before they’re useful, they just help me make better decisions as I go.

From pithy statements to actual useful habits

When you’re just starting out, at some point someone is going to point at your code and say “Premature optimisation is the root of all evil”. That sounds super serious, but also kind of odd.

Optimisation is something that’s good while “premature” usually isn’t. The big problem here is that you’ve now been told that what you’re doing is evil, but you don’t actually know what to do next. Avoiding premature optimisation is a good programming principle, but it doesn’t actually help you write better code.

A helpful senior developer might help you out there and explain You Aren’t Gonna Need It (YAGNI). This is another good programming principle that warns you against writing code that you anticipate needing in the future, but don’t need now. The reason you’re not going to need it is that between not needing it now and the planned future where you would need it, the plans are likely to change in such a way that you actually won’t need it after all. It’s better then to write things “just in time”, when you actually need them.

However, you’ll also be asked to follow the Don’t Repeat Yourself (DRY) principle. Don’t write code that does the same thing in multiple places, because that’s hard to maintain. If you listen to this, all you’d ever do is consolidate code that does the same thing into a single function or module, and call that from multiple places.

All of these acronyms are generally good advice. If you’re building out some functionality, it makes sense to anticipate the future at least somewhat, right? It makes sense that if you need that logic in multiple (future) situations, to optimise or refactor that already. That way you can make sure the current code takes that into account, and you don’t have to write it twice.

YAGNI and premature optimisation are usually brought up because rather than writing the code for the functionality you need now, you start writing code for the general system that offers the functionality you need now, but also the functionality you might need in the future. It means that you end up writing a lot more code, adding a lot more complexity and taking much longer than your senior co-workers.

These principles don’t actually help you as you write code. You could try leaving out random parts that you think you need later, but it would be much nicer to have a principle that helps you know what to leave out.

Enter the “rule of three” — the actually actionable, pragmatic principle that elegantly combines how you should be thinking about YAGNI, DRY and premature optimisation.

The rule of three states that you should only refactor (or optimise) code once you’ve written the same code three times. The first time you write the code, you just write it. It does the thing and only the thing. The second time you see that you need the same code again, you …literally copy-and-paste it and make the few changed you need. Then when you have to do that a third time, only then do you look at the now three implementations you have and generalise them into a single implementation that can handle all three cases.

The concept here is that, once you’ve written that code three times, you have an understanding of what general functionality you actually need, and what parts can be simplified and optimised. After three implementations you know what “level of abstraction” you need, and you can make sure that the generalised implementation actually works for all three cases. I “apply” this principle all the time because it’s so easy (I can count to three!) and it helps me avoid over-engineering right as I’m about to.

When you read up on programming principles, it’s easy to find Laws and Rules that sound very serious, but that require a lot of context to actually apply. I hope that from the example above you can see how getting from the general “premature optimisation is the root of all evil” to the specific “rule of three” has a much bigger impact on your day-to-day coding, and the quality of the code you write.

Writing the right thing

Lets now zoom in to that first implementation. It can be very tempting to optimise the code right from the start, making sure each line is fast and efficient. Often times though, the fast and efficient code is not the most readable code.

When it comes to writing code, we don’t actually spend that much time writing. Instead, we spend time reading the code we just wrote, or that already exists and reasoning about it to decide what to write next. So the easier it is to read and reason about the code, the faster we can write the right code. Code that’s fast and optimized is great, but if it’s hard to read and reason about, it will slow us down in the long run.

We want it all though: we want to write correct code fast and we want to write code that is fast. So how do we go about that? How do we choose?

Here, I like to apply another principle: “Make it work, make it right, make it fast”, which is attributed to Kent Beck, the inventor of Extreme Programming.

At any point during your coding you can look at your code and ask yourself: does it work? If the answer is no, then you focus on making the code work. You don’t care about anything else. Just make it work. If it works: great!

But things that work aren’t always doing the right thing, so next you ask: is is right? As long as your code isn’t right (it doesn’t behave the way you want to, it makes tests fail, it doesn’t accept the input you give it), you focus on making sure that it works right. Only then, when your code works and your code is right, do you ask: is it fast? If it’s not fast enough, you can now focus on making it fast.

This helps you prioritise your efforts. It’s a waste of time optimising code that doesn’t work yet, or that does the wrong thing. You’ll have to rewrite it anyway and then the optimisation is gone too. If your code doesn’t even work yet, there’s no need to worry about whether or not the broken code is right. It’s broken so you need to make it work before you can do anything useful.

What makes this principle so useful is that you can apply it at any time simply by looking at (the behaviour of) your code. You don’t need to plan anything out. You can just ask yourself these three questions, in order, and focus on the one that matters right now. You can forget everything else until it’s relevant.

If you squint, you realise that this is actually the same principle as the rule of three, just applied to a different aspect of programming. Both help you focus on the task you have right now, and avoid getting distracted by other concerns that aren’t relevant yet.

The crappy first version

There’s a bunch of principles that help you get into the mindset of writing that first implementation. Principles in this vein tell you to throw away your first implementation, or to build the best simple system for now and, actually, “make it work” in the rule of three is this exact same idea.

There’s a more high-brow version of this too called Gall’s Law, which states that “a complex system that works is invariably found to have evolved from a simple system that worked.”

The idea here is that if you try to account for all things from the start, the thing you end up with doesn’t actually work. An example of this is every “full rewrite” ever that ended up worse than the original and took significantly longer than planned. (this, of course, also has a name: Second-system effect.)

Reading all of that, you might be reminded of Keep It Simple, Stupid (KISS). The problem with KISS though is that if you’re building something to help people complete a task, some complexity might be unavoidable and then, KISS has no answers for you. Some things aren’t simple. Gall’s Law, on the other hand, at least tells you that the complex can exist if you’re honest about starting simple and iterating towards your goal.

Still, that’s not very actionable as you’re writing code, so lets see if we can find some principles that do help you write better code as you’re writing code.

Idempotency

As much as possible, the functions I write are idempotent. That’s a big word isn’t it? All it really means is that a function always does the same thing when given the same arguments. That doesn’t sound groundbreaking, but it actually has pretty big implications for how easy it is to reason about your code.

If you have a function that is idempotent, you can call it as many times with the same argument and it will always return the same result. For example, getting the length of a string is idempotent. No matter how many times you call "hello".length, it will always return 5. If you know the function is idempotent, you don’t have to worry it secretly returns a new string or read a variable from elsewhere in your code. Same arguments in, same result out.

A function that is idempotent can still have side effects as long as those are also idempotent: changing global state or a database entry can be idempotent as long as calling the function more than once always results in the same value being set.

When that’s not the case, calling a function twice (due to a user double-clicking, or a servers retry-logic on a flaky connection) might change the resulting value. That makes reasoning about your code much harder. If you find you need a side-effect, you can split that off into its own function and then make that idempotent. Rather than one larger function, you have two smaller functions that each do one thing.

You can treat idempotent functions like black boxes that let you “forget” the implementation details while you reason about your larger system. It’s like a brain shortcut that makes it easier to reason at a higher level. The function always does the same thing, so you can collapse it into a single step in your mind.

Single responsibility principle

Related to idempotency is the Single Responsibility Principle. This principle states that a function (or module, or class) should have “only one reason to change.”

In practice, this means that there should be one function that takes care of one aspect of your system. A nice example here is using an Object-Relational Mapping (ORM) to handle all your database access. The ORM module is responsible for talking to the database and the rest of your code should have no idea how that works. If you ever need to change how you talk to the database, you need to update your ORM and no other part of your code.

Again, this lets you collapse parts of the system as you reason about it. You don’t need to know how it constructs SQL queries. It’s not the responsibility of the code you’re working on right now. You can just treat an ORM like a black box that does database access for you.

You also see the Single Responsibility Principle described as “a function/module/class should only have one reason to exist.” If that single reason disappears, you should be able to remove that function/module/class entirely. If you switch to a different database and need a new ORM for example, the old one should be completely removable.

What often happens though, is that your ORM grows in functionality: it doesn’t just fetch data from the database, it also mangles that into a specific format that the rest of your code expects. Now, if you want to switch databases, you also need to update all the code that depends on that specific data format. Your ORM has multiple reasons to change, and that makes it harder to reason about.

Instead, you should have one module that only handles getting data from the DB, and another module that only handles data formatting. Now each module has a single responsibility, and you can change (or delete!) one without affecting the other: that’s the single responsibility principle in action.

A small trick to check for single responsibility is to describe what a function/module/class does in a single sentence. If you find yourself saying “and”, then it probably has multiple responsibilities and should be split up.

One level of abstraction

Related to the single responsibility principle is the idea that a function shouldn’t just do one thing, but also only operate at one level of abstraction. The phrase, “level of abstraction” is in itself quite an abstract concept, if you pardon me the overloading of the term. What it means is that when you read through the code in a function, all the operations should be at the same level of detail.

For example, consider this function:

async function processUsers() {
  const users = await database.fetchAllUsers();

  users.forEach((user) => {
    if (user.isActive) {
      sendEmail(user.email, "Hello active user!");
    }
  });
}

In this function, we have three levels of abstraction:

1. Fetching data from the database (database.fetchAllUsers()).
2. Loop over all the users and filter them to only the active ones (if (user.isActive)).
3. Performing an action based on that data (sendEmail(...)).

Not only do you have to use a lot of “and” to describe this function — it connects to the database to get users and filters them and sends emails only to the filtered users — but you also have to think about three different levels of detail when reasoning about this function: the database, active users and email sending. In real-world code, this might additionally have a bunch more await, validation and error handling.

As you read the function, the thing you’re focused on keeps shifting, making it harder to follow along. For example, first the function is about getting all users, then it’s about filtering them, then it’s about sending emails to those filtered users only.

Some things you can look out for that indicate multiple levels of abstraction:

• Multiple “and” when describing what the function does.
• Multiple loops or iterations over data.
• Mixing “low-level” operations (like database access) with business logic.

If you split this up, you can have three functions that each operating at a single level of abstraction:

async function getActiveUsers() {
  const users = await database.fetchAllUsers();
  return users.filter((user) => user.isActive);
}

function sendEmailsToUsers(users) {
  users.forEach((user) => {
    sendEmail(user.email, "Hello active user!");
  });
}

function processUsers() {
  const activeUsers = getActiveUsers();
  sendEmailsToUsers(activeUsers);
}

The getActiveUsers function only deals with fetching and filtering users to those that are active, the sendEmailsToUsers function only deals with sending emails, and theprocessUsers function gets all the active users and then emails all of them. Each function is easier to understand because it only deals with one level of abstraction, and you can reason about each part separately.

Notice how in the refactored version, sendEmailsToUsers doesn’t care where the users come from or what their state is. It just sends emails to the users it has been given. Each function has a single responsibility and operates at a single level of abstraction.

Are they all the same thing?

At this point, you might have noticed that a lot of these principles are related, and that’s because, to butcher a classic:

All good code is alike; each bad code is bad in its own way.

— Tolstoy (if he was a software engineer)

Good code is easy to reason about and things are easy to reason about when it’s clear what each part does. It’s also clear how the parts relate to each other, so all these principles highlight different aspects of writing code that’s easy to reason about.

On the flip side, it can be hard to figure out why some code is bad. Is it because it has multiple responsibilities? Is it optimised but incorrect? Does it take you on a tour of multiple levels of abstraction as you read it line-by-line? Does it do extra things that you aren’t sure what for? All of these things make bad code so hard to work with.

It’s much easier to end up with good code by (dogmatically) sticking to the principles above than it is to have bad code and make it good again.

Next time you’re writing a new function, I hope you catch yourself thinking about these principles, that you stop yourself from optimising code that doesn’t work yet, that you make sure each function only does one thing and that you keep yourself from designing complex systems before you have a simple system that works. Good luck!

Bibliography and further reading

Like I said, I learned all this stuff on the fly. Here are some of the resources that helped me along the way:

• Refactoring by Martin Fowler. This classic book has a JavaScript edition and though a lot of the code has a distinct Java flavour, the principles are universal.
• Making impossible states impossible by Richard Feldman. A great talk about modelling data structures to make reasoning about your code easier. Though the focus is on data structures and less about business logic like this article, I apply rules from this talk on a nearly daily basis.
• Make It Work Make It Right Make It Fast on the C2 wiki, attributing the quote to Kent Beck.
• Software Design Principles: Single Level of Abstraction
• hacker-laws.com is a collection of programming principles, laws and rules.

Dear {{Boss}},

I have found a JavaScript course that I believe will elevate our team’s knowledge of how the language really works, which in turn, will improve the quality of the JavaScript code we produce, day-to-day. I also think a deeper knowledge of the language will reduce our technical debt levels and also reduce bugs.

The course takes around 15-30 hours to complete, based on an average reading speed and it will also be a useful reference guide for us in the long term too.

JavaScript for Everyone was written by Mat Marquis who has written industry leading courses and books already. He was also part of the jQuery team, a member of the W3C Responsive Issues Community Group and an editor of the HTML specification. In short, he knows his stuff and his material is incredibly trustworthy with all of that experience.

If you would like to look over all the lessons you can find them here. Certificates are also available upon completion of the course should we want them, along with LinkedIn certifications.

I am asking that we allocate some of our training budget for this course and bulk discounts are available should we want the team to go through this together.

Thanks!

{{Your Name}}

If you are a boss reading this, investing in your staff’s training is really valuable in both improving your company’s output, but also making your staff feel rightly valued, supported and invested in. It’s something I don’t even hesitate to do for the staff that work here. Staff training spend is also tax-deductible and often incentivised in various countries.

If you have any questions about bulk licences or anything related to JavaScript for Everyone, we’re ready to help at support@piccalil.li.

I also wasn’t prepared for how difficult it was to listen to people, to open up and not assume I knew all the correct answers right away. I had a lot of help along the way and a leadership team that understood the adjustments I needed to make to move into this position. But there were times when I asked myself, “Was this the right move?”.

All of this to say: I understand what it means to move into a management position as a developer, and hopefully, some advice I can impart here will be useful.

Development tracks

I think many developers view management — of some kind — as the inevitable endpoint of their careers. It’s often seen as the only clear path forward, the default next step to bump your pay, or gain more influence. For a long time, this was largely true — the career ladder had one shape and the rungs at the top were all labelled “Manager”, “Director”, or “VP” — but this is an outdated view, and we’re rapidly seeing it change.

A successful tech career isn’t a ladder; it’s a continuously forking road.

Many modern tech organisations now offer a dual-track career path for developers. One path is for management, and the other is the Individual Contributor (IC) path. Think of it as a fundamental shift in your job’s purpose. As a developer, your primary goal is to solve complex problems. As a manager, your primary goal is to build and support a team that solves complex problems.

This raises the most critical question you need to ask yourself: “Do I want to be a manager?” Are you genuinely drawn to the work of mentoring people, facilitating discussions, clearing roadblocks, and focusing on team health? Or are you just looking for a salary you believe only comes with a manager role?

Here’s the hard truth: managers who don’t want the job make bad managers. They’re often the ones who can’t let go and end up micromanaging, or who become disconnected and can’t course-correct poor performance, or end up resenting their team and seeding a toxic culture.

Making the change for the right reasons is the first and most critical step to becoming a manager people want to follow.

So, you’ve decided to be a manager

You’ve reflected on your options, and you have a good sense of what sort of good you can do in the role. You’ve decided to work towards becoming a manager. Transitioning into this new role is a not insignificant shift, and it’s important to enter it with a clear understanding.

The following sections will guide you through some key skills and mindsets that will (hopefully) help you succeed. We’ll talk about the challenges of letting go of control and delegating, why your experience matters, the importance of finding your own authentic style, and what you can do now to work towards this goal.

Delegation and control

Transitioning from IC to manager means shifting your mindset from “doing the work” to “enabling others to do the work”. This is where the challenge of delegation comes in. For many, it’s one of the most difficult first challenges you’ll face. It certainly was for me.

Effective delegation isn't just about handing off tasks; it’s about entrusting your team with the autonomy to find their own solutions. Your role is no longer to write the code, but to define the problem, provide the necessary context and resources and then get out of the way. This shift requires a leap of faith; you go from needing to only really trust yourself to needing to trust that others can execute based on the resources you’ve provided.

This trust is a two-way street. By giving your team members the freedom to tackle a problem in their own way, you empower them to grow their skills, build confidence, and feel a greater sense of ownership over their work. They may not do things exactly as you would, but that’s ok — in fact, it’s often a good thing. I’ve learned a great deal from my team members over the years, specifically as a result of providing this autonomy.

Delegation is a skill that must be practiced. Spend some time thinking about what information you’d like to receive if given a task. Try to be outcome-focused rather than overly prescriptive. Provide support and be available to answer questions and unblock people, but resist the urge to jump in and take over (trust me when I say this never ends well). Celebrate successes and use any missteps as a learning opportunity, for both them and yourself. The more you practice letting go of control, the more you’ll realise that your true value as a manager lies in the success of the team you’ve built and supported.

Communication

Everyone has a different communication style and it’s incumbent upon you, the manager, to adapt to theirs, not vice versa.

Some people are direct and prefer quick messages, while others thrive on collaborative, in-person discussions. Taking the time to observe and understand these preferences builds trust and ensures your message is received correctly. This also involves active listening, a critical skill for a leader. When you listen actively, you gain valuable insight and show your team that you value their perspective. This fosters a safe environment where people feel comfortable raising concerns and sharing new ideas.

Learn from your examples

I often talk about some of the bad examples of managers I’ve had over the years, teaching me more about the role than the good ones. They’ve taught me what not to do.

For example, I once had a manager who took advantage of a tragic situation involving a business partner's death, using it to gain control of company stock through a manipulative scheme that directly involved the employees. A couple of weeks after this, I was called in to be reprimanded for not being enthusiastic enough.

A year after this, and at another company, I remember having a manager who said, “Thank you so much, this is excellent,” after I delivered my first project to her. It sounds funny to admit this now, but I can’t understate how affecting those words were at the time. In my professional career, I had never felt so valued and essential.

These two examples have really shaped how I approach my team. Building trust is one of the most important tasks I undertake, as I believe it’s the only avenue to open communication, job satisfaction and enthusiasm.

Learn from your examples, good and bad. Reflect on your experiences and try to understand the reasons a manager may have done something they’ve done. Focus on the bigger picture and ask yourself: how might I have behaved in this same situation? Lean on your experience and allow it to shape your management style.

Be your own style of boss

Not every manager is the same; you’re not the same as every other manager. Your greatest strength as a manager or leader is your authenticity. The most effective managers understand their unique strengths and build their style around them.

Think about the skills that make you a great developer. Maybe you’re a meticulous problem-solver, a creative thinker or a great collaborator. These skills don’t disappear; they evolve. Your problem-solving can now be used to clear roadblocks for your team, while your creative thinking can help motivate and inspire them.

Reflect on your strengths and consider how they can be integrated into this new role.

Perspectives

A big light-bulb moment for me when I first moved into a management role was how different everything looked from this new perspective. As an IC, my world was centred on my own work and immediate team. My primary responsibilities were to write code, solve technical problems, and deliver on the tasks assigned to me. From that vantage point, a manager's decisions could sometimes seem arbitrary or disconnected from the reality on the ground. When a deadline was changed or a project was suddenly de-prioritised, it was easy to assume they were just out of touch or that the decision wasn't well thought out.

This new role changed that view completely. Suddenly, my focus had to expand to encompass budgets, client relationships, strategy, and people (a subject that I had sorely ignored to that point). I was no longer managing tasks; I was managing people, their career growth, and their well-being. A project delay that once seemed like a simple technical issue now affected client trust and resource allocation across the company. A single employee’s challenge wasn’t just a matter of support; it was a factor in team morale and overall productivity.

It was a humbling moment that made me realise I’d been making assumptions about previous managers’ behaviours, judging them without understanding the pressures and competing priorities they were balancing.

Your perspective will change as you move into your first management role and it will continue to change as you move into further roles. Understanding that you may not have the whole picture is a critical skill to hone if you hope to be an effective manager.

Management starts at the bottom

Whether you’re just starting to think about whether a move into management is right for you, or you’ve just scored your first management job, it’s important to also understand that management also works in the other direction. “Managing up” is a key skill that I think everyone should learn, because it’s a skill that empowers you and makes you a more valuable asset to your team. And it’s never too early to start.

“Managing up” is a proactive approach to building a strong, collaborative relationship with your manager. It means understanding their communication style, their priorities and appreciating some of the pressures they’re facing. It’s about making your manager’s job easier, making your job and your team’s work more effective.

For example, don’t just bring problems to your manager; bring solutions. Instead of saying “We have a problem with the new build toolchain”, try “I’ve identified a problem with the build toolchain, and I think we have two solutions: A or B. I think B is the better solution because of X, Y, and Z. What do you think?”

You’ll gain essential skills for any leadership role by learning to manage up. You’ll learn how to communicate effectively with people in different positions, and how to anticipate needs and potential roadblocks. You’ll also build a reputation as reliable, thoughtful, and proactive.

Ultimately, your success and job satisfaction are tied to your relationship with your manager, and, as a manager, your relationship with your team. Managing, both up and down, is by far the most powerful way to affect those relationships. Leadership isn’t just a title - it’s a mindset.