Your New Technical Skills


One of the struggles a developer faces when moving up the ladder is how to keep their technical skills.

If they are used to being a high-performing, individual contributor, and a technical go-to resource, this is especially challenging.

Why?

Because the job is different, now.

It’s no longer about how awesome your developer skills are.  Now it’s about bringing out the best from the people you manage, and hopefully *lead.*  Your job is now about creating a high-performing team.   It’s about growing more leaders.  It’s about being the oil and the glue.  The oil so that the team can work effectively, as friction-free as possible, and the glue, so that all the work connects together.

There’s a good book called What Got You Here, Won’t Get You There, by Marshall Goldsmith.  The book title sort of says it all, but the big idea is that if you take on a new management role, but continue to perform like an individual contributor, or at a lower level, don’t expect to be successful.

The irony is that most people will quickly default to doing what they do best, which is what got them to where they are.   But now the rules have changed, and they don’t adapt.  And as the saying goes, adapt or die.  It’s how a lot of careers end.

But not you.

While you will want to keep up your skills that got you to where you are, the real challenge is about adding new ones.   And, at first blush, they might just seem like “soft skills”, while you are used to learning “technical skills.”   Well, treat these at your new technical skills to learn.

Your new technical skills are:

  1. Building EQ (Emotional Intelligence) in teams
  2. Building High-Performance Teams
  3. Putting vision/mission/values in place
  4. Putting the execution model in place
  5. Directing and inspiring as appropriate – situational leadership – per employee
  6. Creating and leverage leadership opportunities and teachable moments
  7. Creating the right decision frameworks and flows and empowerment models
  8. Building a better business
  9. And doing thought-work in the space for the industry

I’ll leave this list at 9, so that it doesn’t become a 10 Top Skills to Learn to Advance Your Career post.

Emotional Intelligence as a Technical Skill

If you wonder how Emotional Intelligence can be a technical skill, I wish I could show you all the Mind Maps, the taxonomies, the techniques, the hard-core debates over the underlying principles, patterns, and practices, that I have seen many developers dive into over the years.

The good news is that Emotional Intelligence is a skill you can build.  I’ve seen many developers become first time managers and then work on their Emotional Intelligence skills and everything changes.  They become a better manager.  They become more influential.  They read a room better and know how to adapt themselves more effectively in any situation.  They know how to manage their emotions.  And they know how to inspire and delight others, instead of tick them off.

Along the lines of Emotional Intelligence, I should add Financial Intelligence to the mix.  So many developers and technologists would be more effective in the business arena, if they mastered the basics of Financial Intelligence.  There is actually a book called Financial Intelligence for IT Professionals.   It breaks down the basics of how to think in financial terms.   Innovation doesn’t fund itself.  Cool projects don’t fund themselves.  Technology is all fun and games until the money runs out.  But if you can show how technology helps the business, all of a sudden instead of being a cost or overhead, you are now part of the value chain, or at least the business can appreciate what you bring to the table.

Building High-Performance Teams as a Technical Skill

Building High-Performance Teams takes a lot of know-how.  It helps if you are already well grounded in how to ship stuff.  It really helps if you have some basic project management skills and you know how to see how the parts of the project come together as a whole.  It especially helps if you have a strong background in Agile methodologies like Kanban, Scrum, XP, etc.  While you don’t need to create Kanbans, its certainly helps if you get the idea of visualizing the workflow and reducing open work.  And, while you may not need to do Scrum per se, it helps if you get the idea behind a Product Backlog, a Sprint Backlog, and Sprints.  And while you may not need to do XP, it helps if you get the idea of sustainable pace, test-driven development, pairing, collective ownership, and an on-site customer. 

But the real key to building high-performance teams is actually about trust. 

Not trust as in “I trust that you’ll do that.”  

No.  It’s vulnerability-based trust, as in “I’ve got your back.”   This is what enables individuals on a team to go out on a limb, to try more, to do more, to become more.

Otherwise, they everybody has to watch out for their own backs, and they spend their days making sure they don’t get pushed off the boat or hanging from a limb, while somebody saws it off.   (See 10 Things Great Managers Do.)

And nothing beats a self-organizing team, where people sign-up for work (vs. get assigned work), where people play their position well, and help others play theirs.

Vision, Mission, Values as a Technical Skill

Vision, mission, and values are actually some of the greatest technical skills you can master, for yourself and for any people or teams you might lead, now or in the future.   So many people mix up vision and mission.

Here’s the deal:

Mission is the job.

Vision is where you want to go, now that you know what the job is.

And Values are what you express in actions in terms of what you reward.  Notice how I said actions, not words.  Too many people and teams say they value one thing, but their actions value another.

It’s one thing to go off and craft a vision, mission, and values that you want everybody to adhere to.  It’s another thing to co-create the future with a team, and create your vision, mission, and values, with everybody’s fingerprints on it.  But that’s how you get buy-in.   And getting buy-in, usually involves dealing with conflict (which is a whole other set of technical skills you can master.)  

When a leader can express a vision, mission, and values with clarity, they can inspire the people around them, bring out the best in people, create a high-performance culture, and accelerate results.

Execution as a Technical Skill

This is where the rubber meets the road.  There are so many great books on how to execute with skill.  One of my favorites is Flawless Execution.  And of the most insightful books on creating an effective execution model is Managing the Design Factory.

The main thing to master here is to be able to easily create a release schedule that optimizes resources and people, while flowing value to customers and stakeholders.

I know that’s boiling a lot down, but that’s the point.  To master execution, you need to be able to easily think about the challenges you are up against:  not enough time, not enough resources, not enough budget, not enough clarity, not enough customers, etc.

It’s a powerful thing when you can turn chaos into clarity and get the train leaving the station in a reliable way.

It’s hard to beat smart people shipping on a cadence, if they are always learning and always improving.

Situational Leadership as a Technical Skill

Sadly, this is one of the most common mistakes of new managers.  Seasoned ones, too.  They treat everybody on the team the same.  And they usually default to whatever they learned.   They either focus on motivating or they focus on directing.  And directing to the extreme, very quickly becomes micro-managing.

The big idea of Situational Leadership is to consider whether each person needs direction or motivation, or both.  

If you try to motivate somebody who is really looking for direction, you will both be frustrated.  Similarly, if you try to direct somebody who really is looking for motivation, it’s a quick spiral down.

There are many very good books on Situational Leadership and how to apply it in the real world.

Decision Making as a Technical Skill

This is where a lot of blood-shed happens.   This is where conflict thrives or dies.   Decision making is the bread-and-butter of today’s knowledge worker.  That’s what makes insight so valuable in a Digital Economy.  After all, what do you use the insight for?  To make better decisions.

It’s one thing for you to just make decisions.

But the real key here is how to create simple ways to deal with conflict and how to make better decisions as a group.   This includes how to avoid the pitfalls of groupthink.  It includes the ability to leverage the wisdom of the crowds.  It also includes the ability to influence and persuade with skill.  It includes the ability to balance connection with conviction.  It includes the ability to balance your Conflict Management Style with the Conflict Management Style of others.

Business as a Technical Skill

Business can be hard-core.   This isn’t so obvious if you deal with mediocre business people.  But when you interact with serious business leaders, you quickly understand how complicated, and technical, running a business and changing a business really is.

At the most fundamental level, the purpose of a business is to create a customer.

But even who you choose to serve as your “customer” is a strategic choice.

You can learn a lot about business by studying some of the great business challenges in the book, Case Interview Secrets, which is written by a former McKinsey consultant.

You can also learn a lot about business by studying which KPIs and business outcomes matter, in each industry, and by each business function.

It also helps to be able to quickly know how to whiteboard a value chain and be able to use some simple tools like SWOT analysis.  If you can really internalize Michael Porter’s mental models and toolset, then you will be ahead of many people in the business world.

Thoughtwork as a Technical Skill

There are many books and guides on how to be a leader in your field.   One of my favorites is, Lead the Field, by Earl Nightingale.  It’s an oldie, but goodie.

The real key is to be able to master ideation.  You need to be able to come up with ideas.   Probably the best technique I learned was long ago.   I simply set an idea quota.   In the book, ThinkerToys, by Michael Michalko, I learned that Thomas Edison set a quote to think up new ideas.  Success really is a numbers game.   Anyway, I started by writing one idea per note in my little yellow sticky pad.  The first week, I had a handful of ideas.   But once my mind was cleared by writing my ideas down, I was soon filling up multiple yellow sticky pads per week.

I very quickly went from having an innovation challenge to having an execution challenge.

So then I went back to the drawing board and focused on mastering execution as a technical skill Winking smile

Hopefully, if you are worried about how to keep growing your skills as you climb your corporate ladder, this will give you some food for thought.

Comments (12)

  1. niclas lindgren says:

    i think there is a problem if moving up the ladder means you stop doing what you ae skilled at, it should be taking on more difficult problems requiring more skill in the same area. why are there no carrier paths to keep your talent doing what they do best?

    managing people is a completely different skill and i find it odd that this is moving up the ladder if your expertise is technical, it is a different carrier.

    something's badly missing, you'll get bad managers and worse technical people as those that remain age obviously not as skilled as they were not promoted...

  2. JD Meier says:

    @ niclas -- Let's explore that.

    Moving up isn't about solving harder problems.  It's about creating more value for the business.

    You can scale yourself up, or you can scale yourself out.

    If you scale yourself up, as far as the business is concerned, you're a good server in the farm, but the server farm is worth more.

    In general, if you want to expand your scope, sphere of influence, and impact, you need new skills, and you need to solve adaptive challenges, not just technical challenges (for the distinction, read Leadership On the Line.)

    If you ran a business, you would probably give more responsibility and bigger rewards to those that created more customers, added new customer segments, added more wallet share, reduced cost of sale, reduced time to market, or grew revenue.

    The bottom line is, the better you connect your contribution to business impact, the more your "career path" will be there for you.

    Personally, I abandoned career paths long ago, and chose to focus on growing my technical skills, business impact, and creating epic adventures with great people at work, while living my values, and driving from my lifestyle.

  3. Niclas Lindgren says:

    @jd

    It depends I think. What you are saying it just further validation of what I am trying to say.

    You seem to be claiming that leadership is a harder and more valuable and thus harder to recruit for. I believe this is not true. Actually I would to claim that staying attuned to your technical skills is a life long never ending pursuit of learning and relearning more than honing of learnt skills like many of those you suggest should be picked up to move up the ladder.

    I believe it is unfortunate of a company to value those that create customers above those that actually please the customers. Because in the long run, for a technical company, if you don't please your customers you will not be able to create more customers. It is just two different skill sets and two different jobs, one not necessarily worth more than the other

    I find it sad that companies won't create proper technical corporate ladders because it would likely be very beneficial in the long run instead of losing those people in the leadership ladder. And in that way drain your technical pool of talent for leadership people that might be better suited for people with non technical skill sets. Of course there are different kind of leadership and there needs to be technical leaderships too, but those leaders are more like playing coaches not your report points.

    You can be a good leader without any technical skills and vice versa. A very proficient surgeon is probably not worth more being the head of surgeons than actually doing surgery. Actually he/she would probably be a pretty poor surgeon given a few years without hands on.

    I chose surgery because it also requires that you relearn what you once new, because new techniques are developed all the time.

    In the software world things are even more interesting and faster, a good product can sell itself, find new segments by itself if it is good enough. But it cannot build itself and it is ever changing.

    The last thing you can likely remove from a software product is developers/technical skillsets. Well you can, but the product will slowly die.

    All I am saying, I believe companies under value the value of technical expertise when the only way to move up the ladder is to diverge from the technical path.

  4. Niclas Lindgren says:

    Had to split in 2 posts, got a bit long, 2nd part..

    ----

    I also think an empowered agile teams will provide a lot of the values indirectly by themselves.

    I am not saying that the skillsets you lists are valuable, they are, and should be picked up by most teams, they should be thinking about how they align their daily work with the company and its business impact, I am questioning the core value of the companies that to do not provide a technical corporate ladder as it might force your 10x people out of your technical pool, and they are needed just as in any area.

    I do believe though that your final conclusion about abandoning career paths is very healthy and something companies should look into and instead drive value in other ways. Driving epic adventures with great people at work is exactly spot on, if you can accomplish that with your employees your business will likely succeed and that is what I would work on creating an environment for and value above any career paths

  5. JD Meier says:

    @niclas -- Not every surgeon can be a Chief of Surgery.  

    If that proficient surgeon becomes a Chief of Surgery, it's no longer about their surgical skills -- it's now about their ability to ensure the highest standards of quality and service are maintained across the hospital staff, directors, and physicians. (e.g. scale their impact and grow more profiecient surgeons)

    If they want to keep doing surgery, then they stay a surgeon.  And they can be a super surgeon.

    I think you missed the point that the scenario in this post is about how to re-think your skills if you take a leadership position -- and you don't have to take the position.

    But if you step into a role where you are supposed to lead people, and you fail to learn those skills, then you fail yourself and you fail the people that count on you.

    If you want to keep cooking, don't become a head chef.  If you want to keep on doing surgery, don't become a Chief of Surgery.  In other words, look before you leap, and if you do leap, then learn what it takes to succeed.  

    And if you stay as an individual contributor, sure you can keep improving your skills, but don't expect to be rewarded like leaders that scale their impact. (Not because of harder, easier, better or whatever ... it's simple economics.)

    Here's the good news -- you'll be less limited as an individual contributor if you learn the basics of EQ.  

    And, you don't need a formal role or title or position to be a leader -- you can amplify your impact and influence from wherever you are.

    And, you don't have to be a great thought-leader to be a great people leader, or a  great people-leader to be a great thought leader.

    Very few things are ever mutually exclusive if refuse the sucker's choice.

  6. Niclas Lindgren says:

    @jd I completely agree that if you step into a role as a leader you need to pick up those skills, formal or informal. But as you say I fail to see your point you seemingly fail to see my point.

    A head of surgeon does not have to come from a pool of surgeons. Also there is a vast difference between a EQ leader and a technical leader.

    Perhaps I am misinterpreting your post, but to me you were talking about corporate ladders and how to take the next step and thus losing your technical skills. And what I am saying is, if that is the only next step available in the corporation for you technical leadership it will deplete the technical pool and might actually create so so leadership, hampering your technical development.

    You need strong technical leadership from people who actually keep their technical edge and they should be as valuable as any other kind of leadership and it must not result in them losing their technical contribution it should scale their contribution.

    To me it sounded like you cannot have great impact and scale yourself in the company without losing/give up your technical skills and I argue that retain them while adding a few other skills, but not core skills.

    And I totally agree that you don't need to be a formal leader to have great impact, but if the company is not putting value in their informal leaders you still end up with my first gripe.

    Because it is also simple economics that if a tech company lose their technical edge they will fall into non existence.

    And I also totally agree that using the mentioned skill set will help you contribute on a larger scale.

    what I am trying to say is that a talented super surgeon will actually contribute to the enhancement of all the other surgeons (and his/her field), that is a the definition of the 10x surgeon. He/she did not trade his/her core skills for another set of skills but he/she might actually have to if that is the way to progress, if progress is measured in paycheck/benefits impact at least.

    Also moving a technical person into a EQ leadership role can actually hinder the technical growth as the technical person will still try to do technical leadership in his new role and not delegate and relinquish the technical development to the one supposed to pick up the technical leadership. (all technical decision still have to go through him/her, even if the role is different). Which I guess is a bit what you are saying.

    Also amplifying your technical impact when you lost your technical edge is likely not a good idea, which might happen a few years (or months even in the tech world), so one has to be careful their.

    Looking at Microsoft a bit from the outside the last couple of years, it feels as if the technical edge is not valued enough, which is why I wanted to comment on your post to pick your view of that.

  7. Niclas Lindgren says:

    @jd Just to be clear, I was talking more about the value ladder of a the company than the benefit of the skillsets which I don't question at all.

    I am arguing you need technical leadership roles that have the same scale and impact and valued equally. And if you make one path formal you will need to make the technical path formal too or you risk depleting the pool (or them changing jobs)

  8. Niclas Lindgren says:

    @jd Thanks for taking the time to answer and Merry Christmas!

  9. JD Meier says:

    @ niclas -- Yes, you're misinterpreting.

    But that's OK -- That's always the challenge of sharing mental models, ideas, beliefs, and experience.

    Here are your points, as I've interpreted them from day 1:

    * There should be paths to move up the value stack technically

    * You don't have to learn EQ or influence and impact skills to do it

    * You shouldn't have to give up your tech skills to move up the stack

    * Tech leaders and business leaders are two different things

    * Tech leaders should be as valuable as business leaders

    (If I missed something, tell me because maybe I don't see it.)

    I've echoed all those same points, so you seem to be arguing with yourself, not me, so either you don't feel validated, or you're reading into what I wrote with assumptions that aren't actually there.

    Keep in mind, I happen to work in a company where we do exactly the points above (in fact, we have a bias for tech 😉

    The part that seems weird, is where I frame out what it takes to expand influence and impact in people leadership roles, by framing out leadership skills, and you twist that into an individual contributor role that wants to be rewarded as much as a leader who scales their influence and impact through others. (Precisely, it's where you argue 1 server = the value of the farm.)

    The other part that seems weird is you don't seem to recognize that whether you are a technical leader, a business leader, an individual contributor or a people manager, you will be limited if you don't know EQ.

    There's a reason EQ is a big deal.  You can look for other things that limit people, but that tops the scale. If you study the science and the data behind it, just read any decent book on it, and you'll get why.

    Again, the point of the post was to help people who move into manager roles both to:

    1) recognize what it takes

    2) figure out whether they want that path, and

    3) help people with a developer background, enjoy the process of translating what seems like soft-skills into technical-skills.

  10. JD Meier says:

    @ niclas -  Here's part 2 ...

    Some of our best tech leaders decided they don't want to manage people.  So they work extra hard on building their EQ, influence and impact skills so they can:

    1) scale their own ideas and get things done with other people, and

    2) compete with tech leaders that have large teams of people making enormous impact.

    They get deeper technically, but they grow their leadership skills so they don't become a mad scientist in the corner, or a relic that nobody listens to.  They become a better "T"-shaped person.  They collaborate effectively and create more impact and value. They get more things done with other people, whether or not people report to them.

    Maxwell puts it best, "Leadership is influence."

    You can fight learning EQ or any of the skills that improve your impact and influence, but they server you whether you are an individual contributor or a team leader (there's not much downside to learning influence and impact.)

    And learning EQ does not mean giving up your technical skills.  And growing in a technical ladder, obviously doesn't mean giving up your tech skills.  Managing people does mean adding new skills and trading focusing on your personal tech growth in favor of helping the people you lead realize their potential and amplify the impact as a team, not you as the hero.

    Rather than debate it, try a 30 Day EQ sprint for yourself and see if you can improve your connection, collaboration, and impact with your peers and stakeholders ... and even design better products with empathy (you might even improve your tech skills because people might like to share or pair with you more.)

    If you keep one thing in mind, it's this:

    If you move up the stack as an "I" and can't figure out why you're stuck, try adding some more "T" (and even "E").

    ... and read my post on "E-Shaped People, Not T-Shaped."

    Merry Christmas to you and yours, and a very happy New Year!

  11. Niclas Lindgren says:

    @jd sorry for not getting back earlier, Christmas got in the way. Not entirely sure you wanted a response however.

    * There should be paths to move up the value stack technically

    Yes sort of at least. To me, when you say "manage", in this part "about bringing out the best from the people you manage" I read into this "a person with a huge impact on your evaluation and effectively works with you to further your career". This part of manage takes a lot of time and effort, and you don't need a particularly large team before it consumes much of your time as a manager. So much it might actually make it almost impossible to keep your technical skills up. So if we define “technical” as leadership with less “managing” I guess.

    * You don't have to learn EQ or influence and impact skills to do it

    No, not at all, not sure where you picked that up, very much the opposite. As I mentioned a few times, I don't question the skills needed for better influence or leadership, or that they are required for great leadership. I suggested not all leadership roles should require managing people, in the sense of managing their careers directly(e.g evals). I actually believe an awesome developer has many of the skills, at least they should have 1,2,3,4,6,7 and 9 tuned in to one degree or another. And 5 at least in their team setting or sphere of impact. Else I am not entirely sure attributing them with awesome is appropriate. To be awesome you need a certain amount of soft skills with your technical skills. And in my experience one can actually be on either side of that scale, one can have stronger "soft skills" than "tech skills" and be awesome, or you can have stronger "tech skills" than "soft skills" and be awesome. And as awesome is like infinity they are hard to compare. It is however, in my view, impossible to be awesome with only one side of the "scale".

    * You shouldn't have to give up your tech skills to move up the stack

    I am saying that retaining the technical skills requires that you work in the field. To be a successful in technical leadership it needs to remain a core skill. I read it as "leave those skills behind it is time for new ones" and this made me a bit surprised. The only thing I was trying to bring up, apparently failing miserably, is that I believe it is a very good thing to keep your technical intact (or actually for the company corporate ladder to keep them intact). I might also be saying that you risk losing the ear of the technical pool if you lose too much of your technical aptitude, thus worth nurturing.

    * Tech leaders and business leaders are two different things

    They can draw from different pools of talents is what I was suggesting, you might not necessarily want to deplete the technical pool for them (by only have one corporate path), meaning, if you require all of them to start managing people it will drain them of the technical aptness that got them into a position of influence to start with.

    My whole post was angled against the “corporate ladder” aspect

  12. Niclas Lindgren says:

    @jd broke out the part where you seem to address me and not the subject at hand

    "(If I missed something, tell me because maybe I don't see it.)"

    I still believe you have missed my point, which was actually a question ill phrased, which is likely my fault. I was saying, or suggesting, or asking, should leadership always require managing people and their careers in a direct way. Indirectly any leader, formal or non formal, will of course have great impact one way or the other on people careers. Or should there be leadership roles, call them technical if you wish, and thus career paths. Not at one point was I suggesting, or meaning to suggest, that anyone should not pick up EQ or the skills you suggest however.

    Perhaps we have a different view on the word manage, my native tongue, as I am sure you have picked up, is not English, so subtle things can make all the difference.

    "I've echoed all those same points, so you seem to be arguing with yourself, not me, so either you don't feel validated, or you're reading into what I wrote with assumptions that aren't actually there."

    I am not entirely sure why you bring up my validation or lack thereof or how that adds to this conversation. Perhaps you read something that is there I am missing. I cannot tell. But validation is a tricky thing, for just about any person and we all seek it in different ways. It is actually often a part of any debate or dispute, but I cannot say I particularly was looking for validation here nor do I feel I am in this spot. I honestly had one question to your suggestions, and it was, do you think companies should have good careers paths for technical leadership or not, i.e. should all leadership roles require managing. But If you were not saying to drop the technical skills to move up the ladder, then perhaps this was a lot of words to no end, except as an interesting conversation, perhaps held in an ill-suited forum with too little bandwidth.

    Somehow it now feels however you have twisted that twist, or want to twist this into a debate about "hero developers" and perhaps also paint me with that brush, which might be a bit premature, which is an entirely different discussion. I am not at all suggesting learning EQ is a bad thing or that you should fight it, quite the opposite, I was actually suggesting that effective Agile teams (and single “awesome” developers) have picked up a good bunch of your list of "technical skills", and if they haven't they should look into it as it will make them more effective.

    I am sure a 30 day EQ sprint would serve me well, but so would any sprint where acquiring more skills or knowledge do, I am sure you have many valid points and insights, I read many of your posts with interest, I am not debating the value of EQ nor trying to push the alluding lonely hero developer with no people skills.

    I do however value the time you spend on the conversation even if I have a hard time coming across with my point/question.

Skip to main content