Session Transcripts

A live transcription team captured the SRCCON sessions that were most conducive to a written record—about half the sessions, in all.

Big Ambition, Small Staff, How the F*** Do I Prioritize?

Session Facilitator(s): Rachel Schallom, Tyler Machado

Day & Time: Thursday, 12:30-1:30pm

Room: Thomas Swain

All right, guys, if you could take your seats.

OK, while you’re getting settled, I’ll go ahead and introduce us. My name is Rachel Schallom, I’m the interactive editor at the Sun Sentinel, which is in south Florida, and we are doing a session because about two years ago we started doing what we would call digital storytelling which is basically where we said maybe we shouldn’t throw everything in the CMS, and over the last two years in the beginning, you know, we were like begging people to work with us, and then it kind of blossomed and then we started getting a lot of ideas and we needed some sort of processing/managing all of these expectations, but up until two weeks ago, the interactive department, which is what I refer to in memos to sound important, was actually just me.

[laughter]

So I’ve learned a lot in the last two years. I basically started this department and have watched it grow and need a lot of love and so we want to talk about the issues that come with being really small and working by yourself. Yeah, I’m Tyler Machado, I work at Harvard Business Review in Boston. I am the only coder on my team. I’m part of the editorial team, but my title is web developer. So I work on, yeah, interactives and dataviz, and that kind of stuff. We have a separate design desk and a separate tech staff that actually makes the website work and so I can grab them on an ad hoc base basis, but most of the time I’m the center of that particular universe, and Rachel is going to go first, but I’m going to go second, talking about kind of managing my own projects, and learning stuff when you have no one to learn off of and you don’t have much of a community in your newsroom on a tech perspective. So yeah, go for it.

Yeah, so we’ve gone over all of the rules in all the other session, be kind, be courteous, don’t use jargon. The only thing I’d like to remind you is that in this session we’re going to talk a lot about managing other people, managing expectations and I want to remind you that this is a live transcription, so let’s not try to talk shit on our bosses. Just use someone I know. Like “someone I know.” But this is on the internet. Norma: Oh, the pressure!

It’s all right, Norma. They’re not Googling themselves yet.

Basically the way we’re going to do this is we have a bunch of questions, we want to then open it up for discussion so feel free to cut us off and feel free to raise hands. I’m a pretty loud person, everyone can hear me, right? How do you communicate with our others who don’t share our jargon. So this was a really big problem when I needed to estimate time or talk about my ideas, with—I work for a legacy newspaper, so a lot of those people are older and they don’t understand the internet and they’ve been doing what they’ve been doing for a very, very long time so when you need someone on your side but they don’t speak the same language, it can be very difficult. So my biggest tip is finding common ground through analogies, like what do they do on the internet. And an example I have is there are some open source tools that are really easy to use and they became less scary when I told people that they were just as ease as uploading pictures to Facebook, and they’re like, OK, I know how do do that, so if you can find common ground, that usually helps. Don’t make assumptions about what people know, especially young people. I am blown away by people in their 20s when I am talking and they don’t know understand what I’m saying and so that has been a really big epiphany for me, and that age really has nothing do with digital literacy.

Sorry they don’t know what you’re talking about techwise or conceptwise or?

Pretty much techwise, I end up having to explain a lot more than I thought I would. Whether that’s just explaining terms like open source. 20-year-old reporters did not know what that meant and so that was a really big eye opener had in digital literacy that you can’t really look at someone and say yeah, they’ll know what I mean and then there are older reporters who have attended hackathon and know exactly what I mean. So don’t make assumptions. Teach jargon whenever possible, so I try and take opportunities instead of just dumbing everything down, to teach them and learn as we go. So right now we are having a 404 contest. Our 404 page is really boring, and living in south Florida is a very not-boring place, so we wanted it to reflect our community a little bit so it was a really good opportunity for me to teach the entire newsroom, what is a 404 page, so whenever you can, without being condescending, those opportunities, because now I’ll be able to use the 404 jargon moving forward.

And then my last point is help them give feedback, so we do these things called project reviews. I don’t know why I acted like that was a fancy name. Where we’re very project- and investigation-based, so we do a ton of long-term stuff, so about 48 hours, 36 to 48 hours before publication, we send the finished digital link to the team for feedback and in the beginning I was just getting typos or I’m having second thoughts about this lede, and then I would finally get to sleep, and right after publication they’d be like oh, yeah, this link doesn’t work and that doesn’t work and we were like why weren’t you doing that during the review period and so we started coming up with a checklist of things that I wanted them to look for, so broken links, usability, open it on your phone, trying to share it on social, we found that if helped guide people, they gave us much better feedback. So those are my points about communicating about jargon. Who else has experienced this? I’m sure all of you have been in a meeting where it hasn’t gone well or that there’s a barrier there. Does anyone want to give an example?

We echoing analogies, I’m pretty sure that’s the only way we communicate, to the point where it’s become kind of an internal joke for us. We just simplifying it down to even core concepts, we talk about, we have 19 websites, but we talk about them like sheds in our backyard and how we want to take all those sheds and build like an aircraft hangar instead and that’s just some of the things we do because it does become so crazy when you’re—for us, we have radio, as well as 19 visual sites, so trying to bring that all together because I don’t understand how the radio works. So the digital site. So I think analogy is the best way to deal with it.

I have the problem a lot of time where I—oh, and please introduce yourself.

I’m Allie Kanik. I work for Public Source in Pittsburgh, PA. I have a problem where I’ll go through a whole spiel and I’ll get to the end and that makes sense right? And the person will be like no. And OK, what don’t you ever understand and they’re like, no. So I’ve found that it’s helpful to stop often in your spiel, and be right? You good? Questions? That helps to not take twice looks it ought to.

Absolutely.

Alex; I work for Newsela. Being super-patient is really, really key. You really the risk of souring communication if you’re abrupt or rude or how do you not know this? You’ve worked in this field forever. It’s really important to keep your head, because otherwise you’re never going to get your point across.

And I think with that, there are a lot of what we could view as opportunities, so I once—we have the system where when something is ready, you email the home page and you can put it on the home page and I did that with a map and the guy running the home page said why would I put this the home page. This isn’t a story. And we were having this huge debate and I was like really frustrated because we’ve been over this so many times but we were in the middle of the newsroom and I was like OK, this is your opportunity, man, like make your pitch and so with other people staring on that’s an opportunity to be like no, this is why we do this, this is our core principles, and so even individually taking those opportunities to kind of get people on your side can really help.

I just want to point out, Michael Grant, San Francisco Chronicle, I’ve noticed that on projects that I’m developing, you know, editorial will come up with a name for, you know, maybe like a drop-down, or you know, but the naming conventions are different than you know of something that I’m building versus what they refer to them as, and it just becomes a bunch of emails and things that Slack is getting rid of thank God, but it really kind of slows down the whole process because we’re talking about sometimes two different things or something that we thought we were talking about, and it’s just horrible. So I think outlining, you know, instilling that we should refer to certain areas as this and defining what we’re calling things makes a huge difference.

Screen shots help with that, too. It’s just describing what you mean is sometimes like, well, what thing that drops down from where but if you’re like screenshot, this thing, then that helps, I’ve found.

We once had a 30-minute spiel of why we wanted to get rid of the drop-down and just going to a hamburger icon, we realized after 30 minutes that no one knew what a hamburger icon was, so prototypes, sketch, screenshots, all helpful things.

Kate; I’m with the Minneapolis Star Tribune, and I really like that you made the point kind of don’t assume to know what people’s knowledge and skills are. One thing that I’ve found really helpful just with managing teams is creating a culture where questions are encouraged and they don’t feel stupid for asking and kind of leading by example, and even larger infrastructure projects that we do, where I go what’s a CDN you know or something like that, even as the project manager, I think can open that up and definitely those projects have been the most successful where people feel like they can ask questions, ask why do you recommend that we do it this way and offer suggestions. So.

The one thing that I also noticed was post mortems, you often don’t really have time to to do them but when we did, we were able to say why couldn’t we have approached it this way and that’s led to a number of projects that never would have happened otherwise. So once we started to do that for major projects, we found that producers and reporters were like, oh, well, this is possible now and we can do this next time and it will make it easier and faster. I think that was a big thing for us, as well.

Absolutely, we do post-mortems on the process, as well, because each project usually has a different editor or this is a reporter’s first time doing something long-form and so it can be a struggle and one of the things that I do in my process reporting as, you know, the project manager and the designer who gets things at the very end you experience some of the most frustration in the process is that I write some of my notes to myself while I’m still mad. So I’m remembering everyone who didn’t make deadline, so you know, this terrible meeting that was two hours and nothing came out of it and then I’ll sleep on it for a couple of days and then I’ll write my post-mortem notes and my boss suggested that because after a while you start to forgive and you like the project that came out of it and that doesn’t do us any good moving forward. So sometimes make notes that made you really, really angry and use them later once you’ve had time to sleep on it a little bit.

So this is a huge one for us. How do we temper editors’ expectations. We started our interactive department the year we won our first Pulitzer prize, which made people really, really hungry for more prizes and really hungry to do things that were cool and innovative and got our name out there and when you’re a department of one and people have huge expectations. I kept getting asked why I couldn’t fill Snow Fall, like seriously, over and again. This became a huge problem for us. A couple of notes is don’t finish early, at least in the beginning. So time estimates are huge for us and them taking our time estimates seriously meant sticking to what we had. So maybe you give yourself a couple of extra days just to make sure because with development you never know what’s going to go wrong and then for them to take you seriously, you have to hit in about that amount of time and I don’t just mean hit your deadlines, I mean don’t finish early, because if I’m on a project and I say it’s going to take me five days but I get done in three, and the next time I say I need five days, they’re going to be like, she only really needs three, and we found until you have this process a well oiled machine, stick to your deadlines and just hold it, you know, just pretend you’re still working on it or QA or ask for feedback, but don’t make it harder on yourself in the future by finishing earlier.

This is on the internet, remember, so the secret is out.

[laughter]

My bosses won’t be here.

Don’t commit to something you’re unsure about. So in meetings when someone’s like, I have this grand idea and I want to do this, even if it’s a really bad idea, you know, sometimes I use phrases like I’ll look into that. I try to avoid committing to anything I’m not totally sure about.

And use data whenever possible to make decisions, so I review all of our project’s analytics and we try to learn as much from them as possible and then I try to use them to make my arguments stronger. So if we told a story a certain way and it had really low engagement, and I think that’s not the way to go in a future project I’ll bring that up so instead of it just being my opinion it’s the data speaking, as well, which can strengthen. So data is your friend. So I was wondering if anyone wanted to share a story about work everything with editors and expectation, because the point of the session is, you don’t have a lot of resources, so this is a pretty big one for us.

Sarah Squire, Wall Street Journal, but small, I work by myself. One thing I found is actually sometimes editor’s expectations, they think something is really big but it’s really easy. Sometimes I don’t pitch projects because they think it will take a month and sometimes it will take two days to do, and then you get to the point that you want them to pitch everything. Explain that they don’t know how long something will take.

Where we used toing often this thing where it’s like OK, on this date we’ll have this done and then on this date we’ll have this done. I have started switching to a this part of the project will take this many days, which has helped a lot with the editors’ expectations because whenever something doesn’t get done on time, they can be like, well, why isn’t this done on time and I could be like well, I told you it would take 4 days at this time, John Schmoe, you know, Joe Schmoe? Didn’t have his data to me until a week like he said he was going to, I’m still taking four days here, but it’s just being pushed back. So that’s helped.

One. Bernard, I’m content strategist at a place called green America. I got really good at doing hourly estimates and I pad my estimates 20% for the holy shit, everything is falling apart, and at the beginning of the project, I give an hourly breakdown or actually a weekly breakdown of what I estimate it to be, and I the deadline and people go oh, he hit his deadline and that’s really rare at my organization. But it teaches them like at the beginning I have them pitch everything they want to me and I now get to say yes and no to things, and I get everything, I get an estimate, I do essentially an RPF and it seems to work relatively well. Like, people learn how hard things are, and people learn how easy other things are. It’s wonderful.

There’s a doc that helps with all this stuff that I’m going to share later. So we’re all coming sort of full circle, which is nice.

Hi, New York Daily News. I had a question, wanted to get some advice from people here. Sometimes when your editors ask you to do something that’s completely are R. new for me, I know I can probably learn it and do it, but just because I have never done it before, I don’t know how long it would take, so what would you tell your editor? How would you phrase that?

I think it depends on the frame of the project. For me I find out does the story absolutely have to run this week or can we push it back if something were to happen and then I’ll use noncommittal phrases like I’ll look into that, give me the afternoon to research it an once I have a better idea of the technology I’ll let you know. If I needed to to research it, let’s regroup tomorrow, and give a better estimate, what are some other strategies?

It’s really important that your editors or anyone requesting a project from you knows your expectations, as well, so I expect that I’m going to have time for discovery to understand what I’m going to do hoo, I expect that I’m going to have the data from this person to be able to implement it, so it’s almost like making a contingent estimate so you don’t know exactly how long it’s going to take, but you can guess that it’s going to take this amount of time if so-and-so is going to be done. Does that make sense is.

Yeah, sometimes I feel the pressure because there will be a larger project based on when I finish that so if I say maybe two weeks we’re going to schedule others for the home page and so that we can launch it on that day, but I feel like intimidated because I’m not exactly sure if I can hit the deadline.

I would try—go ahead, go ahead.

Have you ever tried throwing out something like real and just being like if they are—because I find most of the time that they’re depending on you like that, and you give them a high ball estimate they’ll be like, OK, I mean, how can they tell if you’re the one that –

That’s true, too.

If someone is asking you to do something that you’ve never done before, it’s new it would be worth asking them like what are their objectives, because maybe they’re saying can you do it this way because it’s the only thing they know. Because the editors probably don’t know that there’s a whole range of ways you can build something. If if you say what are you trying to get out of this maybe there’s a way that you can build that you do already know. Sometimes there won’t be, but it would be good to get it, you know, what is it that they really truly want from you?

Hi I’m Peter from public archive. My experience is that I’m always building trust relationships with people and that the way they’re going to trust me is that I’m very up front when I say I don’t know how to do this. So it’s going to take me some time to figure that out, and I will also refuse to give them a time estimate unless I’m comfortable committing to it. And my experience has been that people, even though they would like me sometimes to give them a time estimate on things, will respect me more and trust me more if I don’t give them one, because I’m not comfortable committing to it. And will trust me more if having given a time estimate, I do stick to it. So I have to trust my own sense of can I really meet the time estimate before I’m willing to say it out loud and then I always give them the retail cost, not the wholesale cost.

Absolutely.

And we have to keep in mind, too, sorry, Jamie hut from the Star Tribune, that we don’t always get to tell them how long something’s going to take. They’re going to tell us when it’s going to run, so you know, being able to talk them through what some of the constraints are going to mean for their expectations is important.

Right, so like I was saying, I try to find out, does it have to run, you know, for instance this weekend? And if the answer is yes, because it’s tied to an event or it’s an exclusive or something, we make lists of OK, this is my wish list and then we make that more realistic. Well, in three days I can give you five of these. Pick which five you want. Or you know, and it’s almost like a bartering system and I find that involving them in that process, you know, like saying, OK, you asked for 10 things, I think I can do these five and then having them have the opportunity to say, yeah, but actually item 7 is really important to us us helps, because then it’s not like well, she couldn’t do the whole thing. They were actively deciding what the project was going to be in the end.

My team has a running joke, we’re often asked to do snow fall, as well, and we can could snowflake. Perhaps snow ball flurry, but –

But mostly one flake.

I found it useful, too, like if there’s something new and you’ve got to kick the tires around a little bit to see if you can execute it in a certain amount of time, to like put your code in you know, JS or code pin or something about it and show them a version of it kind of work everything and then measuring how long it would take but I think they can generally see that, oh, yeah, this does work, I would like it to do this, I see there’s a bunch of code here, I respect what you’re telling me that this is a solid deadline or you need more time to figure it out.

Put it in test mode.

Yeah.

Absolutely.

How do we choose the best ideas? This is something that I think is really, really important in a small team. We have about 160 people that work for Sun Sentinel. About 100 of those are reporters, and up until two weeks ago there was just me. And is so there came a time where in the beginning I was doing all these workshops, I was begging people to pitch interactive ideas and then they started doing that, and we didn’t have the resources to handle the capacity. So how can you say no without, like ruining their enthusiasm because we want them to pitch again in the future. You know, maybe in a month when you pitch again I won’t have anything on my plate and it will be perfect, so that was really important. So how do we choose the best ideas? For me it’s all about return on investment. How long is it going to take me versus what can we get out of this project. So questions I can ask is what is the shelf life. If it’s for an event that is two days away that might not be as good as something that is you know, a guide to beaches which can be used all year round. Sorry.

[laughter]

Rub it in.

[laughter]

That was not the nicest example. How much work does this take and are there open source tools available?

Can the code be repurposed? So sometimes so we’re working on something for restaurant week this year that we easily can see could be repurposed for other events. So basically we’re taking something for restaurant week where there’s like 125 restaurants that are participating and we’re picking our 12 favorites so it’s essentially like our picks or something, well, I can easily see that being used for like a dozen projects throughout the year so for that it’s worth putting in the time to create it because it can be used over and over again. Has something similar worked in the past so there are things that I know have not worked so that’s easy for me to know. And if there are things that I know have worked even if we’re short on deadline that may be something that I push forward and then finally. My tips are you should give everyone a fair shot in the beginning, because we’re big and we do a lot of projects, you know, for someone this might be the first time doing a project or first time doing an interactive and I like to give everyone a fair shot in the beginning and then if you are slammed, it’s more likely to turn away those who have proven not to deliver on time, so I know of an editor who never meets deadline. And so—and it’s never turned in in the format we agreed and it’s just typically a mess, so no matter who interesting it is, we actually had this earlier this week, they pitched and interactive graphic and we needed it in 24 hours and I knew it was going to be a mess and I didn’t want to do that to my intern, so we said no to that we because we knew we didn’t have the time right now. So what are things that –

This is not taking on a project or not, but getting back to what you said about how do you say no without ruining their enthusiasm is sometimes it would be useful to let people in on the prioritizing, rather than you having to sit by yourself going do I pick A or B tell the second person that comes along, I can do your project if I stop doing this, and you know, maybe the two requesters can talk together and say, well, this one is more important or this one can move back, and make it more of a group debate, assuming that the merits of them are, you know,.

Right, right, I actually realized that that’s my next slide so I don’t know why I brought that up so we’re going to table that for about about 10 minutes.

Gina from Spokane, Washington. We’re still in the cultivation stage, so when I try to prioritize or not prioritize, choose best ideas, I choose something what is something that can be an easy win to get this person to adopt the next time they have an idea.

Yeah and I try really hard to do a diverse amount of projects and so I try to do one per department or per team as often as possible. So I found that, you know, we win people over one by one, but it’s also a little bit contagious, so if we do a really good one with someone on our politics team, I have found that the other politics reporters are OK, I want in on that and it’s really easy to stick with things like the data team or the investigative team but we try really hard to branch out so that every so often we’re doing something with the business department and the features department, because I do think that spirit is somewhat contagious.

Dan from Stanford, I’ve—I’m not someone who’s easy to work with, but normally I—my sole criteria is that that person has an idea of how they’re going to actually do it even if I get hit by a bus tomorrow. Like it’s not—they have something going, maybe they have a spreadsheet of information that they’re putting—I mean at last resort, they can put it out by hand and I mean like we put information in kind of tabular format and you’ve taken the time to record that, that’s big deal in itself and they’re not expecting me to magically come up with something that, you know, like it’s not like a magic box where their dumb idea suddenly is great, so and I find that when they can explain step by step what they expect to see and what their plan is, that they’ve done their research, which is usually the stumbling block, and to me, that kind of a project I can jump on in a heartbeat, it’s like no, I don’t want to be the magician.

And I think I don’t believe that we should put things on the internet just because we can. I think that they should look and they should feel like the mission of the Sun Sentinel and you know, would you write a story about this? No? Then why would you do an interactive? And so sometimes we have to say no to things that don’t just meet our standards, you know, you’re mapping something just to map it, or you’re putting out a quiz because you think it would be good click bait. You know, when users come to the Sun Sentinel, I want them to know that it’s a value and it’s worth their time and so we also say no to ideas for those reasons, as well.

Now, we can talk about killing enthusiasm.

[laughter]

So my biggest tip is to explain why you are saying no. So normally I’m saying no for a journalistic reason which is much easier for them to get on board with, and respect that decision. You don’t want them to go back and say, well, Rachel says no to all my ideas, I’m never pitching again, so explain why you’re saying no, so if you don’t have time, sometimes we’ll talk about well, we have these other priorities, if this is an evergreen, can we table it for X amount of time and if it’s a bad idea, saying what would improve it? So last week, we had—how many of you have heard of flakka? So Florida has its own drug right now. South Florida specifically, which is surprising to no one. It’s a bath salt combination and it’s $5 and you can buy it on the internet and people keep dying. Miami. We had an editor pitch that we should map these deaths. Well, we did and they don’t tell us anything. There are no clusters, there’s not really enough of them to draw any sort of conclusions or patterns and we went back and forth debating this for a long time, but it was really important for us to say why we were saying, no, we don’t think this is publishable, because maybe next time he’s going to pitch another idea that’s more in line with our goals, so I try to take the time no matter how slammed I am, no, this is how we could improve it because sometimes they just need to pivot it and then it will work. And hearing reporters repeat you come back to you and say things that like, OK, I know you’re looking for X, Y, and Z and I have this new story that meets that criteria, that’s been really fulfilling to us. If you explain your reasoning and you’re not just saying no, I’m slammed or things like that?

Forest, WBUR Boston, one thing I noticed is the first question I always ask is what’s the story? What’s your hypothesis? What are you looking for? And I find a lot of times that that will stop a project because I don’t have the time to look into something. I’d love to do that kind of thing, but there’s two of us and we also run the website. So I think it’s just very interesting and that’s the one thing we always ask is what’s your hypothesis? You never do an experiment without doing that, you don’t just set things on fire. So I think that was—it’s not necessarily killing enthusiasm, but it helps them develop their story, as well, is oh, there isn’t this data, maybe I can see [inaudible]

Absolutely and I think with that too sometimes I think we get really excited about the hypothesis, you know, you’ll have a really great set of data, and it’s about like motorcycle crashes and you’re like oh, my gosh this is going to be so great and being able to say no or like when it doesn’t meet your hypothesis? Being able to say, OK, this isn’t what we thought it was going to be, let’s not publish and not being like super-super tied to like this is going to be so amazing, oh, my gosh, we can’t stop this train, really helps. And that’s a lot harder for people to do than people give it credit for because people are so excited you know, they have this kick-ass budget line and they can’t wait and then it doesn’t meet the budget line and we have to say you know what, this one isn’t great enough.

I actually had a similar—I’m sorry, I’m CJ. I work at the Star Tribune. I had a similar experience with a reporter. She said, can we do something with the data and I said where is the data? Turns out it’s very nice tabular rows and columns and I said, sure, why don’t you come over and we can hook through this a little bit and we narrowed it down and I made up a few mockup charts and she came and looked at them and she said, wow, I wish I would have talked to you before we did this big story and I said, me too. But do you think these charts fit the follow-up story? Eh, not really. They are cool, but it doesn’t really fit. We had this really nice, you know, she understood what I was getting at in that the way we have them now don’t really fit the story you’re trying to tell and even though they’re cool doesn’t necessarily mean you need to publish them and she said, well, were you going to be disappointed if we just don’t publish them and I said no, will you and she said not really and I said honestly this is sort of just learning experience for both of us, now I know the data exists, this is the story we’re probably going to come back to and now you know that when you build these things, you can just come back. That was kind of a long story, sorry, but trying to be open about our process and the way we think about what makes something good to publish and how that matches the story that they’re trying to tell I think that can help foster the enthusiasm for return customers so to speak.

I’m Mary Jo Webster also from the Star Tribune. I think related to this is the idea of are we a service bureau or are we a partner and we really want to be the partner, right, so one of the things we’ve been tossing around is the idea of how can you have a request process of getting on this line and I threw out the idea of maybe we should have the reporter and/or editor sit down with you in the meeting, talk about it, talk about your hypothesis, your theory, whatever, instead of just like filling out a form and asking them to do something, to make it and that would give you that time to determine, is this feasible? You know, not promise anything, but we need to have a meeting, sit down and talk about it.

Yeah, we specifically don’t have a form for that exact reason. Because I think when you fill out a form such as like a photo request, you kind of assume, OK, that’s going to happen. And that’s not—that doesn’t—it’s not really conducive to being a partner. I have often say I work with you, not for you, and so we encourage people to come over and talk with us, you know, I say if it’s going to be five minutes, just stop at my desk. If you need longer than that, find a spot on my calendar and throw it on there and I think some of that comes from, which doesn’t always come naturally to me, is being really upbeat and smiling. And I want people to feel like they can come to my desk. You know, I am not too busy to hear your idea. I’d rather hear it now and then be like, OK, I need two more weeks to research and I’m like great, I’m glad it’s in my brain now and I can think about it and so I fairly recently in the last year or so have been really cognizant of like the aura I’m giving off. Like.

[laughter]

Like is there a sarcastic thing you can put in your transcription for that?

[sarcasm!]

So people feel that we do want to talk to you, so that can play a really big role. Anybody else?

I’m wondering if—I know we all don’t really have time, but should we actually be going to the editorial planning meetings?

I do.

I do.

Yeah.

You can go to some of them.

And ones that are talking long term stuff, not the daily stuff.

The long term stuff, and sitting in and capturing ideas and saying, oh, now that I know this is coming up in X months, maybe you should come talk to me later.

Yeah, and we are strategic about which meetings we go to. Like we don’t go to the dailies because we think it gives the idea of I could turn this around really quickly and sometimes you totally can, but we are more long-term focused. We go to the long-term meetings and my boss reads through all the budgets with the idea of is there an interactive that nobody has thought of. Because we can’t rely on people just to pitch to us because sometimes there are things they aren’t seeing and we’re a very small team but we still split it up. I do more of the in-person stuff, and I think you’ll find your balance. You know, it took us a little bit to figure out which meetings to go to, how often to go, which editors to really build rapport with, but you find something that works for you.

I’m Sarah with Frontline. On our digital team like we make our own editorial meetings, actually and we invite people to come to us and that is also a great opportunity. We didn’t have a lot of formal structure at Frontline, so one it was introducing that, but also kind of getting people invested, and that also helps them think about potential projects. So we advocate, hey, there’s this new tool we want to use.

So is the purpose of your meeting to talk about what you have coming up?

Yeah, we talk about what we have coming up and we talk about ideas that we want to do, like short term and then long-term ideas.

I just want to have riff off of that. I think that’s a beautiful concept. Because—you know, if you come up with an original story and then assign it, similar to what editorial departments, I think development and design desks should totally be doing something like that. I never thought to actually have our own editorial meeting, but that’s a great concept.

Yeah, and we –

OK, for the last 15 minutes we’re going to kind of switch gears and we call this section getting shit done.

And so this is about how to—after you’ve talked to people and you have the perfect process ever and everyone is so collaborative and kind, this is how you actually do things.

Tyler: So I had kind of pitched this because I’m a self-taught programmer, and I’ve never worked in, you know, a web shop, I’ve only worked for print publications on the web side and so and I’ve always been a team of one, so I’m always paranoid or terrified that I actually have no idea what I’m doing or at the that my process is completely poor. So this kind of lingers over my head at basically all times, so I have these three remaining questions that kind of go off of that. I’m going to open this here, but first just put this bit.ly up here. [bit.ly/smallstaff] This links to our GitHub repo in which we have a bunch more links for tools that will hopefully be useful for kind of the stuff we’re talking about, and if you have stuff it’s GitHub so just fork it and do a pull request and if you’re new to this this is a good way to start. So I can put a little thing in that about that. This is from Harvard Business Review’s 20 Minute Manager book on managing projects. I put other links up there. I don’t mean to suck up to my employer but it just so happens that it’s all about management which is grea,t including managing yourself, so I’ve got better at that because because of where I work which is great. But this is a work breakdown structure and it comes from project management. The idea is you define your project, you define what goes into the project and you define what goes into that and generally the idea is that a project manager is coming up with this, and you can use it like that, or you can also just use it for yourself. So when someone pitches a project, here’s your restaurant week guide or some kind of data dive, you don’t have to say, OK an interactive guide to local restaurants, that will take me, I don’t know, a week, instead of doing that, you can say, OK what are the features here and even in your little programmer head things that other people wouldn’t know, OK, I’ll need some kind of Javascript library to filter that, I’ll need some sort of hookup with Google Maps so people will be able to see where these things are. So the text here doesn’t really matter but just the general structure is you’ll start out with the general gist of everything, overall project. The number doesn’t really matter. 3 is a great place to start, I guess. Say what is the major task and then what are the subtasks that go into that. Sorry about the pagination here because this is from a print book. But say what are the subtasks that would accomplish this particular task and best of all you can figure out how long that particular project would take. So this goes back to what we were saying earlier about estimating projects. So from there, so that’s just a cool thing I saw that I like to use a method that I like to use in terms of giving estimates. From there, though, your work is not done. You need to track your own time. Just imagine if you were a freelancer, I’m sure some of you were at some point, and you were billing people and of course, you know, you’re going to track your billable hours. Even if you’re on salary and you’re not doing that, it’s important to know how long a given part of a project would take, how long you expected it to take and whether you were spot on or you were under or you were over. I use a tool called Toggl. It’s just like a toggle switch except without the E on the end. It’s free, it lets you define several projects and every time you log for a time period, you can say what you did in that particular time period, which is nice. But there are any number of other ones and your employers might have harvest or something like that, there are a lot of tools you can use there.

From there, I like to set deadlines, check-in meetings are great. You might not want to do a daily standup, depending on the project. That might be overkill. But if it’s a longer-term project and you want to meet with your team every week or maybe every Tuesday and Thursday, and update people, if it’s a thing where you’re getting stuff from your design desk or you’re getting stuff from a reporter or something like that, then you can say OK, by this time next week you’ll have this spreadsheet for me, I’ll have this part of the project done, that’s that and when you’re doing these meetings. Obviously you want to stay on task but it’s a great way to impose a deadline on yourself because once you say you’re going to do something, you have to do it.

Rachel mentioned the angry post-it notes and I don’t do post-it notes but I tend to just write a reflection paper like high school style in my Google drive and I started doing that as a thing to give to my supervisor so they could see what I’m doing but they didn’t really care so I just started doing it myself and it does seem kind of silly to let out all your feelings on the page. But it does help, it’s a nice war foe moo to just writing stuff down is good for memory, but being able to refer back to that, to know how the people parts of that project went, how the technical parts of the project went, what I did to solve certain things, I find very helpful. So that’s my part in terms of this kind of thing. So if anyone has ideas on keeping yourself on track?

I keep myself a daily diary. I’ve Google drive page that I just put in, you know, June 5th and here’s what I did today and I even find it’s useful so that Monday I come back and I look at what I did the previous week, and then that helps jump start me for Monday, I feel like I’m right back, you know, it’s 5 p.m. on Friday and I’ve jumped right back into it.

Yeah, Dan?

I just like using Google spreadsheets whether it’s with someone else or if I’m just by myself, like if I have some half-assed idea I’ll make a row that’s title and then maybe URL and if you do command enter in a cell in Google docs it will automatically time stamp the cell and I’ll fill it out casually and a lot of stuff never gets done and it eventually disappears down the drive but at least I’m not spending a lot of time entering my thoughts and it is a good data thing and I’ve basically structured data basically.

I use Trello for things like that.

Oh, yes, we use Trello all the time.

We can notify a person if it’s ready to. The problem we suffer is we have too many projects at one time and organizing time and you know, kind of setting expectations is we’re constantly jumping in a given day, two interactives and something else that sucks time, so for me I don’t know how I would—I think I would kill myself managing myself if I started writing everything down, so I wonder if anyone else has that kind of struggle or?

Managing yourself is a struggle.

Well, writing stuff down and be like today I worked on this project but I worked on three other ones.

It doesn’t have to be detailed, though, I mean even just noting that today you worked on this and I find myself as I’m writing it thinking you know, someday I might need this if I need to prove to my boss what I’ve been doing all this time, right? It doesn’t have to be complicated. It could just be I worked on this and hit this one roadblock and I’m still stuck at it, right?

I do have to say, like the more detailed, like I’m doing a project right now that’s like wicked dirty data and it’s just taking forever because I’m documenting really detailedly, but I’ve had things crash and die on me, and it’s fine, because I have this like super detailed record of what’s going on and then the next project I go to, like probably not going to go back to these notes, because there are like tens and tens and tens of pages long, but like that’s in there, you know, that’s in your head and it makes you slow down and think about like, why am I doing this? I’m writing this down, like, why am I doing this one process that I’m doing, so you’ll just slow down enough to see that maybe what you’re doing is mildly self-indulgent or unnecessary.

So I want to move on so we have enough time to get through the rest real quick. Making it easier on yourself is, needless to say, hugely important.

Templates, obviously, I don’t think that’s a secret. But if you’re doing the same types of projects over and over, having templates is so key. If you’re doing a lot of interactive map types of things. If you’re doing quizzes. Those are fantastic, and we tend to do wildly different things from one project to the next, which is maybe not the greatest idea in the world, but—and on that subject, going back to when we were talking about when—whether or not you should decide to do a project, if you can look at a project and say, this not only seems like great for this project, but it seems like something we could repurpose for other stuff, that’s a big bonus point in my book.

And then going off of that, style guides are huge, not only do you want your visual style guide just for you know, your branding and all that for the user, but when you can take as many decisions out of the process as possible, that will really speed things along. If you know when you’re going in, OK, my H3 is going to look like this, my subhead is going to look like that, that’s just fewer decisions you have to make which obviously makes things much easier.

I also mentioned in my notes that I keep a personal code library for like—I almost exclusively use JavaScript so I have a lot of JavaScript functions I’m doing over and over and after Googling how to generate a random number a thousand times I realized I can just keep it in a text file somewhere and refer back to it whenever I have to do that particular thing. So that’s extremely helpful. In the GitHub, there’s a list of tools for doing these sorts of things. If you have any, add those, as well.

Administrative work is an important part of our gigs and I’ve found when I’m really in the weeds at the end of a project, I’m very fond of telling my team, people I’m working with I’m going to check email at 10 and 3 today, that’s it. Outlook is going to be closed out the rest of the day. Obviously you want to remain accessible to your team but you also have to know, OK if I’m going to get this done and make it easy on myself, I really have to know that I have this time that I can dedicate and I’m going to cut all the other stuff out of my life. So I’m really good at scheduling before lunch I’m going to work on project A, after lunch I’m going to work on project B. I’m good at that kind of thing.

Especially as a developer, killing your ego is huge, so when you’re stuck in the weeds on a problem, either I mean if you’re lucky. I mean if you’re able to ask other developers for help or delegate. And just not like getting in your head and thinking, oh, man I should know how to do this, I’m going to figure it out and then four hours later having nothing to explain for it.

Try explaining it to a nape technical person.

Yeah, rubber ducking on a nontechnical person is huge.

I’m part of this Slack group called the lonely coder’s club if anything is interested? In joining, you can go on, you can ask questions of other lone coders. There are some legacy lone coders who aren’t lonely anymore but they’re still there to help, like Alan who was at MinnPost now he’s WNYC but yeah, hit me up later and if you want to.

Do you accept friends and allies of lone coders?

[laughter]

We’ll see.

We’re all owned by media conglomerates and so I find it really helpful to reach out to people who are using the same systems. So like the Sun Sentinel is owned by Tribune Publishing and so I’ve built relationships with the coders in Chicago and Orlando and Baltimore, because they’re under the same restriction, so like for instance, our advertising script is really hard and it competes with a lot of other scripts and so they’re such a great resource for things like that because they have the same exact advertising script and since we’re so small it has been really great to have other teams to say I just need a second set of eyes and it’s usually like a missed comma and you feel ridiculous, but sometimes you just need that second set of eyes.

And even if it’s not pa corporate parent, even like groups. When I was in alt-weekly land, I reached out to the other alt-weeklies.

Andrea use works where I used to work in Burlington, Vermont. Even if it’s not exactly the same systems, it’s the same problems. It’s great to find a shoulder to cry on.

So sometimes it’s about making it easier for yourself. So look if there’s open source code already that does what you want to do, but sometimes also about not making it harder for yourself. Check the documentation first, if it’s not good, don’t touch it. You don’t have time for that, and it’s not worth it so in that sense just be careful.

I still like try to do as much as I possibly can with JavaScript almost like to MacGuyver levels. I should probably move on to Python or something. But you know, this is the last question, we’re almost out of time. But when we’re lonely coders, I love that phrase and I’m going to use it all the time now, it can be tough to learn new things and to know what you need to learn more likely.

Fortunately we all work on the internet which I think helps in this regard, but a thing that’s helped me a lot is knowing your learning style and for me, I really like to have someone there to talk me through things. And that’s, you know, like if you were still in college or something, but even if I’m not taking a class I’ve found Lynda.com is extremely helpful for that. Dan’s presentation before this one about mundane programming was fantastic—I wish we all had a time turner and we could go back and take that before we were here but in terms of figuring out mundane tasks that like your side project tasks to help you learn new things, like you had mentioned what was it a ruby script to help find an apartment on Craigslist?

Yes, which Craig doesn’t like, but as long as you don’t commercially do it, but yeah, when you really need something to to be done you’re not going to bullcrap around with the code, like you find that you’re much more motivated to learn it because not only are you going to learn something hopefully, but you’ll also get whatever you were going towards, too.

Right, and I recently—I wanted to learn Node.js and I found a lot of tutorials that were towards scraping the web with Node.js and so a thing I’ve been doing, up where we live where the beaches are only open one month a year, last winter pretty much killed my winter jacket so I needed a new winter jacket and I found the one I wanted but obviously a good winter jacket is pricey so I set up a Node.js thing to scrape the L.L. Bean website and it will send me an email when the price of the jacket I want will drop. So just this little silly thing, I had to learn Node somehow, so and I learned Heroku, as well. So the first time I ever used D3 which is now a thing I used a lot for charting stuff, I had downloaded my data from Untappd, the social app that lets you log your beers and I figured out what I was rating my beers at and I made a scatter plot but that’s how I learned D3. That was my sample D3 code.

I would just recommend to everyone that when you do learn something new, share it with everybody else. Because one of the best ways to solidify your knowledge is actually to teach somebody else, so create a tutorial or something and put it out there for all of the rest of us to share and I think you’re going to probably be able to learn something else that somebody else learned and if you do it right away as soon as you’ve learned it, I find when I go to write it all down, I’m like I remember that, you know, that thing that I had so much trouble figuring out that the tutorial I tried to learn from totally failed, I’m going to put that in my tutorial, right?

If you do post a question and then figure it out later, please don’t just put never mind.

Yeah, and yeah, I just answered my first stack overflow question a few weeks ago and boy did I feel like a million bucks for doing that.

People who work at other places where you admire their work, don’t be afraid to email someone personally whom you’ve never met in the community and ask them questions. I’ve done that a couple of times. Email someone like someone you met here like in five months randomly like how did you do that can you walk me through this they will most likely be like, yeah, I can get you on the phone. I’ve received a couple of those emails and I will immediately, like I’ll just stop, working on everything else and spend three hours and try and share everything with them because it feels like sharing something I’ve worked on.

And I think a lot of that comes from there can sometimes be a lack of appreciation within your own newsroom because no one knows how you do it. I use Twitter a lot for that, I’ll ask questions and it works I would say more than 50% of the time. When I did my first D3, it doesn’t doing well and I posted a question and a developer from the Oregonian was like I’ve done that exact same thing let me send you my source code and I expensed a Starbucks gift card because you can send those via email address which is a really nice thing and he was like blown away because for him just sharing it he was happier sharing it than I think I was getting it and so yeah, totally people want to help you.

Yeah, I think we’re lucky that the news developer community is unfortunately not perfect but better than other communities and it might be because I’m a white dude, I can say that but I it’s a safe place to say hey, can I pick your brain on this, and I think we all 250 people here are kind of all in on that mission.

So we are over our time so if you like to leave, feel free to, but if you would like to stick around and talk more, please feel free to.

7 minutes, so yeah, that’s our bit.ly and totally find us around today and tomorrow.

[session ended]