The Ability to Change Things

I touched on this previously in Management Shouldn’t Be The Only Option, but I saw this post, and it has me thinking about the topic again. The Codist regrets not having gone into management, for what looks like two core reasons. First the money: pretty straightforward since managers appear to make more of it and have more career advancement options to get even more money (and money has lots of advantages). The second reason – the ability to change things – is way more interesting to me.

I could go on and on but the key is that you can’t make changes in how people do things in a technical sense unless you have the ability, the authority and the opportunity. Once you make that call and assuming you find the right places to grow, the sky is really the limit.” Why doesn’t a top ranking developer have the the ability, authority and opportunity to change how things are done?” (emphasis mine).

I’ve seen three kinds of high ranking developers in my career: the in-house expert, the hatchet man, and the fake executive. Each of them is missing one part of the equation described above.

The in-house expert understands all of the quirks of whatever it is you have; they probably helped build it. In my experience the in-house expert built the system with whatever skills and abilities they had when they started, and they may not have learned anything new since then. As they became more and more valuable to be able to build out new features they get less and less time to learn. As the team for the project scales, they start to become a bottleneck for information as everyone wants the expert’s opinion or insight into what they are working on, and they get less and less time to even do new development. In advanced cases, they even get to the point that when a systemic problem occurs, they are the only person with enough whole system knowledge to diagnose the problem and get it routed to the appropriate people. All of this cuts into their time to learn new things, until they burn out, then they realize they can’t move on due to the fact that all of their skills are years out of date. The in-house expert is probably lacking the ability, otherwise they’d already be doing it that way.

The hatchet man is more the sort of problem solver that behaves like a consultant, showing up from outside the team after something has just gone disastrously wrong. In larger environments this could also be a Tiger Team. The idea is that there is this highly-skilled problem solver who, while too important/expensive to work on this full time, can show up, diagnose the problem, and get the problem under control. This is an interesting role, one I even got to play once, but it is predicated on two basic ideas that are contradictory. The first is that the hatchet man can easily find and fix the problem. The second is that the team can be entrusted with the system when the hatchet man leaves. If the problem is simple enough that an outsider can show up find and fix it easily enough, that seems to correlate with the team not being capable of dealing with the application, so you shouldn’t trust them not to run into another problem and do the wrong thing as soon as nobody is looking over their shoulder. The hatchet man is probably lacking the opportunity, since they won’t be around long enough to make a real change

The fake executive usually used to be a day-to-day programmer, who took a management role, while the company grew at the rate where new levels of management opened up and they got pulled upwards with the growth. I’ve seen a fake executive that has no relevant technical skills anymore but is still committing code off in some corner of the repository for their own amusement. Some are fulfilling the the architect role and watching the entire design of the system. Some are taking stories and adding new features. This can vary between being fine and disastrous. If they aren’t on the critical path or creating more work for everyone else by getting too involved, everything is fine. If they are on the critical path, then you can run into a massive bottleneck because whatever tasks are part of their executive job are either not getting done, or they are not dedicating appropriate effort to the critical path. The weird part of this is that the fake executive can lack the authority to make a change because while they can tell you what to do, they can’t or won’t stand up to their peers to get the resources to make any sort of real change. Their authority over development was given, but they don’t understand the process by which they can influence other departments to make a real change. They can often not have the ability for the same reasons as the in-house expert because they are too busy to keep up with current technologies and tools.

This all wraps up into two other posts on the same blog about this same topic Programming Is a Dead End Job and Yes I Still Want To Be Doing This at 56. These are looks going back two and four years at the same topic where you can see the slide into this sort of thinking. In an alternate universe, imagine his management blog with regrets of moving into management and wishing he had stayed in an individual contributor role. Maybe this is just the grass is always greener thinking and he needs an opportunity to stretch his legs technically to get back to that warm happy feeling he projected in Yes I Still Want To Be Doing This at 56.

I know my own foray into management wasn’t good for me, and it wasn’t good for the team. The time I got pulled into management, I don’t think it was because I had any particular talent for it, but that amongst the people on the team I was the one who the management further up the chain trusted the most. It didn’t seem to have anything to do with the skills to succeed at the role or an inclination to do the role. Maybe this depends on what you want from management, in my foray to management it was all about schedule and budget. If it was more about personal development and building quality in then it might have been a different experience.

Maybe management has a bad reputation since it was always a combination of two different roles that have opposing interests. This would seem to match more with the agile coaching mindset. Doing staff development is time-consuming, whereas delivering a project sooner has lots of benefits, especially to the manager’s career. By splitting these two interests into two separate roles it lets them each have a fighting chance. The product owner doesn’t need to concern themselves with the advancement of the team, and can focus on understanding the customer need. The scrum master can focus on helping the team achieve the best they can and doesn’t need to worry about planning further out for product delivery.

After I had started writing this post, I met a guy who had gone from programmer to upper management to sales engineer to sales engineer management back to sales engineer. I’m not sure how the topic came up, but he described the experience of being in management as nothing but trouble, because people just brought you problems every day and you were involved in too many different things simultaneously. I’m not sure if this was all about having the right temperament, or if the organizations he had been involved in were abnormal or not.  

I guess it all comes down to deciding what makes you happy. I’ve met managers who love helping the team succeed and removing impediments, and I’ve met managers who got sucked into the role when what they really loved was hands-on development, and now they can’t get out. If the management job will make you happy, take the management job. If you just want to create do that. No point wishing you had done something else.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s