Month: August 2014

“It’s not agile” and the “building a home” parable

Itamar, Leave a comment

As Martin Fowler observed almost a decade ago, “Agile” is a term that went through semantic diffusion rather quickly.

Perhaps as a result, one of the areas that seem to draw a lot of resistance from teams who perceive themselves to be “agile”, is around any sort of up-front planning.

As if just-in-time planning is synonymous with only deciding what you’re going to build in the next 2-4 weeks at the beginning of the iteration, and any planning beyond that time horizon is “waste”. Nothing can be farther from the truth.

Mike Cottmeyer of LeadingAgile is one of the true thought-leaders on applying agile principles at scale and his blog posts are almost always well worth the read. This one deals with the topic mentioned at the beginning of the post:

Should you use Agile to build your next home?

Mike uses a very powerful thought experiment to get his point across: what would building a house based on the common misconceptions of what agile is look like vs. building it based on what agile really means? Attempting to summarize the parable will not do it justice, so I’ll only repeat Mike’s conclusion, in his own words:

“Just like you wouldn’t build a house with an open ended scope, your stakeholders don’t want to commit to an open ended software project. We have to do enough work up front to put together a credible plan, mitigate risk, and understand costs. We have to estimate the work, set budgets, and make tradeoffs to ensure the product is done on time and on budget… No estimating, no planning, and not committing won’t be the answer for most organizations. It’s not a starting place anyone can live with.”

 

Advertisement
“It’s not agile” and the “building a home” parable

VP of Devil’s Advocacy

ItamarLeave a comment

It’s a little known secret that the best time to scour Tech Crunch for content that’s actually worth reading is during the weekend. There’s not a lot of “real tech news” going on during the weekend so you’re more likely to run into a thought-provoking post. I found this one about three weeks ago:

The VP of Devil’s Advocacy

Though I resent MG sinking as low as using quotes from a disappointing zombie movie as the “hook” for the story, the gist in compelling nonetheless: often times the biggest product catastrophes/flops seem almost “bound to happen” to the common man. At least in retrospect. Which then begs the question: how come these companies, with all the amazing resources at their disposal, keep making these mistakes?

Answers to this question often leads back to a dysfunctional decision-making process, stemming from very human pitfalls such as groupthink and being trapped in the wrong paradigm.

MG’s advocating for adopting similar lessons to the ones implemented by Israeli intelligence after the ’73 war and creating an official position of “VP of Devil’s Advocacy” – only if a product can withstand all the honest feedback and worst case scenarios prevented by this person – it is allowed to launch. This can also be tied to addressing Lencioni’s 2nd team dysfunction – fear of conflict – head on, by appointing a person responsible for creating (healthy) conflict.

But having someone in that role full time requires scale and organizational maturity that many companies don’t posses. The good news is that there are smaller structural investments that can be made in order to make the decision making process less error-prone on these fronts. A lighter-weight more commonly used variation of this concept is the formation of Red Teams. Red teams don’t necessarily have to exist on a permanent basis, they can be formed ad-hoc whenever a big decision with strategic significance needs to be made.

Do you have a good example of using a red-team-like structure in Tech effectively?

 

VP of Devil’s Advocacy

Employee Equity

ItamarLeave a comment

Employee equity plays an important role in enabling companies to establish the relationship with their employees which are critical to their success. As an alignment mechanism, it’s far from being perfect, but it is effective. Sadly, granting employees equity is far from being a standard part of the compensation package in many industries. But even among companies who grant equity, few do it well. Equity plans often suffer from the not-invented-here phenomena, which leads to a sub-optimal result.

To our rescue comes this great post by Andy Rachleff:

The Wealthfront Equity Plan

[Side note: The Wealthfront blog is a phenomenal resource for anyone who has equity as part of their compensation package. If that’s you – I strongly recommend familiarizing yourself with the content in this amazing resource.]

 

Here it is, in a nutshell:

  1. New Hire Grant – Grant size (% of company ownership granted) calculated according to market data, factoring in: functional role, seniority level, company size and geographic location.
  2. Promotion Grant – Grant size is the difference between current grant and the grant that would be given to a new hire in the new position.
  3. Performance Grant – Given only to the top 10-20% performers. Grant size is 50% of current new hire grant for a person in that position.
  4. Evergreen Grant – Given on an annual basis starting 2.5 years into the new hire grant. Grant size is 25% of current new hire grant for a person in that position.

Other than its market-based approach, this plan breaks away from typical equity plans in the weight and timing it places on Evergreen grants. Check out Andy’s blog post for further details and scenario examples.

I’m not advocating for implementing the Wealthfront Equity Plan as-is.  Every company is different and this should be accounted for, not ignored, in the equity plan that’s put together. But the Wealthfront plan is a great starting point based on solid reasoning and a compelling framework. A good equity plan should start with it and be refined by asking ourselves “how are we different?” rather than trying to completely reinvent the wheel from scratch.

Employee Equity

No Deadlines for You!

Itamar, Leave a comment

Continuing my short series of engineering-oriented posts, this lovely blog post by Dan Milstein of Hut 8 Labs has been leading my secret “most mis-titled blog posts” chart for quite a while now:

No Deadlines for You

This post has very little to do with deadlines and a lot to do with describing the behavior that sets apart senior engineers from junior engineers, in my opinion.

Dan argues that any definitive answer to the question:  “can your team get spec X done in Y months?”  is the wrong answer. The path to the right answer has to start by responding with a question of you own: “Why?”. This is an over-simplification, of course.

What Dan is really advocating for, is to start by developing a good enough understanding of the underlying business problem that led to the request in the first place.  Then, we have enough business context to figure out what work we really need to do in order to address it. And finally, we can present a realistic plan that takes uncertainty into account.

Trying to summarize Dan’s post in a single paragraph really doesn’t do it justice. Reading his entire post WILL be a good use of your time.

No Deadlines for You!

Speed in Software Development

Itamar, , Leave a comment

As promised, something completely different.

Michael Dubakov, founder of TargetProcess wrote a pretty thoughtful post a couple of months ago called: Speed in Software Development.

It starts with a debate about sustainable development speed and a neat idea about structuring iterations more like interval training. But the part that I really liked is his bold attempt to map out the interactions between all the factors that ultimately affect development speed:

map2

It’s followed by a thoughtful discussion of the different factors and some actionable ideas on how to address them.

I think Michael can potentially be on to something very interesting here, but it also left me with two big, unanswered questions which I’ll address to you:

1. Is development speed really the ultimate goal/metric? Michael incorporated into his framework some of the typical contenders like quality, complexity, tech debt, etc. But is it really as simple as that?

2. How can it best be measured in a way that’ll encourage the right set of behaviors?

 

Speed in Software Development

Effective Delegation and the Product CEO Paradox

Itamar, Leave a comment

I’m in the mood for covering another great post by Ben (I promise to not have three in a row). This time it’s:

The Product CEO Paradox

Which Ben succinctly describes as: “The only thing that will wreck a company faster than the product CEO being highly engaged in the product is the product CEO disengaging from the product”

The challenge here, as Ben puts it: ” You must transition from your intimately involved motion to a process that enables you to make your contribution without disempowering your team or driving them bananas.”

He prescribes 4 key activities that CEOs much continue to maintain:

  1. Keep and drive the product vision
  2. Maintain the quality standard
  3. Be the integrator
  4. Make people consider the data that they don’t have

And 3 supporting tactics:

  1. Write it, don’t say it
  2. Formalize and attend product reviews
  3. Don’t communicate direction outside of your formal mechanisms

Now here’s the interesting thing: into those key activities and supporting tactics the word CEO is never mentioned, and the word product is only mentioned twice.

That’s because Ben’s advice is applicable in a much broader scope than the product CEO paradox – it’s phenomenal guidance in any delegation situation.

The general version of this paradox is: The only thing that will wreck a business function faster than its leader being highly engaged in its function (read: micro-managing), is the leader disengaging from the function”. 

Replace “product” with the business function that you’re responsible for, and you have Ben’s recipe tailored to your specific  use case.

Sounds easy? It’s not! Can’t say that I have it fully nailed down in my business function.

Any other effective delegation advice that you can share?

Effective Delegation and the Product CEO Paradox

Titles: Andreessen vs. Zuckerberg

Itamar, Leave a comment

This is another “oldie but goldie” from Ben Horowitz:

Titles and Promotions

In this great post, Ben first establishes that the best way to mitigate the Peter Principle and “The Law of Crappy People” is by having a clear and disciplined promotion process that’ll maintain a consistent quality bar for people sharing the same title across the company.

He then turns to deal with the tricky issue of the size of titles: should your most senior Product person, for example, be titled Chief Product Officer? or simply VP of Product? perhaps even Director of Product for this matter?

He proposes two approaches:

The “Andreessen Approach” – takes an economic view to titles and argues that of all the different asks employees make of you company, this is one of the cheapest ones to grant. Furthermore, it allows your to keep title in your arsenal. to be used as a tie-breaker when competing for talent.

The “Zuckerberg Approach” – intentionally grants titles that are lower than the industry standard as a way to avoid accidentally granting new employees higher titles and positions than better performing existing employees. It boosts morale and a sense of fairness, acts as a forcing function for managers to deeply internalize the promotion process, and creates a self-selection component in the hiring process.

Though Horowitz seems to side closer with the Andreesen camp, I personally side closer with the Zuckerberg camp. First, because I place a big premium on its benefits (self-selection, reinforcement of clarity, fairness). Second, because I think that there’s another dimension in this comparison that Ben overlooks:  as I mentioned when I discussed Turning Your Team, we’re naturally going to find ourselves in situations where people have not scaled as quickly as their roles and we need to hire above them. But in many cases, being able to do so while keeping the original employee with the company can have tremendous benefits. With an “Andreessen Approach” we don’t leave any “title whitespace”, and therefore force the existing employee to either take a formal demotion, or leave the company. And since we’re all prone to loss aversion, the latter is much more likely to happen.

But Ben’s final thought is the one that matters the most: Regardless of which camp you’re in – titles and promotions matter. A lot. If you won’t spend enough time thinking about them, your employees will (obsessing about the resulting inequities).

And therefore, my question to you is: which camp are you in? Team Zuckerberg, or Team Andreessen? 🙂 And seriously now: what have you found to be the key principles of an effective promotion process?

Titles: Andreessen vs. Zuckerberg