It’s a beautiful moment when someone you manage comes to you and says:

I moved forward with this hard/important decision by myself without blocking for approval or advice because:

We were aligned on vision/outcomes,

AND

I had the necessary decision-making tools/framework for reasoning about complex issues like this,

AND

I was empowered to do so without fear of any consequences from my manager.

On this occasion, the person that is providing the feedback to the leader, has decided to rise to a leadership role herself:

Everyone has potential to lead, It’s not something you are, or something that you necessarily get training on, or a role that someone assigns to you.

Leadership emerges at the moment between a problem arises and someone says I am going to solve it. — Nick Caldwell

“Use agile principles, not practices”

Quote taken from Author Q&A: from Chaos to Successful Distributed Agile Teams and applies to any domain, not just Agile.

One of the biggest challenges occur when experienced agilists try to apply the same practices to distributed teams as they do for collocated teams. A typical practice like the retrospective can become complicated and painful depending on the distribution of your team members and their hours of overlap. Instead, we recommend going back to principles and looking at how the practices you want to use were trying to apply those principles. How might the principles suggest different practices for your context to achieve the same goal?

In my experience, people that get too much stuck on “practices” (=ceremonies), in any domain, don’t have a deep understanding of the “principles”.

Example: When I was a Java developer I was stuck on the Sun Microsystems “best practices” about what Enterprise development was (“J2EE orthodoxy”), and after coming across the book “Expert One-on-One J2EE Design and Development” by Rod Johnson, creator of Spring, realized that what I considered as the right way to do things was actually the opinionated approach of a handful of people at Sun.

In the original quote, try swapping “agile” with your domain and see where that takes you:

- Use Sales principles, not practices.
- Use Marketing principles, not practices.
- Use Online publishing principles, not practices.
- etc, etc.

What fundamental assumptions would you challenge?

Partnership and collaboration opportunities can be very beneficial to your organization and/or personal growth. But exploring these opportunities can feel awkward if they are approached as an unstructured chat over a cup of coffee.

Here’s a small framework that could help these exploratory discussions to happen more efficiently:

• Research the other party: Feel free to ask the other party for data before the meeting and be proactive providing data about your organization or yourself. Every collaboration is based on trading differences, and that depends on the willingness of both parties to share information.
• After the initial research fill-in the Needs & Offers board and ask the other party to do the same. Being upfront in writing about expectations will not only help you uncover opportunities that might not be obvious, but it also helps create “connectedness” and trust between the two parties—even before the meeting occurs.

• Come to the meeting having studied the other party’s needs and offers carefully.
• During the meeting use the board as a foundation, but not as a restriction. Through the discussion, focus on value-creation—i.e. identify outcomes that improve mutual welfare beyond what is in the board.

Coming prepared to such a meeting and being creative can uncover opportunities that were not obvious before!

(Image source)

A few months ago I got a demo from a company that provided lead gen services to customers and I had to turn them down because I was not comfortable with the practices they used for collecting personal info. Even though there would have been no liability, I still chose not to work with them as a matter of principle.

When faced with ethical choices like this my rule is to think about the following points before making a decision:

• Legacy: Would you feel bad if this is something you’d be remembered for?
• Publicity: Would you feel bad going on stage to admit doing it?
• Reciprocity: How would you feel bad if others did this to you?
• Trusted friend: Would you feel bad telling this to a close friend or family member?
• Universality: Would it be bad if everyone in the world did this thing?

Having issues with any of these points is a sign you may be compromising your principles.

The way I used this framework in that meeting was the following: I asked myself “if we used this service, how would I feel about getting up on stage and telling my customers about where we got their data?” And the result was to turn them down.

(Inspired by “Ethics and Negotiation: 5 Principles of Negotiation to Boost Your Bargaining Skills in Business Situations”. Image source.)

Here’s one that I really like that uses high school physics and feels intuitive:

These are 5 things to considerwhen evaluating UI/UX (designs, flows, apps, etc.):

• Visual rhyme: Usually vertical and horizontal alignments.
• Accessibility: Is it easy to read and recognize all elements?
• Affordances: Does the UI offer clues about how it should be used?
• Mistake-proofing (“Poka-yoke”): Is the user protected from trivial mistakes?
• Defensive design: Are consequences of mistakes minimized?

Bonus point: Try to identify early if the stakeholders' team goes into bikeshedding mode, and push the discussion forward.

5 Things to Consider When Evaluating UIs was originally published in NYC Design on Medium, where people are continuing the conversation by highlighting and responding to this story.

If you are having challenges managing you tasks, here’s a short list of tips that can change your life!

1. Get familiar with GTD

Getting Things Done is a time-management method described in a book of the same title by productivity consultant David Allen. It is often referred to as GTD and contains some very insightful ideas like separating the actual collection of tasks from the actual process of prioritizing, categorizing and adding dates, etc.

Even if you choose not to implement all of them, I promise that GTD has the potential to change your life.

2. One inbox (and only one)

Having messages comes through many channels — email, social, IM, RSS, etc — might tempt you to keep different list of tasks. You might have some of your tasks in email only, some in the IM platform of your choice, etc.

This is a very bad idea! You need to have a realiable system to be capturing all tasks in one inbox.

For macOS users I recommend OmniFocus and I’m sure Windows users can find something similar.

3. Don’t use app-specific “starring”

You might be tempted to use starring or similar functionality that your email client or IM tool supports.

Again this is a bad idea and leads to poor task management and ultimately frustration.

If something is a task -> it goes in your inbox.

4. Easy task creation: Ad-hoc

Whatever tool you use it needs to support easy creation of ad-hoc tasks. Whatever you do, you need to be able to enter a new tasks in your inbox within 2–3 seconds. If it’s more than that then it becomes an obstacle.

With OmniFocus, every time I need to create a new task, I only have to click Ctrl-1 for a modal to pop-up, enter the description and click enter.

5. Easy task creation: Inside the browser

You need to be able to create a task from a webpage in a single click. For most tools there is a browser plugin (example) or bookmarklet to allow you for that.

These should automatically be capturing the title and the URL of the page, so you don’t lose time copy-pasting.

6. Easy task creation: Inside Slack

Many times tasks will come from your IM of choice and if this is Slack, then you only need to copy the URL and create the task (see).

7. Easy task creation: Mobile

You need to have a system for creating tasks on mobile too. What ever tool you use make sure it supports mobile for tips 4, 5, and 6.

8. Easy task creation: Voice commands

If you’re big on voice commands you might consider a tool that supports them.

E.g. in iOS I can connect Omnifocus to Siri via Reminders.

9. Easy task creation: Inside GMail

Using the tip from 5 you can easily capture tasks inside GMail.

But I would avoid any GMail plugin that does tasks management, because my experience in the past has shown that the various GMail views tend to take many seconds to load and any task management tool needs to work super fast.

10. You solution vs. your company’s issue tracking

“How does my task management solution compare with the issue tracking my company uses (JIRA, YouTrack, Trello, etc)?”

The system your company uses is for high-level alignment and transparency in the organization. It’s not as flexible or fast as it would need to be to support any task management use case you’d need, and it’s not meant for a personal task list.

Feel free to share your ideas about tasks management, e.g. the tool you personally prefer or how would you go about implementing these principles on Windows using Outlook tasks, etc?

Also if you found any value in this post I would appreciate it if you would consider donating to UNICEF — even a small amount can make a huge difference in the life of a child and every child deserves a fair chance in life.

A few years ago I had worked with an experienced designer/UX person that has taught me a very quick, but powerful UX/marketing test which I refer to as the Bistrian test — Bistrian was his name.

This test applies well to both UX elements and marketing messaging and it’s very simple.

It goes like this:

• After observing the dominant UX element/message, or
• Reading the first marketing message sentence

…imagine being the user and say out loud:

“Why the f@#$ should I care?”

There is something magical in that phrase that maps perfectly to the short attention span of the user and relentlessly challenges your copy or design decisions.

Free your mind — challenge product “best practices”

I’ve always felt a little uncomfortable when people use terms like “best practises” or “industry standards”, and this post is about a real world example of why everyone should be cautious of such claims.

One of the tools that are often mentioned in the context of growth hacking is life-cycle emails (aka “drip emails”). These are usually employed for user on-boarding and aim to raise the awareness of the user for your product and potentially let him in to features he might not know yet. Life-cycle messages are mentioned in Dave McClure’s popular “Startup Metrics for Pirates” presentation which you should read if you haven’t already.

Here’s for example how the life-cycle emails are setup for ft.com:

Recently we decided to try out these for InfoQ and although at the beginning the plan was to just launch them, at the end we decided to approach this as an experiment and see if they were truly valuable for our case.

The experiment was setup in the following way:

• We (*) altered the registration process, so that half of the new registrants would receive life-cycle emails after their registration.
• The other half, would not receive any (null hypothesis).
• The system would inject a Google Analytics (GA) custom variable in both cases, so we could later on segment any reports and see differences in usage, retention, etc.

During the time the experiment run we had around 10k registrants participating the experiment and randomly being distributed between the two buckets. The hypothesis bucket got a total of 5+1 email messages during the period of several weeks.

The result

Although the users that got the life-cycle messages generated some additional traffic from the links they were clicking inside those messages, overall the total amount of traffic and sessions were (statistically) equivalent.

In simple terms, even if we launched this feature for all our users it wouldn’t make any difference to our bottom line.

If the numbers were even just a little better we’d probably try to optimise and try out different message formats, but they were not. And I guess this is inline with my personal experience with the messages from ft.com — I got them but I still won’t visit their site unless someone tweets about them.

So are “best practises” wrong?

Of course not! But are worth nothing without context.

In 2009 I was lucky to attend Stefan Tilkov’s “Thoughts on the Generic vs. Specific Tradeoff” presentation at QCon London. In a room packet with alpha geeks Stefan compared XML vs HTML, SOAP vs REST, etc outlining the advantages and disadvantages of each solution, showing that there is no certain answer to an architect’s quest without context.

One of the phrases Stefan used a lot during that presentation was “it depends”.

Is X better than Y? Is practise Z a best practise? Well, “it depends”.

At best one can find indications of “smart” practices that promise solutions that may or may not work for a given situation.

Stay skeptical, stay doubtful

In your product’s lifetime — especially if it’s a mature one — there will be very few things that will move the needle significantly: you might launch a mobile site that increases the number of mobile users, you might stumble upon a single killer features that your users will be crazy about, or even one of your competitors shutting down might send you lots of potential new users. But unlike what some growth hackers bloggers are suggesting, most of the times your online product will grow slowly because the growth initiatives you take have a moderate impact. Considering this and also how many different ideas you might have it’s essential to be disciplined in testing your hypothesis and only pursuing what works for you.

Specifically you should:

• Not take “best practices” for granted and test if they work for your audience.
• Evaluate your alternatives with as much data as possible.
• Your “gut feeling” is good. Data is better!
• Be ruthless with the features you build; if they’re not of real value, put them out of their misery — fast.

Further reading

• You Should Test That: Conversion Optimization for More Leads, Sales and Profit or The Art and Science of Optimized Marketing by Chris Goward.
• The Lean Startup by Eric Ries,

(*) Kudos to Anca from our marketing dept for coordinating, and Mircea from our dev team for the implementation of the experiment.

Disclaimer: The views expressed on this site are my own and do not necessarily reflect those of my employer.