Bill Clifford, Chief Revenue Officer, SessionM.
Bill Clifford, Chief Revenue Officer, SessionM.
At the end of every work day, before my head hits the pillow, I document all major objectives and accomplishments by day in a file called ~/sweller.plan. Any mission yet to be accomplished makes its way into the plan for the next day.
It makes me feel good, no matter how challenging the day was. I find it very calming and a good way to decompress.
Religiously, my .plan is the first thing I look at every morning when I’m sipping my cup of coffee. With this I assemble my “not until” list.
My “not until” list is a list of duties and tasks that must be done before I take on what I perceive to be less important things. Before I scan Twitter, before I start responding to email, before I pull up that interesting article everyone in the office is sharing, I focus on the big impact items first — the ones that drive the most value when accomplished.
This routine has kept a bunch of things in check for me.
1. It helps me to avoid falling into the trap of using email as a productivity tool.
2. It keeps be focused on the most important tasks at hand.
3. It creates a sense of history, revealing to me the missions that are truly driving momentum and making an impact.
While I originally got the name “.plan” from John Carmack, my approach is different in execution.
If you are starting a company or are working for a startup, I highly recommend adopting a regiment like this.
It’s extremely helpful in keeping you focused on the mission.
Besides being the most talented drummer of all time, Dave also reveals in this interview that he is really down to earth and human.
Love his point about being yourself no matter what and not caring too much about what other people think is cool.
It certainly can weigh you down.
Years ago I hiked a section of the Appalachian Trail called the Mahoosic Notch and did an overnight at Speck Pond.
For those of you unfamiliar with this stretch of the trail, here’s what Wikipedia has to say about it:
Mahoosuc Notch is a deep gap in the Mahoosuc Range of western Maine, traversed by the Appalachian Trail. The boulders on this mile-long section of trail present obstacles that must be climbed over and sometimes under, creating a unique hiking experience. There are occasional ten-foot drops, and places where packs must be removed to squeeze beneath a boulder.
Many thru-hikers call this stretch one of the slowest on the 2,179-mile (3,507 km) trail. This so-called “killer mile” or the “Toughest Mile” is a very tough section that can cause even the most experienced hikers to slow down. There are good spots to pitch a tent on both sides of the Notch.
Due to my inexperience, I ended up hauling about 70 pounds of supplies on that trip. I packed way too much stuff. Food. Clothing. Ropes. Extra shoes. Hats. Coats. Sleeping bag. Tin cans. Gas. Cooking gear. I had enough for three weeks in the woods and was only trekking for three days.
I was a pack mule while other more experienced hikers breezed by with no more than a small backpack and a sleeping mat. Even those who had been hiking for more than 4 months thought I was on a long haul.
I laugh when I think about how beat up I was after this short trip. It was really quite silly and entirely because i planned for too many contingencies.
I realized recently that this trip is a great metaphor for product development. Sometimes, as an engineering team and product team, you can be carrying around unnecessary baggage — you can be planning for too many contengencies.
The baggage comes in many forms. In the form of contengency features you keep around for the “what if” and functionality that may enable some future perceived value, or maybe tools you are building that will make you “more scalable in the future” but introduce a dramatic amount of unnecessary complexity into your daily work-flow.
Startups can throw you many curveballs. New paths to follow. Daily challenges to solve.
Speed and agility are necessary. Constant experimentation. Building quick feedback loops. Fast releases. Constantly iterating. This unlocks the truth around if your hypothesis is correct, or if you should be headed down a different path.
I find it so important to take some time every so many weeks to find select features, tools, practices, processes that must be killed at all cost. By removing the extra baggage, you will find clarity in the data you collect, you become more focused on what works best and most importantly, you become far more speedy and agile.
After all, hungry Black Bears love the chase when you have 50 lbs of gear and 20 lbs of snacks on your back.
66% say no way!
Got a question? Ask millions of mobile app users. http://insight.sessionm.com
Got a question?
Poll or survey millions of mobile users via http://insight.sessionm.com.
As a technical founder you want the best team on the field.
As a peer you want to work with only the best. To be challenged, to be strong, to learn, to be quick and to be successful at delivering a top notch product.
Early stage teams tend to hire by consensus. Multiple people from the org interview, question and test the candidate. There is the white-boarding session where you dive deep on technical competency. There is a post-interview meeting of the minds. There is a vote. The candidate is either in or out, with a heavy emphasis on technical competency.
I have found that consensus on technical competency alone can lead to bad fits. If this sounds like your interview process, I have found two elements you can add to help find the best fit for your early team.
Ask two simple questions to your team post interview.
"Do you want to be assigned to a project with this individual?”
The equation changes when you have to think about working side-by-side with someone. You start asking yourself questions that go beyond technical competency.
Can you depend on them? Do our personalities click? Will we be productive? Can this person follow direction? What’s their track record with collaboration?
This is good, you are making the hire personal, which is super important for everyone involved.
"Who needs this individual on their team.”
In our org, we are a hybrid matrix org that starts with domain specific teams. SDK, API, Data, Platform, Front-End, Dev Ops, etc.
Interview people with the notation they may fit across the org. Ask your team-leads this question post-interview. Now teams are lobbying for where this individual is best suited.
Some team leads will want this individual more than others, some not at all. Does everyone think this individual is a technical rock star but no one wants them on their team? Good. You just weeded out a bad fit.
Along with personalizing the interview process, you just made it competitive as well.
Maybe a bit more fun too.