This is life… in Trello

I used to be just like you. I used to have a mass of notecards, Post-It notes, and Evernote checklists. While I used to be unorganized, and lost I am now focused and organized. How did I do that? How did I manage to know everything, and travel through space-and-time with minimal effort? Let me take you on a journey of self-discovery and self-awareness. Let me tell you about…


A five-bin kanban system

Kanban is a well known tool for dependency management. Just ask Google about how you use it on software development! I’ve modified this three-bin system into a five-bin system. My bins are time-based instead of dependency-based. They are as follows: inbox, later, this week, today, and done.

Inbox

This is a dumping ground for all of the little tasks that need to be prioritized. Quick notes can also end up in here like “you should write a blog post about how you manage your life.” This is a tool to make your e-mail less of a todo list, and more of a communication tool — I believe in no e-mail in your inbox but am not an Inbox Zero zealot. Did someone ask you to do something while you were focused elsewhere? Add a card to the inbox bin.

Later

Do you have a list of tasks you need to eventually to take care of? The later bin is for tasks that don’t have a deadline, but need to be tracked or are going to take a big more work than you can support right now. An example card in this bin might be ‘re-architect pgbouncer infrasctructure to run on Mesos.’

This Week

There are tasks you know you need to get done this week because of a deadline. Do you have a presentation to prepare for on Friday, and it is Monday? The this week bin is perfect for that card. The work in this queue is generally prioritized by being moved into the today bin on the day I will have time to handle it.

Today

The today bin is the prioritized queue of work you will complete between 00:00:00 and 23:59:59 of the current day. This queue is prioritized when your day begins, and is empty when your day ends. This is the meat and potatoes of getting things done.

Done

Cards for tasks that have been completed are moved into the done bin. If Trello is your tool of choice at the end of the week you can ‘Archive All Cards In This List’ to start the following week fresh.


Tracking multiple focuses

I have a very basic labeling system to be able to quickly glance at what needs focusing, as well as what needs filtering. I have three labels in Trello. ShopKeep, Family, and Personal. While your labels may differ you must be able to deterministically label cards.


Prioritizing

Don’t be afraid of cross-prioritizing. There are only so many hours in the day to focus on and you need to find balance. Spend 15 minutes in the morning making sure things are properly labeled, and bined. Finding time to re-prioritize is key here. Things come up! Nothing is a “stop what you are doing and refocus” event so a lot of these are dropped into the inbox bin. Trello has mobile apps, and you can use those to quickly add cards to your inbox on the go.


Evernote vs. Trello vs. Notes vs. Paper

Any tool can be used to keep track of your cards, and bins. Find a tool that works for you and use it to power your life.


In conclusion

Quickly, and efficiently viewing your day as a work queue will help you be more organized, and more focused on what you need to do. You will find yourself having more clarity into your efficiencies and inefficiencies. Be retrospective on what you did, and didn’t do. Be retrospective on what you can do and you find yourself accomplishing more towards your goals.

Past performance not indicative of future results

If you’ve spent any time reviewing the outlook of an investment you will recognize this statement. This statement is so that an investment firm can show you how well they’ve done, while protecting themselves from a failure to produce similar results for you. Could we not draw a corollary between hiring and investing?

Hiring is making an investment in human capital, instead of monetary capital. When hiring we tend to review resumes, code samples, and ask questions digging into someones past to see if they are a fit for what is needed. Is this really the best way to make a hiring decision?

Knowing what someones past performance could mean for their future would make you a very wealthy recruiter. Giving someone the chance to show what they are capable is key. Are they capable of working nights and weekends when everyone else is? Are they bought into the processes? Do they contribute the best they can, or are they earning a buck? These are questions we always ask ourselves as hiring managers. These are timeless questions around hiring.

The solution is simple: we don’t know. What we do know is the risk or cost of bringing someone on to a team, giving them a shot and that attempt failing. It is a cost. As hiring managers, you must weigh the potential or upside of that cost. Have they not written a perfect binary sort in their technical interview? Does that fact outweigh their desire to go the extra mile? Does it outweigh their desire to grow and learn how to build the best software with the tools and knowledge they have today?

Give someone a shot at showing you that there are more qualities to a hire then their ability to bend to your interview process. If you give them this shot, you’ll discover a huge trove of amazing people to help build your teams around.

Always Be Cap Deploying (ABCD)

To be successful, in a fast moving startup we must move away from maintenance windows, and scheduled downtime. The team I am currently working with has been beaten into submission, and now deploys multiple times a day. This has allowed us the peace of mind to fix, iterate, change, and break production all in minutes. The idea of continuous deployment is not a new thing, nor a fully conquered problem.

You must decouple your services from your database, you must have lots of tests, and you must code review like a boss.

Sharpen Your Focus

As developers, we have keep too much in short term memory. When was the last time we integrated with master? When was this feature supposed to be turned on in production? Where are we? Who are we? With all of these questions, the addition of social networking we are far too distracted to be as efficient as we should be.

Since the introduction of ‘Do Not Disturb’ across the iOS/OS X framework I have come to know, and love it. It has freed us from the bounds of push notifications and the binding chains of e-mail. Turning it on, you are now notified quietly in the background about what is going on in your eLife. Before this functionality, we were bombarded with Facebook/Twitter/Instagram/LinkedIn/iMessage/Email notifications that are distracting more times than not.

Please allow yourself to break free from the hell that is synchronous notification. All of the tools we use are only as good as how we use them. You simply cannot bring yourself to deleting your eLife, so we have to learn to live with them inside the workflow of our daily life. ‘Do Not Disturb’ is one such way we can all do this successfully.

‘Do Not Disturb’ should have been named ‘Do Not Distract.’ We speak a lot about context switches as a bad thing in our software, so why could it be a good thing in our minds? Stopping these context switches will allow you to sharpen your focus on what matters. Perhaps right now email matters, which often times it can, you won’t be distracted by Twitter telling you that you’ve been followed by a cat.

Do ourselves a favor, work less distracted for a day. Silence all notifications and simply focus on your tasks. We will find out that perhaps push notifications weren’t such a great idea when it comes to productivity.

Keep in mind that your mileage may vary with this. I’ve come to find that it is so useful to allow me to sit and be focused on the task at hand, and then when I am ready I can switch my context to either the next notification that is waiting or something else entirely. My productivity has gone up since utilizing this tool. Many others like it exist, but my iPhone is my information hub so ‘Do Not Disturb’ is exactly what I use and love.

Simplification

As a consultant, I have to track my time. I have to track the amount of time that I work on every project in a single day. On days that I am not on-site with a client, I will jump from project-to-project across six active, busy projects. Tracking time is a solved problem. There are a plethora of apps, web apps, and tools that you can use. I won’t list them here, but search for ‘time tracking.’ I’ve titled this blog post ‘Simplification’ because I’d like to talk about how I track time.

The tools that I’ve successfully used to track time for the last year and two months listed: iOS Clock.app. That is right! I only need a single, built-in app on my iOS device to track my time. A simple, one function stop watch has allowed me to track all of the required information correctly, and accurately.

Stopping the clock, jotting down that information in our billing software before switching to a new task also gives a few needed minutes of respite from thinking. It is like eating ginger between sushi pieces. Cleanse the palate of your mind, figuratively.

But I digress, this post really isn’t about how I track time, or cleansing your palate but how we can all simplify our tools and still be successful, albeit less distracted day-to-day. Do we need a super-duper tricked out ZSH, or can a well appointed Bash do the same job? Is managing an entire directory of vim configurations better than using just the default code highlighting?

Progress will tell you that we’ve come to find that simplification isn’t needed. Amazon will sell you anything made, and have it at your door within 24 hours. While this an incredible service, does selling everything make them the best at selling everything? Is a greater scope of service conducive to greater quality? I argue, maybe. iTunes for instance is an example of something that is one-stop shopping, but it really doesn’t do all of those stops perfectly. Search for instance is a constant issue. Discoverability is also a problem.

What if iTunes was broken into iApps, iBooks, iVideos, iMusic, and each was given the directive to perfect that field. I would be willing to bet that simplifying each project, without affecting the overall feature set would allow Apple to create better, more useable products. As a side note, I realize that Apple has figured this simplification out at the hardware level, but not the software level.

Simplification is hard. It is difficult to do less. It is easy to add more features that will attract more customers, and in turn generate more revenue. I propose that we stop thinking of simplification at the macro-level, but at the micro-level. This will allow companies, like Apple, to have five pieces of software, which each is perfectly suited for it’s task instead of a single piece of software that misses the mark across the board.

Circling back to consulting, I see this conundrum often. We have ten features, and five developers to build them. Each developer is then required to build two features. This means that they will only be able to devout fifty percent of their time to each feature. Would it be better to do five features, across five developers so each can focus fully on each feature? From the macro level, you’d see that half of the work was done in the same amount of time, but from a micro-level the quality of work could potentially be twice as great.

We must simplify everything. Whether it is the tools we use, the features we must complete, or the products we are building, simpler is harder upfront but with the long-tail gains — success should be synonymous with simplification.

Fix It Later

Here is a mindset I’ve come across recently: ‘fix it later.’ In a culture of resourcing, waterfall-ing, and lackluster performers, fixing it later is exactly status-quo and is exactly what is wrong with your software project.

If they, reasons nefarious or not, don’t want the project to be workharder to make the project better they should be removed post haste. Pushing back because it is hard, or the task is annoying should be grounds for removal. Keeping in mind that the change should be well intentioned, and actually beneficial to the team. An example that I’ve come across recently is adding our internal gems to the continuos integration server. These gems are internal to the entire organization, not just our team. This code is shared, and these other teams have a right to know where the code stands.

Stepping off of my high horse for a moment to talk about my shortcomings, I will say that sometimes I don’t want to work on building out new infrastructure, or refactoring all of the view tests to run on webkit instead of Firefox but I do it. I grit my teeth, bite the belt and pull it together. This is why I am paid as a senior developer, this is why I am put in technical leadership positions. People trust me to do the right thing regardless of cost to my persons. Not pulling it together is a failure as a developer personally, and a failure as a team member. You fail, and the team will fail because of it.

No one really wants to work on technical debt. No one wants to put aside a shine-y new feature using all the coolest toys to make the CI server run better, but if no one does it it will not get done. It is your job Mr. Senior Developer to do it. A junior developer probably doesn’t have the skills either interpersonal, or technically, so it falls to us to swallow that pride and get it done.

This is a mindset I learned as a front-end developer that I carried over into the world of DevOps, and technical leadership. Internet Explorer sucks to write CSS for, but we have to. You have no choice. We must, as people, get our mindsets in line with doing what is best for ourselves, for the project, and for the team. They must align. You will grey, you will have high blood pressure, and you will suffer blows to your will to live but at the end of the day you’ve made things better for the entire project, the entire team, and you’ve gained important experience.