http://en.wikipedia.org/wiki/Parkinson%27s_law_of_triviality
[Parkinson] dramatizes this "law of triviality" with the example of a committee's
deliberations on an atomic reactor, contrasting it to deliberations on a
bicycle shed. As he put it: "The time spent on any item of the agenda
will be in inverse proportion to the sum [of money] involved." A reactor
is used because it is so vastly expensive and complicated that an
average person cannot understand it, so one assumes that those that work
on it understand it. On the other hand, everyone can visualize a cheap,
simple bicycle shed, so planning one can result in endless discussions
because everyone involved wants to add a touch and show personal
contribution.
Thursday, April 24, 2014
Tuesday, April 1, 2014
Don't End The Week With Nothing
Source
Don't end the week with nothing. Prefer to work on things you can show. Prefer to work where people can see you. Prefer to work on things you can own.
Why? Because when your work is in public, you can show it to people. That's often the best way to demonstrate that you're capable of doing work like it.
Telling people you can do great work is easy: any idiot can do it, and many idiots do. Having people tell people you do great work is an improvement. It suffers because measuring individual productivity on a team effort is famously difficult, and people often have no particular reason to trust the representations of the people doing the endorsements.
(Quick: if you had credible evidence that a mid-level engineering manager at a company you've never heard of in Nagoya thought I was a really effective employee, would that make you markedly more likely to hire me? Right, without the context of knowing him, that recommendation is almost useless.)
Work you can show off, though, is prima facie evidence of your skills. After your portfolio includes it, your ability to sell your skills gets markedly better. Given that most people's net worth is almost 100% invested in their personal capital (i.e. if you're a young engineer the net present value of all future salary absolutely swamps everything in your bank account), this is a fairly radical improvement in your present situation for not a very radical change in how you go about things.
Thus my first piece of advice: if you have the choice between multiple jobs, all else being equal, pick the one where you are able to show what you've worked on. This could mean working on a language stack where work biproducts are customarily OSSed (e.g. Rails) versus one which isn't (e.g. C#). This could mean working on particular projects within the organization which like external visibility (e.g. Android) rather than projects which don't (e.g. AdWords plumbing -- presumably Google will pay you a lot of money to do that, but consider it compensation for not being able to talk about it). This could mean working in industries which default to being open rather than those which default to being closed.
OSS isn't nearly the only way to be able to show what you've worked on. In the creative industries, where the end product is customer-visible, people keep very close eye on whose name ends up in the credits. Academics spend lots of time worrying about citation counts and directed graphs.
More prosaically, establish an expectation early that you're simply going to talk about what you're doing. I think at Fog Creek / Stack Exchange they call this "producing artifacts" -- conference presentations, blog posts, OSSed software, and the like, centered around the work. Even at very open companies there exists lots of secret sauce, but most of the valuable work of the company is not particularly sensitive, and much of it has widely generalizable lessons. Write about those lessons as you learn them. If at all possible, publish what you write. Even if it is published to an audience of no one, you will be able to point people back to it later.
Some of my most effective writing in terms of career growth was back in 2006 through 2008, when I was struggling through not understanding anything I was doing, and where I -- quite literally -- had less readers than my younger brother's blog on writing superhero novels. Why was toiling in Internet-obscurity still valuable? Because I was able to point to particular experiments that I started in e.g. 2008, and then point to the followups in 2009 and 2010, which showed those experiments were really successful. The failures and false starts aren't extremely interesting to most people, but having some successes under your belt credibly demonstrates that you're capable of either reproducing them in the future or experimenting your way to new successes in your new environment.
If you cannot build things you can show at work, you should build things you can show outside of work. Companies in our industry are gradually becoming more reasonable about IP assignment clauses -- there's less of the "we own everything you think of at any point in your employment" nonsense these days. Even at my very straight-laced Japanese megacorp, they were willing to write an exception into the employment contract for a) OSS work that I did outside of company hours and b) Bingo Card Creator. I offered them this in exchange: "If you let me continue working on these, I'm going to learn lots of skills which I can put to the use of the company. Normally you invest lots of money sending engineers to conferences and professional training. This is even better for you: I'll learn more with no operating expenditure and no decrease in billing efficiency." That's an offer you can make to substantially any employer.
I prefer being upfront with people rather than doing the "It is easier to ask for forgiveness than ask for permission" route a lot of folks suggest. Sure, you can just roll the dice and pretend your employer is unlikely to notice your side project. Unfortunately, the odds of them noticing your side project go up sharply if the side project is ever successful, and then your lack of forthrightness about it give you unbounded liability extending far into the future. Just ask. The worst they can say is "No."
You might consider asking in the context of a more general compensation discussion than just "Hey boss, can I work on OSS?" That way, if they say "No side projects", you'll say "OK, in lieu of the side projects, I'll need more money." It's easier to be sticklers for the stock agreements when there's absolutely no cost to the company to insist on the usual boilerplate, but minor concessions on the boilerplate are often easier than concessions on things which actually appear on the company's books.
Vanishingly few people in our industry have the profile of rock stars. They can still have substantial profile among the audience of "people professionally relevant to them." That might be as tightly scoped as "people with hiring authority for front-end developers in my metro area", which might be a set of, what, a couple of dozen folks?
How do you develop that profile? I'd suggest, all things being equal, working at places and on projects which have above-average visibility.
Many engineering projects are deep in the bowels of late-stage industrial capitalism. Then there's writing the Facebook mobile app. I have no clue what engineers actually worked on the Facebook mobile app, but I'm betting that if I were a Silicon Valley hiring manager in iOS or Android development I'd a) know their names and b) have them at or near the top of my personal poach list.
Side note: A poach list is my informal name for "The people who, if I had infinite money and they had no other commitments, I'd hire to work on a particular project." I have several mental poach lists -- the best people I know on Rails programming, on A/B testing, on writing email, etc. When people ask me for advice on what to do about those topics, I often say "You know who is really great at this? <%= poach_list.pop() %> You cannot possibly waste your time taking them out to coffee." Brokering coffee dates cannot possibly work out poorly for the people who go to them. (My interest? Helping people out is fun, and -- funny enough -- people often seem to remember when you get them a job or a key employee.)
You don't have to optimize for "sexy" projects. You know, sexy projects: I don't know how to describe them but I know it when I see it. Most engineering work isn't intrinsically sexy. I would, however, optimize for impact and visibility.
Don't try to make a career out of optimizing the SQL queries to display a preference page on a line of business app at a company that no one has ever heard of. That is not the straightforward path to having other people learn you are capable of doing meaningful work. Instead, work at higher profile companies/organizations -- AmaGooFaceSoft, startups or small companies with anomalously high profile (locally, nationally, whatever), or in positions where by your nature you're exposed to lots of people.
I have a few friends who are developer evangelists, which is a funny job created at API companies where your brief is basically "Go demo our product to a group of developers. Now, do that again, every day, for the next several years." Sentiment on the actual job is decidedly mixed. Keith Casey gives a pretty good account here.
(Side note: I'd be remiss if I didn't note that Keith just got his work shared with 10,000 people because Keith did the work and made it easily shareable, and also because Keith knew me, through his previous job at Twilio. I'm a customer there. Everyone can play six degrees to Kevin Bacon in our industry, but actually putting in the work makes it much more likely that other people will play six degrees on your behalf.)
Anyhow, developer evangelism. An observation: every developer evangelist I know goes into a much better job right after they quit being an evangelist. This is not true of other engineering jobs with checkered reputations, like e.g. The Build Guy. Why do developer evangelists get upgrades but The Build Guy(s) not? My bet is because evangelists literally spent years meeting thousands of people and showing them "Hey, I'm going to live code in front of you while also making my employers fat stacks of money. You run a company and could use both engineers and money. You should probably remember my name, you know, just in case." The Build Guy(s) suffers in underappreciated solitude, except when maven bottoms out or RubyGems goes down and it is somehow The Build Guy's fault.
If you cannot gain exposure at your day job, try to get some exposure outside of it. Network actively. Go to local meetups of technical folks, but also go to the (often separate) events where the business side of your industry talks shops. Speak at conferences. Take the things you have created (see above) and actively show them to people to solicit feedback. You don't have to have an audience of thousands for an audience to be worthwhile -- for landing a new job, having an audience of one hiring manager is a darn sight better than having no audience at all. Blog and collect an email list. It's old and hackneyed advice but it freaking works, particularly when you can compound improvements over years.
Amy Hoy has a great metaphor for this -- "stacking the bricks". Seen from the outside, you might say "That person with an impressive career? It's like they have a sheer wall made out of awesome. I could not hope to ever have a wall like that." Seen from the inside, it looks like one day of delivering a single good conference talk, a few weeks spent writing an OSS library, another day writing the definitive blog post on getting multiple Ruby versions playing together, a few months shipping a product used by many people, an hour recording a podcast. Brick by brick, stone by stone, the wall gets higher.
I'm not generally a fan of the Silicon Valley model, but I'll say this in their defense: widespread employee ownership of the enterprise is one of the single best innovations in the history of capitalism. Non-managerial employees own plus or minus 20% of Twitter, Facebook, etc. They own plus or minus "rounding error" of almost all other publicly traded companies, with very rare exceptions.
I think that's an improvement on the "no shared stake" model of employment, but I don't think it is the last word in it. For one thing, it overconcentrates employee wealth with one company. As an employee, your short-term cash flow generation is tied to the continued health of your employer. If a large portion of your net worth is tied to their stock, you're magnifying the impact of a secular or firm-specific shock should one occur. (This is, relatedly, why I'm not a fan of buying the stock of an employer in a company-sponsored DRIP or IRA. You've got plenty of exposure to their future already without buying more of it with your own money.)
The explicit understanding among professional investors is that 90% of all shares of early-stage startups are worthless. It seems more than a little self-serving for professional investors to tell employees "While our general partners would laugh us out of the room if we suggested betting the entire fund on a single investment, even if we thought it was a sure thing, you are going the be the lucky ones and you should certainly have 99% of your net worth tied up in the illiquid shares of one particular company."
So if not hard assets directly awarded by employers, then what?
Well, obviously, sock away money like every financial advisor ever will tell you to. (Here's everything you need to know: buy broad market index funds in your tax-advantaged accounts. If that sounds too complicated, get a Vanguard target retirement fund where the number most closely matches the approximate time you'll retire.)
There's another, harder option with higher returns: the side project. You can "buy" them with sweat equity, one bead at a time. They provide you with many benefits, including the direct financial benefits (if you sell things to people for money, you get money, which can be useful), the compounded benefits of investing the financial benefits (my first $2,000 from Bingo Card Creator turned into Chipotle stock at an average price of $50 a share -- don't buy stocks, buy index funds, but that decision worked out pretty decently for me).
There's also intangible -- but no less real -- benefits to having an artifact which is yours. This is one reason why, while I love OSS, I would suggest people not immediately throw their OSS on Github. That makes it very easy for developers to consume your code, but it does not make it easy for you to show the impact of that code to other people, particularly to non-technical stakeholders. To the extent that people's lives are meaningfully improved by your code, the credit (and observable citations) often goes to Github rather than going to you. If you're going to spend weeks or months of time writing meaningful OSS libraries, make a stand-alone web presence for them.
Example: my A/Bingo was once probably the best option for Rails A/B testing, by dint of being the only serious option for Rails A/B testing. It is a little old in the tooth now, but being The A/B Testing Guy got me several consulting gigs. The effort to make e.g. documentation, a quickstart guide, a logo, and a branded web presence beats the heck out of having a junior engineer at a potential client just git clone my Github URL and never have my work exposed to a decisionmaker there at all.
(Much love for Github, guys. Great company, great product, great impact on the industry. I only suggest not using them for a portion of one's projects, for a fairly simple reason: I don't work for them, I work for me. If I don't work for myself, it is unlikely anyone else will.)
If you want to learn more about the actual mechanics of building a side project, my blog covers it in a lot of detail. For a much briefer overview of it, I really recommend Jason Cohen's presentation at Microconf 2013. His formula is "Predictable acquisition of recurring revenue with an annual pre-pay option with a product which solves a demonstrable, enduring pain point for a business." That idea is developed at the above link for an hour, and a lot of the advice given is specific and wildly actionable. I highly recommend it.
Just don't end the week with nothing.
If there's ever anything I can do to help you out, whether you're the CEO of a multi-million dollar a year SaaS company or just getting ready to stack your first brick, drop me a line. Nothing makes me happier businesswise than being able to help people, particularly those who are getting started.
Don't end the week with nothing. Prefer to work on things you can show. Prefer to work where people can see you. Prefer to work on things you can own.
Prefer Working On Things You Can Show
One of the reasons developers have embraced OSS so much is because it gives you portable capital between companies: if your work is sitting on Github, even if you leave one job, you can take it with you to your next job. Previously this happened pretty widely but generally under the table. (Is there any programmer who does not have a snippets folder or their own private library for scratching that one particular itch?) One of the great wrinkles that OSS throws into this is that OSS is public by default, and that's game changing.Why? Because when your work is in public, you can show it to people. That's often the best way to demonstrate that you're capable of doing work like it.
Telling people you can do great work is easy: any idiot can do it, and many idiots do. Having people tell people you do great work is an improvement. It suffers because measuring individual productivity on a team effort is famously difficult, and people often have no particular reason to trust the representations of the people doing the endorsements.
(Quick: if you had credible evidence that a mid-level engineering manager at a company you've never heard of in Nagoya thought I was a really effective employee, would that make you markedly more likely to hire me? Right, without the context of knowing him, that recommendation is almost useless.)
Work you can show off, though, is prima facie evidence of your skills. After your portfolio includes it, your ability to sell your skills gets markedly better. Given that most people's net worth is almost 100% invested in their personal capital (i.e. if you're a young engineer the net present value of all future salary absolutely swamps everything in your bank account), this is a fairly radical improvement in your present situation for not a very radical change in how you go about things.
Thus my first piece of advice: if you have the choice between multiple jobs, all else being equal, pick the one where you are able to show what you've worked on. This could mean working on a language stack where work biproducts are customarily OSSed (e.g. Rails) versus one which isn't (e.g. C#). This could mean working on particular projects within the organization which like external visibility (e.g. Android) rather than projects which don't (e.g. AdWords plumbing -- presumably Google will pay you a lot of money to do that, but consider it compensation for not being able to talk about it). This could mean working in industries which default to being open rather than those which default to being closed.
OSS isn't nearly the only way to be able to show what you've worked on. In the creative industries, where the end product is customer-visible, people keep very close eye on whose name ends up in the credits. Academics spend lots of time worrying about citation counts and directed graphs.
More prosaically, establish an expectation early that you're simply going to talk about what you're doing. I think at Fog Creek / Stack Exchange they call this "producing artifacts" -- conference presentations, blog posts, OSSed software, and the like, centered around the work. Even at very open companies there exists lots of secret sauce, but most of the valuable work of the company is not particularly sensitive, and much of it has widely generalizable lessons. Write about those lessons as you learn them. If at all possible, publish what you write. Even if it is published to an audience of no one, you will be able to point people back to it later.
Some of my most effective writing in terms of career growth was back in 2006 through 2008, when I was struggling through not understanding anything I was doing, and where I -- quite literally -- had less readers than my younger brother's blog on writing superhero novels. Why was toiling in Internet-obscurity still valuable? Because I was able to point to particular experiments that I started in e.g. 2008, and then point to the followups in 2009 and 2010, which showed those experiments were really successful. The failures and false starts aren't extremely interesting to most people, but having some successes under your belt credibly demonstrates that you're capable of either reproducing them in the future or experimenting your way to new successes in your new environment.
If you cannot build things you can show at work, you should build things you can show outside of work. Companies in our industry are gradually becoming more reasonable about IP assignment clauses -- there's less of the "we own everything you think of at any point in your employment" nonsense these days. Even at my very straight-laced Japanese megacorp, they were willing to write an exception into the employment contract for a) OSS work that I did outside of company hours and b) Bingo Card Creator. I offered them this in exchange: "If you let me continue working on these, I'm going to learn lots of skills which I can put to the use of the company. Normally you invest lots of money sending engineers to conferences and professional training. This is even better for you: I'll learn more with no operating expenditure and no decrease in billing efficiency." That's an offer you can make to substantially any employer.
I prefer being upfront with people rather than doing the "It is easier to ask for forgiveness than ask for permission" route a lot of folks suggest. Sure, you can just roll the dice and pretend your employer is unlikely to notice your side project. Unfortunately, the odds of them noticing your side project go up sharply if the side project is ever successful, and then your lack of forthrightness about it give you unbounded liability extending far into the future. Just ask. The worst they can say is "No."
You might consider asking in the context of a more general compensation discussion than just "Hey boss, can I work on OSS?" That way, if they say "No side projects", you'll say "OK, in lieu of the side projects, I'll need more money." It's easier to be sticklers for the stock agreements when there's absolutely no cost to the company to insist on the usual boilerplate, but minor concessions on the boilerplate are often easier than concessions on things which actually appear on the company's books.
Prefer To Work Where People Can See You
I used to phrase this as "work in public", but when people think about folks who work in public, they think of rock stars and figure "Well, I'll never be a rock star."Vanishingly few people in our industry have the profile of rock stars. They can still have substantial profile among the audience of "people professionally relevant to them." That might be as tightly scoped as "people with hiring authority for front-end developers in my metro area", which might be a set of, what, a couple of dozen folks?
How do you develop that profile? I'd suggest, all things being equal, working at places and on projects which have above-average visibility.
Many engineering projects are deep in the bowels of late-stage industrial capitalism. Then there's writing the Facebook mobile app. I have no clue what engineers actually worked on the Facebook mobile app, but I'm betting that if I were a Silicon Valley hiring manager in iOS or Android development I'd a) know their names and b) have them at or near the top of my personal poach list.
Side note: A poach list is my informal name for "The people who, if I had infinite money and they had no other commitments, I'd hire to work on a particular project." I have several mental poach lists -- the best people I know on Rails programming, on A/B testing, on writing email, etc. When people ask me for advice on what to do about those topics, I often say "You know who is really great at this? <%= poach_list.pop() %> You cannot possibly waste your time taking them out to coffee." Brokering coffee dates cannot possibly work out poorly for the people who go to them. (My interest? Helping people out is fun, and -- funny enough -- people often seem to remember when you get them a job or a key employee.)
You don't have to optimize for "sexy" projects. You know, sexy projects: I don't know how to describe them but I know it when I see it. Most engineering work isn't intrinsically sexy. I would, however, optimize for impact and visibility.
Don't try to make a career out of optimizing the SQL queries to display a preference page on a line of business app at a company that no one has ever heard of. That is not the straightforward path to having other people learn you are capable of doing meaningful work. Instead, work at higher profile companies/organizations -- AmaGooFaceSoft, startups or small companies with anomalously high profile (locally, nationally, whatever), or in positions where by your nature you're exposed to lots of people.
I have a few friends who are developer evangelists, which is a funny job created at API companies where your brief is basically "Go demo our product to a group of developers. Now, do that again, every day, for the next several years." Sentiment on the actual job is decidedly mixed. Keith Casey gives a pretty good account here.
(Side note: I'd be remiss if I didn't note that Keith just got his work shared with 10,000 people because Keith did the work and made it easily shareable, and also because Keith knew me, through his previous job at Twilio. I'm a customer there. Everyone can play six degrees to Kevin Bacon in our industry, but actually putting in the work makes it much more likely that other people will play six degrees on your behalf.)
Anyhow, developer evangelism. An observation: every developer evangelist I know goes into a much better job right after they quit being an evangelist. This is not true of other engineering jobs with checkered reputations, like e.g. The Build Guy. Why do developer evangelists get upgrades but The Build Guy(s) not? My bet is because evangelists literally spent years meeting thousands of people and showing them "Hey, I'm going to live code in front of you while also making my employers fat stacks of money. You run a company and could use both engineers and money. You should probably remember my name, you know, just in case." The Build Guy(s) suffers in underappreciated solitude, except when maven bottoms out or RubyGems goes down and it is somehow The Build Guy's fault.
If you cannot gain exposure at your day job, try to get some exposure outside of it. Network actively. Go to local meetups of technical folks, but also go to the (often separate) events where the business side of your industry talks shops. Speak at conferences. Take the things you have created (see above) and actively show them to people to solicit feedback. You don't have to have an audience of thousands for an audience to be worthwhile -- for landing a new job, having an audience of one hiring manager is a darn sight better than having no audience at all. Blog and collect an email list. It's old and hackneyed advice but it freaking works, particularly when you can compound improvements over years.
Amy Hoy has a great metaphor for this -- "stacking the bricks". Seen from the outside, you might say "That person with an impressive career? It's like they have a sheer wall made out of awesome. I could not hope to ever have a wall like that." Seen from the inside, it looks like one day of delivering a single good conference talk, a few weeks spent writing an OSS library, another day writing the definitive blog post on getting multiple Ruby versions playing together, a few months shipping a product used by many people, an hour recording a podcast. Brick by brick, stone by stone, the wall gets higher.
Prefer To Work On Things You Can Keep
The employer/employee relationship is generally "You give us an hour and, in return, we give you some consideration for that hour." As an employee, you very rarely get to keep hours, bank them against the future, or have them redound to your benefit years later.I'm not generally a fan of the Silicon Valley model, but I'll say this in their defense: widespread employee ownership of the enterprise is one of the single best innovations in the history of capitalism. Non-managerial employees own plus or minus 20% of Twitter, Facebook, etc. They own plus or minus "rounding error" of almost all other publicly traded companies, with very rare exceptions.
I think that's an improvement on the "no shared stake" model of employment, but I don't think it is the last word in it. For one thing, it overconcentrates employee wealth with one company. As an employee, your short-term cash flow generation is tied to the continued health of your employer. If a large portion of your net worth is tied to their stock, you're magnifying the impact of a secular or firm-specific shock should one occur. (This is, relatedly, why I'm not a fan of buying the stock of an employer in a company-sponsored DRIP or IRA. You've got plenty of exposure to their future already without buying more of it with your own money.)
The explicit understanding among professional investors is that 90% of all shares of early-stage startups are worthless. It seems more than a little self-serving for professional investors to tell employees "While our general partners would laugh us out of the room if we suggested betting the entire fund on a single investment, even if we thought it was a sure thing, you are going the be the lucky ones and you should certainly have 99% of your net worth tied up in the illiquid shares of one particular company."
So if not hard assets directly awarded by employers, then what?
Well, obviously, sock away money like every financial advisor ever will tell you to. (Here's everything you need to know: buy broad market index funds in your tax-advantaged accounts. If that sounds too complicated, get a Vanguard target retirement fund where the number most closely matches the approximate time you'll retire.)
There's another, harder option with higher returns: the side project. You can "buy" them with sweat equity, one bead at a time. They provide you with many benefits, including the direct financial benefits (if you sell things to people for money, you get money, which can be useful), the compounded benefits of investing the financial benefits (my first $2,000 from Bingo Card Creator turned into Chipotle stock at an average price of $50 a share -- don't buy stocks, buy index funds, but that decision worked out pretty decently for me).
There's also intangible -- but no less real -- benefits to having an artifact which is yours. This is one reason why, while I love OSS, I would suggest people not immediately throw their OSS on Github. That makes it very easy for developers to consume your code, but it does not make it easy for you to show the impact of that code to other people, particularly to non-technical stakeholders. To the extent that people's lives are meaningfully improved by your code, the credit (and observable citations) often goes to Github rather than going to you. If you're going to spend weeks or months of time writing meaningful OSS libraries, make a stand-alone web presence for them.
Example: my A/Bingo was once probably the best option for Rails A/B testing, by dint of being the only serious option for Rails A/B testing. It is a little old in the tooth now, but being The A/B Testing Guy got me several consulting gigs. The effort to make e.g. documentation, a quickstart guide, a logo, and a branded web presence beats the heck out of having a junior engineer at a potential client just git clone my Github URL and never have my work exposed to a decisionmaker there at all.
(Much love for Github, guys. Great company, great product, great impact on the industry. I only suggest not using them for a portion of one's projects, for a fairly simple reason: I don't work for them, I work for me. If I don't work for myself, it is unlikely anyone else will.)
If you want to learn more about the actual mechanics of building a side project, my blog covers it in a lot of detail. For a much briefer overview of it, I really recommend Jason Cohen's presentation at Microconf 2013. His formula is "Predictable acquisition of recurring revenue with an annual pre-pay option with a product which solves a demonstrable, enduring pain point for a business." That idea is developed at the above link for an hour, and a lot of the advice given is specific and wildly actionable. I highly recommend it.
Consumption Is Sometimes Valuable, But Creation Moves You Forward
I'll close with my usual advice to peers: reading this email was valuable (knock on wood). Watching Jason's video is valuable. Rolling up your sleeves and actually shipping something is much, much more valuable. If you take no other advice from me ever, ship something. You'll learn more shipping a failure than you'll learn from reading about a thousand successes. And you stand an excellent chance of shipping a success -- people greatly overestimate how difficult this is.Just don't end the week with nothing.
If there's ever anything I can do to help you out, whether you're the CEO of a multi-million dollar a year SaaS company or just getting ready to stack your first brick, drop me a line. Nothing makes me happier businesswise than being able to help people, particularly those who are getting started.
Sunday, March 30, 2014
Lies Lies Lies, yeah, they're gunna get you..
"four agreements": "Be impeccable with your word. Don't take anything personally. Don't make assumptions. Always do your best."
"The liar's punishment is not in the least that he is not believed, but that he cannot believe anyone else." — George Bernard Shaw
From New York Times:
"The liar's punishment is not in the least that he is not believed, but that he cannot believe anyone else." — George Bernard Shaw
From New York Times:
Peter maintains that telling lies is the No. 1
reason entrepreneurs fail. Not because telling lies makes you a bad
person but because the act of lying plucks you from the present,
preventing you from facing what is really going on in your world. Every
time you overreport a metric, underreport a cost, are less than honest
with a client or a member of your team, you create a false reality and
you start living in it.
You know the right path to take and choose
another, and in so doing you lose control of the situation. Now, rather
than tackling the problem head on, you have to manage the fallout from
the lie. I know people who seem to have spent their entire careers
inflating the truth and then fighting to meet the expectations they have
set.
Thursday, March 20, 2014
Agile is dead
Agile is dead, long live agility.
Most notable point to take away from the article is what Agile originally stood for in the first place.
After years of misunderstanding, misuse and misnomers, this is most likely not what is understood to be agile. So one of the founders, Dave Thomas, co author of Pragmatic Programmer, has declared 'agile' dead, replaced with 'agility', as in 'you’re a programmer who programs with agility'.
Most notable point to take away from the article is what Agile originally stood for in the first place.
Individuals and Interactions over Processes and Tools
Working Software over Comprehensive Documentation
Customer Collaboration over Contract Negotiation, and
Responding to Change over Following a Plan
After years of misunderstanding, misuse and misnomers, this is most likely not what is understood to be agile. So one of the founders, Dave Thomas, co author of Pragmatic Programmer, has declared 'agile' dead, replaced with 'agility', as in 'you’re a programmer who programs with agility'.
Sunday, March 16, 2014
How to Minimize Politics in Your Company
The following is a good article on what a CEO should do to attempt to minimize corporate politics, and it provides some good hypothetical situations to bring up to see if a potential employer is actually doing anything to effectively combat such political machinations.
Source: http://www.bhorowitz.com/how_to_minimize_politics_in_your_company
Political behavior almost always starts with the CEO. Now you may be thinking: “I hate politics, I’m not political, but my organization is very political. I clearly didn’t cause this.” Sadly, you needn’t be political to create extreme political behavior in your organization. In fact, it’s often the least political CEOs who run the most ferociously political organizations. Apolitical CEOs frequently accidentally encourage intense political behavior.
What do I mean by politics? I mean people advancing their careers or agendas by means other than merit and contribution. There may be other types of politics, but politics of this form seem to be the ones that really bother people.
Specifically, you will be rewarding behavior that has nothing to do with advancing your business. The employee will earn a raise by asking for one rather than you automatically rewarding them for outstanding performance. Why is this bad? Let me count the ways:
The difference between managing executives and managing more junior employees can be thought of as the difference between being in a fight with someone with no training and being in a ring with a professional boxer. If you are in a fight with a regular person, then you can do natural things and they won’t get you into much trouble. For example, if you want to take a step backwards, you can pick your front foot up first. If you do this against a professional boxer, you will get your block knocked off. Professional boxers train for years to take advantage of small errors in technique. Lifting your front foot first to take a step backwards will take you slightly off balance for a split second and that’s all your opponent will need.
Similarly, if you manage a junior employee and they ask you about their career development, you can say what comes naturally and generally get away with it. As we saw above, things change when you deal with highly ambitious, seasoned professionals. In order to keep from getting knocked out by corporate politics, you need to refine your technique.
1. Hire people with the right kind of ambition—The cases that I described above might involve people who are ambitious, but not necessarily inherently political. All cases are not like this. The surest way to turn your company into the political equivalent of the US Senate is to hire people with the wrong kind of ambition. As defined by Andy Grove, the right kind of ambition is ambition for the company’s success with the executive’s own success only coming as a by-product of the company’s victory. The wrong kind of ambition is ambition for the executive’s personal success regardless of the company’s outcome.
2. Build strict processes for potentially political issues and do not deviate—Certain activities attract political behavior. These activities include:
Performance and compensation—Often companies defer putting performance management and compensation processes in place. This doesn’t mean that they don’t evaluate employees or give pay raises; it just means they do so in an ad hoc manner that’s highly vulnerable to political machinations. By conducting well-structured, regular performance and compensation reviews, you will ensure that pay and stock increases are as fair as possible. This is especially important for executive compensation as doing so will also serve to minimize politics. In the example above, the CEO should have had an airtight performance and compensation policy and simply told the executive that his compensation would be evaluated with everyone else’s. Ideally, the executive compensation process should involve the board of directors. This will a) help ensure good governance and b) make exceptions even more difficult.
Organizational design and territory—If you manage ambitious people, from time to time, they will want to expand their scope of responsibility. In the example above, the CFO wanted to become the COO. In other situations, the head of marketing might want to run sales and marketing or the head of engineering may want to run engineering and product management. When someone raises an issue like this with you, you must be very careful about what you say, because everything that you say can be turned into political cannon fodder. Generally, it’s best to say nothing at all. At most, you might ask “why?”, but if you do so be sure not to react to the reasons. If you indicate what you are thinking, that information will leak, rumors will spread and you plant the seeds for all kinds of unproductive discussions. You should evaluate your organizational design on a regular basis and gather the information that you need to decide without tipping people to what you plan to do. Once you decide, you should immediately execute the re-org: don’t leave time for leaks and lobbying.
Promotions—Every time your company gives someone a promotion, everyone else at that person’s level evaluates the promotion and judges whether merit or political favors yielded the promotion. If the latter, then the other employees generally react in one of three ways:
3. Be careful with “he said, she said”—Once your organization grows to a significant size, members of your team will, from time to time, complain about each other. Sometimes this criticism will be extremely aggressive. Be very careful about how you listen and the message that it sends. Simply by hearing them out without defending the employee in question, you will send the message that you agree. If people in the company think that you agree that one of your executives is less than stellar, that information will spread quickly and without qualification. As a result, people will stop listening to the executive in question and they will soon become ineffective.
There are two distinct types of complaints that you will receive:
Complaints of type 2 are both more rare and more complex. If one of your executives summons the courage to complain about the competency of one of their peers, then there is a good chance that either the complainer or the targeted executive has a major problem. If you receive a type 2 complaint, you will generally have one of two reactions: a) they will be telling you something that you already know or b) they’ll be telling you shocking news.
If they are telling you something that you already know, then the big news is that you have let the situation go too far. Whatever your reasons for attempting to rehabilitate the wayward executive, you have taken too long and now your organization has turned on the executive in question. You must resolve the situation quickly. Almost always, this means firing the executive. While I’ve seen executives improve their performance and skill sets, I’ve never seen one lose the support of the organization then regain it.
On the other hand, if the complaint is new news, then you must immediately stop the conversation and make clear to the complaining executive that you in no way agree with their assessment. You do not want to cripple the other executive before you re-evaluate their performance. You do not want the complaint to become a self-fulfilling prophecy. Once you’ve shut down the conversation, you must quickly re-assess the employee in question. If you find that they are doing an excellent job, then you must figure out the complaining executive’s motivations and resolve them. Do not let an accusation of this magnitude fester. If you find that the employee is doing a poor job, there will be time to go back and get the complaining employee’s input, but you should be on a track to remove the poor performer at that point.
Source: http://www.bhorowitz.com/how_to_minimize_politics_in_your_company
Political behavior almost always starts with the CEO. Now you may be thinking: “I hate politics, I’m not political, but my organization is very political. I clearly didn’t cause this.” Sadly, you needn’t be political to create extreme political behavior in your organization. In fact, it’s often the least political CEOs who run the most ferociously political organizations. Apolitical CEOs frequently accidentally encourage intense political behavior.
What do I mean by politics? I mean people advancing their careers or agendas by means other than merit and contribution. There may be other types of politics, but politics of this form seem to be the ones that really bother people.
How it happens
A CEO creates politics by encouraging and sometimes incenting political behavior—often accidentally. For a very simple example, let’s consider executive compensation. As CEO, senior employees will come to you from time to time and ask for an increase in compensation. They may suggest that you are paying them far less than their current market value. They may even have a competitive offer in hand. Faced with this confrontation, if the request is reasonable, you might investigate the situation. You might even give the employee a raise. This may sound innocent, but you have just created a strong incentive for political behavior.Specifically, you will be rewarding behavior that has nothing to do with advancing your business. The employee will earn a raise by asking for one rather than you automatically rewarding them for outstanding performance. Why is this bad? Let me count the ways:
- The other ambitious members of your staff will immediately agitate
for raises as well. Note that neither this campaign nor the prior one
need be correlated with actual performance. You will now spend time
dealing with the political issues rather than actual performance issues.
Importantly, if you have a competent board, you will not be able to
give them all out-of-cycle raises, so your company executive raises will
occur on a first-come, first-serve basis.
- The less aggressive (but perhaps more competent) members of your
team will be denied off-cycle raises simply by being apolitical.
- The object lesson for your staff and the company will be the squeaky wheel gets the grease and the political employee gets the raise. Get ready for a whole lot of squeaky wheels.
How to minimize politics
Professionals vs. Amateurs
Minimizing politics often feels totally unnatural. It’s counter to excellent management practices such as being open minded and encouraging employee development.The difference between managing executives and managing more junior employees can be thought of as the difference between being in a fight with someone with no training and being in a ring with a professional boxer. If you are in a fight with a regular person, then you can do natural things and they won’t get you into much trouble. For example, if you want to take a step backwards, you can pick your front foot up first. If you do this against a professional boxer, you will get your block knocked off. Professional boxers train for years to take advantage of small errors in technique. Lifting your front foot first to take a step backwards will take you slightly off balance for a split second and that’s all your opponent will need.
Similarly, if you manage a junior employee and they ask you about their career development, you can say what comes naturally and generally get away with it. As we saw above, things change when you deal with highly ambitious, seasoned professionals. In order to keep from getting knocked out by corporate politics, you need to refine your technique.
The Technique
As I developed as a CEO, I found three key techniques to be extremely useful in minimizing politics.1. Hire people with the right kind of ambition—The cases that I described above might involve people who are ambitious, but not necessarily inherently political. All cases are not like this. The surest way to turn your company into the political equivalent of the US Senate is to hire people with the wrong kind of ambition. As defined by Andy Grove, the right kind of ambition is ambition for the company’s success with the executive’s own success only coming as a by-product of the company’s victory. The wrong kind of ambition is ambition for the executive’s personal success regardless of the company’s outcome.
2. Build strict processes for potentially political issues and do not deviate—Certain activities attract political behavior. These activities include:
- Performance evaluation and compensation
- Organizational design and territory
- Promotions
Performance and compensation—Often companies defer putting performance management and compensation processes in place. This doesn’t mean that they don’t evaluate employees or give pay raises; it just means they do so in an ad hoc manner that’s highly vulnerable to political machinations. By conducting well-structured, regular performance and compensation reviews, you will ensure that pay and stock increases are as fair as possible. This is especially important for executive compensation as doing so will also serve to minimize politics. In the example above, the CEO should have had an airtight performance and compensation policy and simply told the executive that his compensation would be evaluated with everyone else’s. Ideally, the executive compensation process should involve the board of directors. This will a) help ensure good governance and b) make exceptions even more difficult.
Organizational design and territory—If you manage ambitious people, from time to time, they will want to expand their scope of responsibility. In the example above, the CFO wanted to become the COO. In other situations, the head of marketing might want to run sales and marketing or the head of engineering may want to run engineering and product management. When someone raises an issue like this with you, you must be very careful about what you say, because everything that you say can be turned into political cannon fodder. Generally, it’s best to say nothing at all. At most, you might ask “why?”, but if you do so be sure not to react to the reasons. If you indicate what you are thinking, that information will leak, rumors will spread and you plant the seeds for all kinds of unproductive discussions. You should evaluate your organizational design on a regular basis and gather the information that you need to decide without tipping people to what you plan to do. Once you decide, you should immediately execute the re-org: don’t leave time for leaks and lobbying.
Promotions—Every time your company gives someone a promotion, everyone else at that person’s level evaluates the promotion and judges whether merit or political favors yielded the promotion. If the latter, then the other employees generally react in one of three ways:
- They sulk and feel undervalued
- They outwardly disagree, campaign against the person, and undermine them in their new position
- They attempt to copy the political behavior that generated the unwarranted promotion
3. Be careful with “he said, she said”—Once your organization grows to a significant size, members of your team will, from time to time, complain about each other. Sometimes this criticism will be extremely aggressive. Be very careful about how you listen and the message that it sends. Simply by hearing them out without defending the employee in question, you will send the message that you agree. If people in the company think that you agree that one of your executives is less than stellar, that information will spread quickly and without qualification. As a result, people will stop listening to the executive in question and they will soon become ineffective.
There are two distinct types of complaints that you will receive:
- Complaints about an executive’s behavior
- Complaints about an executive’s competency or performance
Complaints of type 2 are both more rare and more complex. If one of your executives summons the courage to complain about the competency of one of their peers, then there is a good chance that either the complainer or the targeted executive has a major problem. If you receive a type 2 complaint, you will generally have one of two reactions: a) they will be telling you something that you already know or b) they’ll be telling you shocking news.
If they are telling you something that you already know, then the big news is that you have let the situation go too far. Whatever your reasons for attempting to rehabilitate the wayward executive, you have taken too long and now your organization has turned on the executive in question. You must resolve the situation quickly. Almost always, this means firing the executive. While I’ve seen executives improve their performance and skill sets, I’ve never seen one lose the support of the organization then regain it.
On the other hand, if the complaint is new news, then you must immediately stop the conversation and make clear to the complaining executive that you in no way agree with their assessment. You do not want to cripple the other executive before you re-evaluate their performance. You do not want the complaint to become a self-fulfilling prophecy. Once you’ve shut down the conversation, you must quickly re-assess the employee in question. If you find that they are doing an excellent job, then you must figure out the complaining executive’s motivations and resolve them. Do not let an accusation of this magnitude fester. If you find that the employee is doing a poor job, there will be time to go back and get the complaining employee’s input, but you should be on a track to remove the poor performer at that point.
Tuesday, March 11, 2014
What you would seem to be..
“Be what you would seem to be - or, if you'd like it put more simply -
never imagine yourself not to be otherwise than what it might appear to
others that what you were or might have been was not otherwise than what
you had been would have appeared to them to be otherwise.” -- Lewis Carroll
Monday, March 10, 2014
How to judge documentation in 30 seconds.
Source: http://ericholscher.com/blog/2014/feb/27/how-i-judge-documentation-quality/
If this is your project, please check out Mkdocs. It is still a new tool, but it will give your users something much nicer. I also recommend Sphinx for the most mature approach to documentation.
A Website
If your documentation is a directory full of files on GitHub, I close the tab. With GitHub Pages, Read the Docs, and other places to host generated documentation for free, not making an effort is unforgivable.If this is your project, please check out Mkdocs. It is still a new tool, but it will give your users something much nicer. I also recommend Sphinx for the most mature approach to documentation.
Prose
If your documentation is generated from source code, I am immediately skeptical. You should use words to communicate with your users, and those words shouldn’t live in your source code. If you included all of the things needed to document a project in source, your code would be unreadable.So please, use a tool that allows you to write prose documentation outside of your source code. Your users will thank you.
A great start is to read this series on Writing Great Documentation, and the resources on the Write the Docs docs. [1]
Permalinks
One of the primary uses of documentation is the ability to link information to other people. If your documentation doesn’t have an easy way to link to sections of content on a page, then the value decreases. Your users should never have to send someone a link and say “go here and search for X”. That means your documentation has failed your users.You’ll notice even my blog has permalinks. I believe all text content should, because it greatly increases the utility of the content.
URLs
There are two things I always look for in the URL:Most often, projects don’t have either. Your URL should look something like: https://docs.project.com/en/1.0/
- Language
- Version
Versions
I see versions in lots of documentation, but not nearly enough. If your project has versions, your documentation should too. Not everyone can always upgrade to the latest version. If someone is using an old version, they should have access to documentation for that version.Along the same lines, you should also have documentation for your development version. If the docs don’t have a version attached, I have no idea if they are up to date or not. You should clearly mark your released versions and development version, otherwise users will get confused.
Language
Language is one I rarely see. The software world has a nasty habit of forgetting that the whole world doesn’t speak English. If you don’t provide a language in your URL, you are implicitly sending the message that the documentation will never be translated.I believe that translating documentation is a really important step towards helping people learn to program. Someone shouldn’t have to learn Programming and English at the same time.
Translations are quite a bit of work, so I understand why many projects don’t have them. But you should at least acknowledge the possibility of translation by putting the language in the URL.
Conclusion
That is the 30 second way that I determine if a project’s documentation is worth looking at. These are all hints about if a project actually cares about its docs. If the project doesn’t care about its documentation, that is a good sign that you probably shouldn’t use it.
Subscribe to:
Posts (Atom)