Today I had a call with one of our vendors who helps find developers and other technically-skilled contractors that we’ve employed in the past. It wasn’t with Marlene, who’s been my contact with this particular agency for many years, this was someone whom I vaguely remember having a chat a while back about potential contract work. As in, I would be the contractor.
So it quickly turned out that this was more about getting my file with them up to date, in case they find the perfect job for me and would immediately put me out as a recommended contractor. Which, slightly awkward given that I’m only five months into my current company and this isn’t exactly the sort of thing I want to be dealing with when I’m actually quite happy with what I’m doing.
As I tried to wrap up the conversation, the question dropped: What are your three principle hard skills? It’s a fairly standard thing for this particular agency, as they require you to choose three (no more and no less, which I think is a bit dumb, but I understand why they do it that way). But here’s the catch – it’s more about things like knowing Active Directory or building Java apps or managing a network infrastructure. And those are things that I know how to do, but I would never put them down as “principle” skills because, frankly, I’m not good enough to be used as a trusted resource.
I didn’t know this then, but the day I started into management was the day my ability to be a trusted technical resource started to wane. Knowing the deep, inside knowledge of how something worked wasn’t going to be on my roster of skills because I had to worry about other things: how other people were getting work done. That’s not to say I didn’t do actual hard work – I did still contribute to delivery – but my job was to help others do their jobs better.
I know, sounds utterly vaccuous, right? A “life coach” sort of thing? That’s the real trick of management, especially with technology teams: you’re not there to do the work, you’re there to ensure the work is done correctly, to standard, and delivered without issue. And that’s not to suggest anything like a “supervisor” or even a “babysitter”, though those images do come to mind, it’s really about ensuring that you’ve got someone with enough skill, knowledge, and experience to catch problems before they become big ones.
This is where we stray in the poorly-named “soft skills”, which is where people usually go when you can’t define “hard” skills – if you don’t have one, you only have the other, right? This is where my meeting took a left turn and went down the road of “this is where we have a bigger problem”.
I have a friend who works for a (unnamed) software development company that is experiencing what I can only describe as “hell”. They have a really great product that would do a lot of genuine good. But due to extremely rapid growth and the demands from some very large, very expensive customers, the company has had extreme difficulties in nailing down direction. I cannot explain where it’s coming from (even if I knew, I couldn’t say), but there are a litany of organizational issues that keep cropping up: HR not checking potential candidates and wasting hiring managers’ time, individual teams not coordinating deliveries, support teams believing that they’re more important than those actually delivering revenue stream products, Director-level people who insist on being hands-on and not seeing the problems inherit to their teams, and so on.
These are the sorts of problems that I now solve. Sure, I understand what it takes to provide an ecommerce solution for an SMB, I’ve done those a few times. But can I also dig into that SMB and discover the internal challenges they have, identify solutions, and give them a phased plan to fix them? Yeah, I can do that. Does that make me a “management consultant”? Heck, no. It makes me useful. Because not everyone sees that.
But more importantly, it’s what I do for my teams, something I’ve been doing since the mid-2000s: make them better. I look for the conflict, the difficulty, the inefficiencies, the miscommunication that exists within and without a given team, the processes that drive the organization. I’ve yet to work anywhere where those problems didn’t exist, because they always will exist: any time you have a human, you will have differences. The trick is to try and smooth them out as much as possible.
But to do that, you need to understand the work: what does (in my case, anyway) a technology team need in order to deliver work in the most efficient manner possible? And, for them to deliver, what do other teams need to do? And how does all that work together? Now we’re looking at:
Mentorship
Building up someone’s skills requires collaboration: they need to want to do the work and you need to challenge them. They also need room to fail, so they remain open to communication and know when to ask for help.
Team Building
Even if you inherit a functioning team, odds are they’re not functioning well enough. I took on one team that was operating fairly well, but there were redundant project managers, a lack of consistent role for managing support, and there was only one developer for a huge platform. Within a year, the Support group had been defined, extra staff hired, and they were constantly led by a multi-decade veteran; the developer were quadrupled so we could plan for vacations, team development, and internal mentorship; projects were clearly managed by one group, with oversight on testing and analysis. Those sorts of things don’t happen when you’re debugging API calls.
Leading Through Change
Other than death and taxes, the only other assurance in life is change. And everyone hates change. The trick is to make change attractive, something people want to do. But that’s not enough for people to want to do it, you also have to help them through the steps to actually do the change. And it might seem very simple to some of you, but I assure you, very few people do this well.
Process Analysis
A process is an input, something happens, and you get an output. But are the inputs correct? Is the output valid? Is the “something” in between consistent and reliable, can it produce the output consistently? Is there anything to catch misfires? Is there a recovery if something goes wrong? Very few people will stop to look at the “how” to understand where the “what” came from.
Communication
Once upon a time, many years ago, we had a communication problem so large that we made a company video with a snippet from Cool Hand Luke: “What we have here is a failure to communicate”. Every organization, without exception, as communications problems. Why they exist and how to fix them is grossly misunderstood and just as grossly underestimated.
And yet, I can still code enough PHP to fix problems. So do I have one hard skill? That makes no sense. But they’re not “soft” skills, either.
In short, I think I’ve graduated out of simple technical agencies. I don’t do pure technology work. I know how to do the work, but you call on me because you have bigger, harder problems that won’t be solved with some elegent React or a well-formed SQL query.
And, maybe, that’s a good thing. ‘Cuz I’m getting too old for the same shit. (With apologies to Danny Glover and Sgt. Murtaugh.)
