“It works as long as you’re the smartest, but then the curtain comes back. Nobody likes being manipulated.”
People hate that word, “manipulation.” As a rule, they don’t hate the concept unless they’re on the receiving end of it, and even then sometimes they appear to prefer it to dealing with…well, reality.
(FYI, we’re using affiliate links to Amazon in this post!)
Technology innovation is vital. It can enable business success – and it can also drive business innovation.
If a business falls behind the technology curve, it opens itself up to the risk of under-serving its customers, and eventually being out-maneuvered and defeated in the marketplace. This happens over and over to businesses, where a competitor’s technological innovation pushes them right out of existence – see Blockbuster (Netflix), and Border’s (Amazon, B&N). Amazon has also innovated while JC Penney has stagnated – department stores could have taken the world by storm via the internet – but their online presences weren’t good, certainly not as good as their competitors, and therefore neither were their sales figures.
We’ve seen a lot of tool transitions across a large enterprise, and one of the coolest examples was changing the opinion of the company we worked for regarding source code analysis. We had a tool that was under-licensed, slow, ineffective, and largely ignored. At best, it was a check box labeled “we’re definitely secure, you guys!” that everyone on the ground ignored.
If you’re a Java developer who’s been working with OpenShift 3.x for a while, odds are very high you’ve worked with their OpenJDK 8 S2I image.
That container includes Red Hat’s S2I magic, which can take a git URL or a JAR and turn it into a running Java application. Combined with Spring Boot, it’s a fantastic way to get running Java containers in minutes.
There is freedom and peace and pride in being truly good at something.
Not to seem good.
Not to check off the boxes of good.
But to actually be good.
Everyone should have the freedom to be actually good.
Establishing governance philosophy in an enterprise is a tricky combination of “how much do we trust our people?” and “okay, but how much do we actually trust our people?” The fact is, people are going to screw up. Some of them might deliberately try to screw something up, but mostly they’ll just make mistakes. If the organization can’t handle mistakes, that’s a problem with the adaptability and flexibility of the organization, not with its people. This means that people’s potential mistakes are not a reason to default to not trusting them.
As leaders, our job is to enable the people we lead to make good decisions. The primary way that we can do that is to give them the clarity they need to make those decisions.
If we don’t give our people the information they may need to make the best decision for them, we have failed them as leaders.
One of the first steps a technical leader takes is taking over as a team lead. In IT, this is often called a Dev Lead, Tech Lead, or Architect, depending on a company’s teams and title structure, or it can be more understood than titled.
This type of technical leader might not have direct reports, but accepting ownership of the team’s technical success is leadership, and it’s one of the first big responsibility changes and perspective shifts in the process of becoming a technical leader.
Technical leadership means taking on ownership of a team’s technical success.
In the two-part series Technical Leadership Progression, we defined “technical leadership” differently – if you’ve read that one, here we’re using it to mean specifically the Single Team Ownership phase.
One of the things we’ve noticed while mentoring is that some people suddenly take off like a rocket – they accept responsibility for more than they previously took on, and then they seek out more. They also handle this increase in responsibility very well, and they impress people who previously were at best neutral – along with people who were previously disappointed.
We’ve seen it happen, and we’ve been trying to figure out how to describe what the pieces are, because if a cool thing happens, you should explain how to reproduce it.
So, we began to think of it in terms of the process, the ingredients, and the result.
If a cool thing happens, you should try to figure out how to reproduce it.
In Technical Leadership, part 1, we talked about how someone grows into a technical leader aware of their team. In this post, we’ll continue on to describing a Tech Lead who takes ownership of their teams’ success, and then moves into the higher levels.
We like patterns. Patterns are cool. Patterns apply to people, and groups, and organizations, and…everything, actually. (L: I could talk about patterns for hours, but I won’t. You’re welcome.)
As we’ve each mentored people into technical leadership and tried to understand how people grow as their leadership role and ability grows, we noticed a pattern with several distinct steps. Because patterns are cool, and because we learn by writing and talking, we put words to the pattern we were seeing.
Before we get too far in, let’s define technical leadership:
Technical leadership is providing knowledge, guidance, support, and strategy to developers, systems, and especially the intersection of the two.
To be clear, it is not project management (although sometimes that’s included) or people/HR management (although sometimes those roles are combined too).
We’re going to break down what we’ve seen with some diagrams and then some explanation of what each stage looks like. We’ll split the explanation into two posts, because there’s a lot to talk about. This was the reasonable-length version, we promise.
As people gain knowledge in Technical Things, that knowledge tends to reflect these levels – self (as in, “my tasks”), single team and system, multi-team/multi-system, and finally, the enterprise/company as a whole.
People also tend to move from awareness of something – for instance, awareness that their team could use their help on something outside of their usual duties – to ownership of it – like, deciding in their soul places to help their team be awesome.
However, fun fact, the basic pattern we noticed was that people move across these at the same time. So really, it looks a little bit like this, assuming they start at the bottom and hop up the levels as they go:
People move from self-awareness to self-ownership, and then they become aware of their team. Eventually they move toward accepting ownership of their team, etc (don’t worry, we’re going to explain these in detail!). However, this diagram is super complicated, so…
TADA! As people progress through technical leadership, they do…well, this. ☝ Self-awareness to enterprise ownership.
Ever worked with a baby programmer, or remember when you were a baby programmer? Someone brand new, out of school, who hasn’t quite figured out how to like… understand things and also talk to people? Or, cooperate on a professional team? Yeah. Mastering the basics is vital to all that comes after it. Also to adulting well, which is another skill baby programmers usually need to learn.
The true first step to being a technical leader is to build a reputation for being reliable in the eyes of your team – and that means executing your development tasks well. A wise person once told Josh, “be good where you are.” Get things done on time, ask amazing questions, and learn to love and understand the system you’re wrangling.
If there’s success here, more challenging and complicated work will be offered. Also, interesting to note, most technical leaders never get entirely away from this step or the next. Solid technical skill (and troubleshooting, spoiler alert) always help a technical leader.
This stage starts at troubleshooter – building a track record for solving tricky problems. This means taking on more frustrating and painful tasks than you strictly have to, and getting good at different kinds of problems.
Basically, this is getting really good at understanding the neuroses of a system, learning how to debug and fix it efficiently and effectively. It also requires a massive dose of stubbornly not quitting.
The better someone is at troubleshooting, the more likely that they’ll become the Help, I am Stuck and You Know Stuff person – dedicating resources to helping other people. This shift means all kinds of patience – with technology, and with people. A lot of great technical people draw the line here, mostly because…well, they don’t enjoy people very much. That’s fine, people are a lot of work.
This step is where people typically stop doing as much of their own implementation – and that can be really frustrating for people who go into IT to write code. Instead of finding joy in implementation, though, they learn to find joy in other people’s successes. Again, a lot of people draw the line here because they love implementing technical solutions, so please stop talking to them and let them code stuff.
In part 2, we’ll talk about growing into taking ownership of the team’s success, and move on to awareness and ownership of multiple teams.