A couple of years ago I had the pleasure of seeing Scott Belsky (of Behance and now Adobe fame speak about his book Making Ideas Happen at the Like Minds Business Book Club).
It’s a fantastic book which celebrates some of the things I value most - collaboration, creativity and getting things done! Here are my some of the passages I highlighted on my Kindle.
On collaboration and creative process
…among the hundreds of successful creatives I’ve interviewed, a fearless approach to sharing ideas is one of the most common attributes. Why? Because having the idea is just one tiny step along the road to making that idea happen.
Regardless of where you are in your career—and what stage your ideas are in—you should not only accept feedback, you should seek it out. Managers, coworkers, and clients have a responsibility to share feedback, and you should encourage them to do so.
“The genius sketch is a myth. Architecture is made by a team of committed people who work together… . Success usually has more to do with dumb determination than with genius.”
…people thrive when their judgment and autonomy are respected.
As you cultivate your team’s immune system, you will want to differentiate between skeptics and cynics.
Share Ownership of Your Ideas The more people who lie awake in bed thinking about your idea, the better. But people only obsess about ideas when they feel a sense of ownership.
Collaboration brings small sparks together to generate breakthrough innovation.
Harvard Business Review cited a recent MIT study showing that employees with the most extensive personal online networks were 7 percent more productive than their colleagues, and those with the most cohesive face-to-face networks were 30 percent more productive. Clearly, our respective communities—both online and offline—play a critical role in helping us refine our ideas, stay focused, and execute to completion.
Have a Tempered Tolerance for Change
…intersection of creative energy and organizational prowess where great ideas become actions and ultimately revolutionary achievements.
On getting things done
…successful creative entity must be comfortable alternating between these two creative phases: ideation and execution.
The way you organize projects, prioritize, and manage your energy is arguably more important than the quality of the ideas you wish to pursue.
Accountability, one of the most crucial benefits of engaging with your community, is what binds you to the relentless pursuit of your ideas.
Action Steps are specific things you must do to move an idea forward. The more clear and concrete an Action Step is, the less friction you will encounter trying to do it. If an Action Step is vague or complicated, you will probably skip over it to others on your list that are more straightforward. To avoid this, start each Action Step with a verb: Call programmer to discuss … Install new software for … Research the possibility of … Mock up a sample of the … Update XYZ document for … Address issue of …
An unowned Action Step will never be taken. Every Action Step must be owned by a single person. While some Action Steps may involve the input of different people, accountability must reside in one individual’s hands at the end of the day.
Aside from friendly questioning along the lines of “Did you capture that?” some teams take a few minutes at the end of every meeting to go around the table and allow each person to recite the Action Steps that he or she captured.
Actions are truly “delegated” only when they are accepted. Regardless of your method for managing Action Steps, it is vital that you (and your project partners) never accept an Action Step unless it is clear and able to be executed.
…minimize (or quit) all communication applications during certain periods of your day.
Constant motion is the key to execution.
Constraints serve as kindling for execution. When you’re not given constraints, you must seek them.
Especially amidst heavy, burdensome projects with hundreds of Action Steps and milestones, it is emotionally invigorating to surround yourself with progress. Why throw away the evidence of your achievements when you can create an inspiring monument to getting stuff done? When you make incremental progress, celebrate it and feature it. Surround yourself with it.
And this fantastic quote from British author A. A. Milne
“Good judgment comes from experience, and experience—well, that comes from poor judgment.”
Leave a comment
With the project we’re currently working on, I was tasked with taking the lead on the front-end side of things. Previously we used Bootstrap, with our styles applied on top, but this was no longer a good fit for a number of reasons:
- Large amounts of unused CSS
- Components had to be overwritten to fit our designs
- The grid system wasn’t particularly flexible
My gut feel was that we need our own framework, but before we went down that road, I took a look at some other options.
At one point we tried Foundation, mainly because the grid system seemed to be quite clever, but there were a number of reasons why that also didn’t work:
- Once again, large amounts of unused CSS
- Changing font sizes altered the grid system
- Browser support doesn’t reach back as far as we need it to
I decided to piece together our own framework, but to save time I wanted a reliable and flexible grid system, oh, and it had to be twelve columns.
After trying out numerous pre-built grid systems and finding none of them worked as we wanted, I was ready to give up and build it myself, until my colleague Nick discovered Neat.
Neat is the grid system that accompanies Bourbon, a solid collection of Sass mixins and utilities. After trying it out for an hour or so, I decided this was what we needed.
The great thing about using bourbon and neat is that only the styles we are actually using will be included in our compiled CSS, and we can also easily use our own classes keeping both our HTML and CSS as clean as possible from presentational class names.
I was now ready to piece together our framework. I already had some styles which were a mix of our own global styles, some bootstrap components (alerts, wells, labels etc), and a few other bits and pieces. These are now kept in their own github repo, and will be included as a git submodule going forward.
Here is a broad outline of how we now structure our CSS:
- Bourbon: Up-to-date CSS3 mixins
- Neat: Stable and flexible grid system
- Config: Variables to customize aspects of each site
- Craven: Collection of styles inc. normalize, bootstrap components and global styles
- Site specific: Any styles specific to each site
So far we’ve found this to be a maintainable way to structure our CSS, and we’re hoping once we port it across all of our sites it will continue to be so.
Leave a comment
It’s easy to take version control for granted when you work in software development as it’s such an integral part of the process. But it’s virtually non-existent in other technical industries.
Recently, when Github launched their new online STL viewer, I asked some friends who work with product and game design if they used version control for their source files. These are a few (edited) parts of that conversation.
Product designer 1: What is a version control for my source files?
Product designer 2: I think he means some way of ensuring that everyone is looking / working on the latest file?
Game designer: Version control can be hella hard for some people to understand… like their mind breaks when it’s explained to them.
Product designer 2: Well, all the major 3D / 2D design packages - especially the parametric ones - do this in some form. Although it’s all controlled by the software. The packages are expensive and generally these part management components add to the price.
Product designer 1: We’ve never used these tools at (redacted - major Australian electrical manufacturer) it would be so difficult to get our factories to abide by the procedures. Generally you just run an assembly and swap out old parts for new as it develops. Pretty sure the engineering departments at (redacted - major European electrical manufacturer) had a dedicated admin guy who would administer the 3D files. BEST JOB EVER."
There are a number of companies that are trying to solve this problem for designers (like Pixelapse, LayerVault and Beanstalk via their design preview feature), but that’s just really scratching the surface. I can’t help but think that the benefits that would be a massive if there was a meaningful (and non-proprietary) way to incorporate version control into more development processes.
Leave a comment
We decided to try out kanban/agile for the development of our new Kubrick platform. None of the team had much experience with agile and we all agreed from the beginning that we didn’t want to take a strict approach to it, but would like to try it out and see how it fits with us. This is what we ended up with.
The board
Our board has columns for Icebox (someday), backlog (someday soon), todo (next two weeks), in progress (now), QA (done but needs review) and done.
We use actual, real post-its. This has numerous positive side-effects: visibility of progress throughout the office, avoiding more software (we’re big Basecamp users here at Easyart), and taking pride in the “done” list. The negative aspects of this: no visibility on progress outside of the office (we have offices in London and Newhaven, and some staff working from home), no ability to comment or add details to the task and of course the questionable legibility of my handwriting.
Action tickets are either small (pink, ¼ day) or medium (yellow ½ day) tasks. Anything longer than that needs to be broken down or to become a discovery ticket. Discovery tickets (green, no time allocated) help us keep an eye on the more mysterious parts of the project, or various technologies, refactors or improvements that could be useful for us. They can usually be broken down either by workshopping the specific issue, or by spending 2 or so hours researching. Mostly they will spawn new action tickets, but sometimes the discovery is a dead-end.
Processes
We do daily stand ups at 9:15. We actually drag the whiteboard into the meeting room every day to have our stand-ups. I tend to waffle on, so these can sometimes run longer than 5 mins, but we do try to keep them short. These only happen Wed-Fri (which I’ll make the subject of another post).
No locked-in sprints. Being flexible about the amount of work in a sprint is very un-Agile and makes it difficult to measure the overall velocity and predict milestones, but so far that hasn’t been a massive issue.
Pair programming. This has been invaluable for us, both to increase our skills and share knowledge.
Weekly wraps. Stakeholders are invited to a recurring meeting every Friday at 4, where we demo the week’s progress. This is useful both for the team (who might not have been involved in each others' work) and the stakeholders (to get a clear sense of progress). It’s also usually paired with a well-earned beer and move the “done” tickets to the wall.
No user stories. Without user stories our process can hardly be called “agile”, but as we’re so far building a platform with no external customers we’re yet to find a place for user stories. I think in time we will.
What we still have to work out
Where does design and creative fit in?. I’ve found it challenging to work with design creative tasks within this process. Tasks like “design hero module for homepage” or “include links to related categories on product page” are fine, but we keep finding ourselves with tasks like “refactor homepage”, which is not very useful. So far I’m yet to find a compelling model for including design tasks in the agile workflow.
Leave a comment
About a year or so ago, I started keeping notes of my most-used Git tricks. I still refer back to them as I am so terrible at remembering commands (particularly unintuitive ones like deleting remote branches), so I thought they might be useful for others too.
Keep git from tracking permission changes to files
git config core.filemode false
Restore a branch to the remote version (i.e. if you have pulled an incorrect remote branch)
git fetch git reset –hard origin/master
Restore a single file to a version on another branch
git checkout branch_name path/to-file
Search for a string in the commit history:
git show :/search_string
Amend the last commit message:
git commit –amend -m “New commit message”
Toggle between branches
git checkout -
colourise all git commands
git config –global color.ui true
Use mergetool
git mergetool -t opendiff
Delete a branch remotely
git push origin :newfeature
Delete a branch locally
git branch -d newfeature
Delete branches that don’t exist on remote
git remote prune origin
This one is Github-specific: You can compare commit ranges by appending compare like so…
compare/master…someotherbranch
compare/master@{yesterday}…master
compare/master@{2.days.ago}…master
compare/master@{2012-05-01}…master
Leave a comment