From Coding To Management To Leadership

Lorenzo Pasqualis on September 04, 2017

This post was first published on CoderHood as From Coding to Management to Leadership. CoderHood is a blog dedicated to the human dimension of soft... [Read Full]
markdown guide

Great post, Lorenzo. Thanks for your work. I agree with almost everything. I have one comment and one question:

My comment: You conflate management and leadership, like leadership is somehow the progression path of the manager. This is actually quite common (a lot of others do it), but I don't think it's accurate. I think leadership and management are very different things, and few people excel at both.

Personally, I like the definitions by Marcus Buckingham: A manager is a coach who brings out the best in her people. Her focus is on each individual. A leader is a visionary who rallies people around her idea of the future - be this the future of a product, or a company. Her focus is towards the outside, and towards the future.

Ultimately, it is a matter of how you define leadership, so it's always a bit random. However, I find the definition you have given a bit unsatisfying. If a manager becomes better and better at his job, this does not necessarily mean that we need a new name/title for him: "Now you are not a manager any more, but you are a leader!"

After all: When a developer progresses, and accomplishes what you describe above ("knowing how to write the algorithms, solve problems, structure your code and design systems"), do you invent a new title for him, as well? "Now you are not a developer any more, but you are a ... senior developer? Ninja?"

That was my comment.

My question: You ask the aspiring manager to decide how they would measure their performance. I'm curious: How would you, or do you, measure it?


Thank you for your very thoughtful comment.
There is much that could be discussed about the difference between management and leadership and it does come down to definitions, as you said. I used to see it the way you define it, but I changed my view a few years ago. I love the way Max Depree talks about it in his book “Leadership is an art”. He says “The first responsibility of a leader is to define reality. The last is to say thank you. In between, the leader is a servant.”

In the long term, I measure my performance by measuring the impact of my efforts. The impact is the delta between what happened because of me vs. what would have happened if I was not there.
In the short term (daily) I measure it by asking myself if I made a difference to people and/or the organization, that day.


Putting "Leadership is an art" on my reading list, thanks :-)

About measuring your impact, or productivity, as a manager: I wrote Recalibrate Your Productivity Sensors some time ago, maybe you find it helpful. It talks about how, as a manager, most of the metrics of productivity you had as a developer just go away, and you have to find new ones. I think it arrives at a similar conclusion as you do: Make a difference to people and the organization. Unblock, teach, listen, encourage, give feedback, bounce ideas back and forth, etc.


Thank you! It is a pleasure to post on Thank you for creating this community and for making it so open and welcoming to contributions.


Great post, thank you. I'm just recently finding myself at the leadership/technical fork in the road and unsure of where I want to end up, and this post has helped clarify some things for me.

For those without management experience, are there any resources that you can recommend?


Adam, I would like to add The Manager's Path to Lorenzo's list of books. It's very actionable, concise, and practically relevant.


I just wanted to follow up on this by saying I've read the book through and it's an excellent, enlightening read. Thanks again!

I'm glad to hear that. Thanks for getting back to me :-)


The straight path continues through a familiar technical landscape. In this direction, most problems are solvable logically and intellectually, with tools and systems built to help. The biggest challenge on the technical path is keeping relevant with the time.

I find myself heading down the technical path (which is difficult... many organizations setup management as the only real advancement path). But I don't agree with your characterization... technical is a hard, scary path too. As a technical lead, the problems I need to solve often have no obvious answer. Usually the key to finding the "right" way is seeing the issue from as many perspectives as I can. IOW, picking the most optimal trade-offs for all parties concerned. And this is a shifting target. It is a large responsibility, and often even my spare time is focused on research. Being a technical lead requires you to be business-aware and people-aware, but primarily for being able to translate these concerns into technical qualities of the software / operations.

Leading on the technical path requires soft skills too. Often my day is mostly spent mentoring or helping people work through problems they are stuck on. Usually we just talk it through, but sometimes pairing is involved. From time to time, I need to talk with customers and stakeholders to try to understand the goals behind their feature requests. I also have user stories to finish, often ones related to architecture (e.g. implement optimistic concurrency so I can go with fully stateless services, enable blue-green deployments, etc) or canary-ing new integrations which others can add onto later. At times it is hard to get my own stories done among all the other things. But that's ok! I took the path because enjoy learning and growing technically. And that has certainly been happening. :)


Thank you for your note. I don't disagree with anything you said. The tech path is very hard.
In my post, I said that it is "familiar" making the assumption that the reader is a developer who is familiar with the difficulties of that path.
For a developer, management can appear scary because it is a completely new direction.
I had no intention to imply that the technical path is easy or relaxing. Far from it. I also agree with you that technical leadership requires many soft skills, even if you are not managing the people you work with.
The biggest difference is in the type of problems you need to contend with using soft skills. As a tech lead you can keep it technical, so you need to know how to approach developers on technical subjects. As a manager, you have to add the soft skills necessary to deal with much more personal issues such as friction between employees, health issues, promotions and raises, performance issues, team building activities, career management, career mentoring, etc. Those are the kinds of things that, in my experience, make management "scary" for tech types.


I have to learn how to interact with people, mentor them, coach them and get out of their way so that they can do their best work.

Thanks for great post.

I just got a position as development manager, i want to lean how to interact with people, mentoring, team leading in better way.

What should i do? Should i join a course?

What did you do learn all this?


There isn't a silver bullet, but there are many things you can do.
What I did:

1) I realized that being a development manager is a different job than being a developer. Depending on your level, you can still code, but priority must be given to people (not code).
2) I read everything I could about leadership, emotional intelligence, effective communication, personal interactions, etc.
3) I had a great mentor. Having a strong mentor to brainstorm situations and learn "how to think" on a daily basis is a great thing.
4) Experience. As for everything, you need practice. You get better as you go.

Just like coding, leadership is a journey, not a destination.

code of conduct - report abuse