A large portion of my career has been spent fighting against organizational disarray. Over the years, I’ve become very accustomed to being dropped into an established culture with the intent and promise of doing everything I could to improve it in some way. Sometimes I was alone, and sometimes I was even accompanied by my closest friends and colleagues. While I’ve both succeeded and failed to varying degrees in both situations — and occasionally, even, at the same time — one thing has not changed: this is not an easy task. We were cucumbers, being dropped into jars with the intent to somehow, against the forces of nature, un-pickle pickles.
Around 2001, I was laid off. It was still early in my career, so it was very upsetting. Those who were in IT at the time probably remember the situations that leads to mass layoffs (Dot-Com bubble burst; 9/11). I felt that I was a valuable employee, and had feedback as such, so it was confusing to my still-naive sense of fair play that I should be handed a pink-slip. After the fact, on a phone call with a VP who had left of his own accord around that time, he shared a tidbit that stuck with me ever since, “Managers never lay themselves off.” The truth of it was undeniable, and it lead to a thought experiment that has always nagged at me: if it turned out I was a part of the problem, and not part of the solution, would I have the courage to lay myself off for the betterment of the company?
I have, on many occasions, been a terrible technical lead. For years, I had no idea why people continued to promote me into these positions, even across different jobs. It’s not like I wanted to be a technical lead, they would just walk up and tell me that would be my new job. I was a terrible technical lead, because I could never work out what the job entailed. To become a technical lead, you had to be the most skilled of any of the other engineers — at least that’s the idea. However, to stay skilled you need to code constantly — that’s the “technical” part. The “lead” part, however, never seemed to fit, because to lead, you have to do more than sit at your desk and code all day with your headphones on. How can you stay technical and still lead?
Ever heard this one: “Come on everyone! If we’re going to make the deadline, we’re going to have to put in some hours!” or “Jimmy is really working hard — look at all the hours he’s putting in!” Yes, Jimmy is putting in a lot of hours. Yes, Jimmy comes in at 9:00 am, and leaves at 11:00 pm. Jimmy is putting in hours. Jimmy is also writing crap that has to be re-written, missing requirements, and pumping out more bugs than functional production ready code. But boy, he sure is putting in hours.
Not a lot of companies do Agile well. I know some very smart people who think Agile is an utter hoax — a gimmick, used to make buckets of money by selling snake oil to gullible organizations that are just struggling to stay relevant. I don’t think it’s because Agile hasn’t been effectively evangelized. I certainly don’t think it’s because there is some fatal flaw with Agile methodologies that makes them abstruse or impractical. I think it’s because switching to Agile is painful, and people are opposed to pain.
Obviously, if you want a high quality product with a clean codebase and low defect counts, you need to be very careful and methodical in your approach to developing software. Ready-Fire-Aim is a sure road to disaster, leading to chaos and confusion. Not only that, but it speaks to a general immaturity and lack of professionalism of the development team and its members. That is, unless you iterate rapidly and continuously improve.
It’s Monday morning, and you walk up to your desk, cubicle, office, whatever, and set your things down. You open up your laptop or wake up your computer, take a sip of your $4.00 coffee, and look around the floor. Wait… something isn’t right. You notice 6 people you’ve never before seen huddled together with laptops. They’re drawing on whiteboards and pointing and arguing and laughing. Well now, don’t they just seem right at fucking home? Something’s not right, here — you can feel it. Relax. It’s much worse than you think.
Ok. Your team is backed into a corner. You know what the right decision is — technical or political — but are, presumably, adamantly disagreed with in your organization. In spite of knowing what you’re in for, you want to take a stand. You need to do two things, quickly and effectively. First, you need to credentialize yourself in front of everyone involved at the same time. Second, you need to focus on the contrasting effect each decision will have on the company, both in the immediate future and in the long term.
School has conditioned us to think that someone who does not know the right answer off the top of their head is an idiot. At this very moment, all around the world, students are called on by their teachers to answer a question, and are publicly humiliated when they don’t know the correct answer. Their peers are taught that it’s OK to jeer at someone who doesn’t know the right answer – even if they don’t know the right answer themselves. As adults in a technology profession, we see this same mentality manifested as interviews that go badly because of one wrong answer (“They should have known that!”) and first impressions that are forever stained (“That guy doesn’t know what he’s talking about”). If only it was that simple.
I have been fortunate enough to work with highly competent people, most of my professional life. Whether they were software engineers, system administrators, project managers, business analysts or executives. Each has been smart, savvy, extremely skilled in their craft and very often, great leaders. In cases where they were my peers, they were great partners in accomplishing whatever challenging tasks at hand. That a group of people were successful and continued to be successful can be attributed to the fact that we trusted one another to do the right thing, and provide the feedback, understanding and support when needed. Trust is the hallmark and the foundation of a great team.
So your organization isn’t responding to reason. What started out as a team that would attempt to exemplify the way your organization wanted to do product development has become a micro-managed monstrosity, full of stakeholders, and absent of accountability. You’ve decided that in the face of this blame-storm you keep hearing referred to as a “team effort” (which you’re starting to believe!), you have to take a stand. Here’s what you’re in for:
One of my most visible faults early on in my career (and something I still struggle with to this day) was my tendency to rigidly represent my own (or my team’s) interests, regardless of how large or small. I say rigidly, because I would tend to hold the same position in spite of the political or emotional erosion to external relationships that might be caused. In short, I didn’t really give a damn about any external team’s preferences — I knew what my team wanted, and that was that. Over the years, I’ve learned that this is not the best way to do business.
In the English language we don’t say, “They made so many mistakes in the past that they know how to avoid them in the future.” Instead we say, “They’re experienced”. Making mistakes is what gives you experience. If you come out of college, and for your whole career never made one mistake, then only one of two things have happened: 1) You are bull[sh*t]ing yourself 2) You have never tried anything outside of your comfort zone. “Comfort zone” refers to things you already know how to do well. When you step outside your comfort zone, you will make mistakes, and the question then is how to recover.
There is a trend with my posts about software design where I write a lot about how it is a creative process. This is largely because for years, software design was considered to be busy work, and I take extreme issue with that philosophy. I find producing consistently effective software designs to be a very difficult task, and I deeply respect those who are good at it. I also find that those who are good at it have in common that they are all inspired workers.
I once created an engineer performance grading system to help management understand when an engineer was ready to be promoted from junior, full, senior, and through to principal. There were seven criteria, one of which was “Grace Under Pressure”. As you become more experienced, your ability to deal with the pressure of tight deadlines, fluctuating requirements, and idiot co-workers should increase as you find creative ways to cope with the stress. Dealing with stress becomes the hallmark of someone with a lot of experience. One of the best ways to deal with stress, I think, is humor.
One of the most common points of extreme contention I find between Agile and Waterfall practitioners involves a heated debate about the appropriate time in the project’s life cycle to be making important decisions about the software’s architecture. In one corner, we have the Waterfall approach of Big Design Up Front (BDUF), and in the other corner we have the Agile approach of Emergent Design. I’d like to outline some of the key differences between the two design philosophies because I think the right choice becomes obvious when they’re contrasted appropriately.
In the software industry, there are always jobs. Sure the larger economy might tank, unemployment might skyrocket, but there are *always* jobs when it comes to writing software. This is one of the reason why people go into writing software in the first place — guaranteed employability. If you’re an out of work software developer, and think I’m being unkind try this: drop your asking price below market – they’ll hire you. The problem is, a job is one thing, but finding the right job is another entirely.
With every new job, there is a short but finite honeymoon period — it’s called that, because similar to marriage, there is an initial rush of adrenalin and endorphins and obviously, the promise of the new opportunities — if there was not promise, why bother leaving one position for another? — and everyone bask in that glow. In time, those feelings might change, and reality will gradually come back into focus. Familiarity will erode the novelty and the real challenges of the role will become apparent. Some employees already recognize this, but many are not fully aware/cognizant… your first ninety days on the job holds the greatest indicator of nearly all your future success in that role.
Held captive in a status meeting, your moment of shame approaches. Vulnerable and exposed, like a naked baby laid before encroaching doom, you await your turn. Your peers’ bold claims, naive honesty, and feeble excuses are recorded for posterity by a stone faced facilitator. They work their way around the room, thinly masking disdain at any answer that is not a crisply delivered “I’m done”. Finally, the time of judgement is upon you. As you fumble to explain your lack of completion, you are interrupted by a question that has struck down even the strongest among us: “When will you be done?” Fighting back a swelling tide of emotion, you try desperately to think of what you can say that you haven’t already. Step aside my child, let me handle this.
One of the most difficult challenges I face in my professional life is is maintaining a healthy working relationship with people who I believe are deeply incompetent. Incompetency is, for me, extremely difficult to stomach — far more difficult than, say, laziness or apathy, because whereas those might point to an attitude problem, incompetency reveals that the basic skills necessary to effectively perform daily tasks are missing. To further exacerbate the issue, one of my [many] personal character flaws is that I find it extremely difficult to relate to or to support someone I do not respect. Because of this, I’ve not only become acutely aware of the truth behind the Peter Principle, but I’ve also picked up on an even more dangerous corollary that’s become more and more prevalent in the workplace. For the sake of discussion, I’ll refer to it as the Napier Principle.
Corporate culture is obsessed with the term “leadership”. They pride themselves on being “leaders”, and for fostering “leadership” within their organization. We even have the idea that everyone is a “leader” in his or her own right, each taking personal accountability over what they do every day and “leading” in their own special way. I glaze over when people talk about leadership. I fully expect that you’re glazing over just reading the opening of this article. It’s old. It’s stale. We’ve heard it all before. At this point it’s boring. Someone who takes ownership of cobbling together a PowerPoint before a big presentation, and the people who lead troops to storm Normandy ain’t the same type of leader. They ain’t even in the same ballpark. Those types of leaders didn’t want to lead, they were drafted into it and rose to the occasion. To the rest of us, these are the people we want to call leaders.
“So, hey, you’ve got that report ready for review at 4 o’clock, right?”
“So, uh…I thought I had until Monday for that…”
“‘SO-A?’? No, not on SOA, on ‘World Domination and All Things Evil.’”
“So…no, I said, ‘so, uh‘…”
“…So…I don’t really know what you’re saying to me, but if you could have that report ready by 4, it would be great…”
If you’re a senior-or-above talent, you know how work longer hours without it significantly impacting your work product. For this, I’m talking about the 40-50 hour range. Most people start to fall off around the 50-60 hour range, and we all start producing crap around 60-80 hours. Beyond 80 hours, it probably time to look for a new job. Having said this, let’s focus on the 40-50 hour range. If your employer suggests or requires that you work these extra hours, it’s probably not going to destroy your home life, or wreck your sense of well-being, so the impact should be minimal, if not negligible. Why not work these extra hours? Because you’re not getting paid for them.
In yesteryear, in the time of our coding forefathers, ancient project managers would gauge a developer’s productivity my measuring the lines of code added per unit time. This was a convenient and intuitive metric, as there was seemingly a correlation between number of lines coded and number of features added. When companies then started rewarding developers according to this metric, it lead to a rash of bad programming habits – most notably copy and paste coding. In modern times, we consider ourselves enlightened, and claim to have realized that not only is there no direct correlation, but that attempting to measure developer productivity in this way is both meaningless and destructive. Yet, if you corner the average development manager and ask them to compare developer productivity, many of them would not be able to resist the urge to pull metrics from source control. This due to a lack of awareness of a complete reversal in the way in which lines of code reflect productivity.
In 2005, socioeconomic researchers at Harvard, in conjunction with the local police force, performed a social experiment in Lowell, Massachusetts. After identifying over 30 of the highest crime rate areas in Lowell, the police forces were instructed to clean up litter from the roads and sidewalks, replace broken street lights, and implement a series of other small “cleanup” initiatives for 15 of the 30 areas. In the other 15, the police were instructed to continue operating normally. The result was an almost immediate 20% drop in police calls in the cleaned up areas. This is an interesting case-study for Broken Windows Theory.
First, let’s define “fired”: At some point, you were informed that your company has made the decision that they no longer want you working there. There are 3 broad categories for which you can get fired: The first is a violation of company policy, which includes absenteeism, tardiness, poor personal hygiene, threatening a fellow employee, discrimination, and sexual harassment. If you’ve been fired for any of these you deserved it, and you better get your life right before you look for another job. The second is incompetence, but most companies require extreme incompetence for a long period of time even after their attempts to train you have failed before they fired you. If you’ve been fired for that, well, you may not be smart enough or hard working enough for this line of work. Blame your parents for not making you study and do your chores. Finally, there is getting fired for standing up for what you believe in, but what you believe in is not in line with the what the company wants.
No organization would say they strive for mediocrity, yet so often they inadvertently reward employees for mediocrity and punish them for excellence. This slippery slope begins by attempting to define a job by the lowest common denominator of skills and responsibilities. Indeed, we hire for this lowest common denominator, and upon hiring we inform our new employees that they will have their performance measured, with an emphasis on executing in accordance with their new job’s requirements – job requirements that were determined through an examination of lowest common denominator expectations. There is often a hint at how an employee can exceed expectations, but no matter how this is presented it typically traces back to number of hours worked above those required. Having hired for mediocrity, set expectations for mediocrity, and offered incentives for longer hours which will lead to an eventual reduction in overall performance, we have successfully created a drone – a fungible resource that can be replaced or scaled a moment’s notice should the need arise. This, in essence, is the role of a middle management – to recruit and groom drones incapable of stepping outside of a company’s documented expectations.
Look, I don’t see what the big [flippin] deal is. We all curse – all the time. Stop [bull pooing] about it – you do, they do, we all do. When you’re around your friends having a drink, you curse like a [mother flippin] sailor on shore leave. So why is it not allowed in the work place? Because it offends people. Well you know what? It offends me that I can’t curse! Now I have to spend all my [gosh darn] time tiptoeing around your [flipped] up [bull poo] instead to telling you like it is! That’s not only frustrating, it’s a waste of valuable company resources!
It’s a well known fact among software professionals that the moment your friends and family discover your technical competency, you will become their indentured technical support servant for life. Whether it’s re-installing Windows or replacing ink cartridges, no task is too demeaning: if it involves a computer, you’re the first phone call they make. And why not? This is your fault, after all.
A regular critique I hear of engineers who are new to projects or codebases is that they provide almost immediate negative feedback about what they see, and are in no position to do so. The feedback tends to be received as being premature, unsolicited, and out of context, and is therefore undesired. To further complicate things, the engineer typically genuinely wants to improve things, and isn’t merely interested in bitching. I’ve personally received this feedback multiple times, and frankly, I’ve had just about enough of it. Rather than meet this constructive criticism with hostility, I’d like to propose a different approach for the receivers of the feedback. I’d also like to offer a peaceful compromise.
Fresh out of college, you have no idea what you’re doing. This fact is true no matter how much you paid for you college education, where you went, what your GPA was, or what Latin title was bestowed upon graduation. You have no clue, because you’ve never had a real job – this is your first. The number one gauge of being good at a job is experience in doing that job, and you have none. You may think that your college education is an indicator of how quickly you will master your job, but there is no correlation. It might actually work against you, because if you believe you already know everything you won’t be open to learning anything. If you want to get good at a job and you have no experience, you’ll need to apprentice under someone who can show you the ropes.
Management loves, and loves to tout about, training. Management distrusts training, because it highlights broken people, systems and processes. How can you love and distrust something at the same time? The dichotomy is a simple reflection that as it is designed today, many if not most training programs are ineffective and are nothing short of last-ditch efforts at salvaging un-qualified employees. This is especially true within the technology sector, a group of professionals that may benefit the most from training yet reaps the least as a result of mandate, motivation and momentum associated with training. There has to be a better way.
How good are you – really? Are you a master of your craft, merely mediocre, or do you suck? How would you know? Asking other people tends to yield nothing more but polite indirection and flattery, or at the other end of the spectrum rudeness masquerading as honesty. Within your organization, there are annual reviews, but they only gauge your performance against set expectations, not how you stack up to your peers. Without true visibility into other organizations, much less how their employees perform, you’re left with how they describe their employees: Typically infallible and elite. In truth, there is no yardstick to assess your own abilities compared to others, so what are you to do? How do you know if you need to improve, if you’re perfectly adequate, or if you’re so good that you need no further improvement?
Go to a developer-oriented gathering and you’ll hear this: “I have no interest in learning <xyz>” where <xyz> represent some kind of operational tasks or knowledge. Why should they? System administration is not really essential to software engineering, and conversely, ops teams have similar disinterest in writing code. Or they would be doing each other’s job already. That doesn’t mean there aren’t lessons to be learned from one another. In fact, the emergence of devops reflect just that recognition. It’s time for operations to adopt and apply the same discipline and knowledge that their brethren in the software camp have gradually refined over the years. It’s time for agile operations.
Terrorism comes in many forms. It’s commonly typified by leveraging hostage situations to undermine national policy and to facilitate foreign influence, or personal ulterior motives. An increasingly common incarnation of what I consider to be corporate terrorism manifests itself as so-called “knowledge anchors”: employees who have been with a company long enough to have acquired intimate knowledge about the business’ problem domain, and have subsequently outlasted any one else who might also have acquired the knowledge.
Work in software development long enough, and one day, you too will hear this phrase uttered by someone, “I used to code.” While the intention may be one of empathy or solicitation, as the identification of the supposed, shared, past is meant to build bonds. Inevitably, this utterance almost always forms a divisive line between those who write software and those who’ve stopped writing software to perform another role. The simple observation is this: developers seem to not respect careers paths past the immediate creation of code, while management — be it project, or product, or even executive — usually resort to this declaration, as some form of critique on effort, resourcefulness and most likely, timeliness of delivery.
It’s extremely difficult to find talented software engineers — especially in today’s market. I have my own theories as to why that is, ranging from the fact that software engineering is still a relatively young profession, all the way to deeper philosophies about how competent people are at their jobs, in general. What’s more, companies that lack talented engineers typically have a very difficult time finding talented engineers, and this is not coincidental.
Maintenance sucks. I don’t care who you are, or what you’re into, maintaining legacy code sucks. You spend your days getting asked to fix other people’s bugs in a labyrinth of crappy code that was clearly written by angry monkeys who could inexplicably hurl feces at a keyboard in a manner that would yield compiling code. In fact, it’s not called “maintenance” if the code is good — that’s just normal development. If you’re on maintenance, then you have done something very wrong at some point in your life — or you’re just starting out. Much like anyone new to anything, you’ve got to pay your dues. In software development, that’s working maintenance.
You need a plan. You’ve just been told by your boss that the highly visible, habitually failing flagship project – yep, the one that’s a year behind schedule – just became your problem. “Don’t worry, you can only come out of this looking good,” you hear, among other things, like “hand-picked” and “Swat Team” – each one making you cringe more than the last. You’ve been here before, and while the stakes may be different, one thing is certain – You. Are. Fucked.
Successful organizations thrive by their talents [people], and it’s mostly a losing battle because so many hiring decisions are simply… bad. Over the years, pundits and experts offer up many theories and philosophies on how to recruit, and then retain, superior personnel. It really comes down to just three things — Proficiency, Passion and Personality. That’s the secret. No more. No less. Interviews, tests and profiles are but the tools to establish how a candidate measure up under each areas.
The people who know me best are rarely shocked when I take a new job. After all, I work in a highly volatile industry, and it’s never long before something potentially more enticing than my current situation shows itself. I like to think this is true for everyone, with the possible difference being that I tend to react to these new opportunities, whereas many people do not.
Shockingly, the word “arrogant” has haunted me my whole career – and really my whole life. I’ve looked up the definition of “arrogant” more times than I care to admit, trying to contrast it with “confidence” and “humility”. I’ve been told more than once that I needed to work on being “humble”, and have genuinely tried to be so. Tried and failed. In terms of personal soul searching, “arrogance” has occupied a disproportionate amount of my staring-at-the-ceiling-trying-to-fall-asleep time. I don’t want to be arrogant – I don’t like the very idea of it, and am ashamed and confused that I seem to attract the description with alarming frequency. Ironically, an aspect of arrogance is an abundance of unwarranted confidence, yet I have no confidence that I can conquer the label of arrogance.
When your boss comes demanding you scale your team, don’t immediately fire up all the recruiters you know and start sifting through resumes looking for the perfect hire. First, give some thought as to what you were just asked to do. You weren’t really asked to hire more people (that’s expensive and risky), you were asked to boost productivity. The first place to look for more productivity is at your current team – especially at the novices. Most teams have some novice to average players who could use improvement, but we tend to ignore them assuming they can’t get better at what they do.