I recently experienced two of the most informative and useful meetings of my life. Lloyd Taylor, the former VP of Technical Operations at LinkedIn, and Olana Khan, the former COO of Kiva, graciously donated their time to speak to us about how to organize our technology goals. We had been in the process of formalizing our thoughts for an upcoming board meeting, but their expert feedback allowed us to cement in some much-needed structure. In addition, we also were given invaluable advice about how to lead an effective technology team in general.

Preface – Agile Development

First, I should set the stage by describing our new development process. Because Samasource is a tiny organization with no shortage of exciting new ventures to pursue, we adopted an agile development framework. This idea has gotten a lot of traction, and Eric lead us through the implementation. He actually wrote up a monster post about it on his blog, but I’ll briefly summarize here.

We divide our attention into short sprints, each lasting one or two weeks. Sprints represent all of the tasks that we will be focusing on during that time, and allow us to keep our minds off of other distractions until it comes time to organize the next sprint.

Each sprint is comprised of various user stories, which encapsulate a qualitative end-goal. For example, one user story from our first sprint was “Website Visitors Understand the Mission and Trust the Org”. What this does is it allows us to focus on the real impact that our work will be making. We will not be blindly executing tasks from stale to-do lists, and will make sure that each project has tangible impact.

And each user story is made up of tasks, which are small, discrete items of work that take a short amount of time to complete. This allows us to quantify the work that will be done.

This system of agile development allows us to be flexible from week to week with what we prioritize, ensures us that we are working towards a real goal with measurable impact, and breaks the work down into bite-size pieces. With this basic system in place, we can begin talking about business organization and the steps we can take to make the engineering team as effective as possible.

1. Set Clear Priorities

At Samasource, and nearly all other startups, the list of things we want to do is ten times longer than the list of things we can do. Another way to look at it is that you can do anything but can’t do everything. The first thing you need to do if you want to be focused and productive is to clearly establish a system for prioritizing. Take the time to think about what the organization’s overall mission is, and align all engineering goals with the organization’s goals. The user-stories in our agile process help us do this, as we can always keep the big-picture objective in mind.

Each organization is going to have different objectives and different ways of prioritizing, but the point is to be clear about what those methods are, be deliberate in assigning priorities to different objectives, and to be ruthless about cutting out low priority items. Some important questions to ask are, can the company survive without this feature? How does this affect our bottom-line? Does this item relate to any organizational bottlenecks? I’ve tried to organize our projects into 4 categories:

1) High priority items that either fix bottlenecks or have high return on investments 2) Medium priority items that would be great but aren’t necessarily killing us 3) Low priority items that would be great but that we could do without 4) Items that don’t immediately affect business processes but are essential steps towards achieving high-priority goals.

Once you have the system in place, run every idea through it and be certain of what your main priorities are. You need to be sure that your time is being used in the best way possible.

2. Be Clear About Costs

Building things takes time. No matter how passionate or incredibly talented you are, at some point you’re going to have to say that you can’t do it all. This is perfectly reasonable. The important thing is how to communicate this information, and how you prioritize your time with that idea in mind.

It is your responsibility to be clear about what the cost of each project is, and also to be upfront about communicating this. If there are two high priority items that will each take 4 full days to complete, you won’t be able to finish both this week. Creating a concrete and dependable system for allocating engineering resources will make it easier to make this point. It certainly should be formatted more as a mathematical fact, and not as a reflection of the engineer’s ability. And if something ends up taking longer than anticipated, or if an unexpected issue comes up that needs to be taken care of, this needs to be realized as early as possible. There is room for flexibility in a sprint schedule, but making changes early is far preferable to explaining later why a deadline was not met.

Once you have a system for establishing priorities and costs, you will have a strong ability to set determine immediate goals for your next development cycle. High priority items with low costs will obviously be at the top of the list, while low priority items with high costs will need to be reevaluated. Determining your goals for the week becomes a logical exercise in cost/benefit analysis, motivated by actual numbers. Being systematic about these decisions makes things more efficient, but it also gives the management team a solid framework for motivating decisions. The rationale behind decisions is far easier to communicate, and everybody involved can be on the same page.

3. Run Short Development Cycles

Our sprints generally last one work week, and give us a compact set of objectives that we can focus on. If you’re only looking a week into the future, you have a short list of user stories that you are concerned with. Because you took the time at the beginning of your sprint to prioritize your projects, you don’t have to worry about that during the week. You can focus entirely on the list of items in front of you, and sprint forward with confidence.

A specific benefit of keeping the cycles short is that if something new and distracting comes up, you will be able to postpone its evaluation until the beginning of the next cycle. Most things generally can wait one week before being acted upon, and nothing hurts productivity more than having your head constantly turned in different directions. With the proper systems in place, the management team can also feel comfortable with postponed action on new opportunities because they know that these will be given the proper attention soon, and that items with a high priority will be acted on at that time. Again, the point is to organize your processes into reasonable, formalized systems that match your schedule and allow you to work effectively.

4. Sharpen Your Saw

This is in reference to a point that Steven Covey makes in 7 Habits of Highly Effective People. If you are a logger, you will not be able to cut down more trees by simply sawing unceasingly. The loggers who get the most work done are those who take the time to step away from trees and sharpen their saws. Software engineering is no different, and you must set aside time from feature-building for maintenance.

For example, our system at Samasource follows a simple structure. Every fifth sprint or so, we will dedicate an entire development cycle to maintenance and optimization. Reducing time of page loads, cleaning up stale code, and rewriting functions to be more efficient are all examples of things we might do during these maintenance cycles. This is something deserving enough attention that you should formally set aside a significant amount of time to do it. Also, as often as once per sprint we will set aside a day for catchup and fixes. There may be small website upgrades that don’t find their way into weekly priorities, or there might be small bugs in some recent code that requires attention. Small things are bound to fall through the cracks, and the best way to keep them from piling them up is to regularly attend to them.

5. Respect yourself

I know I run the risk of sounding self-serving, but I do believe there is a message here unrelated to ego. Programmers tend to be perceived in a similar way as construction workers. “We know what we want built, and we’re paying you to build it. I don’t care about the details of how you do it as long as the finished product is what I had in mind, and the sooner you finish, the better.” But the discussion needs to be more than just that. Software development is an interesting field because the bulk of the work that goes into a project is invisible to everybody else. It is doing a disservice to everybody involved to not bring more of the process to the surface.

There’s an art to showing the amount of work that is being done, and it’s especially important for tech people to convey this information accurately. The aforementioned processes for organizing your effort will make it much easier for non-technical people to be on the same page. Breaking down ideas into discrete tasks allows everybody to understand what is being done to achieve a certain goal. An engineer’s time is both valuable and finite, so everybody will benefit from a solid understanding of where that time is going.

Conclusion

These ideas represent the current state of Samasource’s tech team, and I think that this exercise in strategic organization has been invaluable. These processes are a work in progress but I believe that they’ll allow us to grow rapidly and work effectively. I’d love to hear your feedback on these ideas, and whether you incorporate similar principles at your workplace.