If you are on your way to becoming a manager, or you're thinking of starting your journey to become a manager, then this book will give you all the insights, tools, and techniques that you will need for your journey.

This book is your ultimate guide to the journey of becoming a manager and a leader of a technical team. I share my own unique experiences so that you can learn from my own journey. You can take my successes and make them your own, and you can hear learn how to avoid the mistakes I made along the way.

Developers have a wide range of skills, and usually this includes a great capacity for logic. I'll show you how to utilize this key strength, and together we'll plan the Developer-to-Manager journey as logically and methodologically as possible.

We're going to launch our journey in this first chapter, by exploring together the fundamental and positive reasons that are driving you forward to become a manager. By taking a balanced view of the pros and cons of becoming a manager, as well as the outcomes and impacts, we'll be able to pinpoint exactly where you are, and how you got here so far, in terms of your career. This will give you a clear sense of what your current course and trajectory are, as well as your natural tendencies, your likes, and dislikes. These are the most important factors for you to think about.

Over the course of this journey, we'll also define what your end destination will be, based on key ideas about what a "manager" really is. By analyzing the more human side of being a manager together and exploring key questions – such as whether being a manager means that you need to be responsible for a team of real people – we will also demystify some of the common preconceptions you may have about becoming a manager.

So, let's get started! We asked the question, why you want to become a manager? And what if you're part of the "Accidental Manager" phenomenon where you didn't get to choose? How could you use this to your advantage? We'll be answering these questions by the end of this chapter.

Like everything in life – from both a professional and personal perspective – the real reasons behind your motivations, and the ultimate decision you make to really change and move forward, is fundamental to succeeding. As TED speaker and author, Simon Sinek, puts it best:

Finding your own "why" can be a wondrous journey, but that journey is not a defined process. Unlike software development, this journey is different for everyone. My own journey took five years, three jobs, and four managers. And my journey is still continually evolving even to this day. Every day, I'm still learning to balance a hands-on techie approach, and a hands-off manager approach – and the various combinations in between. In fact, the one thing that I've learned is that different requirements and situations require a different mix.

So, you must be honest with yourself. Do you want a bigger salary? Higher prestige? More learning and development? Or simply the challenge of trying something new? Are you even a little bored with being just a developer? Your why sits in the middle of your Golden Circle, as set out by Simon Sinek.

The Golden Circle model can be seen in Figure 1.1. It sets out the layers and relationships between your innermost values and your outermost physical behaviors, and it's like an onion. Knowing why you are doing something is the most powerful driving force behind any movement:

Now, feeling bored or unchallenged, and yearning for a new test, would be more of an inner driver, while having more money, a grander title, or greater power would be more of an outer driver. It's vital here to understand what the cause is, and what the effect is, because there's nothing wrong with wanting the results of your labor but you need to be looking in the right places for the rewards you want.

If your singular aim is to earn more money, then there are alternative methods for achieving this – you could work in sales, because, simplistically speaking, more sales will lead to more money.

If you genuinely want to be a great manager, then your journey from Developer-to-Manager needs to be a sustainable and meaningful endeavor – because you will need to really know what is your why. If you don't, then you you'll run the risk of failing, regressing, and being typecast as a techie who can't do anything else. In short, you must know your inner cause!

It's always important to consider as many factors as possible when deciding to undertake this journey. So, let's take a balanced view and explore both the pros and cons of becoming a manager.

The road ahead to becoming a manager is quite complex. The journey requires navigation, planning, and a mindful acceptance that you might make a wrong turn here and there before you reach the finish line. Without this planning, you're likely to get very frustrated and give up at the first hurdle. For some people, that's enough to decide that they don't want to take the journey.

You should certainly consider whether becoming a manager advances your career, your happiness, or perhaps a mixture of both. Likewise, whether your journey will be slow or fast, because balancing your professional and personal ambitions can be difficult to achieve along the road ahead. At times, you will need to concentrate on one of your ambitions and sacrifice or postpone your other ambitions.

This might already be true in your life now as a developer, but by becoming a manager, you risk your work taking over more of your life than you might expect. For example, you might suddenly find yourself bringing home emotional baggage from the office, because being a manager can put you in challenging people situations. While taking these manager type challenges home for some private contemplation may ultimately help you achieve a better outcome, it comes at a price of less personal space and downtime to relax for your own wellbeing. And of course, some situations may also affect you very directly and emotionally.

Another consideration is whether becoming a manager fits your natural talents, and whether you think you'll be any good at being a manager. At the end of the day, we are all different, and our talents are all unique; everyone has their own unique set of strengths and weaknesses, and their own likes and dislikes.

Being a developer is different from being a manager in that your focus will change from writing code yourself to helping others write quality code. As we've already mentioned, people are different – so some of us will naturally be more suited to becoming a manager than others.

It's also quite natural to worry that since you're a good developer you might not be so good at being a manager. Why become a manager and potentially stop doing what you're doing so well? There are so many things that you can learn about software development. But the biggest consideration is most probably, what if you fail?

Everyone's attitude and tolerance for risk-taking will be different. Some people take a more gung-ho, or "go big or go home!" stance, while others take necessary comfort in making smaller, incremental changes.

It is quite natural to worry that if you don't succeed at becoming an effective and respected manager, then it will be a personal failure, and all the negative things associated with that. You might worry about then being viewed as a techie who just didn't make it as a manager; or having a below-par performance appraisal; perhaps even getting less bonus pay as a result, or a negative mark on your résumé and reputation.

But just imagine that worst-case scenario again, where you don't become a manager, or you fail as a manager. Would it really be considered a setback by others? And, most importantly, by you? There is always a possibility that a future employer will ask you questions such as the following:

• What happened?
• Why did you go back to being a developer?

Sure, it's important to acknowledge this possibility and be prepared to answer such questions directly, even if the answer is that it was not such a positive experience, and you reply with an answer as clear as this: it just wasn't for me.

In favor of making the Developer-to-Manager journey, there are also numerous things to consider. First and foremost is dealing with the perception of failure. If your attitude to risk-taking is more like the entrepreneurial Silicon Valley style of thinking, then you may acknowledge and accept that failure is part of succeeding. Failing at multiple start-ups is considered a necessary step toward setting up a successful, and hopefully billion-dollar, "unicorn" business.

It's a badge of honor and follows a "you win, or you learn" mindset. When an athlete suffers a severe injury or crushing defeat, they learn from the experience to improve and avoid losing again. This positive mental attitude toward risk-taking is rare and will be recognized by more insightful managers and people in general, which will put you in good stead as a manager or a developer.

Now just for a minute, put yourself in an interviewer's position. One candidate has done the same type of development, at the same level, for their entire career. Meanwhile, another candidate has learned multiple technologies and has also tried becoming a manager. Which candidate would you think has more of a story to tell? Which would you consider to be a more rounded professional? So, whether you absolutely nail becoming a manager first time or not at all, it can still be considered progress.

As former U.S. President, Barack Obama, eloquently puts it:

His takeaway point reinforces the idea that the Developer-to-Manager journey is not a predefined process. Imagine the best-case scenario: you've made the successful transition from Developer-to-Manager, whenever that may be; and you've obtained the added pay, the job satisfaction, and the recognition you wanted. Now, do a retrospective review and ask yourself: What was the best part of my journey?

For me, the best part of my journey was the personal growth I attained by meeting all the new challenges along the way. I was truly stretched beyond what I thought I could achieve. I used to think that I wanted nothing more than to be left alone to write the programs I wanted to write, and to hell with anybody else: my goal was to be the master of my own domain, however large or small it was. However, once I began my journey, I started dealing with people from across a huge spectrum and working on issues not caused or fixed by code. My horizons were broadened as a result, and my confidence to connect with people socially grew exponentially.

Looking back, if I hadn't made the journey, I could easily see myself still doing the same job, albeit as much more of an expert! By understanding these considerations, and knowing the best-and worst-case scenarios, you'll understand all the important steps to discovering your why, which is the fundamental reason and driving force behind the Developer-to-Manager journey.

Understanding your innermost desires and drivers that lead to you wanting to make this journey is a crucial step. To help discover your inner cause, it's often useful to look back and review your work history.

Let's take a minute to sit back to ask ourselves – and you may even want to write your own personal answers down to these – the following questions:

• How many jobs have I had?
• How often have I changed jobs?
• How many companies have I worked for?
• Have they been in vastly different businesses or sectors?
• Did I instigate these changes, or did they happen to me because someone else made a decision that affected me, such as redundancy?

The answers to these questions are all key indicators. If you have proactively changed jobs frequently, it's a likely sign that you are searching for something more, and is a sign of your curiosity, inquisitive nature, or even that you easily get bored, depending on how positively you choose to look at it! Either way, it's a sign.

If you don't change jobs regularly, or if you've worked in a variety of organizations, then perhaps you love what you're already doing, or simply feel comfortable and safe in your current environment. This is not negative; a safe and secure environment can actually be a wonderful place to start your journey.

Perhaps you've been asked to make the change by someone else. Sometimes, we all need a nudge, a pep talk, or even to be forced into something we didn't think we were capable of or think we would even enjoy. This acts as another possible starting point. The "Accidental Manager," which we'll explore in more detail throughout this book, is often associated with this scenario.

Each starting point has its own merits, advantages, and disadvantages. Whatever you do, don't let your own starting point become a psychological barrier to actually starting. Choose to see it as a springboard, and as a source of infinite possibilities, which it is. It would be extremely boring if everyone's journey started at the same place and followed the exact same path!

It is also important to note that this journey is not a race. Like the projects you've been working on, time is only one part of the time, cost, and quality triangle, which is also known as the Project Triangle and Triple Constraint. I honestly believe that if you focus on quality, your journey will ultimately be more fruitful. After all, this is your career we're talking about, which is not just another project!

Achieving true quality requires commitment in many ways. You will be able to appreciate the quality of your own journey first-hand through your subjective experiences along the journey you're going to take. You'll also see how the reality of your journey compares to your expectations, and you'll experience other people's responses to your journey.

Let's talk about time scale. The Developer-to-Manager journey is not a single leap or overnight transformation. It's okay to be spurred on by quick wins and instant gratification. Just understand that they're not the be-all and end-all, since making a change from being a developer to a manager is a journey, and, as with any journey, it's important to have checkpoints and milestones along the way.

All these checkpoints would be useful tools that allow you to gauge your progress, whatever that may mean to you. Overall, you must be willing to be in it for the long haul, because you don't know how long the journey will ultimately be. The adage that it's about the journey, not the destination, is absolutely true.

The cost of your journey can be considered mainly to be the effort you put in. This is the blood, sweat, and tears you will spill along the way. For instance, even reading this book can be considered part of the cost of your journey! You must decide how much you are willing to spend, or not, or, more sensibly, how much you are willing to invest, in balance with time and quality.

Practically speaking, if you choose to invest in some extra training, which is rarely a bad idea, it may cost you some money. However, one of the more likely reasons why you might be considering becoming a manager is the usually associated higher salary and benefits package. So, in the long term, there shouldn't be much of a direct financial cost.

Whether or not a manager is worth more to a company than a developer is a highly subjective debate and a topic for deeper discussion. By accepting industry norms, it's safe to say that a manager can normally command a higher salary than a developer, whom they may well manage. There are exceptions to this, some of which I have experienced myself, but looking at a respectable independent salary benchmark for the overall picture, then this is a clearly defined position for most companies. If you look at Glassdoor, which provides a real-world, data-driven view of the average salaries for various jobs, then you'll see that this is the case.

So, where are you now in relation to the Developer-to-Manager journey? If you have been able to answer all the questions at the start of this chapter, then you should have some indicators already in your mind about your answer.

This jumping-off point is crucial to any plan. In Chapter 2, What Are the Key Skills I Need?, I will provide you with more answers and also give you clear directions on how to start your journey.

Of course, you may already be more of a manager than you realize! It's quite likely that you already do some of the things that managers do in your current work. This could cover anything from reviewing someone's timesheet, performing a document review, putting together a presentation, or sitting on a committee. This is likely to be informal, and you may not even have noticed or realized that it is managerial work. So, my point is that you may already have started your journey more than you think.

You can analyze how much you might already be a manager, by breaking down your typical week to understand how much of what you do is pure software development versus anything else.

You could try putting anything that is not regarded as pure software development, or personal learning and development, into the "managerial" category. The goal here is to give you a rough idea of how much time you currently spend not doing software development, and how much time you already spend doing management-related tasks.

The answers you get might just surprise you. One tried and tested way to analyze your time is with the Time Log method devised by Peter Drucker in his ground-breaking book, The Effective Executive. You can break down your working time into 15-minute units, and you classify them into a particular purpose or category, such as coding and managerial. You may be pleasantly surprised at how much managerial work you already do, and even enjoy!

To make it even more scientific and discerning, you could make a simple side-by-side comparison between the average week of a manager you respect and your own week. Better still, speak with them to understand what their typical week looks and feels like. The idea is to gauge how much overlap there is between you as a developer, and them as a manager.

What does the phrase "a manager" really mean anyway? It means different things to different people, and it is often overused for anything that isn't an analyst-level position! So, as common as the term is, it's worthwhile for you to define what the phrase "a manager" really means, especially in the context of software development.

A simple distinction that I have used to illustrate the difference between an analyst and a manager is that while an analyst identifies, collects, and analyzes information, a manager uses this analysis and makes decisions. Or more accurately, a manager is responsible and accountable for the decisions they make.

The structure of software companies is now enormously diverse and varies a lot from one to another, which has an obvious impact on how the manager's role and their responsibilities are defined, which will be unique to each company.

Even within the same company, this is subject to change from time to time, as the company itself changes. Broadly speaking, a manager within software development can be classified into three categories, as we will now discuss.

This role is often a lead developer who also doubles up as the team spokesperson and single point of contact. They'll typically be the most senior and knowledgeable member of a small group of developers, who work on the same project, product, and technology.

There is often a direct link between each developer in the team and their code, which means the team manager has a direct responsibility to ensure the product as a whole works. Usually, the team manager is also asked to fulfill the people management duties, such as performance reviews and appraisals, and day-to-day HR responsibilities.

This person could be either a techie or a non-techie. They will have a good understanding of the requirements, design, code, and end product. They will manage running workshops and huddles to facilitate better overall teamwork and delivery. This role may include setting up visual aids, such as team / project charts or boards.

In a matrix management model, where developers and other experts are temporarily asked to work in project teams, the development manager will not be responsible for HR and people management duties.

This person is most probably a non-techie, but there are exceptions, and this could be a distinct advantage on certain projects. Most importantly, a project manager will be process-focused and output-driven. They will focus on distributing tasks to individuals. Project managers are not expected to jump in to solve technical problems, but they are responsible for ensuring that the proper resources are available, while managing expectations.

Specifically, project managers take part in the project budget, timeline, and risks. They should also be aware of the political landscape and management agenda within the organization and be able to navigate through them.

The project manager ensures that the project follows the required methodology or process framework mandated by the Project Management Office (PMO). Project managers will not have people-management responsibilities for project team members.

As with all roles in today's world of tech, these categories will vary and overlap. They can even be held by the same person, which is becoming an increasingly common trait. They are also constantly evolving, which exemplifies the need to learn and grow continually, regardless of your role or position.

If you are a true Agile practitioner, you may take issue with these three generalized categories, and you'd be right to do so! These three categories are most applicable to an organization that practices the traditional Waterfall model. Without diving into the everlasting Waterfall versus Agile debate, let's just say that these are categories that transcend any methodologies.

Even if they're not referred to by these names, they are the roles that need to be performed, to varying degrees, at various times. For completeness, it is worth noting one role specific to Agile, that of the scrum master.

A scrum master is a role often compared – rightly or wrongly – with that of the project manager. The key difference is that their focus is on facilitation and coaching, instead of organizing and control. This difference here is as much about a mindset than it is a strict practice and is often referred to as being attributes of Servant Leadership.

I believe a good scrum master will show traits of a good project manager at various times, and vice versa. This is especially true in ensuring that there is clear communication at all times and the team stays focused on delivering together.

Yet, as we look back at all these roles, it's worth remembering that with the advent of new disciplines such as big data, blockchain, artificial intelligence, and machine learning, there are new categories and opportunities to move from a developer role into a management position, for example, as an algorithm manager or data manager.

Despite what the word itself suggests, being a manager and having to manage people is, in fact, a misnomer. The modern English word is derived from the Latin word manus, which means hand, as in control, and does not include the meaning of man, as in a person. The meaning of the word manage in common usage has today evolved to essentially meaning to be responsible for, and in control of, a bunch of stuff.

I'll start by saying that managing people is something you should always prepare yourself for, because, regardless of whether direct team management is part of your role, you will always have a part to play in managing stakeholders, who are people. However, it's best not to confuse people management with stakeholder management, which is a topic all on its own and will be covered later in this book.

Back to the original question: does being a manager mean managing people? The answer in fact depends upon your exact job or role. Using the broad categories – Team / Development / Project Manager – that we've previously set out, your involvement and level of people management responsibility will differ at various times. Let's explore this question of people management one step further now by thinking about Maslow's hierarchy.

It's vital that you, your team members, as well as other managers, understand and agree on their responsibilities. This means defining what responsibilities people have, and where they begin and end for each person.

This clarity is important because it sets everyone's expectations accordingly. This sounds simple and easy but in reality, it is exceedingly difficult. There are several reasons why it's more difficult than it looks, and not the least of these is because people's needs change all the time!

Specifically, we are talking about higher-level needs, as defined in Maslow's hierarchy of needs, of which you can see a representation in Figure 1.2. These are essentially emotional needs, which sit above the basic physiological needs such as air, water, food, sleep, and shelter. Our basic physiological needs change all the time, from our choice of food to where we live, so, as you would expect, the higher level needs also change. Moreover, these higher needs are complex and deeply personal:

An example of applying the concepts from Maslow's hierarchy of needs can be dealing with a friend, because what you do to make them happy is different depending on their physical and mental state.

If they're sad, they may need a shoulder to cry on. If they're happy, they may need someone to share and celebrate with. If they're tired, you might provide them with somewhere to rest. Sometimes, however, what they really need is the opposite of what you might think! Your very tired friend might need some fresh air and exercise to reinvigorate them, rather than you simply providing them with somewhere to rest!

Being a people manager doesn't mean you have to become a professional psychologist or therapist. But like being a good friend, you need to be understanding and adaptable to their needs. It's about understanding their needs as well as your own, and, at times, putting their needs before yours. Knowing the boundaries of both your responsibility as a people manager, and what your team member does and doesn't want to share, is also particularly important. Everyone needs privacy, and everyone's ideas and limits of privacy are different.

I have discussed some very deep and personal thoughts and issues with individual team members, which include positive and negative feelings, ranging from delight and love, to hate and grief.

However, it's important to note that some team members prefer only to discuss work and keep most things private, and in general, there's no right or wrong, or even a magic formula for this. It's about what feels appropriate for you and them.

One aspect that is often forgotten about is the possible gap or overlap between people managers. In an era where we are all constantly busy and time-poor, there is a real risk of having only superficial, ticking-the-box, transactional dialogue. Far worse, a one-to-one meeting turning into a monologue with only the manager talking! Moreover, since people management is all about understanding and giving your team member what they really need, this can be counterproductive.

This is especially true in a matrix management structure, where a person can have multiple managers. If the managers involved are not clear on what aspect they are responsible for, or neglect that responsibility, then the person ultimately may not be managed appropriately. Conversely, as the old saying goes, "Too many cooks spoil the broth." If a person is ill and cannot come into work, having multiple managers call to ask, How are you? or What's wrong? will most likely be counterproductive.

The art and science of people management is a remarkably interesting and broad topic, and while there is no magic formula or one-size-fits-all approach, there is an entire range of research and tools. Like a good developer, a good manager will also have a suitable toolkit, which we will discuss in more detail throughout this book.

The "Accidental Manager" is perhaps ubiquitous now more than ever, but the concept has been around for a long time. The Peter Principle, by Laurence J. Peter, introduced the concept that people successful in their role are promoted until they reach a level where they are no longer competent, and that was published back in 1969!

This idea was further popularized by the Dilbert cartoons, in which the Dilbert Principle mocks the notion that the least competent people are given more managerial responsibilities and power, which is often misused. Quite simply, the "Accidental Manager" can be characterized by a person who reluctantly, unknowingly, unintentionally, or inadvertently becomes a manager.

Perhaps the people management responsibility has defaulted to the "Accidental Manager" because the incumbent manager is too busy, or perhaps the organization has created the new position and has mandated that a person from the existing hierarchy and team takes on the post.

It is of course possible that the manager position has been removed altogether to reduce headcount, but all their responsibilities still need to be picked up by someone, or perhaps the organization has struggled to recruit for this position from the labor market, and "you're it" until they find someone better! There are many circumstances where an accidental manager is created.

In the organization's defense, from their perspective, succession and continuity are rarely easy. Taken to the extreme, the alternative would be to promote someone who is clearly struggling in their current role. Out of the two choices, it's logical to opt for the seemingly more reasonable option. So, if you are an accidental manager, take it as a compliment and confidence booster. It's in your organization's interest to set you up to succeed, and there are people who believe you are capable of becoming a manager.

Rewarding underperformance, as opposed to achievement, could be seen as a blow to the morale of others and a cultural disaster affecting the organization's core people values. It would be a realization of the Dilbert Principle! Ask yourself the following questions:

• You're a brilliant developer. Can you manage the team as well?
• You're a brilliant developer. Can you manage some projects, too?

So, what does all this mean to you, and how can you understand it and use it to your advantage? For argument's sake, let's say you are a brilliant developer, probably the best among your peers as recognized by the organization. In that case, there's a chance you could become an accidental manager if the circumstances arise, and perhaps you already are. Being an accidental manager can be interpreted as a purely negative thing, a lesser version of what you may think of as being a "real manager," but let's be clear - it is not!

Circumstances create the accidental manager, but they don't define the person in this position. The key to making this accidental journey a success is to embrace it and get the required training and support – as little or as much as you need, when you need it.

Recognizing that you may not know what you need is an important first step. It is also an ongoing management skill to learn as you develop, which we will discuss later in the book. So, part of the support structure you will need around you is someone who will constructively point out your blind spots.

Everybody has blind spots, so spot them early instead of ignoring them. In fact, the Johari Window, which you can see in Figure 1.3, allows you to think about your own strengths and weaknesses, your blind spots, and ways or people that can help detect them:

One key thing for all managers to avoid, but especially for accidental managers, is what technologist and writer Peter Gillard-Moss calls imposter syndrome. This is when an often newly promoted manager feels compelled to show that they know everything, even when they don't.

When imposter syndrome sets in for a manager, an array of negative behaviors and impacts can result, including becoming ever more insecure about your position of responsibility and alienating your own team because you're killing their motivation to collaborate and be creative. Not to mention that the manager is stressing themselves out by trying to stay on this treadmill, which only goes faster and faster, even if they're still going at the same speed. The most common way to be a victim of imposter syndrome is to believe that your superior technical ability and/or experience entitles you to be a manager and to lead.

A simple hack to avoid imposter syndrome is to recognize and admit that there will always be things you don't know and aren't even aware that you don't know! This is what makes the journey interesting, and you should never be in denial that there is still so much to learn, no matter how much you think you already know.

On the other hand, it is important to keep this in balance with what you do know. One of the key tools to achieve this is the Known/Unknown matrix, or the Rumsfeld Matrix, which was made famous by Donald Rumsfeld, the former U.S. Secretary of Defense. This chart can be a valuable tool to track your progress and ongoing development as a manager.

The first version you produce will give you an idea of where you need to focus your efforts on learning initially, and, as you repeat the exercise regularly, you can use it to assess your proportion of knowns and unknowns.

As you become more experienced and confident as a manager, you will trend toward more knowns versus unknowns. The idea is not to eliminate all unknowns, but to simply understand what they might be, while affirming and reaffirming the things you are knowledgeable and confident on. Here is an image of the Rumsfeld Matrix:

As an accidental manager, you may not have had the time or opportunity to prepare for the new responsibilities to shape the role before being "it." You can, and should, use this to your advantage. As a newly bestowed accidental manager, you need to maximize the opportunity to ask open and unassuming questions. Tell people that while you don't know something, you want to learn, using open questions like these:

• Where can I get more information on this?
• What are the pros and cons of this process?
• Can you help us to improve this?

Ultimately, as you learn more, your proportion of unknowns will decrease, while the proportion of knowns will increase. As a result, you'll progress along the learning curve, which is no different from learning a new technology as a developer.

When you start, you are likely to have more unknowns than knowns, and you'll be asking more questions than answers. But don't – and never let yourself – be put off! You are still adding value by asking these questions, both to yourself and to the team and organization.

In fact, asking the right questions is often cited as the most important and powerful skill in senior management. This is often referred to as part of corporate governance. Think about the latest corporate scandals and crises in large-scale organizations, which are often traced back to a lack of adequate corporate governance. Those at the very top can fail to recognize the impending cliff edge that the organization is headed toward until it's too late.

To be reasonable, a manager is not expected to know absolutely everything that is happening at any one time. This reinforces the need to ask judicious questions at the right moment, and, in return, getting truthful and insightful answers back. Especially as an accidental manager, one of the key behaviors you should learn and demonstrate early on is the canny shrewdness to ask challenging questions. This has the power to make people respect you, even if your domain knowledge level is low.

Transitioning, growing, progressing, or simply changing from a developer to a manager is a wonderfully rewarding journey that is unique to everyone. I hope you now have a better idea of your personal response to the original fundamental question that we asked in the introduction.

Just for a minute, think back to the opening of this chapter. It was a thought-provoking statement that said that you're a confident and brilliant developer / coder / programmer / techie. So, why do you want to become a manager?

Just as in software development, there is not necessarily a right or wrong way to answer this question. If you are still struggling to answer this, that's perfectly okay. There are a lot more ideas and considerations to think about, which we will cover throughout the upcoming chapters.

It's important to note that it is completely normal to have reservations and even doubts anywhere along the journey to becoming a manager. Having doubts at the start is not only normal, but also potentially advantageous because it's always good to fail fast, learn, and improve. It's the Holy Grail of a more efficient feedback loop, just like in software development.

If you do have a definitive answer to this question and are eager to start your journey, then that's great too. Once you know what your way is, that being whatever is at the center of your motivations, everything can be rooted in these foundations. Whether it's more money, power, responsibility, kudos, or something entirely different, it must be clear and convincing enough to keep you motivated for the long haul. The Golden Circle by Simon Sinek is a simple model that can help you to frame your thoughts and guide yourself toward your why.

Overlaying your risk-versus-reward considerations on top of your why will give you a solid base to decide whether, and how, you should set off on your transitional journey to becoming a manager. Most importantly, this will help you understand the impact of your decision. Be prepared to answer the critical question: "What if you fail constructively?" Remember that progress is not a straight line, and you should always be willing to accept that there are risks that go with the rewards.

In planning your journey, knowing where you currently are is a vital step, just like a navigator getting their position and bearings. By doing a focused retrospective review on your career so far, you will learn more about yourself – specifically, your preference and tolerance to less technical, more managerial tasks. By doing a little analysis of your work time, you can gain real insight into whether you are already doing, and enjoying, lots of the managerial tasks.

The legendary management guru Peter Drucker's Time Log method is the perfect tool to quantify and discern your current mix of developer and management work. You will also debunk the notion that becoming a manager is a gargantuan leap, and you can confidently reassure yourself that you already have some experience and achievements to be proud of.

After clarifying what being a "Modern Manager" really means, and the broad categories applicable in software development (Team / Development / Project / Agile manager), the overarching and often key consideration for developers is whether it means they will be managing people and writing less code.

While this is a big and nuanced topic, you can rest assured that it isn't as daunting, or indeed as difficult, as you might think. However, it will require you to be open-minded and receptive to learning new skills along the way, with a focus on fewer technical skills and fewer binary concepts. Consider, as an example, the art of negotiation and stakeholder management.

If the type of manager you wish to become does include the privilege of managing people, then there are extra considerations for you to ponder, because people management is certainly not a trivial responsibility that can be taken lightly.

As a people manager, you have a professional and moral responsibility to lead, protect, nurture, serve, and constructively challenge your team members. This is one of the key areas you will need to have support and mentorship in. So, when you are building your overall support network, finding some extra resources to help you with people management is highly recommended.

To help you tackle each challenge, a comprehensive toolkit for a new developer-cum-manager will be provided and built on across the coming chapters. This is one of the main aims of the book and will include exploring the various elements of managing people in a team. While there's no magic one-size-fits-all formula, there are proven approaches and techniques that can be applied to help you become the best manager you can be.

In today's fast-moving work environment, a common way for a developer to become a manager is often "by accident." The emergence of the "Accidental Manager" is not a new phenomenon. While it is the butt of most Dilbert cartoon jokes, the circumstances in which an accidental manager is created do not define the manager themselves. It can actually create genuine opportunities to ask quality questions from a fresh perspective and add value on a different level.

Look out for imposter syndrome and refrain from succumbing to your insecurities. By using classic and powerful tools such as the Johari Window and the Rumsfeld Matrix, you can become comfortable in knowing your own strengths and weaknesses, your blind spots, and ways that people can help to detect them. Above all, if you do find yourself becoming an accidental manager, take it as a compliment that the company needs you now more than ever, and use it to your advantage!

In the next chapter, What Are the Key Skills I Need?, we'll look at the key skills you need to undertake your journey from developer to manager.