Grounded & Steadfast

est. 2008

Be Kind

Andrew Bosworth shares his experience that was his wake up call. After having his job changed and team feedback given to him, he reflected on his attitudes and made changes.

Not only is this a great story because he had the wisdom to look within and own up to his failings. It's also encouraging to see a friend (and boss) be willing to gently admonish and promote the change. That's true friendship!

I love that he includes a caveat in the last paragraph:

I’m still not as good as I’d like to be at any of this. When I’m under stress I can sometimes fall back into my old habits. But believing deeply that I am responsible for how I make others feel has been life changing for me.

Changing who we are doesn't come overnight. There are no life hacks, shortcuts, or 4 hour work weeks that make us change who we are and how we live. That takes energy, purpose, and determination.

And time!

Tales of a Non-Unicorn

Laura Shenck shares a personal anecdote about the issues she faced regarding job titles. Her story includes applying for a role that was titled one way, then being tested in a manner befitting a role of another type.

Why do we seem to struggle so much with titles in our industry? I suspect it's due partly to the rapid pace at which the Internet has evolved, the underlying technologies, tools, and frameworks shifting constantly so that those who build things for the web are ever learning. While that change occurs, it's difficult to even find consistency and agreement as to what our roles and duties are. What is UX? UI design? Front end development? It depends who you talk to.

In Laura's case, it's likely that the person writing the job posting was not working closely with the interviewer. As she mentions:

I smell someone listing buzzwords.

Here at Wildbit, we've had a similar struggle. As a team, we've completed the exercise of defining the guidelines of our various roles. What makes a good designer vs. a bad one. Same for developers, sys admins etc. And we've done the same for the Customer Success team (of which I'm a part of).

But what is our Customer Success role called? Customer Success … person? Engineer? Advocate? It's a familiar problem for anyone who works in the support/success field. And some ask whether the title even matters? They certainly matter less than the work and goals that define your role, but having a title to refer people to does help.

We decided, perhaps lamely, on Customer Success Champion. But, like Laura, our focus is more on what we do and less on the title. As it should be.

Are You Just LARPing Your Job?

John Herman has some astute observations about Slack and how it's changing office culture. As people migrate to it from other options, there's no denying it feels better. But that may not necessarily be healthy.

As Mr. Herman states

But the thing about Slack that gives you that low dread of unstoppable acceleration is how fully it encompasses how you talk to coworkers …

And the problem with this:

Slack allows, in the most extreme cases, for a full performance of work—the clocking in, the ambient noise, the watercooler discussions, the instant availability and accordant impression of responsiveness—without the accomplishment anything external.

I'll admit, I prefer Slack to Hipchat, Campfire, and most certainly Skype. But I'm hesitant to support a company that takes funding just 'cuz … and while it's an innovative tool compared to the industry standards, it's not making my life better. John eloquently articulates the danger of being busy rather than productive and how Slack contributes to the illusion.

But hey, some think it's just another chat tool, but with nicer colors and a good logo. This too, shall pass.

Why Startups Should Train Their People

Ben Horowitz talks about both the importance of training your team and how to set up a training plan. This is such a vital part of building an effective team, yet it blows the mind to see how little thought many companies put into it. Big and small.

Ben nails it:

Almost everyone who builds a technology company knows that people are the most important asset.


Training is, quite simply, one of the highest-leverage activities a manager can perform.

Well said. Who should be doing this training? The leaders (aka managers) on the team. How can new team members fully understand how your team works and what's expected of them without a proper onboarding and training plan? Beyond that, how does your team improve over time if your team members are not growing their skills? Invest in your people, both with time and money.

He closes with this:

Keep in mind, that there is no investment that you can make that will do more to improve productivity in your company. Therefore, being too busy to train is the moral equivalent of being too hungry to eat.


The Full-Stack Employee

Elea Chang makes the case for focusing less on any new titles for workers, especially tech workers. Her thoughts are a response to Chris Messina’s glorification of the employee who gets it all, from ideation, to strategy, to the technology that enables it all to happen.

I love Elea’s point here:

Unfortunately, the continuous pursuit of professional skillsets tends to diminish the boundaries between work and everything else, leaving you with less and less time to actually grow as a human being.

Generalize or specialize, the most talented people I’ve worked with have had one consistent trait: interests outside of their job. I’m fully on board with the idea that the best employees are those who have a full breadth of interests and passions and seek time to learn and grow.

I appreciate a jack of all trades, but one with the abilities go beyond the full stack of web components.

Blogging Tools

It feels like a long time since I posted my first entry to my first WordPress via Mars Edit. That was early in 2008 and I still remember the sinking yet thrilling feeling I had when Shawn Blanc first linked to one of my articles. Blogging tools have come a long way since then.

Back then, I used MarsEdit and only MarsEdit to publish to my WP run blog, The Weekly Review. Now days, I use a set of web based and desktop tools to share my thoughts on my Kirby run blog.

I realize many folks consider talking about your blogging toolset is akin to talking about your relationship issues in public. Loudly. But I appreciate hearing how the writers I respect get content on their site and hopefully someone can benefit from hearing about my own. Rian shared his own use of Pinboard lately, so he’s truly to fault for this post.

Here’s how I do it in 2015.

On the Mac

As mentioned above, I use a collection of tools to get content published to my flat file Kirby install on my Media Temple server. The full list:

The full process is for writing link posts. I start by finding something I want to share and add commentary. I save the article to Pinboard and add a tag titled “link”. Like Rian, this is picked up by IFTTT and the linked article is saved to a text file in Dropbox. IFTTT uses my link article template to populate the text file.

IFTTT Template

So far, pretty simple. The real action happens on OS X after that. I have Hazel watching the writing folder in Dropbox for various activies. I use 4 rules to prep my articles for writing, to remind me to write, to actually publish to my site, and to keep my Dropbox folder in sync with my journal folder on my server.

Hazel rules

This may sound complex, but each rule is fairly simple.


The first thing to do is get the new text file created by the IFTTT recipe to match the structure of my Kirby install. Because Kirby is a flat file CMS, each post lives in a folder with a certain name and number. As well, each text file within the folder has a general file name of article.txt or (depending on the article type).

I wanted Hazel to do most of the manual work for me.

1st rule in Hazel

What does this do?

That’s it. If you step back and ignore all those details, the process is simply this: I find an article of interest, add it to Pinboard, and the minutes later the file and folder are sitting on my Mac and are ready for me to add commentary.

Reminding Myself

Sometimes I get busy or am away and have little time for writing. The 2nd rule is in place to simply remind when I have some older link article files ready for publishing.

2nd rule in Hazel

After a week, I’ll get the Hazel notification that some items should get attention.


The most important step here is publishing. Before this setup, I would simply connect to my site in Coda and add the new file directly. Now, when the article is filled in, edited, and ready to go, I just make a few changes in OS X.

3rd rule in Hazel

I simply add a green label to the article folder. That’s it. Hazel then uses the Upload command to connect to my server and add the folder and file. The article is then fully published.

What is not shown in this rule is my change to the folder title. Usually, the title that IFTTT pulls from the original source is long and cumbersome. So I change the folder name before publishing, giving it a shorter, more sensical name along with the proper number to be the newest article on my site.


The last step is simply to mirror the content of my server on my desktop. Why? Simply because I can then make sure my folder names (and the number that is included) for new articles are ordered correctly.

Kirby structure

Because Kirby is flat filed, the order of posts on your blog is dictated by the number in the folder name. And so the 4th rule in Hazel makes sure I never forget the most current number on the server. It’s a rule that is run once daily to sync from server to desktop.

4th rule in Hazel

As you can see, the rule does little. The details are in Automator. It simply runs Transmit and uses the Sync option available in that app. I filled in the server details, path included, and when the rule runs, Transmit launches and syncs away.

Sync options

It would be nice if this part of the process happened in the background, rather than have Transmit pop up and interrupt whatever I’m doing (I’m open to suggestions!).

My process is slightly different for writing full articles. They start in Ulysses and are simply put into the correct folder with the green label. The Publish rule takes care of the rest. So my Mac workflow is automated and about as easy and frictionless as it can be. Which is great as most of my writing takes place on the desktop.


But what about iOS? I do write on my iPad frequently. And if inspiration strikes, I will simply fire up Ulysses and write away. Dropbox is available, so the full folder structure that is synced thanks to Hazel is available to me.

The only downfall is that I can't set the OS X color label on a file or folder on iOS (that I’m aware of). This means I either finish up on my Mac at some point, or use Transmit or Diet Coda on my iPad to publish an article manually.

I’m guessing that more automation would be possible. If I could just sit down long enough to finish one of Federico’s articles, I could probably get inspired on how to improve this. However, the last 12–18 months have proven that I spend far more of my writing time on OS X than iOS (perhaps because iOS 8 runs like crud on my iPad 3) so this set up fits my current habits well.

Whether on OS X or iOS, the 3rd party tools like Hazel and IFTTT are incredibly enabling. And the result is that self publishing involves little friction, helping me spend the majority of my publishing time actually writing.

That’s a good thing.