Several years ago, when I first started at PayPal, the front-end development environment was still fairly young. As a result, tools that might have existed in other environments were missing.
As a veteran coder, I quickly grew tired of repetitive tasks - I wanted to be writing code - and set about writing scripts that developed into a significant tool suite. I shared that tool suite with both front-end and back-end developers (there were no full-stack developers in those days) and the use of those tools spread throughout the company, across the globe.
Out of that activity, there were two different experiences that bear examination. I'll address the later of the two experiences first.
In later years, as the development environment matured, another engineer - one responsible for establishing a standard development environment - took control of the tool suite (totally understandable) and put his name on my work (not understandable). The tools I had birthed and nurtured through numerous changes in the development environment, and continually promoted so they would be visible to all engineers - were adopted and their new foster father promoted himself as their creator when they became visible to upper management.
This is not an unusual situation. It happens all too often - much more frequently to women, of course - that someone other than the individual who has done the work takes credit, especially as the work becomes more visible.
That experience taught me two lessons. First, how you handle it says volumes to those who see the situation. Second, obscurity can be moments away, behind someone else's shadow, even when you think the visibility you've worked to cultivate over years is secure.
The second experience was much more pleasant. On a regular visit to a development office, I was introduced to an engineer who had recently joined the company. The engineer and I exchanged pleasantries - the normal "nice to meet you" bit - and then the engineer who introduced us told her my username (which was explicitly tied to the aforementioned tool suite)...and her expression and demeanor shifted dramatically. As someone who's never been in the "popular" club (yes, I've been a nerd and geek since before secondary school), that reception was quite an ego boost.
I had no real expectation of receiving such a reception - none of my long-time friends who'd seen me develop the tools reacted in the same manner - and it caught me by surprise. That reception also taught me a lesson - there will be some ways in which you're always more visible than you believe you are.
History is eager to write out of the picture those who have struggled to build great things - whether it's a woman who's made a significant contribution to our community (like Nicole Sullivan, the creator of OOCSS) or a man who is more interested in the work than the credit (like Nikola Tesla).
When you find yourself in these situations - situations of visibility and/or obscurity - how you navigate those shoals says volumes about your ambition, your drive, your values - such as integrity and trust, and what you know to be true about yourself. In those situations, may you have fair winds and running seas.
Happy coding.
Showing posts with label managing vision and purpose. Show all posts
Showing posts with label managing vision and purpose. Show all posts
Monday, June 26, 2017
Friday, August 29, 2014
The Party's Over
On the way in to the office today I was listening to the radio. No, not "internet radio", real radio - with a real DJ and everything. There was an interview with Paul McCartney, who was asked, in light of his upcoming appearance at Candlestick Park, why the Beatles stopped performing...his response was "it wasn't fun anymore". Something about the culture of money, fame, and ostensibly doing what they loved changed and it wasn't fun anymore, and that was enough to make them walk away.
I know that the Beatles, individually, were famous and talented enough that they were able to enjoy 'solo' careers, and that even if they never toured or recorded again, they could probably have survived quite comfortably, and that's no small comfort (for them)...but still - walking away from millions of dollars and instant recognition with no guarantees that you will be able to do what you love again...it's nearly mind-blowing.
You might find yourself asking "why is this important, why is he bringing this up" - and with good reason. After all, my most recent posts on this blog have been at least somewhat technical...and there haven't even been any of those for a significant span of time (at least in blog years). So, your curiosity is understandable...and I'll get to the why of the timing eventually.
Back to the original train - "it wasn't fun anymore". When I heard this come over the airwaves, it reminded me of something I'd read in April of this year - Brian Chesky Note 1 relating the advice of Peter Thiel Note 2 when he funded Airbnb.
There have been a lot of people considering Thiel's advice - there are around 31,000 document matches when searching for Thiel's exact words - and now here is my journey down that particular rabbit hole.
When I was at university in the Metaphysics course, a question intended to highlight the division between essentialists and existentialists arose, framed not as a question about people but objects. Consider that we're rebuilding a sailing ship and we tear it down to the keel and replace all of the boards. When our work is complete, is it the same ship? If we think of it in terms of automobiles, it would not fit the definition of being the same car, because the identifier for the car - the VIN Note 3 - no longer accurately represents information about the vehicle. So, is it a question of how much we change something or what we change that makes the determination? Are organization analogous to objects? How does this apply to organisms?
Corporations are not people, but they are organisms, with values and personality that govern their actions, for good or evil. If we go back to the question of 'how much change' or 'what kind of change' makes something no longer identifiable as itself, we can think of situations in which we've thought, even though we may not have formally defined it, that some person we know has changed in some way and now they are not the same person - we may even readily claim this using this exact phrase. We should consider corporations subject to these same rules of behavior and personality. In fact, we can most likely each think of an organization - such as a business or philanthropic organization - that after an unsettling experience left us with the thought "they would have never done that it the past" or "they sure have changed."
Thiel most likely has seen organizations that have damaged their culture time and time again in organizations that have come to him for venture funding. He certainly sees it not only as a possible problem, but one that is likely as well. This, too, stands to reason as the common thinking is that as an organization grows, the culture changes as efficiency of scale is achieved in various areas.
The problem that I imagine Thiel sees - and yes, I am putting words in his mouth to an extent - is that when the culture changes, people leave - a situation that is also accepted as not only survivable, but normal. However, in reality, the turnover caused by culture changes are dangerous for an organization - it's like having an illness that has not yet been diagnosed - one with symptoms that you decide you can live with but that just might kill you. Part of the reasoning here is that culture changes are generally a self-reinforcing loop - the sort of loop that once it's started is not only difficult to stop, but also difficult to control or in some cases to even recognize.
Given the semi-private nature of an organization's culture, the earliest greatest impact of damage to an organization's culture will be to those within the organization. Why is this important? People are generally not motivated by money - culture is what motivates people - and it motivates people to do amazing things - like work 80 hours a week for several weeks at a time even though they're only compensated for 40, meet ridiculous deadlines, or nearly violate the laws of physics to deliver a high-quality, low-cost product quickly - whereas incentive programs generally don't work. Note 4 Because of the tight coupling between culture and other areas - like motivation and productivity, changes to culture can have a dramatic effect on the organization as a whole.
At this point, we might be tempted, after seeing people violate Thiel's advice, to think the culture of the organization is permanently damaged any time that it is changed dramatically. There certainly are people who have departed any number of organizations thinking just this thought. A brief review of companies on a site like glassdoor gives insight into the number of people working for a company who believe "changed" is equivalent to "damaged". However, here we have to stop and notice that Thiel's advice wasn't "don't have a damaged culture", his advice was "don't damage the culture". The linguistic difference between those two messages is less significant than it should be, because they are drastically different concepts.
In one version, culture is in a damaged state and in the other it's different than what it was. We need look no further than our own history of romantic relationships to see the truth of the premise that these are different, regardless of our willingness to admit it in the pain and grief that comes immediately after the recognition of how we, or the other, have changed. Just because someone or something you love - be it a person or an organization - changes and you find they are now intolerable (to you) that does not mean that they are therefore befouled or damaged - they can be a perfectly nice, good person (or organization) and still not be your cup of tea. Changes are significant, however, because once you've changed the culture, people no longer have the company they love, and people not only lose motivation, people start leaving - whether they're customers or employees - and that's seldom a good thing. Note 5
When the people most invested in the success of an organization - like employees - leave because the culture has been damaged, there are likely to be repercussions that ripple out in ever-widening circles, like those created when a pebble is dropped into a pond. If the damage to the organization's culture is significant enough, it's just a matter of time before that trend carries outward as far as customers. Whether the organization can repair the damage and weather depends on a variety of factors that are outside the scope of this brief essay, but in every case, the nature of the business will be profoundly changed. Whether that change is for good or ill is something only time can tell. If your organization survives by knowing their customers (or users), such turbulence can be exceedingly dangerous, and it is unwise to assume that it is not.
Now, to address the question of why this post, now.
Recently there has been a lot of interest in why I left a position I held for nearly a decade. Here is the best brief explanation I can offer - I left for the same reason the Beatles stopped touring - it wasn't fun anymore. Unfortunately, that explanation has frequently proven inadequate and I have developed a longer, but still brief, explanation.
Several years ago, I started what I believed could potentially be my last job in the industry. The work was challenging and interesting, the people were, as they say, "wicked smart" and immensely talented, the product was an economic product geared toward serving under-served populations, and the general corporate culture was based on four basic values that resonated with me. It was, in a lot of ways - very nearly every way in fact - the perfect fit. Over the course of the next several years, things changed - as things do. The work became mundane as my skills were under-utilized, the vast majority of people moved on, and the product and culture changed significantly. The organization was not the same organization with which I had fallen in love, and I finally came to recognize that all the perks and incentive programs were metaphorical chains that bound me in place.
As a result of changes that transformed the organization from something I loved into something that I didn't, I left - and yes, it was before finding another gig - because I'm a firm believer that when you see it's time to go, you put your affairs in order, raise your sails, and go. Now, three months past my departure, I still have a sense of what I've lost, and yet there are times that, like the song says, I'm "too relieved to grieve" Note 6 because, in the end golden chains are still chains (Robert's Rule #33).
I know that the Beatles, individually, were famous and talented enough that they were able to enjoy 'solo' careers, and that even if they never toured or recorded again, they could probably have survived quite comfortably, and that's no small comfort (for them)...but still - walking away from millions of dollars and instant recognition with no guarantees that you will be able to do what you love again...it's nearly mind-blowing.
You might find yourself asking "why is this important, why is he bringing this up" - and with good reason. After all, my most recent posts on this blog have been at least somewhat technical...and there haven't even been any of those for a significant span of time (at least in blog years). So, your curiosity is understandable...and I'll get to the why of the timing eventually.
Back to the original train - "it wasn't fun anymore". When I heard this come over the airwaves, it reminded me of something I'd read in April of this year - Brian Chesky Note 1 relating the advice of Peter Thiel Note 2 when he funded Airbnb.
Don't fuck up the culture.
Peter Thiel, 2012
There have been a lot of people considering Thiel's advice - there are around 31,000 document matches when searching for Thiel's exact words - and now here is my journey down that particular rabbit hole.
When I was at university in the Metaphysics course, a question intended to highlight the division between essentialists and existentialists arose, framed not as a question about people but objects. Consider that we're rebuilding a sailing ship and we tear it down to the keel and replace all of the boards. When our work is complete, is it the same ship? If we think of it in terms of automobiles, it would not fit the definition of being the same car, because the identifier for the car - the VIN Note 3 - no longer accurately represents information about the vehicle. So, is it a question of how much we change something or what we change that makes the determination? Are organization analogous to objects? How does this apply to organisms?
Corporations are not people, but they are organisms, with values and personality that govern their actions, for good or evil. If we go back to the question of 'how much change' or 'what kind of change' makes something no longer identifiable as itself, we can think of situations in which we've thought, even though we may not have formally defined it, that some person we know has changed in some way and now they are not the same person - we may even readily claim this using this exact phrase. We should consider corporations subject to these same rules of behavior and personality. In fact, we can most likely each think of an organization - such as a business or philanthropic organization - that after an unsettling experience left us with the thought "they would have never done that it the past" or "they sure have changed."
Thiel most likely has seen organizations that have damaged their culture time and time again in organizations that have come to him for venture funding. He certainly sees it not only as a possible problem, but one that is likely as well. This, too, stands to reason as the common thinking is that as an organization grows, the culture changes as efficiency of scale is achieved in various areas.
The problem that I imagine Thiel sees - and yes, I am putting words in his mouth to an extent - is that when the culture changes, people leave - a situation that is also accepted as not only survivable, but normal. However, in reality, the turnover caused by culture changes are dangerous for an organization - it's like having an illness that has not yet been diagnosed - one with symptoms that you decide you can live with but that just might kill you. Part of the reasoning here is that culture changes are generally a self-reinforcing loop - the sort of loop that once it's started is not only difficult to stop, but also difficult to control or in some cases to even recognize.
Given the semi-private nature of an organization's culture, the earliest greatest impact of damage to an organization's culture will be to those within the organization. Why is this important? People are generally not motivated by money - culture is what motivates people - and it motivates people to do amazing things - like work 80 hours a week for several weeks at a time even though they're only compensated for 40, meet ridiculous deadlines, or nearly violate the laws of physics to deliver a high-quality, low-cost product quickly - whereas incentive programs generally don't work. Note 4 Because of the tight coupling between culture and other areas - like motivation and productivity, changes to culture can have a dramatic effect on the organization as a whole.
At this point, we might be tempted, after seeing people violate Thiel's advice, to think the culture of the organization is permanently damaged any time that it is changed dramatically. There certainly are people who have departed any number of organizations thinking just this thought. A brief review of companies on a site like glassdoor gives insight into the number of people working for a company who believe "changed" is equivalent to "damaged". However, here we have to stop and notice that Thiel's advice wasn't "don't have a damaged culture", his advice was "don't damage the culture". The linguistic difference between those two messages is less significant than it should be, because they are drastically different concepts.
In one version, culture is in a damaged state and in the other it's different than what it was. We need look no further than our own history of romantic relationships to see the truth of the premise that these are different, regardless of our willingness to admit it in the pain and grief that comes immediately after the recognition of how we, or the other, have changed. Just because someone or something you love - be it a person or an organization - changes and you find they are now intolerable (to you) that does not mean that they are therefore befouled or damaged - they can be a perfectly nice, good person (or organization) and still not be your cup of tea. Changes are significant, however, because once you've changed the culture, people no longer have the company they love, and people not only lose motivation, people start leaving - whether they're customers or employees - and that's seldom a good thing. Note 5
When the people most invested in the success of an organization - like employees - leave because the culture has been damaged, there are likely to be repercussions that ripple out in ever-widening circles, like those created when a pebble is dropped into a pond. If the damage to the organization's culture is significant enough, it's just a matter of time before that trend carries outward as far as customers. Whether the organization can repair the damage and weather depends on a variety of factors that are outside the scope of this brief essay, but in every case, the nature of the business will be profoundly changed. Whether that change is for good or ill is something only time can tell. If your organization survives by knowing their customers (or users), such turbulence can be exceedingly dangerous, and it is unwise to assume that it is not.
Now, to address the question of why this post, now.
Recently there has been a lot of interest in why I left a position I held for nearly a decade. Here is the best brief explanation I can offer - I left for the same reason the Beatles stopped touring - it wasn't fun anymore. Unfortunately, that explanation has frequently proven inadequate and I have developed a longer, but still brief, explanation.
Several years ago, I started what I believed could potentially be my last job in the industry. The work was challenging and interesting, the people were, as they say, "wicked smart" and immensely talented, the product was an economic product geared toward serving under-served populations, and the general corporate culture was based on four basic values that resonated with me. It was, in a lot of ways - very nearly every way in fact - the perfect fit. Over the course of the next several years, things changed - as things do. The work became mundane as my skills were under-utilized, the vast majority of people moved on, and the product and culture changed significantly. The organization was not the same organization with which I had fallen in love, and I finally came to recognize that all the perks and incentive programs were metaphorical chains that bound me in place.
As a result of changes that transformed the organization from something I loved into something that I didn't, I left - and yes, it was before finding another gig - because I'm a firm believer that when you see it's time to go, you put your affairs in order, raise your sails, and go. Now, three months past my departure, I still have a sense of what I've lost, and yet there are times that, like the song says, I'm "too relieved to grieve" Note 6 because, in the end golden chains are still chains (Robert's Rule #33).
Notes and references
Links in the notes and references list open in a new window- Brian Chesky is the founder and CEO of Airbnb. You can learn more about him on wikipedia.
- You can learn more about Peter Thiel, an outspoken entrepreneur and venture capitalist, on wikipedia.
- The Vehicle Identification Number is an alphanumeric sequence used to uniquely identify a vehicle.
- A summary of a journal article in the Harvard Business Review says it clearer than I've seen it said before - "according to numerous studies in laboratories, workplaces, classrooms, and other settings, rewards typically undermine the very processes they are intended to enhance."
- There are a number of reasons it's not good when people leave an organization - brain drain and the ills associated with turnover - hiring costs, overtime costs, low morale, and low productivity to name just a few - are just two of the big reasons.
- "Let It Go" (Kristen Anderson-Lopez and Robert Lopez) as performed by Demi Lovato.
Wednesday, December 25, 2013
A New Broom
At the end of the year, I look back and think about the auld lang syne1...like many of you, I would suspect. This past year, for a lot of us, saw a jump into yet another technology stack as the newest broom - in this case dustjs - sweeps the UI engineering world (thanks to the powerhouse known as LinkedIn and later, PayPal, who took the ball and ran with it). It was bound to happen sooner or later, of course. As one person commented about learning to code, you must realize that if you choose to become a developer you will learn to code every day for the rest of your life.2
This realization - or remembrance on my part - brings up another point, however. People, especially geeks in my line of work, get über excited about new technology, and a lot of that excitement is misplaced. Let me say at the outset, there are usually legitimate reasons for getting excited about a technology stack, but we are too often subject to more hype than reality.
Long, long ago in a galaxy far, far away...when I started on my career path, I worked for a company that was built on COBOL 74, courses covering C were finally making it into university programs, and RDBMS languages like PROGRESS and PARADOX were making inroads on PCs (which were still fairly new themselves). Those first few years when businesses were setting up token-ring networks and figuring out how to share data across multiple workstations that weren't linked to a mainframe were exciting - primarily because it was a minor revolution. The cost of several PCs, even in those days, was considerably lower than the cost of a mainframe and it became a lot less expensive to do business.
In a few years we were all connecting to a little corner of the Internet called "the World Wide Web" and there was another minor revolution as the online world enabled a globalization of business that previously had been the domain of international businessmen (and let's be honest, there really weren't international businesswomen in those days - so we're slightly less sexist now - not much, but a little). In the almost 20 years since, we've gone from HTML, with its simple styling tags to CSS, JavaScript, and HTML5 in front-end code and gone through (something like six production versions of) ColdFusion, ASP and ASP.Net...and C#.Net...and well...everything Dot Net, Perl (and LAMP), PHP, Stripe, Ruby (and Ruby on Rails), Python...and on and on. Yes, the world has improved...except...it really hasn't.
In my time, I've written software for a number of organizations, and nearly every time I've changed organizations I've changed the language(s) I've used. This realization leads me to two conclusions - both relevant to today's environment. First, I cannot recall the last coding class I took that actually applied to what I was doing or about to do in which I did not know as much, or more, about the topic than the instructor. On the other hand, I easily recall the last time I used what I learned in a number of courses in maths, language, history, and philosophy - so that is what I will make sure I pass along to the next generation.3 Second, the technology used by someone (organizations included) is nearly irrelevant.
Why would I, a geek at my core, say something like the technology is nearly irrelevant? Because I believe it to be true. For evidence, we need only look to the any of a number of organizations, both public and private, functioning quite well on technology that is decades old. We might also consider that while there is no doubt that I am not a fan of complexity, newer technologies are sometimes improvements or even required even though they typically add complexity on any one of the many layers an organization has. To see the truth of this one need simply follow the path of the World Wide Web from document markup and delivery to ecommerce.
In my own career you may be surprised at the number of organizations that I have worked with that have said "we're not responding to <something> fast enough because our technology is out-dated, but we'll be able to respond much more quickly if we start using <your favorite technology>". You might also be surprised at the number of times an organization has been wrong when it has made such a claim. Let's look at this idea from a few points of view.
First, let's consider the learning curve associated with any new technology. If we have, for example, engineers expert in C, they will likely be able to switch to C++ with little effort. If, on the other hand, we switch to Java (which is a much more likely scenario) they are likely not experts and may in fact be novices, not only with the language itself, but with purer object-oriented languages in general. It takes time and effort to become an expert, time and effort that make the claim of being able to respond more quickly if a different technology is used questionable.
Since responding quickly is often a question of productivity, let's look at another activity - developers building productivity tools. Historically, manufacturing operations had a person (or persons) designated as 'tool and die maker'. However, because of the distributed nature of application development that position has been abandoned. There may be productivity teams who look at how productivity can be increased, but typically those groups are too far separated from the process and paint with too broad a brush to be as effective as possible. Further exacerbating the problem - when the underlying technology changes, tools used previously are obsolete, even if the problems those tools solve are not. This alteration of process alone increases the learning curve associated with new technology, and if the underlying problems have not been addressed, new tools must be built to replace the obsolete tools.
These are just two of the myriad issues associated with changing a technology stack. So, if it's not the technology that makes an organization successful, what is it? How the organization functions.
One of our idiomatic expressions is "a new broom sweeps clean", and unfortunately this is true in organizations - sometimes through the diminishing of knowledge capital by significant turnover in human resources but more often simply because the new person has a different way of doing things or is used to a different technology. How new brooms are put to use is a part of how an organization functions, and if each new broom sweeps clean, there is little history from which to learn.4
Another aspect of how an organization functions - where money is budgeted - demonstrates the organization priorities. In short, budgets are power - the larger the budget, the greater the power, and an easy way of securing a larger budget is by making the case that <your least favorite technology> is out-dated and must be replaced. You can claim that you won't be able to compete for better job applicants or that support for <your least favorite technology> is going away or that <some other technology> is faster and more reliable. Some of your claims might even be true, but they need not be verifiable to induce a mild fear response and increase your budget. Of course once you have the budget, you have to spend it to keep it - otherwise you lose your standing of power in the next round.
Of course, the truth of the matter is that there are job applicants who are expert in <your least favorite technology> who are happy to work for well-functioning organizations and most established technology will be continually supported, simply because organizations providing the technology understand the importance of backward compatibility. As for claims of <your favorite technology> being faster and more reliable...sometimes those are true, but typically only after becoming established technologies. Increased complexity rarely produces speed or reliability as offspring; rather, complex systems fail in complex ways and, unfortunately, failure is not an option - it's a certainty built into every system.
For all the hype, the technology should not be the ultimate concern. For instance, LinkedIn could just as easily run their entire site using classic ASP rather than dustjs. I understand their reasons for not doing so and I understand their reasons for getting away from a fragmented stack5 but I also recognize that getting to a point where the stack is fragmented is a function, not of the technology, but the organizational culture and the way in which the organization operates.
There are usually a number of legitimate reasons for changing a technology stack, but let's step away from the hype of how "<my favorite technology> will help us get to market faster" (there are other, better ways to do that - Lean UX6 for example) or the "how <my favorite techonology> is better than <your favorite technology>" arguments that have been known to start something akin to a holy war in engineering departments. We're better than such puerile behavior, and maybe if we're not focused on how great the squirrel scampering by is, we can focus on building from our strengths and making more awesome...because sometimes we do not need a new broom, we need to learn how to sweep.
This realization - or remembrance on my part - brings up another point, however. People, especially geeks in my line of work, get über excited about new technology, and a lot of that excitement is misplaced. Let me say at the outset, there are usually legitimate reasons for getting excited about a technology stack, but we are too often subject to more hype than reality.
Long, long ago in a galaxy far, far away...when I started on my career path, I worked for a company that was built on COBOL 74, courses covering C were finally making it into university programs, and RDBMS languages like PROGRESS and PARADOX were making inroads on PCs (which were still fairly new themselves). Those first few years when businesses were setting up token-ring networks and figuring out how to share data across multiple workstations that weren't linked to a mainframe were exciting - primarily because it was a minor revolution. The cost of several PCs, even in those days, was considerably lower than the cost of a mainframe and it became a lot less expensive to do business.
In a few years we were all connecting to a little corner of the Internet called "the World Wide Web" and there was another minor revolution as the online world enabled a globalization of business that previously had been the domain of international businessmen (and let's be honest, there really weren't international businesswomen in those days - so we're slightly less sexist now - not much, but a little). In the almost 20 years since, we've gone from HTML, with its simple styling tags to CSS, JavaScript, and HTML5 in front-end code and gone through (something like six production versions of) ColdFusion, ASP and ASP.Net...and C#.Net...and well...everything Dot Net, Perl (and LAMP), PHP, Stripe, Ruby (and Ruby on Rails), Python...and on and on. Yes, the world has improved...except...it really hasn't.
In my time, I've written software for a number of organizations, and nearly every time I've changed organizations I've changed the language(s) I've used. This realization leads me to two conclusions - both relevant to today's environment. First, I cannot recall the last coding class I took that actually applied to what I was doing or about to do in which I did not know as much, or more, about the topic than the instructor. On the other hand, I easily recall the last time I used what I learned in a number of courses in maths, language, history, and philosophy - so that is what I will make sure I pass along to the next generation.3 Second, the technology used by someone (organizations included) is nearly irrelevant.
Why would I, a geek at my core, say something like the technology is nearly irrelevant? Because I believe it to be true. For evidence, we need only look to the any of a number of organizations, both public and private, functioning quite well on technology that is decades old. We might also consider that while there is no doubt that I am not a fan of complexity, newer technologies are sometimes improvements or even required even though they typically add complexity on any one of the many layers an organization has. To see the truth of this one need simply follow the path of the World Wide Web from document markup and delivery to ecommerce.
In my own career you may be surprised at the number of organizations that I have worked with that have said "we're not responding to <something> fast enough because our technology is out-dated, but we'll be able to respond much more quickly if we start using <your favorite technology>". You might also be surprised at the number of times an organization has been wrong when it has made such a claim. Let's look at this idea from a few points of view.
First, let's consider the learning curve associated with any new technology. If we have, for example, engineers expert in C, they will likely be able to switch to C++ with little effort. If, on the other hand, we switch to Java (which is a much more likely scenario) they are likely not experts and may in fact be novices, not only with the language itself, but with purer object-oriented languages in general. It takes time and effort to become an expert, time and effort that make the claim of being able to respond more quickly if a different technology is used questionable.
Since responding quickly is often a question of productivity, let's look at another activity - developers building productivity tools. Historically, manufacturing operations had a person (or persons) designated as 'tool and die maker'. However, because of the distributed nature of application development that position has been abandoned. There may be productivity teams who look at how productivity can be increased, but typically those groups are too far separated from the process and paint with too broad a brush to be as effective as possible. Further exacerbating the problem - when the underlying technology changes, tools used previously are obsolete, even if the problems those tools solve are not. This alteration of process alone increases the learning curve associated with new technology, and if the underlying problems have not been addressed, new tools must be built to replace the obsolete tools.
These are just two of the myriad issues associated with changing a technology stack. So, if it's not the technology that makes an organization successful, what is it? How the organization functions.
One of our idiomatic expressions is "a new broom sweeps clean", and unfortunately this is true in organizations - sometimes through the diminishing of knowledge capital by significant turnover in human resources but more often simply because the new person has a different way of doing things or is used to a different technology. How new brooms are put to use is a part of how an organization functions, and if each new broom sweeps clean, there is little history from which to learn.4
Another aspect of how an organization functions - where money is budgeted - demonstrates the organization priorities. In short, budgets are power - the larger the budget, the greater the power, and an easy way of securing a larger budget is by making the case that <your least favorite technology> is out-dated and must be replaced. You can claim that you won't be able to compete for better job applicants or that support for <your least favorite technology> is going away or that <some other technology> is faster and more reliable. Some of your claims might even be true, but they need not be verifiable to induce a mild fear response and increase your budget. Of course once you have the budget, you have to spend it to keep it - otherwise you lose your standing of power in the next round.
Of course, the truth of the matter is that there are job applicants who are expert in <your least favorite technology> who are happy to work for well-functioning organizations and most established technology will be continually supported, simply because organizations providing the technology understand the importance of backward compatibility. As for claims of <your favorite technology> being faster and more reliable...sometimes those are true, but typically only after becoming established technologies. Increased complexity rarely produces speed or reliability as offspring; rather, complex systems fail in complex ways and, unfortunately, failure is not an option - it's a certainty built into every system.
For all the hype, the technology should not be the ultimate concern. For instance, LinkedIn could just as easily run their entire site using classic ASP rather than dustjs. I understand their reasons for not doing so and I understand their reasons for getting away from a fragmented stack5 but I also recognize that getting to a point where the stack is fragmented is a function, not of the technology, but the organizational culture and the way in which the organization operates.
There are usually a number of legitimate reasons for changing a technology stack, but let's step away from the hype of how "<my favorite technology> will help us get to market faster" (there are other, better ways to do that - Lean UX6 for example) or the "how <my favorite techonology> is better than <your favorite technology>" arguments that have been known to start something akin to a holy war in engineering departments. We're better than such puerile behavior, and maybe if we're not focused on how great the squirrel scampering by is, we can focus on building from our strengths and making more awesome...because sometimes we do not need a new broom, we need to learn how to sweep.
Notes: links open in a new window
- Days long past or in American vernacular, the good 'ol days.
- Dachis, Adam. Don't Learn to Code: Learn to Work with Technology.
- You can read more of my thoughts about coding classes in "Coding education, coding life".
- Those who cannot remember the past are condemned to repeat it. [Santayana, George. The Life of Reason; or the Phases of Human Progress. New York: Charles Scribner's Sons, 1905.]
- Basavaraj, Veena. Leaving JSPs in the Dust: moving LinkedIn to dust.js and client-side templates.
- Gothelf, Jeff. Lean UX: Getting Out of the Deliverables Business.
Thursday, August 1, 2013
Ambition
There's more here than just my ingrained beliefs, however; more that relates to ambition and how others perceive it. More that we in the corporate world refuse to discuss because we all know what the words and concepts mean. We are so convinced we know the meaning that we really need not think about the words or the concepts they convey. However, I wonder if perhaps it is that we don't really understand ambition, even though we think we know the definition.[1]
As a case-in-point, I recently received a message from a former coworker - I'll call him Mr. Foo - that I'm going to paraphrase here, removing references that will identify who it was or which employer we shared in common. All edits will be enclosed in *[ and ]* to identify them.
When I was at *[our common employer]*, I was full of ambition and could not for the life of me figure out why you didn't put a ton of effort into sharing your *[tools]* with the *[rest of the employees there]* in a more formal fashion than just have them 755[2] in your home dir.
...
*[It]* might sound kind of weird, but in this weird way that chosen inaction on your part really stuck with me and I've always respected and always will respect you as an awesome developer and wise person in general...and time to time I think "well, Robert had this awesome stuff and didn't really share it or align himself with movement x y or z". There's wisdom in your actions, I think, and its taken me a while to come around to understanding that.Now, I might have shared this message because this person referred to me as "an awesome developer" (and yes, I appreciate "awesome developer" more than "wise person" - it's better geek cred) and it's not really blowing my own trumpet because Mr. Foo has done it for me - that sort of ego stroking always feels good, but that's really not why I share it.
My thought today is this - most of us - and by most I mean nearly all, have become convinced that ambition and self-promotion are inseparable. They are not. Few of us have difficulty with people who are ambitious - at least to a small degree; however, more than a few have difficulty with those eager for self-promotion - people who, as they say in the western US are "all hat and no cattle"[3]. While ambition is a necessary condition for self-promotion, it is not a sufficient condition.
My experience of the cycle of self-promotion rampant in corporate culture has been one that has shown it to be one of the most emotionally damaging issues confronting humanity. It is a vampiric greed that drains the soul of a person, because just as for the gun-fighter of the old west, there is always someone faster or willing to cheat just a little, and in the end you're just as dead.
In honesty, I created the tools Mr Foo references to make work easier - for me, sure, but for anyone who used them. I promoted the tools (not myself as author) on several occasions as something that could help resolve a problem but if others didn't use them I wasn't offended - I decided to not be bothered by the action of others.
That is not to say there aren't consequences for avoiding self-promotion. There are. It would be nice if the world - or our little part of it - were the meritocracy we teach our children it is - one where management paid less attention to self-promotion than work. Unfortunately, life is not nice - nor is the corporate world. If you're going to avoid self-promotion - the grasping greed of blind ambition - be prepared to get punched in the face, hard. People around you will not understand, and will likely criticize, your lack of ambition. Of course what they really mean is that you don't share their goals, but that will not be how it is put forward - this isn't a cooperative game with a win-win outcome, this is a bare-knuckle fist fight because people don't like what they don't understand, and people don't understand others who refuse to engage in self-promotion.
The good news, however, is that while self-promotion may not keep you from getting punched in the face, without it you're more likely to keep your soul in the exchange.
To Mr. Foo, if you're reading this and recognize your words, thanks for everything.
Notes:
- Ambition: (a) an ardent desire for rank, fame, or power; (b) desire to achieve a particular end
- 755 is the numeric representation of permissions for a file that indicates it is readable and executable by users on the network but only modifiable by the owner
- Full of big talk, but no action; pretentious
Wednesday, June 12, 2013
Rockstars and Innovation: Stairway to Heaven
A friend recently posted a link to an article[1] by Francois Marchand of The Vancouver Sun that covered a portion of the Kennedy Center Honors - specifically the tribute concert for Led Zepplin[2]. Being a big fan of the Kennedy Center Honors, I watched this particular celebration when it aired on my local CBS affiliate, but the article brought something back to mind that I had temporarily forgotten - a question I had nearly every year when I watched the program - do stars realize they are creating something epic when they are creating it?
We know a lot about stars (divo or diva, if you will), especially in the US where we're constantly fed minutiae, from what they wear and eat to the foibles of their children and the sins that will be visited upon them - we even know about their demanding, uncompromising fits of rage and a little about how their attitude might be handled[3]. It would be dishonest to imply that all the stars are thespians and musicians, after all, we in the technology industry have our share of stars (some of which, Steve Jobs for instance, have notable rants). However, we might say that all the stars consider themselves artists. It's with this area bordering aesthetics[4] that I'm particularly interested.
First, I would posit that people, stars in particular, never realize the true nature of their creation - they may have visions of a possible future, but never fully grasp the import. Even some of the (arguably) most brilliant of minds do not realize the most minor consequences of their actions until they see the first glimpse of their creation come to life[5]. One reason for this is that we simply cannot foresee the future. We cannot anticipate the many ways in which our creation will be re-arranged, re-interpreted, or re-worked.
A more important reason for this disconnect between the recognition of the impact a creation has and the birth of the creation, however, is in the very act of creation itself. The two events - the birth and the post-birth impact are bound to different understandings of time. Where the birth is held by kairos[6], the impact - whether or not something is epic - is held in chronos[7].
Some artists are entirely comfortable with this difference, willingly surrendering the telling of the story or the composing of the song to the moment and leaving the remainder to time and even going so far to say that they are driven only to create - storytellers have stories that they feel must be told, or in some cases, tell themselves, and musicians have songs they feel must be sung. It is the purity of this brief moment - a brief moment in which things are possible - that births what is epic, and even though we strive for perfection, we cannot intentionally create anything truly epic, for all of our planning and working - logos - is bound to chronos.
What does this say about pleas for organizational leadership for 'innovation' then? As we've begun to see, innovative has suddenly come to mean not only 'changed' but also carries the connotation of the change being epic as well. Innovative is revolutionary, evolutionary is passe.
There are only two directions in which we can move from this false understanding of innovation - recognize that striving for 'innovation' is irrational and therefore counterproductive, or move to the original understanding of 'innovation'.
Given that epic creations are rare and cannot be crafted through striving, strive instead to innovate in the true sense - change things, especially through small, non-fundamental (evolutionary) changes - changes like adding a choir to your arrangement of an iconic song. Not only does this approach involve less risk than major or fundamental changes, it can just as easily give birth to something epic - something that even the creator didn't imagine[8].
Notes:
We know a lot about stars (divo or diva, if you will), especially in the US where we're constantly fed minutiae, from what they wear and eat to the foibles of their children and the sins that will be visited upon them - we even know about their demanding, uncompromising fits of rage and a little about how their attitude might be handled[3]. It would be dishonest to imply that all the stars are thespians and musicians, after all, we in the technology industry have our share of stars (some of which, Steve Jobs for instance, have notable rants). However, we might say that all the stars consider themselves artists. It's with this area bordering aesthetics[4] that I'm particularly interested.
First, I would posit that people, stars in particular, never realize the true nature of their creation - they may have visions of a possible future, but never fully grasp the import. Even some of the (arguably) most brilliant of minds do not realize the most minor consequences of their actions until they see the first glimpse of their creation come to life[5]. One reason for this is that we simply cannot foresee the future. We cannot anticipate the many ways in which our creation will be re-arranged, re-interpreted, or re-worked.
A more important reason for this disconnect between the recognition of the impact a creation has and the birth of the creation, however, is in the very act of creation itself. The two events - the birth and the post-birth impact are bound to different understandings of time. Where the birth is held by kairos[6], the impact - whether or not something is epic - is held in chronos[7].
Some artists are entirely comfortable with this difference, willingly surrendering the telling of the story or the composing of the song to the moment and leaving the remainder to time and even going so far to say that they are driven only to create - storytellers have stories that they feel must be told, or in some cases, tell themselves, and musicians have songs they feel must be sung. It is the purity of this brief moment - a brief moment in which things are possible - that births what is epic, and even though we strive for perfection, we cannot intentionally create anything truly epic, for all of our planning and working - logos - is bound to chronos.
What does this say about pleas for organizational leadership for 'innovation' then? As we've begun to see, innovative has suddenly come to mean not only 'changed' but also carries the connotation of the change being epic as well. Innovative is revolutionary, evolutionary is passe.
There are only two directions in which we can move from this false understanding of innovation - recognize that striving for 'innovation' is irrational and therefore counterproductive, or move to the original understanding of 'innovation'.
Given that epic creations are rare and cannot be crafted through striving, strive instead to innovate in the true sense - change things, especially through small, non-fundamental (evolutionary) changes - changes like adding a choir to your arrangement of an iconic song. Not only does this approach involve less risk than major or fundamental changes, it can just as easily give birth to something epic - something that even the creator didn't imagine[8].
Notes:
- Heart plays Led Zeppelin’s Stairway To Heaven, makes Robert Plant cry, The Vancouver Sun, 27 December 2012.
- Heart - Stairway to Heaven Led Zeppelin - Kennedy Center Honors
- Robert's Rule #6: when working with rock stars, get your M&Ms ready
- The branch of philosophy dealing with the creation, appreciation, and nature of art, beauty, and taste.
- Oppenheimer, in recalling reaction to the first test of the creation produced by the Manhattan Project, said that he, and his fellow scientists realized the world would never be the same, and called to memory a line from the Bhagavad Gita, "now I am become death". [Video]
- In mythology, Kairos (opportunity), was the youngest son of Zeus. He is described as running swiftly, balancing on the razor's edge, unclothed and with only a forelock - so that if you grasp him from the front, you might be able to hold him, but once he has moved on not even Zeus himself can pull him back. Because of this tie to mythology, kairos is the brief moment in which things are possible, and is a qualitative measure of time.
- In mythology, Chronos is the personification of time and the serpentine consort of Ananke (inevitability) who co-creates the cosmos. He is not unending time (represented by Aion), but is the one turning the wheel of time and is, therefore, not a brief moment, but a quantitative measure of time.
- Make note of the reaction of both Plant and Page throughout the video of Heart's rendition (see note 2).
Wednesday, May 1, 2013
Doing the impossible (with Robert's Rule #31 & #32)
This post is not going to be a 'how-to', or an example of critical thought applied to a current topic, but rather a prosaic reflection with career advice mixed in - somewhat like earlier posts.
When I was a young child, we were discussing poetry in primary school and I pulled a book of American poets off the shelf and found It Couldn't Be Done by Edgar A. Guest[1]. I still recall the note my schoolteacher sent home saying how much the poem reminded her of me, even though I cannot find the note - of course that was quite a number of years ago.
I would not encourage anyone to be excessively optimistic (I would say pollyannaish, but I believe that unfairly associates optimism with feminism), there have been a number of credible studies that demonstrate the benefits of positive thinking[2]. Yet, there is something beyond even positive thinking that I feel is crucial to our survival in a corporate environment - an indomitable will. For some, an indomitable will manifests as an "incorruptible patience" or "a destructive pursuit of perfection"[3]; for others, there are other ways - but they have this in common - they are not skill related and won't be found on the Programmer Competency Matrix[4] - in fact, it's those times that we're faced with a situation that we know is beyond our bounds that this applies, and it's what made Bert Bell's belief that on any given Sunday any team could beat any other team in the league real. (Robert's Rule #31 - success is about more than skill - is based on that belief.)
A personal story - several years ago I was preparing to fly to California for an in-person interview for a position that I considered a dream job when I found out that my sister, who lived 2000 miles away, was critically ill, and a few hours before I was to leave for my day-long interview, I learned she had died. My grief was beyond anything I had borne before, but I also recognized that the only thing I could do at that point was request PTO and book a flight - and one more day would make little difference in the grief or support that I, or anyone else in my family, could offer.
Even though I knew a rigorous interview process was beyond my bounds in that circumstance, I went and did my best. After I returned home, I contacted my employer and booked a flight, and left the next day. After I secured the job (yes, I did get it), I discovered that some who interviewed me noticed (what they interpreted as) a lack of enthusiasm - several commented to me that interviewing in that situation was something they thought couldn't be done, yet it was done - and well enough to secure the job.
So, here's the lesson I learned that day - if you want something enough and your will is indomitable, you will likely succeed - success is not guaranteed, mind, but very likely.
There was another lesson I learned that day - one that's probably more important
that I carry with me, especially every time I interview a candidate - on any given day we see only a part of a person, and like in jazz, the important bits might be those not heard, so make allowances for what you don't see (Robert's Rule #32).
Or, in the words of Bill (in Bill & Ted's Excellent Adventure), "be excellent to each other".
Notes:
When I was a young child, we were discussing poetry in primary school and I pulled a book of American poets off the shelf and found It Couldn't Be Done by Edgar A. Guest[1]. I still recall the note my schoolteacher sent home saying how much the poem reminded her of me, even though I cannot find the note - of course that was quite a number of years ago.
I would not encourage anyone to be excessively optimistic (I would say pollyannaish, but I believe that unfairly associates optimism with feminism), there have been a number of credible studies that demonstrate the benefits of positive thinking[2]. Yet, there is something beyond even positive thinking that I feel is crucial to our survival in a corporate environment - an indomitable will. For some, an indomitable will manifests as an "incorruptible patience" or "a destructive pursuit of perfection"[3]; for others, there are other ways - but they have this in common - they are not skill related and won't be found on the Programmer Competency Matrix[4] - in fact, it's those times that we're faced with a situation that we know is beyond our bounds that this applies, and it's what made Bert Bell's belief that on any given Sunday any team could beat any other team in the league real. (Robert's Rule #31 - success is about more than skill - is based on that belief.)
A personal story - several years ago I was preparing to fly to California for an in-person interview for a position that I considered a dream job when I found out that my sister, who lived 2000 miles away, was critically ill, and a few hours before I was to leave for my day-long interview, I learned she had died. My grief was beyond anything I had borne before, but I also recognized that the only thing I could do at that point was request PTO and book a flight - and one more day would make little difference in the grief or support that I, or anyone else in my family, could offer.
Even though I knew a rigorous interview process was beyond my bounds in that circumstance, I went and did my best. After I returned home, I contacted my employer and booked a flight, and left the next day. After I secured the job (yes, I did get it), I discovered that some who interviewed me noticed (what they interpreted as) a lack of enthusiasm - several commented to me that interviewing in that situation was something they thought couldn't be done, yet it was done - and well enough to secure the job.
So, here's the lesson I learned that day - if you want something enough and your will is indomitable, you will likely succeed - success is not guaranteed, mind, but very likely.
There was another lesson I learned that day - one that's probably more important
that I carry with me, especially every time I interview a candidate - on any given day we see only a part of a person, and like in jazz, the important bits might be those not heard, so make allowances for what you don't see (Robert's Rule #32).
Or, in the words of Bill (in Bill & Ted's Excellent Adventure), "be excellent to each other".
Notes:
- If you've never read this poem, do so. I recognize as a (more cynical) adult that it's a bit trite, but it's somewhat uplifting and motivational, and there are times we all need that.
- The article How the Power of Positive Thinking Won Scientific Credibility is an interesting read regarding the evolution of thought and research in this field, and has links to a number of those studies.
- These are two traits of a fantastic programmer from Signs that you're a good programmer.
- http://sijinjoseph.com/programmer-competency-matrix/
Sunday, March 10, 2013
What kind of engineer, indeed.
Several of my friends and colleagues have tweeted and otherwise commented about a post on the extremely knowledgeable Nick Zakas' blog.
I have a lot of respect for Mr. Zakas, and often enjoy his blog posts, learning something each time I visit, and this post was no exception. Unfortunately, there is also a point with which I don't agree...but it's not really Mr. Zakas' point. He says,
Still, Mr. Zakas is correct in that our reputation is important...but therein lies my problem, and it's demonstrated to a degree by those Peter Hinssen refers to in Will the real CIO please stand up - individuals who associate responses to the phrase 'IT departments' which are "wonderfully colorful comments such as 'arrogant', 'out of touch with reality', 'language of their own' and - increasingly often - 'hopelessly out of date'."
Are there engineers who are reasonably considered "arrogant" or "out of touch"? Certainly, and, I suppose if Mr. Zakas' post were geared toward those engineers alone, we might not have anything to discuss. Note, however, that Mr. Hinssen's post discusses the prevailing attitude. If we see "arrogance" and "hopelessly out of date" as the status quo, then I would posit that Mr. Zakas' advice to adjust our attitude addresses a symptom of the underlying problem without addressing any of the underlying issues.
In part, the prevailing attitude - that we are arrogant and out of touch - is our fault as software engineers. Whether we write software for the World Wide Web, smartphones, or desktops - we have, to some degree, failed to convey our value to the organization. Often we do speak a language of our own, and life would be much easier (from the perspective of those who see us as arrogant and out of touch) if we would just communicate more/better/the right way - if we would stop being so out of touch - if we would stop seeing ourselves as so valuable to the organization - after all, the contribution of an engineer is not that significant because "writing code is something that a lot of people do" (emphasis mine).
As a User Interface Engineer (or web developer, if you'd like), I often hear comments similar to this - comments about how someone's teenage relative can build a good web page. While there are, of course, prodigies, the amount of engineering that is required to create the best web page is significantly greater than the skill level held by general practitioners, as is the amount of engineering required to create the best software for other media. I would posit, therefore, that our challenge is not as much improving our soft skills (though every engineer I've met would benefit from such development), but rather conveying our value to the organization in a meaningful way. To that end, as a counterpoint to Mr. Zakas, I would commend a quote that Baskin-Robbins used to hang in their stores: "there is hardly anything in the world that someone can't make a little worse and sell a little cheaper - and people who consider price alone are this man's lawful prey."1
There are a number of issues that might be discussed when an organization perpetuates a culture similar to Mr. Zakas' comment above (that people who code are a commodity) or similar to those Mr. Hinssen references; however, one of the most significant is that organizations which learn to accept "close enough" when it's less expensive incur technical debt that becomes deadly. Further, the effect such an attitude has on morale within the IT department can be equally as deadly as mounting technical debt.
There is, in my estimation, another side to this story. In the face of significant potential issues, such as creating code that's "good enough" under one estimation and not another, mounting technical debt without having resources to address it, and demotivating personnel, there is also the thought that perhaps the perception of engineers as weak in soft skills, arrogant, and out of touch, is mistaken. Perhaps, just perhaps, those engineers are instead are significantly different than other employees.
Perhaps these engineers are not arrogant and out of touch. Perhaps there are weaknesses related to their soft skills, but if we, instead of operating from the assumption that what these engineers do is something that a lot of people can do, operate from the assumption that what these engineers do is something that few people can do, and that they are therefore in a different realm than others, might we see their "arrogance" as an indication they have a different understanding of their capabilities and the situation? Might the perception that they are "out of touch" be due to the manner in which they, in their different world, relate to those outside of their area of expertise.
Let us consider then, the possibility that their "arrogance" and being "out of touch" are, at worst, simple weaknesses in their soft skills. What is the best advice? Certainly Mr. Zakas' advice is good, and traditional - work on your weaknesses. However, is that really the best way in which these engineers can contribute? In this consideration, I would offer the following advice that Dr. Donald Clifton gave his son: "your weaknesses will never develop while your strengths will develop infinitely."2
Let me be clear - the best advice the creator of the Clifton StrengthsFinder, Gallup's own online psychological assessment, could offer his son, was to build his life and work around his strengths rather than try to fix his weaknesses. For Dr. Clifton's son, and many engineers, Mr. Zakas' words, and in fact the words of those who brand us as "arrogant" and "out of touch" would have them "fix their weaknesses".
In this, I would posit that rather than engineers spending time fixing their weaknesses, that they spend time using and developing their strengths, and that management (at all levels) spend time seeing and celebrating diversity and the value it brings. I understand this is unconventional wisdom, but perhaps, just perhaps, this is a new age - an age in which each of us can contribute to our fullest.
What kind of engineer do I want to be? One that develops my strengths infinitely.
I have a lot of respect for Mr. Zakas, and often enjoy his blog posts, learning something each time I visit, and this post was no exception. Unfortunately, there is also a point with which I don't agree...but it's not really Mr. Zakas' point. He says,
If you stop and think about it, writing code is something that a lot of people do. You can hire someone cheaply out of college to write code and it may not be as good as an experienced software engineer, but if it’s close enough, that’s usually all you need. So if your programming acumen is the only thing that you focus on, you aren't improving your position in the company. What matters far more are the soft skills that you have along the way. Do people enjoy working with you? Do you add something over and above your coding skill?First, to Mr. Zakas' point, there are a lot of people who can code...but there is a potentially significant difference between "close enough" and "correct". With "close enough" your revenue most likely will not be zero, but it will also likely not be as much as it would with "correct"...and in some situations, "close enough" may be nowhere near close enough. If we're talking about a web page that responds in 8 seconds instead of 4 or 6, that may be one thing (though you might want to see my earlier post about speed in websites, Faster, faster, faster) but if we're talking about real-time or life-critical software, is "good enough" really good enough.
Still, Mr. Zakas is correct in that our reputation is important...but therein lies my problem, and it's demonstrated to a degree by those Peter Hinssen refers to in Will the real CIO please stand up - individuals who associate responses to the phrase 'IT departments' which are "wonderfully colorful comments such as 'arrogant', 'out of touch with reality', 'language of their own' and - increasingly often - 'hopelessly out of date'."
Are there engineers who are reasonably considered "arrogant" or "out of touch"? Certainly, and, I suppose if Mr. Zakas' post were geared toward those engineers alone, we might not have anything to discuss. Note, however, that Mr. Hinssen's post discusses the prevailing attitude. If we see "arrogance" and "hopelessly out of date" as the status quo, then I would posit that Mr. Zakas' advice to adjust our attitude addresses a symptom of the underlying problem without addressing any of the underlying issues.
In part, the prevailing attitude - that we are arrogant and out of touch - is our fault as software engineers. Whether we write software for the World Wide Web, smartphones, or desktops - we have, to some degree, failed to convey our value to the organization. Often we do speak a language of our own, and life would be much easier (from the perspective of those who see us as arrogant and out of touch) if we would just communicate more/better/the right way - if we would stop being so out of touch - if we would stop seeing ourselves as so valuable to the organization - after all, the contribution of an engineer is not that significant because "writing code is something that a lot of people do" (emphasis mine).
As a User Interface Engineer (or web developer, if you'd like), I often hear comments similar to this - comments about how someone's teenage relative can build a good web page. While there are, of course, prodigies, the amount of engineering that is required to create the best web page is significantly greater than the skill level held by general practitioners, as is the amount of engineering required to create the best software for other media. I would posit, therefore, that our challenge is not as much improving our soft skills (though every engineer I've met would benefit from such development), but rather conveying our value to the organization in a meaningful way. To that end, as a counterpoint to Mr. Zakas, I would commend a quote that Baskin-Robbins used to hang in their stores: "there is hardly anything in the world that someone can't make a little worse and sell a little cheaper - and people who consider price alone are this man's lawful prey."1
There are a number of issues that might be discussed when an organization perpetuates a culture similar to Mr. Zakas' comment above (that people who code are a commodity) or similar to those Mr. Hinssen references; however, one of the most significant is that organizations which learn to accept "close enough" when it's less expensive incur technical debt that becomes deadly. Further, the effect such an attitude has on morale within the IT department can be equally as deadly as mounting technical debt.
There is, in my estimation, another side to this story. In the face of significant potential issues, such as creating code that's "good enough" under one estimation and not another, mounting technical debt without having resources to address it, and demotivating personnel, there is also the thought that perhaps the perception of engineers as weak in soft skills, arrogant, and out of touch, is mistaken. Perhaps, just perhaps, those engineers are instead are significantly different than other employees.
Perhaps these engineers are not arrogant and out of touch. Perhaps there are weaknesses related to their soft skills, but if we, instead of operating from the assumption that what these engineers do is something that a lot of people can do, operate from the assumption that what these engineers do is something that few people can do, and that they are therefore in a different realm than others, might we see their "arrogance" as an indication they have a different understanding of their capabilities and the situation? Might the perception that they are "out of touch" be due to the manner in which they, in their different world, relate to those outside of their area of expertise.
Let us consider then, the possibility that their "arrogance" and being "out of touch" are, at worst, simple weaknesses in their soft skills. What is the best advice? Certainly Mr. Zakas' advice is good, and traditional - work on your weaknesses. However, is that really the best way in which these engineers can contribute? In this consideration, I would offer the following advice that Dr. Donald Clifton gave his son: "your weaknesses will never develop while your strengths will develop infinitely."2
Let me be clear - the best advice the creator of the Clifton StrengthsFinder, Gallup's own online psychological assessment, could offer his son, was to build his life and work around his strengths rather than try to fix his weaknesses. For Dr. Clifton's son, and many engineers, Mr. Zakas' words, and in fact the words of those who brand us as "arrogant" and "out of touch" would have them "fix their weaknesses".
In this, I would posit that rather than engineers spending time fixing their weaknesses, that they spend time using and developing their strengths, and that management (at all levels) spend time seeing and celebrating diversity and the value it brings. I understand this is unconventional wisdom, but perhaps, just perhaps, this is a new age - an age in which each of us can contribute to our fullest.
What kind of engineer do I want to be? One that develops my strengths infinitely.
- This quote is attributed to John Ruskin, though there is some debate about whether or not that attribution is valid.
- Reported in a post by his son.
Monday, September 17, 2012
Following the eight-fold path
Following your passion is probably not the worst advice ever, but it's easily not the best. For most of us, it's simply impossible. Oh, we all dream of being a rock star/athlete/astronaut when we're kids, but seldom do we even find the energy or opportunity to fulfill one passion. So, what do we do? How do we find fulfillment and happiness while at the same time settling for something that pays the bills?
1. Find your one thing. What is it that you want? Deciding to follow your dreams can be a terrifying, thrilling, and dangerous activity - but then again, deciding to abandon your dreams to the dustbin is too. It's helpful to keep in mind that your 'one thing' is not a specific plan, like to be a rock star/athlete/astronaut, but is a more general idea, like living simply, having power and influence, or making a difference.
2. Be flexible. There is seldom 'one perfect job' - but there are often a few not-quite perfect jobs, several workable jobs, and countless run-away-as-fast-as-you-can jobs. Flexibility frees you from the need to find 'the job', helps prevent you from chronic (and frequent) job-hopping, and it also lets you select jobs that encourage you to focus on you (more on this next). Since job-hopping can be an effective career killer, this is pretty important, but this last bit is really the more important of the advantages, because it gives most any job the potential to be one in which you can find and grow your passion.
3. Focus on you. Simple, right? A few really interesting studies have shown that competence and autonomy yield higher rates of job satisfaction than other factors. (Check out Drive: The surprising truth about what motivates us for more information.) To keep it simple, ask yourself "how do I get better?" By answering this question, you'll increase competency (keep in mind Robert's Rule #1) and as a result, you'll most likely increase your autonomy. Just keep focusing on you.
4. Look to the stars. This is the companion to focus on you. This will answer much of the question about how you get better. The stars who do the same work you do will show you the skills you need to hone to become better. Often, they will enact those skills without even noticing what they're doing, so asking them "how do I get better" will most likely not yield the results you expect (see Robert's Rule #3). Instead, observe them - note what situation they address and how they address it, ask them to mentor you, ask them questions about their skill that make them think, but don't ask them "what do I need to know" or "how do I get better" - those are your questions to answer.
5. Become visible. There is a theory that if you're invisible, you're less likely to become redundant, "riffed", or otherwise "terminated". Perhaps there was a time that line of reasoning was true; however, job security of that sort is truly an anachronism. While it may be that the squeaky part gets the grease (or gets replaced), very few employers are a pure meritocracy, and even in a meritocracy there is the concept of 'winking in the dark' - so increase your visibility.
6. Understand what you value. As you focus on you and become more visible, those you work for will begin to see your value. As the organization sees your value, they will (most likely) push you toward those roles and activities which they value. It stands to reason - after all, who wouldn't want their best employees on their most important projects, right? Keep in mind, however, that what an organization values may not be the same thing that you value, and following what someone else values may take you off your path.
7. Be relentless. Passion is called passion for a reason. If the potential you see does not drive you, if it is not a goal you can taste without which life would be a miserable, empty shell, settle. The work is too hard and your ambition is not enough. On the other hand, if there is a single thing you want more than anything else, then in the words of Yoda, "do or do not, there is no try".
8. Leverage your value. As you follow the path, it can lead you to a point where you can leverage your value. Here's the payoff for all your hard work. Here's where you get to follow your passion. You may not the rock star/athlete/astronaut who gets to sing the national anthem before the championship game where you score the winning point before the manned mission to Mars, but maybe, just maybe, you'll be able to follow your passion, and like friends of mine who have become the surfer-web developer, the hiker-photographer, and the UI engineer-disc golfer.
1. Find your one thing. What is it that you want? Deciding to follow your dreams can be a terrifying, thrilling, and dangerous activity - but then again, deciding to abandon your dreams to the dustbin is too. It's helpful to keep in mind that your 'one thing' is not a specific plan, like to be a rock star/athlete/astronaut, but is a more general idea, like living simply, having power and influence, or making a difference.
2. Be flexible. There is seldom 'one perfect job' - but there are often a few not-quite perfect jobs, several workable jobs, and countless run-away-as-fast-as-you-can jobs. Flexibility frees you from the need to find 'the job', helps prevent you from chronic (and frequent) job-hopping, and it also lets you select jobs that encourage you to focus on you (more on this next). Since job-hopping can be an effective career killer, this is pretty important, but this last bit is really the more important of the advantages, because it gives most any job the potential to be one in which you can find and grow your passion.
3. Focus on you. Simple, right? A few really interesting studies have shown that competence and autonomy yield higher rates of job satisfaction than other factors. (Check out Drive: The surprising truth about what motivates us for more information.) To keep it simple, ask yourself "how do I get better?" By answering this question, you'll increase competency (keep in mind Robert's Rule #1) and as a result, you'll most likely increase your autonomy. Just keep focusing on you.
4. Look to the stars. This is the companion to focus on you. This will answer much of the question about how you get better. The stars who do the same work you do will show you the skills you need to hone to become better. Often, they will enact those skills without even noticing what they're doing, so asking them "how do I get better" will most likely not yield the results you expect (see Robert's Rule #3). Instead, observe them - note what situation they address and how they address it, ask them to mentor you, ask them questions about their skill that make them think, but don't ask them "what do I need to know" or "how do I get better" - those are your questions to answer.
5. Become visible. There is a theory that if you're invisible, you're less likely to become redundant, "riffed", or otherwise "terminated". Perhaps there was a time that line of reasoning was true; however, job security of that sort is truly an anachronism. While it may be that the squeaky part gets the grease (or gets replaced), very few employers are a pure meritocracy, and even in a meritocracy there is the concept of 'winking in the dark' - so increase your visibility.
6. Understand what you value. As you focus on you and become more visible, those you work for will begin to see your value. As the organization sees your value, they will (most likely) push you toward those roles and activities which they value. It stands to reason - after all, who wouldn't want their best employees on their most important projects, right? Keep in mind, however, that what an organization values may not be the same thing that you value, and following what someone else values may take you off your path.
7. Be relentless. Passion is called passion for a reason. If the potential you see does not drive you, if it is not a goal you can taste without which life would be a miserable, empty shell, settle. The work is too hard and your ambition is not enough. On the other hand, if there is a single thing you want more than anything else, then in the words of Yoda, "do or do not, there is no try".
8. Leverage your value. As you follow the path, it can lead you to a point where you can leverage your value. Here's the payoff for all your hard work. Here's where you get to follow your passion. You may not the rock star/athlete/astronaut who gets to sing the national anthem before the championship game where you score the winning point before the manned mission to Mars, but maybe, just maybe, you'll be able to follow your passion, and like friends of mine who have become the surfer-web developer, the hiker-photographer, and the UI engineer-disc golfer.
Tuesday, August 21, 2012
Constraints and success become inversely proportional when creative energy is applied. (Robert's Rule #27)
It may be counter-intuitive, but perhaps it's time we saw constraints as a necessary condition for greatness. Take, for example, what Igor Stravinsky said: "the more constraints one imposes, the more one frees one's self...and the arbitrariness of the constraint serves only to obtain precision of execution" (Harvard lectures, 1939-1940). This sentiment is echoed in another (modern) musician, Jake White. (If you haven't yet seen it, take a minute to watch a clip, from Under Great White Northern Lights, that describes his take on this idea - seriously, do it now.)
"That's all fine for musicians", you say, "but what does that have to do with me?"
Often those of us in the tech industry think "if I had ..." and then proceed to fill in that blank with something that will lift a constraint. Over the years we have filled that blank spot with "more RAM" or "a faster drive" or "a faster bus" and so on; meanwhile, NASA's space shuttle is famous in part because of the memory constraint imposed by the technology of the time.
So, how does this relate to you, today? First, and foremost, we can easily point to the spin-off products that we use every day that were developed from NASA patents - products that were initially developed to deal with special constraints around space travel. One of those products, satellite communication, is especially applicable to our (DARPA created) web environment.
Since we're already on the communications track, perhaps we should think about mobile technologies as our next opportunity for greatness. There are several constraints, especially related to web apps, in the mobile space. The limitations of memory, processor speed, bandwidth, and battery life are all constraints that give us the opportunity to create greatness.
Look at it from this perspective - it's very likely that a great mobile web app will be a great desktop web app, because the primary influence determining whether or not people visit/use/return to your site or app (after content/functionality) is speed, and if, with all the constraints in the mobile space, your web app is fast, it should be blisteringly fast in a desktop experience.
I am certain that there are other ways in which constraints can help you achieve greatness. Look for those opportunities to, in the words of one industry leader, "make more awesome".
"That's all fine for musicians", you say, "but what does that have to do with me?"
Often those of us in the tech industry think "if I had ..." and then proceed to fill in that blank with something that will lift a constraint. Over the years we have filled that blank spot with "more RAM" or "a faster drive" or "a faster bus" and so on; meanwhile, NASA's space shuttle is famous in part because of the memory constraint imposed by the technology of the time.
So, how does this relate to you, today? First, and foremost, we can easily point to the spin-off products that we use every day that were developed from NASA patents - products that were initially developed to deal with special constraints around space travel. One of those products, satellite communication, is especially applicable to our (DARPA created) web environment.
Since we're already on the communications track, perhaps we should think about mobile technologies as our next opportunity for greatness. There are several constraints, especially related to web apps, in the mobile space. The limitations of memory, processor speed, bandwidth, and battery life are all constraints that give us the opportunity to create greatness.
Look at it from this perspective - it's very likely that a great mobile web app will be a great desktop web app, because the primary influence determining whether or not people visit/use/return to your site or app (after content/functionality) is speed, and if, with all the constraints in the mobile space, your web app is fast, it should be blisteringly fast in a desktop experience.
I am certain that there are other ways in which constraints can help you achieve greatness. Look for those opportunities to, in the words of one industry leader, "make more awesome".
Thursday, August 16, 2012
A lot in life is like a Wookie (Robert's Rule #25)
A lot in life is like a Wookie: hard to understand, very hairy, and can rip off your arms and beat you to death with them. (Robert's Rule #25)
Summertime for me is generally a very busy time. It's during this time that into the work/life mix are thrown not only the daily work/life challenges like how to make sure the laundry gets done and the bathrooms get cleaned but also additional things like children being on summer break and the resulting coordination of child care and the planning, scheduling, and taking of a summer holiday (not to mention trips to see family et cetera that really are 'holidays'), and when you travel with infants or toddlers such trips are whole projects in themselves.
Of course that's just the time that work activities seriously ramp up before we head into a release moratorium for the holidays as projects that were originally estimated to take 30 developer days are crammed into 5, and, the reasoning goes, since each 30 day project is crammed into 5 days, we can do 6 such projects. Thus, as the pressure from work mounts and you attempt to maintain work/life balance, you will undoubtedly come into conflict with those above you in the corporate chain and you will likely lose.
"That's life", they say, or "at the end of the day, that's what you have to deal with" as if a cliché will somehow make it more palatable or at least easier to endure. Here's the difficulty: as engineers and scientists, we expect, at least subconsciously, that life is somewhat orderly and something of a meritocracy where people compete like ideas and the best advance according to their abilities, just as ideas advance according to how well they are proven using scientific methods. To further add insult, we're taught as children in America that this is, in some degree, the reality as we celebrate those who work hard (either at sport or academics).
While there are those who recognize the failings of our educational system (in that it reinforces idea that our democratic republic is on some level a meritocracy), there are those who refuse to believe that we can be what we want to be and do (for the most part) what we want to do. There are those who recognize that even if we sincerely want to rescue the princess and make a daring escape while being pursued by the dark lord, we cannot - not even figuratively. Thus, the honest answer, as you've no doubt learned by now, is that the idea that our society or even our employer is a meritocracy is not even close to true. Those above you most likely are not there because they deserve it more than you, they are there because they played it more than you.
So, in your career, in this little game of whispers and thrones, learn who the Wookies are and let the Wookie win (First Corollary to Robert's Rule #25), because while no one worries about upsetting droids (scientists and engineers), in the words of the immortal Han Solo, "that's 'cause droids don't pull people's arms out of their sockets when they lose".
Summertime for me is generally a very busy time. It's during this time that into the work/life mix are thrown not only the daily work/life challenges like how to make sure the laundry gets done and the bathrooms get cleaned but also additional things like children being on summer break and the resulting coordination of child care and the planning, scheduling, and taking of a summer holiday (not to mention trips to see family et cetera that really are 'holidays'), and when you travel with infants or toddlers such trips are whole projects in themselves.
Of course that's just the time that work activities seriously ramp up before we head into a release moratorium for the holidays as projects that were originally estimated to take 30 developer days are crammed into 5, and, the reasoning goes, since each 30 day project is crammed into 5 days, we can do 6 such projects. Thus, as the pressure from work mounts and you attempt to maintain work/life balance, you will undoubtedly come into conflict with those above you in the corporate chain and you will likely lose.
"That's life", they say, or "at the end of the day, that's what you have to deal with" as if a cliché will somehow make it more palatable or at least easier to endure. Here's the difficulty: as engineers and scientists, we expect, at least subconsciously, that life is somewhat orderly and something of a meritocracy where people compete like ideas and the best advance according to their abilities, just as ideas advance according to how well they are proven using scientific methods. To further add insult, we're taught as children in America that this is, in some degree, the reality as we celebrate those who work hard (either at sport or academics).
While there are those who recognize the failings of our educational system (in that it reinforces idea that our democratic republic is on some level a meritocracy), there are those who refuse to believe that we can be what we want to be and do (for the most part) what we want to do. There are those who recognize that even if we sincerely want to rescue the princess and make a daring escape while being pursued by the dark lord, we cannot - not even figuratively. Thus, the honest answer, as you've no doubt learned by now, is that the idea that our society or even our employer is a meritocracy is not even close to true. Those above you most likely are not there because they deserve it more than you, they are there because they played it more than you.
So, in your career, in this little game of whispers and thrones, learn who the Wookies are and let the Wookie win (First Corollary to Robert's Rule #25), because while no one worries about upsetting droids (scientists and engineers), in the words of the immortal Han Solo, "that's 'cause droids don't pull people's arms out of their sockets when they lose".
Wednesday, March 7, 2012
Silence and neutrality enable oppression (Robert's Rule #11)
[Tweeted 2011-05-09]
Today's post isn't directly related to work experience...at least not for most people.
I grew up in the middle of blue-collar union country at a time when unions were strong. Members of my family would have never considered crossing a picket line. Why? In part because it feels good to know that someone has your back. Of course there's always the collective bargaining thing too...after all, it's usually difficult, not impossible but difficult, to oppress a large group of committed, active people.
History is full of examples of people who have stood up to those who oppress them. One of the most famous in American popular culture is the Molly Maguires (if you haven't watched the Sean Connery/Richard Harris movie you really should). I understand that the real history of the Mollies is a bit clouded, and also that history is written by those who win. However, instances of the oppressed standing against those who oppress them provides a valuable lesson that applies to all of life, both working and non-working life.
Because this lesson applies to both work life and non-work life, it's become one of the rules I strive to remember every day. Every day, silence and neutrality enable oppression (Robert's Rule #11), and every day we must combat it, because oppression brings everyone down to the lowest common denominator.
Today's post isn't directly related to work experience...at least not for most people.
I grew up in the middle of blue-collar union country at a time when unions were strong. Members of my family would have never considered crossing a picket line. Why? In part because it feels good to know that someone has your back. Of course there's always the collective bargaining thing too...after all, it's usually difficult, not impossible but difficult, to oppress a large group of committed, active people.
History is full of examples of people who have stood up to those who oppress them. One of the most famous in American popular culture is the Molly Maguires (if you haven't watched the Sean Connery/Richard Harris movie you really should). I understand that the real history of the Mollies is a bit clouded, and also that history is written by those who win. However, instances of the oppressed standing against those who oppress them provides a valuable lesson that applies to all of life, both working and non-working life.
Because this lesson applies to both work life and non-work life, it's become one of the rules I strive to remember every day. Every day, silence and neutrality enable oppression (Robert's Rule #11), and every day we must combat it, because oppression brings everyone down to the lowest common denominator.
Wednesday, February 29, 2012
Vision without action is a dream, action without vision is a nightmare (Robert's Rule #5)
[Tweeted 2011-04-29]
We'll start off a short post with the rule today. A vision without action is just a dream; action without a vision is a nightmare (Robert's Rule #5).
One of the things that I have consistently argued against in every organization I've worked for is what I call "Getting Shit Done Syndrome", or GSD. (Feel free to think of it, or call it, "Getting Stuff Done Syndrome" if you'd like.)
There's a simple argument behind this that goes something like this...
We'll start off a short post with the rule today. A vision without action is just a dream; action without a vision is a nightmare (Robert's Rule #5).
One of the things that I have consistently argued against in every organization I've worked for is what I call "Getting Shit Done Syndrome", or GSD. (Feel free to think of it, or call it, "Getting Stuff Done Syndrome" if you'd like.)
There's a simple argument behind this that goes something like this...
- If you're in "information technology" then you're in a knowledge economy
- If you're in a knowledge economy then your product is knowledge and information
- If the product is knowledge and information, that requires thinking more than doing
- Therefore, you're paid to think, and then do, not just do
Subscribe to:
Posts (Atom)