I’ll be speaking at the SoCal UX Camp, and at 4pm we’ll be moving the shindig over to 7 Seas in downtown Garden Grove. I’ll buy a drink for the first five people that show me they have downloaded the UX Drinking Game.

7 Seas / Savori
12941 Main St
Garden Grove, CA 92840

 Comments | Comment

Looks spot on from what I’m seeing. Cheers.

© 2013 From Onward Search.

 Comments | Comment

I’ll be presenting “From Application To Portfolio: How To Get A Great UX Job” at the SoCal UX Camp Saturday, June 1. Heckling is welcomed and encouraged.

I’ll be the one wearing a Hawaiian shirt and shorts.

The address is:

Cal State Fullerton, Garden Grove Center
12901 Euclid Street
Garden Grove, CA 92840

It’s sold out, but there is a wait list.

 Comments | Comment

The users want it. The numbers show it. But that feature that proved so useful, it might be get implemented in 2014 — if ever. There might be a lot of reasons: The CTO doesn’t have the right team in place or may dislike the designer that designed the feature, the CEO wants the color red, or product is going after the wrong priorities. All decisions that are at expense of the user (and long term, at the expense of company profitability).

Design in large organizations isn’t for the faint of heart. 

Leisa Reichelt talks about the political or organizational struggles many designers face within their organizations in this great post:

Many times I’ve suggested a design approach only for the in house designer on the team to literally pull the design from their desk drawer or computer and to tell me how they tried to get the organisation to go this way two, three, maybe four or five years ago. They tried and tried, had no success, and filed the design away so they can get on with the work the organisation deemed acceptable or appropriate. It’s kind of depressing, and almost embarrassing when my main role is to advocate for work that was actually done years before I appeared. And sometimes it works.

…

Politics and egos are the main reasons that great design goes awry – either it is never presented (because presenting it is a risk to those egos and would be not wise politically), or it is presented and dismissed, or it is presented and then changed such that egos are not wounded and the politics are in tact, the design integrity is hardly a passing consideration.

 Read on…

 Comments | Comment

“So why should I understand what a product manager does?”

It’s because 60 to 70 percent of what Interaction Designers do has a direct correlation in skill set to the Product Management job description. Outside of pricing models and a few other business methodologies, good Interaction designers can easily act as Product Managers in many environments.

Great product management and product design is the crossroads of minimizing risk and maximizing value.

With the advent of the user experience process, it can be argued that many Interaction Designers are better trained in Product Management than the Product Managers they work with. Product Managers are trained in business theory and have to learn how to build and project manage a product; Interaction Designers are trained in the process of building a product and connecting it to engagement and business value.

It has many commonalities with great user experience — we push the boundaries of great design and technology while mitigating user adoption risk. That’s why learning how to act as almost a “second Product Manager” can be impactful: your influence can go much further than just the interactions because of how much you should know about the product development process.

It’s about showing everyone that great product design isn’t about control or dictating direction, it’s about impact and process related results. It’s about a team that where everyone can be a product owner and be part of the process. It’s about changing the dialog from management to team oriented results.

We can turn conversations from the worthless “make the button blue” threads to “what you are trying to accomplish” within context of great product development. Defining that context is the best result any Interaction Designer can deliver for their organization.

Understand the business model

Repeat after me: no service is ever free, you just aren’t paying for it.

When designing any product, the most likely goal is to make money. Some designers think user experience is some altruistic pursuit that’s funded by a magical non-profit money machine. Unless you work for a non-profit where you are trying to save the world, that’s wrong.

If you’re working for a startup with investors or a larger business that’s bringing in revenue, everything you do should lead to the almighty dollar, whether it be user acquisition, engagement, or the most direct way, a direct conversion. Designers design for goals, and what you are solving should meet the goals of the company.

Know the user journey inside and out, and figure out what you can do to get that user to convert to something tangible. Establish user goals that are directly related, and work with the product manager to make sure those goals are reflected in the product roadmap.

Understand prioritization

The last thing that an Interaction Designer should ever think is that they are the most important person in the organization.

Companies are very complex places where User Experience is but one part of the larger machine. Your wish list is prioritized with the wishes of sales (more features!), marketing (features they can talk about!), and engineering (features that don’t cause the system to crash!).

Pick your battles and ask yourself the following questions when pushing any feature:

• Is shipping more important?
• Do you really need it to be pixel perfect?
• Does every form element need inline help?
• Can you get by the minimum viable user experience?

If you take an iterative approach to design, you can learn more with smaller steps than with giant leaps. Remember that every minute you spend on a feature it’s costing the company money. If you ask developers to build it, it costs that multiplied by the number of developers on it. If it’s a feature that is half baked, you’ve wasted precious time and money.

In other words, pick your battles wisely.

Understand the organization

Interaction Designers should never end their thought process at how the user uses the application.

What User Experience designers should be doing is talking to almost everyone in the company and figure out how the complete service works, from customer service to accounting to engineering. The best opportunities are usually outside of your job description.

The best example is customer service: representatives on the front lines are some of your best allies. Ask them questions over lunch or a couple of drinks, and learn their jobs. Sooner or later, you can propose solutions that make their lives easier.

Many times, those solutions are what I call “two-fers:” you can solve two pain points at the same time.

At one job examined at the customer service process and figured out low-cost ways to improve the process by including more help text before customers asked questions. Emails dropped 25 percent over a month, and revenue went up. It the end, we had happier customers and cut overtime to zero by providing better solutions.

Understand conflict

The best thing about the three legged stool of Product Management, User Experience and Engineering is the healthy conflict it generates.

Conflict generates passion, viewpoints, and eventually results in better solutions if handled right. You can turn that conflict into an advantage and control the conversation. Here’s how:

Have a beer with the engineers to understand their pain points. Ask them questions about implementation, and think about solutions. Have a beer with the Product Managers and ask what they are trying to get accomplished. Ask them questions, and learn their pain points.

Then you can be white knight that rides in and saves the day because you can propose the solution that meets both the goals of product (profitability and engagement) and engineering (stability and less complexity). You can facilitate and negotiate. This process builds trust not only in the UX process, but the product management process as a whole.

Understand context

Product development can be the Tower of Babel, but great designers can be the Babelfish of any organization.

Every once in a while, I slip into UX Speak, which is code for using jargon thrown around at clients for processes and terms that we purposely make hard to understand. Ethnographic research? That’s studying users in their environment. User Journey? That’s that pesky user lifecycle thing. Wireframes? Personas? Use Cases? It goes on and on.

We should be speaking in the languages of the people we are working with. Engineers want to hear engineering terms. Product Managers want business terms. Everyone wants a common language to speak about the common goal.

We should define that common language for them.

Set the common thread of communication by describing the business in language everyone can understand, and evangelize that in every corner of the organization. Gently correct users during the product definition process, and you’ll be amazed how quickly context will be understood.

Great product leaders create one path that everyone can follow, and that’s as simple as defining where the path starts.

Understand ownership

Ownership means that you care.

The biggest difference between being an Interaction Designer and a Product Manager is exactly this: Product Managers are product owners — they are where the buck stops, and are ultimately held accountable for every decision.

They are also responsible for being a leader, and getting buy in from the organization. If they can’t build support with soft skills, no amount of mandates from the CEO will save the product. Everyone from the programmers down to the customer support will ignore the product manager (I’ve seen it, and it’s ugly).

If you show ownership in your work, you’ll fight for what you think is right, and will put your job on the line if you think a way of think. It means taking chances, not playing it safe. It means making decisions that you own, right or wrong. It means taking responsibility for all calls, good and bad.

The Money Shot

Great Designers and Product Managers get people excited about creating great products without the need of a title, and should be able to explain holistically how the decisions made contribute to the long term success of the product.

That may mean making decisions that may seem counter intuitive in the short run, but if they can describe their vision, that all important buy in can be an important asset in product success. Evangelism in any field is a great skill to have, and if you can cover more than just the UX role, that makes any team an unstoppable force.

 Comments | Comment

One request I made when I started the new job was to include Product Design in the title, because I believe a) you can’t expressly design User Experience, and b) User Experience is everyone’s responsibility.

There’s another divergence in UX: in-house versus agency. The goal may be the same (usable product or website), but how you get there varies mainly because how you have to communicate product design. I’ve worked on both sides, and my approach to how I get things done is very, very different.

In the agency world, wireframes are deliverables. In the product world, they’re wasted time and money if you can communicate your ideas quicker using a whiteboard, prototype or anything else.

David Cole covers it eloquently in his post:

Increasingly the best designers of our time are not working for agencies, but for in-house teams at startups and tech companies. I think this is an important shift, not just for where the work is done, but how the work is done.

…

Looking back at the ideas espoused by the UX community, I find their relevance to my work winnowing by the year. Many of the practices seem forged in the fires of consultancy. Advocacy is a repeat theme in UX writing, but is borderline irrelevant when working for a product- and design-centric organization. Similarly, when you have internal stakeholders who understand the design process, you don’t need to worry about constantly building consensus. Deliverables like lengthy specs, comprehensive wireframes, and pixel-perfect PSDs are all artifacts from a time when risk-averse clients needed to enforce progress and limit variability. Inside of a product company, these efforts waste time, create politics, and mask responsibility.

Read the post here.

 Comments | Comment

Very, very funny.

 Comments | Comment

 Comments | Comment

From GetResponse

 Comments | Comment

They let me in. Big mistake.

None of my experiences appear officially on my LinkedIn profile or my resume, because what I do is much more than what I do professionally. But each helps me in the day job more than I could ever admit, because while it’s not relevant to design, it is to the process to creating amazing things and seeing the big picture.

I don’t tell many of my friends about some of them, because it seems overwhelming and I’m a fairly private person, but when I meet other people that have also taken unorthodox paths in life, there’s a certain kinship that is wonderful.

Each experience brought me something different and varied, and each had it’s own unforgetable moments: from a shake machine catching on fire, to photos that seem to capture something other than reality, to driving down the Harbor Freeway and seeing the rightful anger of 1,000 neighborhoods glow in the night.

Each I’ve took pride in and I’ve grown from.

Each has helped me learn from my mistakes.

Each has helped me leave a legacy at places I go, friends I meet, and places I have worked.

You can read the post here and learn more about me.

 Comments | Comment

From Inigral (they product Facebook applications for Colleges). These numbers are important to watch, because college students become heavy consumers of content and social media in a hurry.

 Comments | Comment

Now’s the time many designers are graduating from college. That’s great — we need more designers in the field — but it’s really, really hard to break into.

I’ve written about this a lot (read my Career Guide, I have about 40,000 words there about this and probably should publish a book), but I still get the occasional email asking me questions about how the process works, where to download a resume template, and if we actually get to do the complete UX process (The answer: “No, we don’t, especially in startups.”).

So, before you email me and I make fun of you over the phone or Skype, here’s a few questions you should ask before you hit the send button.

Did you intern last year or did you do any side projects?

Yes, awesome. You have something to show on your first interviews!

If you haven’t, you’re already a year behind of most your classmates. Some have been working on startup ideas or coming up with neat little websites that do things.

Many students spend time during their Bachelors and Masters programs working as interns to learn the craft of interaction design. They might have been working on something during school (the best idea is to turn a school project into a potential startup).

Remember, the job search isn’t fair. If you don’t put the effort in moving ahead of your classmates, your path deserves to be much, much harder. You have to make your own luck, and that’s through hard work.

Do you have a portfolio?

That’s where you put all those projects you did at your internship. When you see how thin the portfolio is, you’ll be motivated to do more work.

The portfolio shouldn’t be cute or show too much of your personality (they aren’t hiring you for your like of cute flowers). What it should show is your line of thinking, soup to nuts in a project so they know how you think.

Behance is good enough for most people (Every time I talk about this, I bring up LaiYee Lori’s portfolio, because it’s amazing), and most of us just want the design to be clean.

What’s your skill set?

Do you know how to do front end coding, can design simple graphics in Photoshop, or know your way around Visio? Those are the kind of questions that you’ll be asked at any interview or first job interview.

We honestly don’t care about the super cool science project you did; we want to know how you built it so if there’s something than you can do we can’t.

Most of older designers will be looking for interns that know how to code up a page because a) we hate doing it, and b) some of us don’t have that in our skillset. Frankly, there’s a serious shortage of front end developers right now, so if you can pick up that skillset before you graduate, you’ll have an advantage over every single designer you are up against. You have a whole summer to learn it!

I will gladly give that work to them because they can build interactive prototypes that are perfect for doing usability testing.

And, if you’re smart enough, you’ll get to do the testing too.

I did mention both of these are perfect to put in your portfolio, right?

Are you applying through applicant tracking systems?

If you’re applying directly through them, it gives you about .41 percent chance of getting the job. That’s right around a 1 in 260 chance.

You’re better off buying lottery tickets or responding to one of those Nigerian scams.

All that work you do to pretty up your resume may not work — some applicant tracking systems present only a text only version of the resume on the first display (they have to download it to see the real deal). This is the first impression the recruiter gets. It may work for smaller startups because they usually accept resumes through email.

The better thing? Stalk people on Twitter or at events and become a personal referral.

I encourage you to find companies on LinkedIn that you want to work at, find out who works there, and find them on Twitter. Or even better, go to a something like Jobvite’s job board, where you can see the connections you may have at the company. Invite them out for a coffee.

Being a personal referral works: Those people that apply for jobs through personal connections or recruiters have a 10 percent chance (or better) of getting hired.

Are you an idealist looking for the perfect job?

You probably aren’t going to be hired into an organization and get to develop Facebook Home. you’ll be a wireframe monkey or doing research that may (or may not be) used. Don’t expect to get something at Twitter. You can apply, but don’t bet on it.

The employers have the upper hand, and once you realize that life becomes much easier. The competition for those jobs is intense, and best if you actually know somewhere there.

Even better, look at companies that are boring, and see if they are interested in internships. Reach out to companies without a program. They might create one for you. Go to any meetups for these companies (and ironically, not the UX ones) to talk to recruiters and hiring managers.

If you’re lucky, the work might be interesting, but the reason you intern is that you gain valuable connections in your profession and learn who the process is different than the ideal they teach in school.

Are you discouraged?

Don’t be. Don’t give up. You have an amazing path ahead of you: read Christina Wodtke’s post for more education of how you should craft your career.

User Experience is a meritocracy — we want to see what you can do. Find the right place, and you’ll do amazing things.

 Comments | Comment

Twitter is a great resource for User Experience information and engagement with professionals in our field. I also think it’s invaluable as a professional branding tool. One of the groups that has embraced this most are user experience professionals.

I have a list of people that I respect and follow to retweet their content. The list I have is literally called Stuff I Follow. It’s not all UX types — some of them are personal friends — but it helps me keep up to date on what’s going on.

Yes, I play favorites. Yes, this may promote people I like. But it’s my list.

Here are some of my favorites, in no particular order:

• Ha Phan — Designer extraordinare out of San Diego working at a cool startup called Porch, Ha’s commentary on user experience and engineering has a sharp and pointed wit few can match.
• Jon Fox — Jon’s the Director of User Experience at a new startup down in Los Angeles and has a lot of great thoughts on startup UX. We’ve traded a lot of ideas on dealing with product management. We’ve also traded war stories, and is a curator of The Big Idea List.
• Coburn Hawk — He’s the Director of User Experience at Magento, and another curator of The Big Idea List. We’ve drank, talked, traded war stories also. His passion project, The Middle Man.
• Winnie Lim — Winnie is the amazing designer behind Simple Honey, a travel personalization website. She’s the best example of introverted designer that uses social media to communicate. She also has some amazing stories with meeting founder types in San Francisco two weeks after touching down. The best days of her work are really ahead of her.
• Jake Hercules — Sometimes we have to see the field through the eyes who’s new and excited by it, and Jake’s that person for me. An Usability Researcher at Citrix, super sharp and does a great job merging theory with real world challenges.
• Lynn Teo — Lynn’s the CXO over at McCann Erickson, and one of the best public speakers on UX I have ever seen. An Carnegie Mellon alum, every single one of her comments about Experience Design is insightful and informed. She also sees Twitter is a great engagement channel and a way to create tangible relationships.
• Timothy Whalin — Timothy is a great guy out of Denver that retweets a lot of awesome information about user experience and visual design (some of which I retweet). He also engages with users, which is a sign of a true Twitter enthusiast.
• Leah Reich — Leah’s is an ethnographer, and it shows with her live tweet observations of fellow commuters on BART — one of the best uses I’ve seen of Twitter. Her engagement on Twitter is solid.
• Kristen Johansen — She’s the Director of Product over at the gold standard for online training, lynda.com. Very straightforward, insightful commentary on the art of design.
• Paul Sherman — Paul’s the former leader of the Usability Professionals Association and a consultant out of one of the flyover states. Smart guy. Great at super technical solutions.
• Jonathan Lupo — Very smart, and he’s done something with his agency Empathy Lab few have done: sold it to a much larger company. Really worth following his feed.
• Ian Fenn — He’s a really, really sharp guy, and is really opinionated. I also like Ian because he engages instead of just broadcasts, a true example of someone who understands how Twitter should be used.
• Ian Smile — A great curator and editorializer of UX content, Ian brings a sharp wit and a keen eye for what’s good in the field. His tweet, “Why has “no portfolio” become a bragging right in UX? I hear it too often to not ask” was classic.
• Jared Spool — Whenever I want to know how bad flight delays are on United, I read his tweets. Really informative stuff about user research, and we’ve had some great conversations about organizational theory. Really funny avatar.
• Jonathan Korman –– Never mind his hair (I think he has the longest hair in UX), or his vocabulary, he has one of the smartest and most eclectic feeds in UX.
• Startup L. Jackson — He’s not really a person, but an impersonation that relates it’s stories to the startup world. Always wise, seldom boring, and always worth following.
• Laura Klein — Sharp wit, very knowledgeable, uses profanity when appropriate, and currently reading her Lean UX book. Worth following both her feed and her blog, Users Know.
• Dorian Taylor and Lynn Polischuik (2,800 followers) — I listed them together because they are usually engaging with each other, and both of them reside in Vancouver, so it’s useful to keep track of the scene up there. Very smart conversations, plus a lot of Lynne’s dog pictures.
• Jason Shen — He’s a San Francisco startup guy, and writes a kick ass blog about kicking ass. All an absolute must read, truly motivational.
• Dustin Curtis — A mostly personal feed with the occasional interesting quote (CNN is the TMZ of news) makes it a worthwhile read.

 Comments | Comment

Yup, it must be April 1.

 Comments | Comment

How to choose a 486. Scary.

 Comments | Comment

Great read, for you data wonks. Data has to have meaning:

The problem with data is that the way it is used today, it lacks empathy and emotion. Data is used like a blunt instrument, a scythe trying to cut and tailor a cashmere sweater. Some folks do a better job of making data interesting — like the fine folks at Foursquare. They use cutesy phrases to remind me of my coffee addiction and occasionally point out that Jared Kim and I are besties when it comes to eating ramen noodles or visiting Hakkasan, but they don’t really tell the whole story and they need to do more.

…

[Foursquare] knows that I check-in with a handful of people, whose relationship to me can be inferred from the social graph. Add to the mix the fact that I have left tips and taken photos at that spot. Now, compare it to all other coffee shops I have checked into and how they rank against this one location. Add all of them up, and you end up with a rudimentary conclusion: I don’t go to this coffee shop simply because it’s an interchangeable part of my daily routine, or because it’s on my way to work. I visit it because it is my happy place, my one cup (or dozen) of zen. And a company like Foursquare could use that fact to package even more compelling experiences for me.

…

The symbiotic relationship between data and storytelling is going to be one of the more prevalent themes for the next the few years, starting perhaps inside some apps and in the news media. I was reminded of the future filled with data narratives when I saw this visualization – Out of Sight, Out of Mind, by Pitch Interactive. It takes data about drone attacks and makes them visual and easy to understand, and in doing so, elicits a strong reaction.

But it merely scratches the surface — presenting a slight improvement on an infographic that might have appeared in the pages of a magazine. In a future where we have tablets and phones, packed with sensors, the data-driven narratives could take on an entirely different and emotional hue.

How are you using data?

 Comments | Comment

Less clutter. Closer to Mobile First.

Thoughts?

 Comments | Comment

I’ve been kicking the tires of a new collaboration platform, Hunie. It’s a place where designers can posts their designs and get feedback from other designers who are experts in the field (you know, not those self proclaimed experts).

Designs are easily annotated, and it provides even non-designers and great platform to comment and collaborate. 

You should sign up. Now.

Congratulations to Damian Madray on the launch.

 Comments | Comment

 Comments | Comment

Every once in a while, I read an article that is completely spot on about software development. Oscar Godson’s What I Learned At Yammer is one of those articles. Remember that he’s a developer when you’re reading this, not a user experience professional. Great developers understand the user experience process and how it works with software development. They know what it means to test, build fewer features, and concentrate on an end goal of a product sold holistically, and not by bullet point.

Every one in software development should read this. Cheers.

Today marks my last day at Yammer. It’s been a hell of a ride. It’s bittersweet. I’m leaving Yammer to be back in PDX to be near family and long time friends. I’ll be starting at Simple as a front-end dev where I’ll be changing banking for the better.

While at Yammer I learned a lot. Not just about programming, but about running an engineering team and project management as well. Yammer not only made me a more skilled programmer, but a smart programmer. I decided to write up some of the things I learned outside of just programming that I’ll probably bring with me to every company I work with in the future.

Test all the things

I can’t stress this enough. If there’s one thing I learned at Yammer it’s that you need to test everything, and by everything I mean, everything. It’s not just about getting your users to come back or to engage with your software more. That’s a large piece of it, but it’s also about saving countless engineering time. A lot of people I talk to who don’t do any testing say that they feel their intuition is doing fine because they can see that the overall new and returning users are increasing. What they’re missing is that, how do you know what feature is driving those gains? Which features are hardly even being used? Could you increase your new users by 2x, 4x, 100x, what it’s increasing at now?

I spent some time trying to think of a good analogy of this problem and this is the best I could come up with:

Not testing your software is like playing darts in a pitch black room. When you throw the dart you will be able to hear if it hit the target or hit the wall and fell to the ground. What you can’t really do is adjust your throw. You don’t know where you hit the target when you did, just that you did. Testing is like turning on the lights. Now you can see the target. You might still miss here and there, but if you miss you can readjust.

Testing also allows you to figure out what features to kill before you spend too much time on them. You might have this idea that some feature is going to be super awesome and everyone and their dog will want to use it. So, you spend all this time building it out and you put it into the wild. Overall it gets good reviews from a vocal minority (probably power users). What you might not know is that most people don’t really use it or don’t understand it. Now you’re spending 90% of your time making features for <10% of your users, or not, but you really have no idea. This feature could be expensive time wise to keep up. Maybe it has a lot of support tickets or is unreliable for some reason.

Testing allows you to move faster, make better products for consumers and keeps engineers from wasting time with features nobody uses.

Unit test all the things

I didn’t get how important unit tests were until I had to refactor a large chunk of code for a project. I had absolutely no clue what I could and couldn’t remove or change and even if I thought I could remove or change it I wasn’t sure if I had broken anything somewhere else in the product. Around the same time there was a huge push at Yammer on the front-end side to put tests on everything. It became a rule that you can’t ship it unless you have tests. Looking back I wish that was the rule from the start.

A lot of people think tests slow you down and it’s over hyped. It’s not. Sure, making a small bug fix that’s a 1 line change and having to write 12-15 lines of test code seems overkill and a waste, but you get all that time back tenfold when someone goes “Huh, wonder if we need this line here?” deletes it, and the “preventLaunch() is called to prevent accidental nuclear weapon launches” test fails. Not only does the next guy know it’s important and why, if the code needs to be refactored they know what they’re missing and can make sure the app runs as it did before.

Autonomy and trust are a must

If you’re the owner, manager, etc, let your employees do their job. Hire engineers you respect and leave them alone. If you can’t trust them to do their best work and work that’s acceptable for your product you shouldn’t have hired them. Simple as that.

Instead spend your time helping them break down obstacles and blockers. Make them happy. As long as they get their work done, don’t question when they come and go or if they watch cat videos and browse Reddit /r/wtf all day. Some of the best engineers I know work only a few hours a day, but get more done than others working 8hrs. Being creative is hard and giving them more rules kills creative thinking.

No limit on vacation isn’t as great as you would think

Originally Yammer had no policy on vacation. They called it the “take what you need” policy. We all rejoiced. I thought it was amazing and it’s a great selling point when trying to recruit people. The problem is nobody takes vacation when they can’t lose it and there’s no pressure to use it. When you do use it there’s no limit so you have to decide what’s acceptable. Obviously, not every employee thinks this way, but when we introduced a three week vacation policy people were actually happy including me.

My suggestion to startups thinking about unlimited vacation? Instead, give 3-4 weeks of vacation, but if an employee wants more just give it to them.

Actively try to prevent burnout

Burnout is real and it’s deadly to your company. Yammer was great about this. We were regularly asked how busy we were and how we felt about our workload. We were asked if we felt others were feeling overworked too. If you were feeling overworked it got fixed.

Your employees shouldn’t have to work long hours on a daily basis. If your employee is working long hours to complete a projects regularly you’re mismanaging the projects. The choice is pretty easy actually: would you rather have an employee for 1 year who worked 12-14hr days but burned out, was unhappy and quit, or an employee for 5 years plus who worked half as many hours, but was happy and working optimally? The hours don’t matter it’s what they produce.

And lastly, use Yammer

I had never used Yammer until I started at Yammer. In fact, to be honest, I was skeptical about working at Yammer at first because I wasn’t sure how interesting it would even be. “It’s just some crappy Facebook clone”, I thought. My friends there insisted it wasn’t, so I decided to give it a shot.

The first day it became pretty obvious just how useful it was. All our docs were on there. On-boarding processes, tips for new employees, everything. It was all where I could find it. I could message HR about general HR questions, in the public feed, get responses and months later someone else would drop by and say thanks or expand on it. People don’t realize just how useful it is and once you start using it you forget how useful it is until you don’t have it anymore and you’re jumping between a dozen different products with fragmented conversations between email, chat, and other products. Yammer pulls it all together.

It’s also extremely useful for project management. At Yammer we’d make a group for each team (engineering, front-end, rails, etc), as well as groups for each project (inbox, online now, etc). This made it so we could put specs, comps and the conversations around those in a central location where we could easily find it. This also killed the need for doing stand ups, weekly team meetings or SCRUM. We could see what everyone was working on at any time in any project. It’s also extremely useful to be able to share a Yammer thread to show past decisions about the product and why those choices were made.

Another added bonus is there’s a great API. You can have things auto post things like deploys. “Oscar is deploying release XXX to production”, for example. Or, if your spec fails, “Oscar broke the build!”. Super handy because now you can have an archivable conversation about these things. Maybe that production deploy was failed and brought the site down. 6 months later someone could link to that thread.

That’s all folks!

There’s so much more I learned, but I’m thinking about expanding on these individual topics, or things I didn’t cover in separate posts. Yammer was the first job where I came out feeling like I had more to offer my next team aside from just better programming skills. If you have any questions about any of these things feel free to contact me.

 Comments | Comment