Eh, I think your co-founder has the wrong attitude here. I edit the copy all the time my co-founder writes. Sometimes I tell him, sometimes I just deploy if I'm in the middle of pushing something out. Building startups is all about iteration. One person sees something from one point of view, the next sees it from another. As each person adds their improvements you get a much better final product - you wouldn't be changing it if you didn't see something wrong with it.
By the same token, I totally accept when the things I've spent hours pouring over get thrown out the door. We recently had a design review where someone said one of the elements I put hours into looked like a 3 year old had drawn it (they didn't know it was done by me, they thought it was outsourced). It was the kind of style I was going for, but that reaction made me realise it totally wasn't suitable for the site. I was a little hurt of-course, made a joke about it and brushed it off. We now have a completely new version of this page that's way better than my original vision.
Wrong response:
“You fucking trimmed my copy.”
“I don’t want to get mad but I sat there for FIVE HOURS crafting that yesterday, there’s a reason for every word.”
Right response:
“I see you changed my copy. What improvements were you trying to make? I felt point x,y,z were important and you left them out. If you were trying to make it shorter, here's a shorter version that includes the more important points.“
You know, I'll just go into the middle of your application and screw around with some of it. Delete a feature I don't like even if it causes a few tests to fail, tests I didn't even know you had.
I'll also add a few CSS rules that break things on other pages. Who knew you were supposed to put those in particular files, or that you'd used those selectors for other purposes.
Since I needed another database column, I added one to one of the central tables, locking the database and breaking a batch job that couldn't recover properly, leaving a messy clean-up job for you later.
Oh, and I also just copied over the patches and rebooted the server to makes sure they were applied properly. Sorry about all the background processes that didn't restart properly because of the hard boot.
That is what it feels like to a copywriter when you mess with their words.
No, that is what it feels like to a primadonna when you mess with their words. They conflate the quality of their work, a highly objective measure, with breaking tests and screwing up a server, a distinctly objective measure.
No one's work is sacrosanct and without opportunity for improvement. So when you're f-bombing someone because they altered your work, maybe stop to see if your work just wasn't all that good to begin with and needed a boost.
This isn't about changing someone's work, it's about effective collaboration. What's obvious to you may not be obvious to me. Whether it's an application or copy for a homepage, there are subtleties that a reviewer will miss.
What makes a good application "great" isn't obvious. It's the little things hidden in the details. Often, we don't even notice the details. That's what makes great applications so difficult to replicate: you can't enumerate their greatness in a bullet-point list.
Likewise with great copywriting. If you don't trust that every word your co-founder wrote has importance, and that you should at least review with them before making changes, then you didn't pick the right co-founder. It's ok to work toward improvement, but that work shouldn't be performed unilaterally.
Finding it in yourself to trust those around you is a difficult trait to acquire, but it's essential to strong team building.
"Likewise with great copywriting. If you don't trust that every word your co-founder wrote has importance, and that you should at least review with them before making changes, then you didn't pick the right co-founder. It's ok to work toward improvement, but that work shouldn't be performed unilaterally."
Totally agree. The overarching issue here is cooperative communication.
Well my point wasn't about what it feels like, but the way the reaction was handled.
I would never send an email that said "You fucking changed my CSS". It happens ALL the time to developers. In fact refactoring, telling each other what you think is wrong in the code and how to fix it is a core part of team software development. Nothing is ever perfect. You can't be that protective of any part of your product.
If you're on a small team and can't say how you feel, especially when it's warranted, I'm not sure you're on the right team.
In terms of efficiency, "You fucking changed my CSS" says a lot in just a few words. Once that's out of the way, you can always get on to the finer points of why that's a bad thing.
I do agree that you should be able to say how you feel, but "You fucking changed my CSS" is an overreaction. I work on a project with 4 or 5 other people. Sometimes they change something and it breaks me, and sometimes I change things and it breaks them. When that happens I can choose to react in a few ways:
1) "You fucking broke my code."
2) "Why did you change my code?"
3) "Why you change THE code/Why did you make this change?"
4) Ignore it and fix it myself.
Of the 4, #3 is probably the most appropriate reaction and can easily be stated as "Why did you make this change? It broke functionality/function X!" And it easily conveys the issue and your dissatisfaction.
She could have stated, "Why did you change my copy? I carefully selected each word and I think the changes detract from the overall feel." Boom. Done. Dissatisfaction has been conveyed without sounding like a child.
Exactly - asking questions will get someone to realize that they fucked up, and if they're at all conscientious, as the post's author appears to be, they'll feel bad enough, with no need for a harsh tone.
I would view asking questions to get someone to realize that they fucked up as passive aggressive. Ask if you're genuinely curious, but if it's clear that your friend/coworker/cofounder screwed up by meddling in something that they don't have expertise in, then call them on it!
Actually, your example includes the best reason for restating the objection. ""Why did you change my copy? I carefully selected each word" ... where the word selection refers to co-founder's response to Jesse.
Why choose words carefully when communicating to the public / investors, and not to team members / partners?
It obviously depends on the kind of people you're working with. If it's with someone who you've been in the trenches with for a while, then formality is often something you both discard.
I understand that this blunt approach works in the short term, and maybe it's even effective.
But trust me, do this for two years instead of just two weeks, and the team stops respecting or trusting each other. Each little verbal jab accumulates over time and deteriorates the working relationship. "Don't work with John or touch his stuff - he goes ape shit every time some little thing happens."
There's a good saying that goes "never attribute to malice what can be attributed to incompetence / stupidity / misunderstanding" (the last word depending on your context).
Basically, cursing someone out does not necessarily yield results over the long term when there is an underlying problem that can be solved in a more civil fashion.
In terms of efficiency, "You fucking changed my CSS" says a lot in just a few words. Once that's out of the way, you can always get on to the finer points of why that's a bad thing.
I'm glad I haven't had to work with people who acted like this yet. As I'm pretty sure my response would be a very efficient "Fuck you, stop being a child." somewhere around the second time it happened.
In my experience that isn't what it feels like at all. Copywriting is just as much about iteration as software, and as a copywriter you can expect half a dozen or more people to monkey with your work. Sometimes they'll make it worse, sometimes better, but they're always going to change things. And on subsequent reads you will too, if you're any good.
That said, while she was upset for the wrong reasons, she wasn't wrong to be upset. One thing you shouldn't do is monkey with someone's work and then push it out without any sort of dialogue.
Also, for what it's worth, your examples all beg the question. There's nothing in the blog to indicate that Jesse's changes had a measurable impact on the copy one way or the other.
It's not entirely the same. Imagine instead that it's your technical cofounder, who isn't quite as well immersed in the application as you, and may not get all your code idioms, but still knows their way around a compiler, and can hack in a quick bug fix in a pinch, even if the resulting code isn't as elegant as you would have done it. They know to run the test suite, even if they don't add a new test case for the bug fix. How mad should you be then?
The reality is that everyone here speaks English, and if the guy is editing your copy, it means he has opinions about English, which is enough to make him "technical" in the sense of the previous example. He's not as good as you are, but his copy will be serviceable. The situation you describe would be akin to having your cofounder be unfamiliar with English grammar.
"He's not as good as you are, but his copy will be serviceable" - highly dubious about this. Copywriting is a skill, separate from fluency in English, and not everyone - indeed, very few people - have it.
I've seen plenty of "sales" documents written by people who could write English, but couldn't write copy. If you're considering "might actually convince someone to buy this product" as your end goal, it's very, very easy to end up with something that isn't servicable at all.
It's a shame when people's feelings get hurt, for sure.
But have you looked at the text in question?
It's no work of art. I don't know whether the live version is before or after, but in all honesty it could use quite a bit of trimming, as well a whole lot of editing in other ways. The current copy makes the typical noob mistake of trying to cram every bullet point in the pitch deck onto the front page. This is not someone with ten years of experience who actually knows how each word will help the business, it's a kid trying to figure it out by spending five hours thinking about it.
If an intern sent me a "fuck you" message for refactoring a bunch of not quite working spaghetti code, I'd show them the door. That's a lot closer to the situation here...
If this was an experienced copywriter with a decade of real world experience putting out content that was close to perfect, your story would seem a lot more reasonable, but it doesn't seem to be the case here.
The edits weren't done in the spirit of screwing around with it. They were done in the spirit of improving it.
Yes, if you've got someone who can't stand not leaving their personal imprint on everything that passes by them, you've got a problem. Doubly if it breaks stuff.
However, if you've got someone who makes studied changes to (text|code) with the goal, and better yet, effect, of improving it, you've got gold.
The team here could use some process. It could also use a lot of maturity.
The less was less about the fact that he did change it, it was the fact that, by oversight, he changed it, and deployed it live without once discussing or even mentioning the changes, even after the fact. She was understanding of the change and we're working on a happy medium (just as you said we should), it was just a shock to find something she'd put so much effort into go live completely different than she expected. That kind of communication among founders is vital.
She didn't overreact, she just sent him a private email. How is that unhealthy? Now if she felt frustrated by his behaviour and bottled it up, that would be unhealthy.
The person in question had been working stupid hours on a crazy deadline. She was probably at the end of her tether from stress and fatigue. That doesn't make her response the right one, but it does make the wrong response forgivable. Which of us can say we have never done likewise under such circumstances?
If you've got 2.5 weeks to turn a hackathon project into a "company" to pitch to investors, it could be that the underlying issue your cofounder has isn't related to the copy.
It could be related to the fact you took 2 days off during the middle of your sprint to get the project ready while she worked through.
Thank you also for 'pitch to investors'. When you 'pitch investors' (like in the blog post) you are presumably either, depending on your cultural reference points,
1) Hurling them at a man who wants to hit them with a bat (a bubble metaphor?)
2) Tying them to the ground with guy-ropes so they don't get blown away (I won't try and find a metaphor).
This is a trivial aside in the context of the article but it reads in such a dissonant way, up there with 'could of'.
My first thought when I hear 'theres a reason for every word.': amateur.
Don't take yourself so seriously. Unless you've literally tested every word, theres not a reason for every word. You are just flinging paint on a wall and calling it art.
(side note: you're young, its not bad being called an amateur. It's a good time for you to get rid of bad habits)
Yeah. And the second thought is: hand it off for a second opinion earlier. Writing copy is teamwork, except for experts at writing copy (exactly as writing code is teamwork, requiring review by someone else and refactoring).
Well, it's only about a day old, but the conversation between him, her, and the rest of us went well from there. We're working on v2 right now :) I don't really think this is going to tear us apart--I was actually the cause of a worse mishap a bit earlier, and that ended much better after clearer, and apologetic communication. The point stands though, it is important that you stay considerate in situations like these, so they don't become something that jeopardize your team dynamic. Jesse immediately responded in an incredibly understanding and apologetic manner, and now we're working together to fix things, as we should!
However, the article is right. If you delegate something to someone, you should discuss with them before (or occasionally after) overriding their decisions. If you do that too often, they may not be compatible with your vision for that position, in which case you should find someone who is.
Reading this made me feel sorry for the other co-founder: "The last two days, while I’d been relaxing in the rivers and mountains of upstate NY, one of my cofounders had been tirelessly building the landing page." This really means that while this dude was goofing off for two days the other parter was doing the real work. What's amazing to me is that this guy is so oblivious to this...
...actually he was very open (maybe too open) about the work/life ratio thing and went into detail: That's what stood out to my eyes. You're right, it's not my business -- but in his article he makes it my business by pointing it out. But if I may be blunt this may also be a generational issue: In a startup you don't get a star for just showing up (frankly that's an employee mindset), what counts is what happens -- the results.
Always useful advice. If you delegate, then you delegate. That said, when someone changes your work without telling you its always useful to go in trying to learn. Both of you come away with a better understanding that way.
When I went to university, there was a design class I had to take. He was known to be pretty tough when critiquing people's work. In the first class one of the things he told us was: "It's not personal, it's just business".
I find that it's generally helpful to keep this mindset. I try to keep in mind, it's really the result of my work (the final product) they are criticizing, it's not really me that they are trying to attack. Sure, I spent nights on something, but in the end if it looks bad, it looks bad. I can choose to feel hurt for a few seconds, over it, and make it better the next time around.
I would much rather the phrase be something like, "don't take it too personally, we're all on the same team and even though I'm harsh, the goal is to improve your work."
I know it doesn't roll off the tongue like "it's not personal, it's just business," but the problem is most of the time when I hear that particular phrase, I'm probably about to be screwed over in some way.
I disagree. If you're going to work as a team no-one can 'own' something entirely. What if you spotted a typo? Would it be OK to change the copy then? Everyone needs to be mature enough to trust that the other person wasn't being malicious, and be prepared to talk about things that they don't disagree with. And iterate. The words weren't carved onto a stone tablet and then launched into space. They're on the internet and can be changed in a heartbeat.
I don't think they should need to. You set up a situation where we can't touch the home-page without consulting Mike, or we can't change that data access code without talking to Sue about it. Do stuff. Make mistakes. Iterate.
I disagree. If your team is senior enough, I think it is very important to give people delegated areas of responsibility. I've found people start to take pride in their work when this happens, because they know the buck now stops at them, and any outcome (positive or negative) is their own doing.
If you have everyone putting fingers in everyone else's work, why would you want to spend a week working on something when you know someone could just come in and undo it on a whim?
In saying that, it doesn't mean people shouldn't take feedback, though eventually, you'll have to start trusting your team to make decisions for the business. As a founder, you can't go around making every decision for your company, it doesn't scale that way.
At a certain size, maybe, but for a 2-week seat-of-your-pants getting ready to pitch to VCs sprint I don't think delegated areas of responsibility, or exclusive ownership is warranted or healthy. I think if you go and stomp over someone elses good work you need to be responsible for that, but I think you need a team/organisation where you have that freedom. By the downvotes it looks like I'm the odd one out here. Whatever.
I think you can still iterate and stay in touch. Indeed, I think that's the best way to iterate.
The problem wasn't the copy changes. It was not demonstrating sufficient respect for the other person's work. If he had emailed the colleague with a note as he started tinkering ("Great work on the landing pages; I'm going to see if I can tighten the prose up a bit.") and then sent her the diffs, there shouldn't have been any upset.
I think your cofounder might be annoyed that you took two days off, came back and changed the work they'd been diligently working on while you were gone... and then wrote a blog post about it? Seriously. What have you actually learned here... it should be more than "treat others the way you wish to be treated" in my opinion.
It probably wasn't a good idea to edit the copy without consulting others, but I've dealt with situations where I've had to decide what to do with copy that's long and rambling to the point of being unreadable. Something needs to be done in those situations. When a website reads like a novel, it's time to have a discussion, figure out what your users are there for, and determine whether you might be failing to promptly fulfill those needs. There's nothing wrong with providing ample information on a website, but it needs to be organized in a way that delivers the right amount of the right information to the right people. If you can't do that, you're probably delivering a mess of an experience for the majority.
If the modification this guy made actually made the copy WORSE, then the reaction is completely understandable.
I think the problem is on how do you know what is actually best?
This is a problem for developers as well. "you refactored my code into some unreadable crap" - "I made it more clear and DRY"
Lots of code (and copy) are highly subjective, like when to use a design pattern or when/if to break the Single responsibility principle etc.
It's easier if you have a tight team that have worked together for a long time and get a long fine. However, it's also good with different views in order to actually get the best solution in place.
How do you handle these kind of problems in a good constructive way?
"... It’s a saying I learned in Quaker school, but it applies to almost every situation. I don’t want to be undermined, so I shouldn’t undermine anyone else—consciously or unconsciously. ..."
It's all about the goal. Be flexible. To get there someone has have responsibility to make a final call. If it's technical, a right or wrong answer can be made on merit.
For non-technical or subjective decision defer to founder(s) experience, training or gut feel and back this decision up with measurement and make adjustments if needed.
It's a largely necessary phrase because "I'm a sophomore" is otherwise ambiguous if you just finished your sophomore year or are just about to start your sophomore year.
the whole thing could have been averted with a simple
"hey - great work so far - can I tweak a couple of things?"
instead, you now have a blog post (and HN thread) worth of analysis on something that should have been very simple.
OTOH, no publicity is bad publicity, so it's all good in the end.
By the same token, I totally accept when the things I've spent hours pouring over get thrown out the door. We recently had a design review where someone said one of the elements I put hours into looked like a 3 year old had drawn it (they didn't know it was done by me, they thought it was outsourced). It was the kind of style I was going for, but that reaction made me realise it totally wasn't suitable for the site. I was a little hurt of-course, made a joke about it and brushed it off. We now have a completely new version of this page that's way better than my original vision.
Wrong response: “You fucking trimmed my copy.” “I don’t want to get mad but I sat there for FIVE HOURS crafting that yesterday, there’s a reason for every word.”
Right response: “I see you changed my copy. What improvements were you trying to make? I felt point x,y,z were important and you left them out. If you were trying to make it shorter, here's a shorter version that includes the more important points.“