The Wolf

Interesting explanation. Maybe you're not gonna be able to share that, but I would be curious to see some examples of what they did, that is so exceptional. Did they decide to rewrite some critical module using language/framework X, which resulted in a crazy performance gain? Did they completely change the architecture of something which made the whole company (or a whole group of devs) much more efficient?

I would't call someone a wolf -- it kind of makes the caller sounds like a tool imo -- but I think I have seen different types of engineers along these lines. The sort of people who build projects, getting them to the point where a rough draft is useable then increasingly refining them until you have a 1.0 or maybe a 2.0, do not seem to be the sort of people who are good at taking a 2.0 to a 5.0. The latter need, and need a tolerance for, process which seems to kill the former.

Also, the problem with doing as told is you are taking for granted that the person doing the telling is worth listening to. My advice to most new grads is don't do startups. Go to a company like google or fb for the first 2 or 3 years and get a solid handle on good software engineering practices, then go do startups.

It is either in your nature or it is not. We all need good soldiers.

This is how you train soldiers. Some aren't cut out to follow.

> Does anyone know any reliable ways of telling the difference? Beforehand I mean; it's easy to tell in hindsight.

Sure, here are some:

* Ask the opinion of people who have worked with the candidate.

* Arrange for the candidate to explain some of his recent code and its workings to someone unfamiliar with his specialty. +1 if the listener comes away understanding the code.

* Ask the candidate to write a short algorithm that solves an uncommon problem, see what kinds of methods and variable names he uses, and whether there are enough comments (not too many, not too few) and structural clarity that the code could be maintained by a third party.

Most programmers don't want to be replaced, but the dangerous ones are those who think they can't possibly be replaced. Some of the latter group code in such a way that their personal belief becomes a self-fulfilling prophecy.

Spaghetti code isn't necessarily bad code. It's impossible to decide without understanding the business circumstances. Our job isn't to write code; it's to create business value. If the business value of doing a hack job really fast outweighs the cost of doing things in a maintainable way, it was the right thing to do.

Finally, the problem with hiring a so-called wolf is you can't. Acting that way relies on having credibility within the org that you can only build by having a track record of delivering stuff for senior execs. And that you can almost certainly only create by working for a company for a long time.

Spaghetti code sells the same alas. In the CF these are called fighting men. Average is that you train 8 guys and you will likely have 2 in the unit. Sometimes zero, sometimes three.

See how they operate in the trenches. Or give them a restrictive position to see who disobeys intelligently.

Keep in mind they like to eat, so feed them. Otherwise, well they get bored and sheep are tasty.

>The problem always seems to be identifying the Wolves from the Cowboys. ie. Telling the difference between a "10x" coder who will live outside the rules and get things done, versus a "10x" coder who lives outside the rules and leaves you with a humungous mess of undocumented, unmaintainable spaghetti code when he leaves.

The problem is by-the-book, team-work friendly "soldiers" also tend to leave a mess of BS architecture decisions and crappy spaghetti code when they leave...

From what I've seen, the difference with the depth of understanding of the organization- its mission, goals, capabilities, and failings, and commitment to work with the organization's interests in mind.

The Cowboy is- consciously or not- out for himself, and imagines the organization to be something other than it is in order to be able to present himself with some technical problem that he wants to solve. The problem the Cowboy is solving for is more or less irrelevant in the context of a deep understanding of the needs of the organization.

The Wolf is aware of the organization as it is, works to solve the most important problem the organization faces, using technology, whether or not others in the management or executive hierarchy understand.

This situation can arise particularly in older organizations that are in the midst of making a major transition, or facing major competitive or existential pressures. Strong engineers are often able to see the new physics by which digital businesses need to operate by before others, and may need to make decisions in accordance with that physics.

TLDR: the Cowboy solves deep technical problems that are irrelevant to the business. The Wolf solves deep business problems using technology.

I think it's pretty rare to set out to hire a wolf, although a manager of a large, well-resourced team could do so just to shake things up. That would be tough, though, since it is very difficult to come in from the outside and perform as a wolf immediately.

My own experience has been, instead, that a wolf emerges from the herd after 6–12 months. They've learned the culture, they've learned the personalities, they've learned the dividing line between the strictly forbidden and the mostly forbidden. Your juvenile wolf will show a propensity for solving long-standing hard problems that had long been deferred or inventing new trifles. A cowboy may act similarly, but generally gets into more trouble and has less substance behind his solutions. A kludge is a hack that works; a wolf is a cowboy who gets the kill.

It is at this point that you must act to place new wolves in an environment where they can excel. I think customer-facing interdisciplinary teams work well, where success is demanded, glory is possible, market feedback is immediate, and they provide unique skills to the team. You can also place them on more seasoned technical teams, where the burden of management is a bit lighter.

I am a wolf (it's been over a decade since I told my first manager I wanted to become "the wolf", a la Pulp Fiction). There are downsides. The more process-driven the management, the more battles you will have to fight. The wolf often wins, but not without injury. Corporate combat is exhausting and, worse, can become an end unto itself. Also, being always on the hunt often precludes working on a single large project for a sustained period of time. A wise wolf must remember to hunt big game instead of feasting on readily-available mice.

In other words, it's easy for the wolf to become the asshole. Both proper management and self-awareness can keep this from happening.

Ah, you must be what I like to call a "Bull" — an essential factor to startup success!

Switching jobs often gives you more opportunity to raise your salary.

There is a level that some employees and consultants reach where "Seniority" is no longer relevant, whether the Consultant is brought into the company either as a Contractor or as an Employee. When I'm brought in it is because no one at the company knows how to fix something, install something, and/or scale something. It doesn't matter how long I have or haven't been with the company, I get it done. I have been fired/terminated because the "Manager" was afraid he'd lose his job or have me promoted above him. I could give two shakes if you've been at a company for 15+ years and have "Seniority" over me. I have vast, real-world experience...you have your very narrow problem set of experience that culminated in not knowing how to do something that resulted in bringing me in. The differences are rarely, if ever, spoken aloud, but are confirmed daily.

Sorry, I'm feeling very wolfish today.

Was anyone else disappointed by that guy? "Please clean up the mess" is basically what he said.

Was he? I have't read his biographies but my general impression is that while Steve Jobs was certainly a visionary and an entrepreneur, he was not really an engineer. Did he write a lot of code? Did he really engineer anything? Or did he surround himself with excellent engineers who could create his visions?

Consider that many organizational structures are designed to get maximum benefit from most employees - and, almost by definition, most employees are average. HR, for example, exists partly if not primarily to 1) identify those in the bottom fraction (whatever that fraction is) and make them harmless as painlessly as possible (this might mean getting them out the door or it might mean shunting to a position where the {harm, value, cost} equation works out adequately well; 2) identifying those in the middle and retaining them as cheaply as possible, possibly with non-financial incentives appealing to affiliation motives, sloganeering, etc.; and 3) to identify the crème-de-la-crème, the wolves, the going-places-and-will-rock-it-along-the-way, etc., and tailoring incentives, including compensation, for these.

I'd go so far as to say that most managers (not all, and not the best ones, but most) will attempt to game HR into forcing their misfits into the bottom fraction (these could be potentially stellar performers who don't fit with the manager) and will attempt to convince everyone that they have stars when they don't, because it makes them look good.

The managers and executives who want the top percentile players recognize that they have to fight HR to make the right things happen, because often HR, like all other organizations, is filled with average players who recognize those whose performance is below theirs and cannot fathom those whose performance is above - they see only the bared teeth, the feral eyes, and assume the wolf must be culled.

They do not recognize its value.

(Yeah, OK, this meandered a bit. Honestly, I'm too lazy to write it well, so I'm going for metaphorical effect. But you might know what I mean....)

Of all the Apple legends, I would not have picked Steve Jobs to fit the OP's description of a "wolf". Steve Wozniak seems a much more appropriate choice, given that he pretty much single-handedly wrote Apple BASIC (despite not formally studying compilers or languages himself), built the floppy disk (with some help), and the first connection between keyboard and terminal. From the various biographies of Woz and Jobs, it seems unlikely that Jobs would've even realized the potential of a color monitor had Woz not brilliantly designed it for maximal efficiency.

"Wolves" -- if you accept the concept -- are basically the anti-entrepreneur. We're talking about engineers who get head-down in deep problems, without the interest or ability to turn them into actual products. I learned the hard way that when a startup's key differentiator is "run by a brilliant engineer/scientist/mathematician," back away slowly.

Someone on this thread mentions Woz as a prototypical "wolf," which is probably right -- what made him work within the later Apple environment is that he could work on very focused, discrete projects such as the Disk ][. Compare with Burrell Smith, who was equally brilliant and equally idiosyncratic, but was able to function within the confines of the Mac development team (albeit with a certain degree of effort by management).

I've worked with plenty of "good programmers" who absolutely need a structure and process in order to feel comfortable turning on their machines in the morning. Some people need to feel like they have approval to do anything, and would never suggest a new framework or toolset ever. Most would recoil in horror at someone doing anything different from the Process. I'd argue these developers can do really good work in certain teams, but they need some hand holding.