We have a lot of custom tools at SEER but I didn't build any of them. The SEO team built them.
As SEER's programmer, I created the "building blocks" they use to create their own tools. In less than 15 minutes they can make a small tool to respond to any immediate problem. They don't need a programmer because they make it happen themselves.
Here's my story about how I'm helping to build an agile team with my code and "put myself out of a job" (so to speak).
Save people's time. By any means necessary.
When I started at SEER I was told that my job is to save people's time using any means possible. I'm a programmer, so I'm good at writing code that automate repetitive work. Things like collecting CSVs, merging data, creating reports, or tabbing through dozens of websites to check client metrics.
During my first few months on the job, I was getting to know the SEER process and interviewing employees. I asked them lots of questions like:
How do you do keyword research? What's that spreadsheet do? Why did you download that CSV? How did you merge those two datasets in Excel? What do you have to report to clients? What does Wil want to know from you?
I also sat behind them for an hour and watched how they used their computers. Then I asked: "What tool could I make that would save you the most amount of time?"
Too many tools. Too little time.
The requests came in. Lots of them. So I started writing code. Lots of it. And with every tool I wrote, I saved a little bit of time. That made everyone happy. This was great until about 6 months into the job. I realized I made a big mistake. Each tool only solved one use case. Eventually, there would be too many tools and I wouldn't be able to maintain them all.
Yes, I wrote reusable code to save me time (programmers call it a "class" or "module"). But I knew every tool also came with some level of maintenance. And as with any program, it's never if something breaks, it's when. If it's not broken, then someone needs a slight tweek to fit a new use case. Add our company's growth rate and now you have a scaling problem.
What do you do? Ask to hire another programmer? I've only been around for 6 months. That seemed like a ballsy request at the time. I wasn't going to go there. Even with a few contract programmers, the problem still existed. Too many tools, too many to maintain, not enough resources. Contractors can only take you so far and there are some other risks involved. The code was showing signs of wear and tear with my inbox filling up with, "Hey, XYZ is broken. Can you help?"
Create leaders... by putting yourself out of a job?
Then, I remembered something a really smart friend of mine told me:
"I'm constantly trying to put myself out of a job." - Jared Byas.
That was his weird way of saying, "Teach people everything you know so they can become leaders too." (Or maybe he hated his job... Leadership sounds better... I'll go with that.)
He trained leaders at his previous organization by giving away all the tools and knowledge he had. Today, he's a university professor helping to create future leaders.
Does that mean I should teach people how to program? No. Most of them don't want to learn how to program because it's not what they love. They love SEO. They love marketing. That's the right seat on the right bus.
Instead, I created tools that our team combines to create their own tools. I thought, instead of giving them something fully assembled I gave them a pile of lego bricks and teach them how to put them together to make whatever they want. The idea is to help others solve their own unique problems. I should not solve it for them. I should not be their bottleneck.
Helping people do the stuff they love.
Does that mean more work for them? Yes. That kinda sucks. There's a learning curve involved but the payoff is much greater than the total investment. Here's one example:
Pulling SEOmoz metrics for a large list of URLs. Internally we use the one of tools I publicly released (Seomoz for Google Docs). Down column A is a list of URLs. Down column B you can get all the Linkscape metrics for each URL. The first time around, it might take 30 minutes to learn how to setup the macro. If they did it manually using the website, it might take 20 minutes. Net time savings: -10 minutes. The next time around it will take 5 minutes. Net savings: 15 minutes. Multiply that a few times a week... then a few times a month that turns into 4 hours a month. They love spending 4 hours to diving into real research than 4 hours of "click, control-c, control-v." Copy-paste is a pretty boring job. We want to get to the stuff we love.
Infecting the system... from the inside.
With anything in an organization it took time (about 3-4 months) to train people and gain widespread adoption. I originally launched it like a viral marketing campaign. (Hey, this programmer can still learn a few new tricks too!). I singled out a few people at SEER who I thought would really get value from the new tool. I introduced the new building blocks to them them individually and show them a few common uses for them. When they had questions, I tried really hard to be available to help them.
Then... maybe a month later, they would present a small tool at our company show-and-tell meeting. First, they showcased a client problem, then how they solved it using their custom tool and shared it with everyone. Everyone else would give it a try it after that. Soon within a few weeks, a few new people would try making their own custom tools. Within a few months, it would achieve widespread adoption. For our culture, this strategy actually works every time. Best of all, when other team members had questions about the tool they had other people in the company to ask for help. Yes! I finally put myself out of a job! The job of building one-off tools.
Creating agile teams by getting rid of myself.
This post is not about our awesome tools (although, we have awesome tools). This is about one way of helping our team be agile. With their own little tools they have speed up or automate their own workflow. When a new problem came up they can think about ways to solve it more efficiently. Then... they just make it happen.... for themselves. They don't need a programmer to slow them down. It's an agile team. That's how I put myself out of a job of creating one-off tools and put myself into the job of saving people time by any means possible.
-- You can find me on Twitter @djchrisle
