Category Archives: Management

How To Use Your Unfair Advantage To Create an Unforgettable First Day For New Hires

Posted on by

commerce-sciences-starter-kit

Let’s say that you’ve just hired Emma, one of the most talented [title goes here] on the face of the planet! How cool is that, right?!

If you’re like most of us, you’ve probably prepared a powerful (mac)laptop and a gigantic, cinema-size screen waiting for her arrival. But you didn’t stop there, haven’t you? You smart, devilish-fox…

You also came up with one or two tasks she can do on her first day at work, maybe even considered to let her press the BIG RED button and deploy her work to production. Anything you can do to make her feel frighteningly productive, eh? Nodding your head?

I’m sorry to burst your bubble, but you’re doing it wrong.

People want to connect with people, not with todo lists

Even though feeling productive is a strong emotion, it is also a short-lived one. In order to create a long lasting emotion, a real WOW effect, you have to create a personal bond.

Research has shown that a person’s mood can be affected even by 3 degrees of separation from people they don’t even know. That’s right, t-h-r-e-e. Do you remember feeling utterly ecstatic because a task of a user-story of a feature smiled at your direction? Nope? Nothing? Bingo!

It’s time to pull out your secret weapon.

airbnb-secret-weapn-their-team

 AirBnB’s secret weapon

 

Do you remember the slide of which investors drool on? The one with those smiling faces of people trying to have fun and build things? “Our Team”, you refer to it (others may call it holy-f$ck-what-a-bunch-of-geeks), and this, my friend, is your unfair advantage.

Ever wondered how you can use this handsome bunch of people to create an unforgettable first day at work for your new employees?

“Your job is to bring down the walls”

I really like the way Roy Klein, our newest secret weapon at Commerce Sciences, puts it -

You’re job at the first week is to bring down the walls and let new teammates talk and get to know the team. If they’re good, they’ll be effective anyway, so don’t worry so much about it. Find ways to make them connect. Eat lunch out every day together, play some Team Fortress 2. Whatever works!

Some ideas to get your brain ticking, your heart pumping and your face doing some funky stuff

Make them smile

To fuel your creativity, let me share a personal story. Five years ago, after getting a super talented engineer to agree joining the team at Delver, I wanted to make sure he’ll have an awesome first day.

I was so excited to have him with us that my mind was spinning like crazy, figuring out how to make it a memorable first day.

About a week before he joined, I saw on Facebook that he raved about Let’s Say You’ve Gone Back in Time poster. “Ahh!”, I thought, “I can purchase it and have it framed!” This is exactly what I did, having it hang above his workstation, waiting for his arrival.

Ask your team to be creative, to go crazy, to give away some loovvvvve

If you know that your new guy or gal enjoy playing a game, say Startcraft 2, maybe you can buy a miniature and place it on their table, with a little note “We’ve got your back! Attack!” Or, if your new hire is a part of distributed team, send them a barber shop quartet to sing her a song.

It’s time to pull some Nicki Minaj craziness to show them you were waiting for them!

Make it a company tradition

We have a little tradition, where the last person to join the company is responsible to create a “starter kit” for the next one to join. No rules, no guidelines, just your creativity, time and effort. It’s something that started before I joined, and it blew my mind on my first day at work. What a day!

8 months ago, when Omri joined the company, it was my turn to prepare something for him. Luckily, I had the chance to sit with him for lunch before his official arrival. We had an interesting discussion about our shared interests and how we’re both fascinated by “brain hacks” – figuring out how our brain works and how we could utilize it better. I remembered a great book I read called Your Brain: The Missing Manual and thought to myself that it would be a great welcome gift to give him. I knew that 5 years from now, when Omri opens this book and re-reads my dedication on the first page, he’ll remember his first day with us. It wasn’t much of a starter kit (yes, we had his working station ready as well ;)), but it was something I thought he would appreciate. I hoped it would make his first day with us memorable.

When our latest teammate, Roy, joined us, it was Omri’s turn to prepare an awesome starter kit. I forgot to mention that Omri is our marketing hero and by far the most creative dude on the team. The box you see at the top of this post was made by Omri, and was waiting on the table for Roy when he arrived. It was filled with jokes, coffee capsules, nerf-gun ammo (don’t ask) and above all, Omri’s personality.

Passionate about #culture and #people?

Check out my latest side-project, SoftwareLeadWeekly.

Your turn!

Do you have a story you can share about how you WOW-ed your new teammates? I’d love to hear from you in the comments.

Teammates First Deadlines Second

Posted on by

“Am I investing my full attention in my team’s deadlines at the expense of leading by example?”

Deadlines, by nature, create a powerful feedback loop, where you get rewards such as external recognition from your boss/peers and internal ones by removing a task from your To-Do list and going home feeling “productive”. Due to their visibility and ease of measurement, most managers prefer to invest their time in keeping deadlines, instead of exercising their leadership first. By entering the “deadlines loop”, it’s easy for your teammates to feel that you’re only pushing more work into the pipeline, rather than being someone they can actually follow and rely on. It’s a rhythm that is hard to break without intentionally taking steps to put your teammates first.

Even though you’ve got plenty to prove, one of the things that should be on your mind when you’re managing people is how you can engage them in a way that will make them respect you and earn their trust.

Start with setting the tone and lead by example

The idea is to gain trust by drawing on values your teammates will appreciate:

  • Get to know your people better: Treat each feature and each task as an opportunity to learn something new about your teammates. Pair Programming and Code Review are great ways to check for coding style, provide feedback and have a discussion. Make sure your teammates include these tasks when setting a deadline for a feature. Use your time together to learn which parts drive them – is it the code? architecture? new language? performance tuning? the discussion itself? the product?
  • Show them they can learn from you: Many times you’ll find yourself thinking “I could do it twice as fast” while asking for an estimation. It may be because you’ve got some expertise or (more often) you simply have a better ability to visualize the required work, thus better estimating the time it will take. Take this chance to do some pair programming: break it into tasks together (so s/he could learn from you) and my secret trick – create dependencies between the tasks, so you’ll be waiting for each other at the end (solve it by introducing interfaces and mockups so you could both work). This creates anticipation to prove to each other you can nail it. When the mockups are replaced with real code, you’ll have fun laughing if something breaks down, run mutual code-reviews and ship it together.
  • Define what “beautiful code” and “beautiful documentation” means in your team’s context: There is nothing worse than having a “religious debate” while deadlines are keeping your team working around the clock. From my experience, you should prefer using business concepts such as “beautiful code makes it easy to add new features on top of it” versus “beautiful code has 95% code-coverage” or “beautiful code has up to 5 methods per class” (here is my definition, slides 32 and 34, use it for reference but always prefer your own). Next time you sit with one of your teammates, you could say “I think the design you made for the feature is awesome *and I want it to be super easy to add more features on top of it later on. I’m not sure if we need the abstraction you suggest at this point, I prefer to see 1 or 2 more usages before we’re adding abstraction layers. I’m afraid we will build something that will make it harder to add things as we move forward, just because we’re lacking more context and real use-cases. What do you think?” 
  • Build expectations with your boss: One of the most underused tools available for you as a manager is your own boss. There is no one more passionate to see you succeed than him/her. Learn to explain why you prefer delaying a deadline and show the value you are hoping to gain – “I know that we should have completed this feature today, but I feel there is a great lesson here my teammates can learn and I want an extra day to do some retrospection and improve parts of the code. I believe it will improve their work in the long run“. Your manager, like you, has an interest in building a long-term A+ team. That means sometimes you will both need to sacrifice short-term wins. Having honest discussions with your boss, sharing your experience and asking for guidance can provide you the oxygen you need. My advice – ask your boss to tell you when s/he think you’re too focused on short-term deliveries. It will do wonders to your 1:1 sessions. 
  • Self-retrospection is not a nice-to-have anymore: I’ve written before about building a framework for improving your management skills and I highly recommend setting a 1 hour recurring meeting in your calendar once a week just for you to reflect on your work (early morning of the last day in the week should be ideal). Use it to ask yourself again “am I too focused on my deadlines or am I building confidence within my team?”

 

What do you think? Got more tips about setting the right balance between short-term and long-term team building? Would love to hear from you!

* always replace “but” with “and”, a great tip from Bill Gross on How to give GREAT employee feedback

———————————–
If you enjoyed this post, I’d be humbled if you’d follow me on Twitter.
photo credit: Alan Cleaver

My secret trick for Proactive Leadership

Posted on by

For some, the term “Proactive Leadership” means being aware of gaps, obstacles and faults before it becomes noticeable to others. The problem though, is that noticing a problem and even taking care of it, doesn’t mean you’re being perceived as proactive leader.

Let me explain – do you remember the last time your boss jumped by and said something like “you noticed that X is stuck right?” or “what are you going to do about Y?”.

“OF COURSE I DID!” you reply, “I’ve talked with Joe, and he’s taking care of it”.
This doesn’t feel like you were perceived as proactive leader right?

Proactive leadership is about being communicative when you spot these faults, as soon as they happen. So here is my secret trick – next time you see it coming, follow the “I’m on it” template:

TO: [relevant people: your boss, your peer, your teammates etc.]
Subject: Saw that [gap], I’m on it! (EOM)

For example:

To: myboss@mycompany.com
Subject: Saw that Joe left angry today, I’m on it! (EOM)

I tend to add EOM (“End of Message”) if it’s a short status update. If you feel that you’ve got more to add to this email, feel free to add to it, but never wait with the first email! It’s perfectly fine to use something like “Saw that [gap], I’m on it! More details to follow… (EOM)”.

Being communicative will reduce the need of your boss, peers and teammates to double-check everything with you. They will get custom to the ritual of “when shit happens, she’ll raise a flag”. This is how proactive leadership should be – being aware, communicative and setting the tone.

Now I pass it to you – which tricks are you using to let everyone know you’re in control?

———————————–
If you enjoyed this post, I’d be humbled if you’d follow me on Twitter.
photo credit: TORLEY

Why using roles and permissions internally? Trust died?

Posted on by

In almost every management tool out there, there is a sophisticated roles and permissions system that allows you to pick what your developers / product manager / project manager can or cannot do with the system. “You can move a Feature to In Progress only if your Team Leader authorize it”, “Only product manager can create new Feature”, “Only Project Manager can start a new Sprint”. I see it happen sometimes also in source control tools “You can commit only after your Team Leader checked the ‘code review done’ checkbox” or “Only Team Leader can commit code”.

Again, this is an internal system being used inside the organization!

I think it’s a destructive and counterproductive approach. People will stop using tools that are making them less efficient. If I know that only my Team Leader can commit my code, I’ll probably commit once a week or once a month as I cannot sit and wait for him every 10-60 minutes that I normally commit. Same goes for management tools. People will not use the tool to its full potential, if they’ll need to send emails such “can you please create this feature for me?” or “can you please approve this feature so I could start working on it?” What’s the point? I can create tasks in my OneNote or excel file and keep moving from there.

This way, data becomes less relevant, less honest, less up to date. You should trust your people to act smart and train them to utilize tools better.

How do I recover from disasters?

two words – backup system. Usually it’s really simply to backup your data every X hours (or minutes) and rollback if disaster occurred. Your people will get better as they’ll practice more often, get feedback from you and adjust. This will prevent disasters from happening to begin with. Backup system should allow your teammates to practice often, this is their safety net. Don’t use roles and permissions to create virtual trust or avoid personal headaches. At the end of the day, it will cost you more.

Sprint Planning versus Version Planning

Posted on by

Should you start with planning your sprints and then see how it fits your versions? Maybe start with versions and understand how your sprints look like? Maybe planning versions by themselves is enough? How do you start?

Decouple external planning from internal planning

External value (features your customers will enjoy) moves the organization. It is why you get paid. No one will pay for “let these kids develop for fun only”, this is why open source projects were born, for developers to write some code that may or may not be used by others. Versions are communicated out to your customers, named in a language your customers can understand “in version 1.0 we will allow our customers to upload their profile image” rather “we will integrate jQuery and develop highly scalable upload mechanism over Amazon Cloud”.

Internal value (features your organization will enjoy) keeps the organization fully operational, doing its best over time. It is usually not communicated out (your customers don’t really care if you’re using C# 4.0 or C# 3.0) and not named in customer’s lingo.

Versions are more tangible

Most of us stick to planning versions and our sprints actually look the same as our versions. We’re results oriented and we want to please our customers. Moreover, no external power is actively pushing us toward internal value.

Sometimes internal value > external value

If you’re strictly results oriented, you might produce great results but only for short, unpredictable periods. Sometimes you’ll need to delay customer’s value to handle broken “machine” in your factory. Your customers won’t like this delay, but they will understand it if you’ll offer tradeoffs and communicate “we are fixing internal machine to keep our high level of production steady”. They will prefer stable producing rather than insane, poor quality or unpredictable results.

Use Sprints to prioritize internal value with external value

Maybe you can devote 5% of the sprint to maintain your ability to produce fast? Maybe 10%? Maybe 1%? It’s really up to you to figure out what you want to push every sprint. Be careful of dismissing internal value, it’s your role to actively push for it.

How do I start?

I prefer to set some goals for my sprint first: (a) is there an internal value I want to push? (b) Are there people in my team that I want to push by leading features? (c) What is my team availability for this sprint?

With this in mind, I’m starting to plan my versions for the sprint and next one, making sure I understand perfectly what should enter the sprint and when. This is the first time I validate my plans. If the planned versions fully occupying my sprint (or even more than that), I raise a flag and trying to figure out if something can be shifted without causing damage. If not, and I have some “buffer”, it leaves me with understanding how much of my internal value I can push inside the sprint, alongside external value. This is the second time I validate my plans. Did I manage to push my goals to the sprint while producing external value? If I notice there is a big need for internal value that cannot wait, I will try to understand alternatives with our product team and supply tradeoffs.

Then, all is left is to organize when should each feature start/end and making sure external value (versions) are released on time while internal value is keep moving. Keep your head above the water, plan to last.

Should you allow changes during Sprint?

Posted on by

Sprint is a planning unit, keeping it stable during that time allows a pretended piece of mind for the developers from marketing/product ever-changing demands. So it feels anyway. We developers signed up a virtual contract with our product teams saying “we will be Agile enough to allow you to change your mind every 1-3 weeks, but don’t disturb us during that time! We want to work, not wasting our time on talks!”.

Does it make sense to you? Is this the true notion behind Agile? Would it be acceptable for a great business?

Well, it makes sense only if you think that waste is more valuable than your attention. Delaying smart decisions or cutting off bad ones after 2 weeks, 2 days or even 2 minutes is simply counterproductive. If you know that a feature selected for the sprint became a waste due to priority change, why should you move forward with it? why throwing the problem to the other side of the fence: “well, my product team should have been wiser with their priorities. We’ll do it anyway just to teach them a lesson so they won’t do it for next sprint!”

Priorities tend to change. It happens constantly. Don’t panic, be open-minded and make sure your team leaders can handle priority shift. It’s perfectly okay to say no, but make sure it’s a “reasonable no”. If you see it does make sense to move out some features and move in some others, do it with care, offer tradeoffs (“this change might mean we won’t be able to release the version on time, let’s delay it in 2 days”) and make sure motivation passes to your team. Your teammates need to realize that providing organized waste is plain dumb; they also need to trust you doing these changes with full attention, clarifying tradeoffs and setting expectations. Practice your agility!

Why tracking actual work hours is so imperative

Posted on by

After bashing prediction systems, claiming that measuring performance of your teammates to predict release dates or personal behavior is inherently wrong, you might deduce that I meant “measuring Actual Hours is pointless”. On the contrary my friend, I believe that tracking Actual Hours is imperative for better planning and cutting off waste.

Translate internal units (Story Points / Ideal Days) into external units (Calendar)

How can you translate a 3 Story Points or 3 Ideal Days to “it will be ready next Tuesday”? By using the actual time it took to perform a task or a feature, you could actually see a correlation between Story Points size (internal to the organization) to the total amount of actual work hours range (external as you can put it on the calendar). For example, you might notice after a few sprints that 3 Story Points (based on latest 5 features), are usually taking 23-28 actual work hours to complete. Assuming you pick a number, say 6, as the amount of “effective” work hours in a single day, such features will translate to 4-5 working days.

Story Points can be translated quickly, based on empirical knowledge, to a range of working days. This will make release dates predication much easier, assisting your Project Manager and your marketing team to communicate it within their roadmap.

Tracking your actual work hours will help you to quickly balance effort in a Sprint

You’re on the first day of the Sprint and you’ve got seven Features (/ User Stories) in your “Not Started” column. You also made sure that your teammates’ availability is updated as some have vacations and some got exams during the sprint.

How can you balance your tasks effort, in hours, between your teammates?

By looking at your actual work hours history, from the example above, you can see that a 3 Story Points feature translates into 23-28 hours of work. You can immediately add to all features worth 3 Story Points one task called “TBD” with 25 (average) hours and assign it to one of your teammates. That way, you can add a “TBD” task to each one of your features, simply by checking their Story Points -> actual work hours range.

Next, you slowly break these big TBD tasks, in each feature, into multiple smaller tasks, each with different owner and estimation, until you see that the effort is balanced between all of your teammates. When your team is mature enough, they can break down their tasks and provide their own estimation at the beginning of the sprint.

Two flows for example:

a. 3 Story Points (range: 23-28 hours) -> 1 task worth 25h for Joe -> 1 task worth 10 for Joe, 1 task worth 5 for Jim and 1 task worth 10 for Annie.

b. 2 Story Points (range: 10-18 hours) -> 1 task worth 14h for Jim -> 1 task worth 10 for Jim and 1 task worth 4 for Annie.

c. [ … until all work effort are balanced by availability and optimal ownership … ]
d. Make sure that your breakdown makes sense in terms of people availability. Make changes if needed.

Summary

Tracking your actual work hours is imperative as it (1) provides a way to translate internal work units to external work units and (2) enable fast estimation of large features. The key is to clearly explain how using internal estimation can help with these goals. Asking your teammates to remain open and honest about their actual effort (versus rough estimation) requires a lot of trust from their side. Don’t break it and don’t use it against them.

Story Points over Ideal Days?

Posted on by

Many teams going into Scrum, have internal debates around whether or not moving to Story Points or sticking with Ideal Days. It seems that there is a lot of personal feelings involved.

Ideal Days – what is it all about?

Just imagine a work day without any meetings, phone calls or people bothering you. It’s a full day of making things done, full day working solely on your tasks, whatever that means.

Story Points – what is it all about?

Story Points are a bit more abstract notion. It includes 3 parts: Work Effort (how much effort the work will take), Complexity (implementing known yet complex code) and Risk (3rd party integration, POC required etc). It inherently abstracts away the “who” to allow you to consider the “what”.

Estimation is expensive

I’ve said it before – estimation is expensive. You should find ways to make your estimation faster, unless you were specifically required to execute the Feature or bringing a super detailed estimation. If it’s not the case, and you were asked for numbers to determine Product Roadmap or feasibility of features, stick to fast gut feelings, may it be private hunch or collaborative hunch.

Fibonacci size – what is it all about?

To make estimation faster, it’s easier to have smaller list of options to pick from. For example, instead of picking a size from 1-100, you should pick from a smaller numbers range, like Fibonacci: 1,2,3,5,8,13 and then go to 20, 40, 70, 100. Why the jumps? Because the bigger the estimation, the bigger likelihood of being wrong or wasting too much time discussing how wrong. So instead of arguing on whether it’s 6 working days or 7, you just pick 8 or 5, depending on the specifics (effort, complexity, risk). The purpose is to estimate fast, not to be 100% precise.

Using Anchors

Usually, the idea is to price Features (or User Stories) against other Features *like* them. “This feature is around the same effort as that feature so it will be 3 Story Points as well”. After picking a few Features as “baseline”, it’s easier to estimate faster others features against them.

Ideal Days baggage

I personally believe that Ideal Days brings too much baggage into the discussion (making estimation slower):

1. Who’s Ideal Day? How long is one Ideal Day? Each member will consider her/his Ideal Day. Instead of focusing on fast estimation, everyone passing in their head “well, Joe is new in the team, it will take it twice as much! Let’s price it as twice as much then”. Story Points “don’t care” who is implementing the Feature. This is exactly how it should be done as you never really know who will actually be the implementor until you start working on it.

2. Ideal Days are not strongly correlated with estimating Complexity and Risks: People have in mind, when using Ideal Days, mostly effort involved. Story Points, due to its abstraction level, allows better focus on Complexity and Risk.

Matter of flavor, I guess

Anyway, I feel that it’s not really important whether you’re using Story Points on Ideal Days, as long as you (1) remember to price Complexity and Risk as well; as long as (2) you understand that estimation is expensive. I feel that Story Points offer better abstraction which allows faster estimation, but it’s really matter of “whatever works”.

Write down Estimation Reasoning!

Make sure you keep your estimation reason. “We said its 5 Story Points because it’s ~3 Story Points for effort and ~1-2 for Complexity and Risk. We felt good enough with 5 Story Points.” Why? If you would like to use this estimation as an anchor in the future, while trying to estimate a new feature, you should remember what the original 5 Story Points meant for you: “Was it 5 Story Points only because of effort?”

Experimenter’s bias kills software predication

Posted on by

“In experimental science, experimenter’s bias is bias towards a result expected by the human experimenter.” – Experimenter’s bias, Wikipedia.

Almost every management tool out there attempts to provide estimation regarding when the feature / user story / version / release will be ready. Fogbugz took it to extreme with their Evidencing Based Scheduling, others such VersionOne and Mingle use pretty graphs or other visuals to achieve the same.

“Computer, when it will be done?!”

I think there is an inherent paradox with such prediction – it depends on developer’s honesty. You must ask yourself what is the developer’s incentive to fill the information as it is? why should she or he be honest? The way I see it, developers are staying in their safe zone, pricing things in high enough granularity (around 8h or more per task) and fill the actual or remained hours so they won’t look bad or good. They just want to be right. Why? So they won’t appear as too optimistic or too pessimistic to the prediction system their boss is using to plan the next few releases. It actually makes sense; the predication system caused the results to behave as expected by driving developers to “safely” play with the numbers. The actual, somehow, always equals to the estimation! How nice!

The second you’re telling your developers that their estimated and actual hours are being used directly to predict the future, don’t be surprised that it will be the future they want you to see. This is why I’m not convinced about using Actual Hours for readiness prediction or judging if a teammate is over optimistic/pessimistic.

As a team leader, you should care that your teammates will learn to estimate better, to allow themselves to be wrong, without everyone to see it on their prediction tools. They need to make mistakes and get personal feedback. People over Tools !

Why should you still use Actual Hours then?
More on it to follow…

Why should you strive for moving Features to done?

Posted on by

If Sprints are not execution unit, what is the rush of moving Features to done as soon as possible during a sprint? Why should you care about it if you’re not limited by end of sprint deadline?

Other than the fact that done is fun ™ (obvious sense of accomplishment), striving for done features will push the entire team to excel. I’ll try to cover it from two angles, manager and developer.

Nothing new, you commit to version instead of Sprint

The only difference of introducing versions to decouple execution from sprints, is that you commit to version rather than sprint. So far, no big change, you need to release on time to allow fast feedback by your customers. It’s the same “Agile attitude”, the same fuzzy feeling in your tummy.

From Developer’s point of view

1. Prefer small amount of WIP (Work In Progress) – we are poor with multi-tasking and we hate to get back to things we thought we already finished. If you aim to move Features to done, you can be more confident moving forward without leaving some concerns behind you.

2. Practice Growth – the more features you’re estimating, breaking (into tasks) and leading, the more you’ll improve your communication and leadership skills. Because all of the above is so hard to get right, you need to practice as much as you can to feel comfortable leading bigger features over time and later on, if desired, leading your own team. Great leaders not only know how to push features but they also can explain to others how to get better at it, to share feedback. For that, you’ll need to practice enough, to reflect enough, until you really grasp the complexity behind it.

From Team Leader’s point of view

1. Prefer small amount of WIP – you should prefer 7 features done from 9 planned rather than 15 features in progress from 20 planned. You cannot deploy half-baked features thus 15 features in progress means zero value to your customers.

2. Create predictability by making Velocity graph stable - If you want to plan your sprint faster and with more confidence, you’ll need to understand how many Story Points / Ideal Days you’re able to do each sprint. For that, you’ll want your Velocity graph to avoid spikes every sprint (example: 30 SP, 2 SP, 87 SP, 40 SP) but rather have a “stable” Velocity graph (example: 30 SP, 27 SP, 34SP, 29SP). Constant spikes mean that you won’t be able to say how many Features (by Story Points) you’re able to perform. Less confidence => more time spent on planning.

3. Create predictability by making Features Size Completion stable – again, if you want to plan your sprint faster, you’ll need to know how many big / medium / small features you’re able to pull off every sprint or every version. Try to strive for known throughput per feature size to increase confidence.

Planning Sprint, just like estimating features, might be very expensive and hard to nail down. The trick is to create solid picture that strengthen your gut feeling about what you can actually do. With this in hands, you’ll spend less time breaking everything to little pieces or worry about the quality of your plan; instead, you’ll have solid empirical history behind you to back you up. More time for you to get some tan!