As I’ve been working with developers looking to grow with their careers, I’ve been asked one question (or variations on it) repeatedly:
How do I grow my career while remaining technical? I don’t want to be a manager, I want to be a senior technical leader.
That question has prompted me to think about my own career, and what it means to be a senior technical leader. I’ve come to this conclusion:
Growing and having more influence means scaling your reach.
Let me go into some detail about what I mean by that statement.
No matter how good you are, there’s only so much code you can write. Being more senior doesn’t mean you code faster. You don’t finish designs exponentially faster. You are still a single individual, and you will still only get so much done in so much time.
Managers scale because have significant influence on their staff. To grow as a technical leader, you need to answer the question of how you scale? If you continue to view yourself as an “individual contributor”, you will find that you reach a point where you cannot continue to grow. (It’s even more important for your management to have a good answer to how you scale in the organization.)
Your value as a technical leader is measured by the positive influence you have on the other members of the team.
There are many ways that your technical skills can scale across your team. They all have a common theme: As a technical leader, your responsibility is to raise the technical skill level of the development team as a whole.
Here are a number of examples that your could take on to have a positive influence:
If you follow all those suggestions, you may become a very respected senior leader for your tech team. Or, you may be seen as that jerk that criticizes everyone.
It’s about how you deliver your ideas.
The best senior technical leaders have learned how to critique, teach and help people grow. They are able to make suggestions that help people grow. They are able to have people take pride in their work, and yet want to improve it.
If you want to take on this role, you need to spend a lot of time working on how you deliver your ideas to your peers, and to the team members you want to view you as a technical leader. You’re not a manager; you have no real authority. You need to work on your inter-personal skills, and grow the muscle to affect change with everyone on your teams.
Yes, I’m talking about soft skills.
One of the best bits of advice I ever received was this:
There are few people that listen. Most are just waiting for their turn to talk. Be a listener.
These developers you want to mentor: they have knowledge you don’t. They’ve thought about the problems at hand. They are doing the best work they can today. Your job as a mentor is to tell them they are wrong, but to augment their thinking with your insight. That’s only possible when you listen to the thought process behind their design and code. You have to learn as much as you can about the problem, the proposed solution, and the thinking behind the process.
Only after you have listened, and learned as much as you can, will your guidance carry weight.
The last piece of the puzzle is to determine if your current organization’s culture values the role of a technical leader. Some do; some do not. You need to work with your managers to see if that role exists in your orgamnization.
If not, you can work with your managers to create it.
And, if your company and your management team aren’t interested in a role you want, you need to decide if it’s the right fit for you.
More and more, it is possible to remain in a technical role and achieve career growth. You need to learn how to make technical skill scale across an organization. You need to convince the team and management of it’s worth. Most importantly, you need to grow the skills needed to be viewed as a technical leader.
The subtitle of Mary and Tom Poppendieck’s latest book is “Ask the Right Questions”. This book guides you to a different Mindset, the Lean Mindset.
They begin by defining a Mindset as a mental model that enables us to make decisions. Throughout the book you are led by Anna and Otto, two characters that represent two modes of thinking. Otto is our everyday mind, where we make most of our decisions.He makes decisions on autopilot, adjusting quickly to any new situation. Otto uses his current mental models to guide his thoughts and actions. Anna is far more analytical. She analyzes the data behind everything and makes decisions slowly and in a measured fashion. She’s more likely to apply new models to new situations. Together, these two different ways of thinking provide a balanced view of the world and help us make great decisions. Throughout the book, they’ll show you how using both your current mental model, and questioning that model, you can improve yourself and your organization. One skill is learning to both modes of thinking appropriately.
The Poppendieck’s have again written a great book that will make you think about your organization, and how to make it better. It’s not a long book. It can be read over a weekend. but it will make you think, and think deeply.
The book is divided into 5 chapters.
The first, The Purpose of Business, discusses the Shareholder Value Theory, and Rational Economics. Then, they discuss alternative business theories, such as cooperative work systems. They stress the wisdom of centering your business around your customers. You must define your customers, your business, and the reason for your business’s existence.
The second, Energized Workers,explores techniques that can motivate and energize workers in your business.Poppendieck’s guide us through several case studies where organizations have created an environment where workers achieve beyond normal expectations. As you’ll learn, it takes empowerment and trust, among other things.
The third chapter, Delighted Customers, is a great read for anyone in an organization practicing Agile Development. Poppendieck’s talk about the risk of building just what is required, and never building features that truly delight customers. Again, case studies are provided from companies whose products delight you.
Chapter 4, Genuine Efficiency, talks about the tensions between productivity and flow efficiency. You’ll also learn the keys to energizing your team to build the right product, and to learn as quickly as possible what products and features are delighting customers, and which are not creating the reaction you want.
The final chapter, Breakthrough Innovation, provides a few case studies on companies that have made great innovative changes to their business and achieved great success. You’ll learn about a very successful news publisher, and how Intel moved from memory chips to CPUs.
This is not a cookbook filled with recipes you can just follow. In fact, Poppendiecks’ point out that the case studies in the first and 5th chapters follow opposing recommendations. What works for one company will not work for everyone. You must ask the right questions in order to find the right path for your organization.
Like all of the Poppendiecks’ books, I highly recommend this book. It provides many thoughtful questions that will help you make your organization more effective, following a lean mindset. If you want your organization to improve, you need to read this, and think about how it can help your organization.
I really enjoy creating software. I’m thrilled to be part of this industry, and able to create useful apps for people our customers. But yet, if we want to remain productive and engaged throughout our careers, we need to actively exercise other parts of our brain from time to time.
It’s too easy for many of us to fall into that trap of doing the familiar, working the same way, choosing the comfortable path. That kind be stifling. You do the same things the same way, and it becomes habit.
If you want to stretch, you need to open yourself to new ideas, make your brain do different things, and grow.
That’s why we did a workshop this past winter with The Improv Effect. It was an exhausting afternoon of fun. Our entire team ran a number of different exercises. Throughout the afternoon, everyone was laughing, thinking, and trying to produce the best improv sessions we could. it was fun because the exercises are designed to apply humor to your daily activities. you look at challenges from a different perspective when you’re trying to make them humorous. It was exhausting because you use very different parts of your brain than you do when creating code. You’re reacting to your partners in Improv. You’re listening very carefully. You’re doing the first thing that comes to mind. You’re going to make mistakes and fail. A lot. And then, you need to recover.
Because of all that, maybe software development should be more like Improv. We should handle change. We should handle updates. We should handle mistakes. If you’re tasked with making innovative applications, stretching the boundaries, and implementing new ideas, maybe you need to treat your brain the same way: Stretch it. Try new things. Innovate in different areas.
I encourage you to try totally new disciplines. We found Improv a great way to expand our minds. I encourage you to do the same. And, if Improv isn’t your thing, look for other opportunities to grow your brain in other areas.
All of these projects are Open Source (using the Creative Commons license for content, and the MIT license for code). If you would like to contribute, visit our GitHub Repository. Or, if you have questions, comments, or ideas for improvement, please create an issue for us.