All Those Other Products Suck

Interesting perspective on the eternal build vs buy dilemma by the folks at Github (in Inc article):

githuboctacat“Our finance people should have their own developers to automate the things that finance people do,” says Preston-Werner. “People shouldn’t be responsible for what we call ‘s––– work.’ We prefer to solve repetitive sorts of jobs with technology.” As for why it builds so many internal tools, such as a company directory, rather than just buying them, Preston-Werner explains: “Wedemand that the products we use be excellent. All those other products suck.”

Traditionally the bar has to be pretty high to build something internal:

Decades of trial, error, and egghead analysis have yielded a consensus conclusion: Buy when you need to automate commodity business processes; build when you’re dealing with the core processes that differentiate your company.

These internal IT projects  almost always end up larger than estimated, and a pain to maintain.  But I wonder if the circumstances haven’t changed recently and it’s time to re-evaluate.  The recent explosion in open-source frameworks, libraries and applications mean that build-yourself is almost assemble-yourself, meaning, take off-the-shelf open-source components and build upon them to suit your purposes.  Developer productivity has never been higher.  Will we see a boom in internal system building?  Will the finance dept hire a developer instead of a couple of spreadsheet wranglers sometime soon?  I’d bet on it.

 

Posted in Uncategorized | 3 Comments

Don’t have a black hole in your team where a star should be

Jack Welsh makes the case that managers should expect to bat .750 or worse on hiring.

Look, hiring great people is brutally hard. New managers are lucky to get it right half the time. And even executives with decades of experience will tell you that they make the right calls 75% of the time at best

What’s the big deal?  Poor performance can bring down the team – especially when the hiring failure is a poor cultural fit.  And high performers exceed average performers by multiples – especially in software development…

Every smart idea matters. Every ounce of passion makes a difference. You cannot have a black hole in your organization where a star should be.

But managers – especially new managers – are slow to recognize, face up and deal with these errors….

The real reason most managers don’t act is that they fear looking stupid and worry that admitting they made a hiring mistake is career suicide. In any good organization, that logic is exactly backward. Any company worth its salt will reward managers when they acknowledge they’ve hired wrong and swiftly repair the damage.

I’d like to think that we get our hiring right at Bazaarvoice more than 50% – 75% of the time.  Especially in R&D where we have 4 or 5 separate interviews where we try to assess: (i) can they do the job (with excellence)?  (ii) will they do the job (with excellence)?

But this article reminds me not to be too discouraged or deny reality when I find myself with a poor fit.  So what to do?  Fix it.  I try to give important critical feedback quickly, and set clear expectations about expected behavior and performance.  But if things aren’t working out, it’s best to part ways.  Jack has some good advice:

Remember: You made the error. Don’t blame the person who persuaded you that he was right for the job. Break the news candidly, take responsibility for what went wrong, make a fair financial arrangement, and then give the departing employee time to look for a soft landing somewhere else. Both you and the person you hired need to feel as if you handled everything properly, especially should you ever meet again

 

Posted in Uncategorized | Leave a comment

How To Get That Product Manager Job

Interested in becoming a Product Manager?  Check out this informative and entertaining presentation by Google Product Manager Shreyas Doshi on How To Get That Next PM Job:

Some Highlights:

  • Go ahead and do the job at your current company, before you earn the title
  • Best outcome of an interview: the interviewer learned something new

Posted in Uncategorized | Tagged | Leave a comment

Tours of Duty: The New Employer-Employee Compact

Is there an alternative balanced between between permanent employment and contract employment?  Reid Hoffman (CEO of LinkedIn) proposes the tour of duty in this month’s Harvard Business Review: “firm but time-limited mutual commitment with focused goals and clear expectations.”

When possible, a tour of duty should offer an employee the possibility of a breakout entrepreneurial opportunity. This might involve building and launching a new product, reengineering an existing business process, or introducing an organizational innovation.

The interesting thing is that the tour-of-duty really is a shorter term commitment on both parts.  There is no assumption made on either side of the work relationship that it will be extended beyond the tour.  From the perspective of the company this means good employees will need to be re-recruited within a known timeframe, and that mediocre employees simply may not have their tour renewed.  From the perspective of the employee this means that if the company has been a good one to work for, they will want to be sure to impress them with their accomplishments and not take permanent employment for granted.  And time working for not-so-great companies can come to a natural end once the tour-of-duty is complete.  

The tour-of-duty approach works: The company gets an engaged employee who’s striving to produce tangible achievements for the firm and who can be an important advocate and resource at the end of his tour or tours. The employee may not get lifetime employment, but he takes a significant step toward lifetime employability. A tour of duty also establishes a realistic zone of trust. Lifelong employment and loyalty are simply not part of today’s world; pretending that they are decreases trust by forcing both sides to lie.

Why two to four years? That time period seems to have nearly universal appeal. In the software business, it syncs with a typical product development cycle, allowing an employee to see a major project through. Consumer goods companies such as P&G rotate their brand managers so that each spends two to four years in a particular role. Investment banks and management consultancies have two- to four-year analyst programs. The cycle applies even outside the business world—think of U.S. presidential elections and the Olympics.

It’s an interesting idea but I’m not sure it would work well at scale.  Software development lifecycles are a lot shorter than two-to-four years these days.  Organizations cannot realistically commit to keeping employees working on particular project or technology for that long.

One important issue that the article does raise is that employment very often does entail a tour-of-duty even when it isn’t explicitly stated.  Engineers and Project Managers generally want to stick around to see their product developed and launched.  At the end of a big project, employees – especially your best employees – will be thinking, what next?  And it is important to recognize the approaching end to a particularly substantial piece of work, and the need to re-recruit your highest performing employees for another tour – even if that’s not what you call it.

Posted in Uncategorized | Tagged , | Leave a comment

The one cost engineers and product managers don’t consider

I love this article from Chris Gale, VP of Engineering at Yammer – The one cost engineers and product managers don’t consider – which is about reducing complexity…

On the product side, your best tool for eliminating complexity cost is data. Studies show that most product ideas fail to show value, and many even remove value. If you methodically test the impact of each change you make, you can discard those that are negative, but equally relevant to complexity cost, also discard those that are neutral. A change that doesn’t hurt the key performance indicators still hurts the product because it adds complexity debt that must be paid on all future projects. Often, the best thing for a product is taking something away from it. 

Beyond establishing the impact of changes, data also helps you to shed complexity over time. All of your features should be logging their usage, and this usage must be made transparent to everyone. Show your team where to find this data, and given them the means to ask how to interpret it if it’s unclear. At Yammer, where data is collected on most every feature and is made available to everyone, I’ve repeatedly seen this pattern: A developer is working in an area of the code and discovers that it will take more than a trivial amount of time to carry a feature forward in a refactor or other change. Instead of blindly taking on that work, he or she will run reports against the usage data to find out whether a given feature is often used. That data can then be run past the product managers who can help decide whether it’s sensible to just drop the feature. This can also save time before something even becomes a proposal, because product managers will start by asking how well-used is a feature area they intend to enhance. Many things that seemed like great ideas are revealed to be wastes of time, and complexity is saved. 

Complexity is also introduced by well-meaning people on the implementation side as well. Software developers like challenges, and the challenge of building a complex system that serves up a simple interface is especially alluring. Consider DSLs, abstractions and the attraction to being the one to build a framework that gets leveraged for years. This drives us to introduce huge complexity debt we defend with statements like “it makes it so easy once you understand” and “it will save us so much coding.” Writing the lines of code is rarely the big cost in engineering: it’s the understanding, the communication and the maintenance. 

Embrace simplicity in your engineering. The best engineering usually isn’t showy or intense-looking. Given the same result, the simpler code is more valuable to your organization. This will often be unsatisfying to people’s egos, but the best engineers have nothing to prove.

Posted in Uncategorized | Tagged , , | Leave a comment

Getting Actionable Manager Feedback

At Bazaarvoice R&D we have a peer feedback system that we use every six months.  Since it’s mostly focused on individual contributors, the questions relevant to management are too few and too broad (IMHO). e.g.

… Do they provide effective and timely feedback about your performance and work with you to establish and achieve your career goals? Do they coach, mentor and empower their team members (and those outside their team?) How effective are they as a leader of people? …

There’s a lot of important areas mentioned in that one question (feedback, career development, coaching, empowering, leadership).  Some of those areas might not get addressed.  I want more actionable feedback focused on items that are important to management excellence.  

A while back I wrote about Google’s Project Oxygen – an analytical approach to examining manager effectiveness.  I took their information on effective behaviors and passed it on to my team (the developers, QA, and designer who report to me, along with the Product Manager I work closely with) to see how I’m doing against the Oxygen criteria.

Here’s the survey I fashioned from their criteria:

===========

Anonymous Manager Feedback

These behaviors were articulated by Google as being an important factor in employee happiness and team effectiveness.  I would like to use this survey to help become a better manager.

Please rate me for each item on a scale of 1-5 (or N/A if necessary)

(1=never, 2=rarely, 3=usually, 4=often, 5=always)

Coaching

  • Provides specific constructive feedback, balancing the negative and the positive. [1-5]
  • Has regular one-on-ones, presenting advice tailored to employees’ specific strengths [1-5]
  • Comments (Optional) [text area]

Empowering and not micro-managing

  • Balances giving freedom to employees, while still being available for advice [1-5
  • Makes ‘stretch’ assignments to help the team tackle big problems [1-5]
  • Comments (Optional) [text area]

Team members’ success and personal well-being

  • Gets to know employees as people with lives outside of work [1-5]
  • Makes new members of the team feel welcome and helps ease their transition [1-5]
  • Comments (Optional) [text area]

Productivity and results-oriented

  • Focuses on what employees want the team to achieve and how they can help achieve it [1-5]
  • Helps the team prioritize work and uses seniority to remove roadblocks [1-5]
  • Comments (Optional) [text area]

Communication

  • Communication is two-way: manager listens and shares information [1-5]
  • Holds team meetings and is straightforward about the messages and goals of the team [1-5]
  • Encourages open dialogue and listens to the issues and concerns of employees [1-5]
  • Comments (Optional) [text area]

Career Development

  • Helps employees with career development [1-5]
  • Comments (Optional) [text area]

Vision and Strategy

  • Even in the midst of turmoil, keeps the team focused on goals and strategy [1-5]
  • Involves the team in setting and evolving the team’s vision and making progress toward it [1-5]
  • Comments (Optional) [text area]

Technical Skills

  • Has the technical skills to advise the team and understand the specific challenges of the work [1-5]
  • Rolls up sleeves and conducts work side by side with the team when needed [1-5]
  • Comments (Optional) [text area]

Misc

  • Any other feedback on how I can improve? [text area]

==================

I’ve used this for two separate quarterly rounds of feedback now.  Some of the aggregate results are below.

image

I think it’s a pretty good set of criteria to assess against, and it accurately picked up some areas for me to work on (career development, stretch goals).   Over the quarter I managed to improve on a few areas that I worked on, but the team also pointed out that I had missed some 1:1s in the past quarter.  I wasn’t sure they would notice or it would matter – but they did notice, and it does matter!  

Overall I think this is a good tool to identify and help prioritize areas for improvement, and I’m hoping to roll this out to all Bazaarvoice R&D managers based on my initial experiment with it.

Posted in Uncategorized | Tagged , | Leave a comment

Are coders worth it?

An interesting long form piece in Aeon Magazine by James Somers – titled “Are coders worth it?” – aims to examine whether web developers are worth the six figure salaries that they currently command in their first year of employment.

I am a web developer, and there has never been a better time to do what I do. Here’s how crazy it is: I have a friend who decided, part way into his second year of law school, to start coding. Two months later he was enrolled in Hacker School in New York, and three months later he was working as an intern at a consultancy that helps build websites for start-ups. A month into that internship — we’re talking a total of six months here — he was promoted to a full-time position worth $85,000.

Although the article is well-written, Somers doesn’t really go deep into the question – he quickly settled into the comfortable and well-worn points that  the value and price of things are different, and that things of equal value might have very different prices because of supply and demand.  Price shouldn’t exceed value, but there can be a huge gap (see consumer surplus) or no gap depending on conditions.  And right now conditions are great for developers:

You can imagine what it does to the ego, to be courted and called ‘indispensable’ and in general treated like you’re the one pretty girl for miles. When a lot of your contemporaries don’t even have jobs. 

It’s interesting to be experiencing this second tech boom as a software development manager, responsible for recruiting, hiring and managing great tech talent.  I experienced the first boom as a programmer – I graduated in 2000 with a degree in Math and Computer Science during the peak of first big tech boom.  Companies were flying candidates across the country for interviews and recruiting weekends.  I could hardly believe it when I was offered a starting six figure salary and a signing bonus that would comfortably pay for a new car.  We’re thirteen years later and things feel the same, but now I’m on the other side of the table.

And are coders worth it?  Somers says …

We call ourselves web developers, software engineers, builders, entrepreneurs, innovators. We’re celebrated, we capture a lot of wealth and attention and talent. We’ve become a vortex on a par with Wall Street for precocious college grads. But we’re not making the self-driving car. We’re not making a smarter pill bottle. Most of what we’re doing, in fact, is putting boxes on a page. Users put words and pictures into one box; we store that stuff in a database; and then out it comes into another box.

There’s a couple things wrong there.  First of all, the web is a communication network.  Everything is going to have a web interface ‘with boxes on a page’ – even self-driving cars and pill bottles.  Secondly, software developers at a pre-eminent Web company are building the self-driving car.  The criticism of small companies pursuing small ideas is totally misguided:

Take Doormates, a failed start-up founded in 2011 by two recent graduates from Columbia University whose mission was to allow users ‘to join or create private networks for buildings with access restricted to only building residents’. For that they, too, raised $350,000. You wonder whether anyone asked: ‘Do strangers living in the same building actually want to commune? Might this problem not be better solved by a plate of sandwiches?’ (The founders have since moved on to ‘Mommy Nearest’, an iPhone app that points out mom-friendly locations around New York.)

The reason these ideas are worth pursuing, and that coders are worth it, is that the productivity of software and software developers continues to grow exponentially.  Open source libraries, tools, languages and operating systems – combined with the continually diminishing cost of computing means that two recent graduates can build something that reasonably might be worth $1/yr to a small fraction of the residents in an apartment building.  But since there are millions of apartment residents (just in the USA) then a couple smart young women might be able to create something worth a million or two per year.  Using a range of free or low cost marketing tools (Facebook, Twitter, Blogs, etc) they begin to reach their market and start selling.  And if they leverage some other good open-source tools they can internationalize their service and offer it in Europe and China too.  Now they’re making $10MM a year.  And two developers can do this.

Because of the incredible productivity of software, a few developers can support thousands or hundred of thousands of users:

image

(source: Pingdom)

Instagram, which isn’t in the chart above, had more than two million users per employee when it was purchased by Facebook.

An interesting measure of productivity is revenue per technical employee.  A software company also requires sales, accounting, support, HR, etc – but each software developer generally build software that supports revenue of 3x to 10x their salary.  Take a look at fully loaded revenue per employee (including non tech employees) at some leading web companies:

(source: Pingdom)

Without software developers to build the technology, there are no Sales, HR, Support etc.

Scalability.  Productivity.  International reach.  Low upfront capital requirements.  Near-zero marginal distribution costs.  This is why coders are paid so much.  And yes they’re worth it.

Posted in Uncategorized | Tagged , , | Leave a comment

How to be happy

Stumbled upon a great article on Happiness by Steve Camb.  Summary:

Here’s how to build the habit of making yourself happier:

  • When you wake up, try meditating before checking your phone or turning on your computer. Even if it’s only for two minutes.
  • Do what you can to spend your time on projects you love, and less time doing work that doesn’t make you happy.
  • Spend less money on things and instead on experiences.
  • Spend time each day in “the zone” on a passion, project, or activity you love. Build something, make something, do something.
  • Incrementally improve your health, and reward yourself for it. Pick an activity or exercise to improve your physical wellbeing.  You’re in the right place!
  • Spend more time with people you love, and less time with people that drag you down. Don’t have friends or a partner? Work on your skills to find them!
  • Be grateful every day for the things that have gone right. Keep a record to remind yourself of these things.
Posted in Uncategorized | Tagged , | Leave a comment

How Google Sets Goals

There’s a surprising lack of public information on OKRs (Objectives and Key Results) – the goal setting and tracking philosophy used by Intel, Google and others.  This past month Google Ventures Startup Lab released a great presentation video by Rick Klau on how Google does goal setting and tracking: “How Google sets goals: OKRs

Some takeaways:

  • OKRs were introduced by John Doerr (Google board member) in 1999, based on his exposure to the use of OKRs at Intel.
  • OKRs are set and evaluated on a quarterly bases.
  • Objectives & Key Results should be bold, slightly out of reach, a little uncomfortable, unreasonable.  Objectives are not necessarily measurable, Key Results must be measurable (e.g. NN monthly visits by Y/M/D)
  • Keep it focused, max 5 Objectives with 4 Key Results
  • OKRs are not a performance evaluation tool – not a standard element of annual employee evaluation.  Although they are helpful for employees to draw upon and summarize/recall their impact over the past 4 quarters.
  • OKRs are graded each quarter.  Each Objective score [0-1] can just be an average of the Key Result scores [0-1] for that objective.  “Grades don’t matter except as a directional indicator.”
  • 60% – 70% accomplishment is good.  40% is bad.  80%+ means your goals are too easy.  The scores provides data about the individual and teams’ ability to accomplish certain goals.
  • Everyone’s OKRs are public (part of the employee directory listing)
  • Company-wide quarterly meeting to examine the top-level OKRs. This provides an opportunity to calibrate and re-prioritize.
  • Needs alignment, buy-in and participation from the top on down.  Cannot be half-hearted.

Here are some example OKRs that Rick established for his first quarter working for Google as Product Manager on Blogger.  Included are the grades [0.0 – 1.0] assessed at the end of the quarter:

Objective:  Accelerate Blogger Revenue Growth  [0.7]

Key Results:

  • Launch “Monetize” tab to all users   [1.0]
  • Implement AdSense Host Channel Placement Targeting to increase RPMs by xx%   [0.3]
  • Launch 3 revenue-specific experiments to learn what drives revenue growth   [0.7]
  • Finalize PRD for Blogger Ad Network, secure eng allocation to build in Q1   [0.8]

Objective:  Grow Blogger traffic by xx% over organic growth    [0.45]

Key Results:

  • Launch 3 features that will have a measurable impact on Blogger traffic    [0.6]
  • Improve Bloggers 404 handling, extend time on site and pageviews per session on sessions that start with a 404 error by xx%    [0.3]

Objective: Improve Blogger’s Reputation     [0.72]

Key Results:

  • Re-establish Blogger’s leadership by speaking at 3 industry events    [1.0]
  • Coordinate Blogger’s 10th birthday PR efforts    [0.8]
  • ID and personally reach out to top xx Blogger users    [0.8]
  • Fix DMCA process, eliminate music blog takedowns    [0.4]
  • Set up @blogger on Twitter, regularly participate in discussions re: Blogger product    [0.6]

In the video, a few of John Doerr’s original presentation slides are displayed.  Here they are:

image

image

image

image

image

image

image

image

image

Hat tip to TechCrunch

Posted in Uncategorized | Tagged , , , | Leave a comment

The Automattic Creed

I’m a sucker for a good creed.  Check out Automattic’s:

I will never stop learning. I won’t just work on things that are assigned to me. I know there’s no such thing as a status quo. I will build our business sustainably through passionate and loyal customers. I will never pass up an opportunity to help out a colleague, and I’ll remember the days before I knew everything. I am more motivated by impact than money, and I know that Open Source is one of the most powerful ideas of our generation. I will communicate as much as possible, because it’s the oxygen of a distributed company. I am in a marathon, not a sprint, and no matter how far away the goal is, the only way to get there is by putting one foot in front of another every day. Given time, there is no problem that’s insurmountable.

Posted in Uncategorized | Tagged , , | Leave a comment