• The solution to premature commitment bias starts with a K

    As you may have noticed, I have recently found myself consumed by the problems facing technology entrepreneurship today.  In particular, it’s the amount of sheer waste that gets to me.  As I’ve mentioned before, the real tragedy here is all of the time that is wasted by really talented entrepreneurs and early employees.  Unlike money, time is non-renewable.  You don’t know how much you actually have, and you can’t make any more of it when you run out.

    As an entrepreneur about to embark on my next journey, this is something I think a lot about.  I want to avoid premature commitment bias like its a plague (which, by the way, it is.)   And I want to find myself on the right side of the disequilibrium of success!  I don’t want to bust my ass for 2-5 years just to chase a mediocre dream.  Not worth it.

    So here’s what I’m going to do

    I’ve decided that it’s time to take a new approach to building companies.  That approach involves assembling a team of the most talented people in the world.   Then we’re going to unearth really hard problems and solve them.

    Companies will be formed.

    Fun will be had.

    What about all the details?

    I don’t know them yet.  It makes sense to figure out the details of how this thing works after the right people are on the team.   Here’s what I do know, though: we’ll be calling ourselves the Kemists.

    And we’ll have a website that looks like this, and a logo that looks like this:

    Kemists Logo

    If you know remarkably talented people who like building companies, or are one yourself, send them to (or go to) the site and apply.

  • A followup on rapid prototyping

    In an earlier post, I offered some thoughts on rapid prototyping. I mentioned my preference for the “high-fidelity prototype”, which leaves very little room to the imagination and provides users and stakeholders with a realistic sense of the user experience of the product.

    I’ve been using a couple of different rapid prototyping tools and thought I’d offer some opinions on their limitations and what looks promising as I see it.

    Rapid prototyping tools

    I’ve been using Balsamiq and Axure a fair bit. I think they’re both pretty good tools, but the problem is prototyping and design are subsets of communication and these two tools don’t seem to get that.

    You don’t come up with a design in isolation, you need to validate it with users and other stakeholders. For the most part, these tools make it easy to put UIs together, but they have issues when it comes time to send out your work for feedback. The biggest problem I see with both is managing workflows in the review process.

    Because they’re desktop based, you need to make all supporting files accessible to your reviewers and provide instructions to them for getting the prototype to look and act like it’s supposed to.

    In reality, by the time someone gets to the review, you’ve already made changes. Every time you send out a new iteration, you need to include lots of attachments and send everything out all over again. Getting timely feedback can get so aggravating that you reach a point where you don’t want to bother doing it at all. Major pain.

    And then there’s ProtoShare

    I got to thinking, “There must be a better solution, even if I have to build it myself”. Then I discovered ProtoShare.

    There are several things I really like and admire about ProtoShare – both the company and the tool, including:

    • When you first go to ProtoShare’s website, they talk about design as a form of communication, which I agree with and relate to. They seem to “get it” in that regard.
    • With ProtoShare, I can prototype in a browser but can also link pages to one another. Even though they’re just sketches, at least I’m able to link to them. Axure can do this too, but it’s a desktop tool so everything has to be uploaded somewhere.
    • The killer functionality with ProtoShare is its one-click publishing capability. You can prototype your whole site and then publish it to a live link to be shared with others to get feedback.

    Another advantage ProtoShare has against Balsamiq is ProtoShare uses built in Javascripts. Every time I use a Flash or Flex app, it doesn’t feel like a web application because of the way it handles scrolling, right clicks, text highlighting, etc. It’s the “Adobe way” of doing things that, to me, is just plain annoying and doesn’t feel natural.

    A few shortcomings

    The shortcomings I see with ProtoShare center mostly around pricing.

    • First, it’s not really cheap. The Professional version is $49.99 per month. For that you get up to 3 users and 10GB of web storage. Additional users cost $25 each – every month.
    • If you want to get feedback from someone, that someone needs to be a ProtoShare user. I really don’t see asking my reviewers to become ProtoShare members.
    A step in the right direction

    While it’s not perfect, I see ProtoShare as taking rapid prototyping to the next level. It’s not just wireframing, it’s really a collaboration and communication tool. Because it’s built in JavaScript, it feels native and not clunky. All in all, I’m a pretty big fan.

  • Some thoughts on rapid prototyping

    So I have made my feelings regarding functional specs pretty clear already. It’s clear to me, and a lot of other folks, that prototyping can be a very powerful way to capture requirements. What I have been thinking more about lately is, “What is the best way to do that?”

    While there probably is no single right answer to that question, I have been learning a lot so far. Here’s where I’m at.


  • Kanban and Agile Software Development — Part 3

    Where we left off

    In the introductory Kanban post, I provided some background on Kanban and in Part 2, I went on to discuss several ways Agile and Kanban have been put into practice together, including examples of some of the several different ‘flavors’ of Kanban being used in software development.

    Now I want to discuss some of the key tradeoffs that might occur in using Kanban systems for agile development, leave you with some food for thought and discussion, and provide some resources for digging into the topic further if I’ve stirred your curiosity a bit.

  • Kanban and Agile Software Development — Part 2

    Where we left off

    In the introductory Kanban post, I provided some background on Kanban in order to give you some context for how Kanban might be used in an agile software development environment. Now I want to provide some insight on how Kanban is currently being used with agile and why I think the idea of doing so holds some merit.

    In Part 1, I mentioned that Kanban and Agile share some basic tenets: improve efficiencies in a non-prescriptive environment where rules are kept to a minimum. I also said that at the very least, incorporating Kanban into an agile environment by combining rules 5 and 6 of Toyota’s Production System (TPS) seemed to make the most sense. In other words, using Kanban as a means for fine tuning in order to stabilize and rationalize the process could bring a lot to the table in an agile software environment.

    Let’s take a look at some of the ways it’s been done so far.

    How has Kanban been implemented in an agile software environment?

    In his article, Kanban Applied to Software Development: from Agile to Lean, Kenji Hiranabe discusses several ways Agile and Kanban have been put into practice, including:

    • Agile Kanban
    • Sustaining Kanban
    • Lean + Agile Kanban
    • Portable Agile Kanban
    Agile Kanban

    Hiranbe equates Agile Kanban to ‘Task Kanban’ in that, like Agile, it doesn’t show processes, such as Development, Testing and Deployment, but instead relies only on visual cues that show the status of a story, such as To Do, Doing and Done. He uses this photo of a Task Kanban implemented by the JUDE development team at Change Vision, Inc. to illustrate:

    Agile Kanban Board

    Agile Kanban Board

    Sustaining Kanban

    Unlike Agile or Task Kanban, Sustaining Kanban has separate and serial processes (Development, Testing, etc.) and the Kanban cards move between those processes from left to right, as shown in this example, a pieced-together image of Yahoo’s Kanban system from Jeff Patton in his article, Kanban Development Oversimplified.

    Sustaining Kanban Board

    Sustaining Kanban Board

    How Yahoo’s Kanban board works:

    • The circled numbers along the bottom are the number of stories allowed in the corresponding column.
    • The boxed numbers in the left column represent an approximate wait time in days, so items at the bottom will have a slightly longer wait time than those higher up on the board.
    • Stories start on the left side and move to the right across the board as they progress through various phases of development. Those in the top row are in progress. As they complete a phase and move to the right, stories below them are moved up.

    Although at first glance you might think otherwise, Hiranbe explains, “Sustaining Kanban is not a classic waterfall process, where all the requirements are ‘designed’ at one time, ‘developed’, and ‘validated’ at another time, which would cause all the cards to move in a group. Instead, the cards move one by one, like the one-piece-flow of manufacturing.”

    Using the Yahoo example, you can clearly see the “flow of work” concept used in Sustaining Kanban is different from the “iteration” concept of agile. And, in order to be a true ‘pull’ system, rules would need to require that only the next group to the right is allowed to move the cards on the board.

    Lean+Agile Kanban

    Hiranbe describes Lean+Agile Kanban like using Agile Kanban synchronously within each process and using Sustaining Kanban asynchronously across the whole value stream of processes


    Patton also found a smaller “portable” Kanban system he in a project being developed by Central Computer Services, Co. At Central, a team works in several smaller sub teams (usually pairs). When a sub-team pulls a user story, they break it down into their tasks and post them onto their own portable Kanban board (in this case, a bulletin board they can carry with them).

    Kanban Nano

    Kanban Nano

    In Central’s case, the Kanban system consists of two levels:

    • A project level in which a card represents a user story.
    • A team (or a pair) level where a card represents a task.

    Central uses the term ‘Kanban-nano’ to refer to its agile-Kanban system.

    It’s just another way to be agile!

    The idea of using a simple task board with index cards or sticky notes is as old as Agile itself.

    Even after seeing only a few styles of Kanban in place for agile software development, it’s certainly not a stretch to imagine other variations that could be used in order to create hybrid agile-Kanban systems. One example is Scrumban, fully discussed by Corey Ladas in his 2008 paper, in which he describes Scrumban as “Incrementally enhancing Scrum with more and more pull-like features.” In doing so, Ladas says, flow becomes smoother as process capability improves, providing opportunities for kaizen.

    The beauty of the Kanban system: it’s very visual. If logjams occur they’re obvious and action can be taken to address them.

    Over time, the process of improving the system is considered ‘smoothing’ or production leveling, and is sometimes referred to in production as “heijunka”. It’s a technique for reducing waste and is an important part of the production efficiency in the TPS and in lean manufacturing in general.

    So, at least to this point, you might agree as I said in part 1:

    “At the very least, incorporating Kanban into an Agile environment by combining rules 5 and 6 of the TPS seems to make a lot of sense, i.e., using Kanban is a means to fine tuning in order to stabilize and rationalize the process.”

    But what are the tradeoffs?

    Phew, that’s enough to read for now. In Part 3, I’ll discuss some of the tradeoffs that might occur and if bringing Kanban into an agile environment necessarily means we lose the collaboration between teams with different perspectives, a very important part of product development in my mind.

    I’ll also provide some additional resources you can use to find more information on using Kanban in an agile environment.

  • Kanban and Agile Software Development — Part 1

    I’ve never made it a secret that I am a fan of agile management practices, both inside and outside of software development.  Historically, however, two things within the agile space have always been a little bit frustrating to me:

    1. First, folks too often view different flavors of agile as competitive instead of complementary.  I hear questions like, “What’s better?  Scrum or XP?”
    2. Secondly, there aren’t that many great resources for learning about the practical reality of implementing agile within an organization.

    I have heard about Kanban systems applied to software development for a while now, but mostly through conversations with other agile practitioners. After doing some research, I’ve found that there were not many resources on the internet about Kanban and how it is used in agile development.  So I decided to pull something together here and use it as a basis for further discussion.

    Kanban’s origins and use as a JIT manufacturing tool

    First, what exactly is Kanban?

    The word kanban is Japanese. Roughly translated, it means ‘signboard’, ‘billboard’ or ‘card you can see.’ In its original usage in 17th century Japan, Kanban was a wooden or metal sign often used to represent a trademark or seal.

    In more modern times, however, Kanban became a term used in Just-in-time (JIT) manufacturing systems that seek to reduce in-process inventory and its associated carrying costs, most notably by Toyota. Thus the concept of Just-in-time manufacturing has also become known as the Toyota Production System (TPS).

    JIT or TPS is a lean, pull system of production. American manufacturing has traditionally been based on a push system where the manufacturer estimates the quantity of product it must produce in order to meet forecast demand. A push system can result in either a shortage or surplus of materials needed for production depending on the accuracy of that forecast.

    Conversely, pull systems like those used in the TPS rely on observed and not forecast demand. Signals at different points in the process are used to determine when more parts are needed. To illustrate the concept simply, imagine a parts bin on the factory floor with a Kanban card (signal) inside that carries part identification. When the bin is empty, the bin and the card are taken to the factory’s store for replacement. The factory store replaces the empty bin with a full one containing its own Kanban card. The factory store then presents the empty bin and its Kanban card to the appropriate step in the supply chain for replenishment.

    In such a system, as long as there is one spare in the factory store, the process will never run out of needed parts and supply costs are only incurred when they’re actually necessary.  While it may not seem revolutionary at first blush, it turns out that it is.  This subtle shift in thinking can have a dramatic impact on efficiency and waste.

    The general flow of Kanban would look something like this:

    Kanban Process Simplified

    Courtesy of leanandkanban.wordpress.com

    OK, so software development isn’t manufacturing

    By now, you’re probably thinking:

    “This is all well and good in a factory production line, which is a very linear process where the product moves from one assembly stage to another in orderly fashion and once the product moves form point A to point B, it doesn’t come back (provided quality is satisfactory when it arrives at point B). But software development doesn’t always operate in a linear process.”

    It’s true that flow is often non-linear with software development. It’s not always a clean handoff from elaboration to development to testing.  Sometimes design and development are happening in parallel, for example. Plus, we’re talking about labor and not physical, raw materials.

    However, Kanban is in use in lean non-manufacturing environments and, in fact, Kanban has already been adopted in some agile software development environments. That’s likely because Kanban is relatively easy to adapt to specific environments because there aren’t a lot of rules.

    The 6 rules of Kanban and the TPS implementation of Kanban

    Kenji Hiranabe1 succinctly lists the rules of Kanban as:

    1. Customer (downstream) processes withdraw items in the precise amounts specified on the Kanban.
    2. Supplier (upstream) produces items in the precise amounts and sequences specified by the Kanban.
    3. No items are made or moved without a Kanban.
    4. A Kanban should accompany each item, every time.
    5. Defects and incorrect amounts are never sent to the next downstream process.
    6. The number of Kanbans is reduced carefully to lower inventories and to reveal problems.

    And, in fact, Toyota’s TPS itself has only six very simple rules:1.

    1. Do not send defective products to the subsequent process.
    2. The subsequent process comes to withdraw only what is needed.
    3. Produce only the exact quantity withdrawn by the subsequent process.
    4. Equalize production.
    5. Kanban is a means to fine tuning.
    6. Stabilize and rationalize the process.

    In non-manufacturing environments, the primary purpose of Kanban is to facilitate efficient workflow. In manufacturing it’s about having the right part in the right quantity at the right time. This is as opposed to producing based on guesswork and estimation.  It’s about being lean. Very lean.

    Can agile and Kanban coexist happily?

    The real question then, is “Does Kanban conflict with Agile concepts/principles?”
    The best answer might be, “In some ways, maybe. In some ways, maybe not.”

    Over the last several years a large number of Agile practitioners have begun to include thinking from lean manufacturing in their Agile approaches, thanks to trailblazers like Tom & Mary Poppendiek in their book Lean Software Development. But Kanban, at least as discussed thus far, seems to break the primary rule of today’s common agile practice: the fixed development time-box. Kanban systems are continuous, not iterative, yet both exist to promote workflow efficiency.

    In his article, Kanban Development Oversimplified, Jeff Patton illustrates some of the conflicts between Agile and Kanban. With Kanban development:

    • Time-boxed development is out
    • Stories are larger and fewer
    • Estimation is optional or out completely
    • Velocity is replaced by cycle time

    Implementing Kanban in an Agile environment might require a bit of ‘shoehorning’ to make it work. But Kanban and Agile share some basic tenets: improve efficiencies in a non-prescriptive environment where rules are kept to a minimum.  In this way, they certainly seem complementary.

    At the very least, incorporating Kanban into an Agile environment by combining rules 5 and 6 of the TPS seems to make a lot of sense, i.e., using Kanban is a means to fine tuning in order to stabilize and rationalize the process. And, just as Agile has evolved into several different flavors over time, like XP and Scrum, it’s not a stretch to imagine Agile-Kanban hybrids like Scrum-ban just might create a synergy for software development that neither could achieve on its own.

    Where do we go from here?

    I’ve laid the groundwork by providing some context on the possibility of using Kanban in an Agile software development environment. Just as I think different forms of Agile shouldn’t be seen as conflicting but as complementary, I also think it’s important to keep an open mind and consider that Kanban and Agile have the potential to be complementary and not contradictory.  The subtle shift in lean thinking turned out to be revolutionary in classical production, and it may just have a significant impact in the world of agile as well.

    In Part 2 I’ll take a look at how Kanban is currently being adopted in Agile environments and the key tradeoffs that might result.

  • Throw out your product specs…

    I don’t like requirements documents. There, I said it.  I’ve been thinking about this latently for a number of months now, but all of this thinking really caught up with me this weekend.  We’ve been thinking a lot lately about evolving our product management practices and there are no shortage of opinions around the office and from experts in the community.  As such, I’ve tried to do a lot of listening, reading, learning, and reflecting over the last few weeks.  Here’s what I’ve come up with so far.

    There are many flavors of requirements out there.  Depending on the product management practices you use, you are likely to have some of the following: product requirements documents (PRDs), market requirement documents (MRDs), business requirements documents (BRDs), software requirements specifications (SRSs), and feature specifications (FSs).  For the sake of simplicity, I’ll just refer to all of them as PRDs or specs.

    There are a number of shortcoming with PRDs. I’ll take the time to just list a few here:

    • They take a long time to write.  Also, they aren’t super useful until you are done writing.  (Think of the value curve as a stair-step function)
    • They are not enjoyable, engaging, or interesting to read.  Ergo, they aren’t read often.
    • Similar to the above, but potentially worse: they are nearly impossible to ‘diff‘ in most typical formats.   Which, for a living document, is bad.
    • They give people a false sense of security.  You read through that fifty pages and you think, ‘wow, we got this thing completely specced out.’  Wrong.  See below.
    • They don’t cover the most important of the product: the user experience.

    Let’s talk about what a good spec should do

    To me, a good set of requirements is supposed to describe a product that we are reasonably confident will be successful in front of real users.  But why does it exist in the first place?  Well, it’s core purpose is to facilitate discussion and decision making around the product in question.  Typically, there are a lot of stakeholders (with a lot of different paradigms) around that table: QA, Engineering, Marketing, Merchandising, Operations, Executives, etc.  So a good spec is able to quickly communicate what this product does and how it will do it.  The goal of such a specification is to create more clarity than confusion.  It should be your single source of truth.  Finally, a sustainable spec is one that is built for change.  Your product will no doubt evolve and change as you gain more insight from users.

    Delivering on all the expectations of a good specification is much easier said than done.  There are a lot of things that a spec has to do, and it’s only really useful if you can create it in a reasonable amount of time.  Furthermore, in most typical formats, the spec ends up getting thrown in the trash after the product is launched.  So you really don’t want to invest that much time into it.

    Also, there is a timing issue here.  How can we have any degree of confidence that our product will be successful without actually having tested the product in front of real users?   If you look at most specification creation processes, you’ll find that people are writing tens or hundreds of pages well-before they’ve actually put anything in front of a user.  What’s worse is that they haven’t even begun to think about the interaction or visual design of the product yet.   That’s counterintuitive to me because it goes against the most important rule I have learned in my time managing products: The user experience is the most important part of any product. It’s not about ‘what it does.’  It’s about ‘how it does it.’

    Now don’t get me wrong.  Some really forward-thinking product teams actually pay close attention to interaction design and visual design in their PRDs.  Some of them actually sketch out ideas and test them in front of users while building their requirements documents, which is a huge win.  If you are in that select group of forward-thinkers, you are definitely a step ahead.  But, in this scenario, there is an obvious question that we are left with: if you are actually beginning the process of product discovery (and doing real user testing), why are you using a document as the format to store your findings and insights?

    The ‘aha’ moment: prototyping

    When we look at all of the things that a specification is supposed to do well, it becomes clear that building a good one is a really tall order.  But when we combine the goals of communicating the needs of the product with actually validating/discovering the solution, an answer emerges: a high-fidelity prototype!

    The beauty of a high-fidelity prototype is that it actually provides people with a realistic sense of the user experience of the product.  A good prototype describes the functionality of the application while leaving very little room for imagination.  High-fidelity, to me, means that the interface is clickable, but that the backend is not necessarily functional.  In most cases, it will be ‘stubbed’ or simulated.  While every single corner case need not be designed, the major use cases and features should be fleshed out.  After all, the idea is to capture the proposed user experience.

    Imagine the kind of robust dialogue that can be had around a high-fidelity prototype versus a 50-page spec.  All of a sudden, these disparate stakeholders with very different frames of mind, will all (literally) see the same thing.  They will not only have a sense of what the functional requirements are, but they will see the proposed information architecture, user flow, interaction, and visual design.   They can actually understand how this product will come together and will have a much more robust understanding of what it means to them.  Also, they’ll have a single source of truth.  No need to dig through several email chains to find the answer to the question about a certain use case.  Just click through the prototype to find your answer.

    If you think a high-fidelity prototype will help facilitate discussion and decision making around a product, just wait until you see what it does for your engineering team.  Beginning engineering without having fleshed out the user experience can be very costly.  Typical specs are so ambiguous that the really tricky product management decisions are faced only after the engineers have begun writing code.  Also, typical written specs leave so much open to interpretation that its very likely engineers will write code that doesn’t do precisely what you intended.  This usually creates time pressure for PMs and engineers.  The pressure generally causes them to make hasty decisions without user input and to re-write code without taking the time to be thoughtful.

    But a high-fidelity prototype changes a lot of that.  The experience has been thought through much more significantly by the time the engineers begin writing (back-end) code.  Furthermore, there are few (if any) better ways to communicate the needs to an engineer than to show them precisely how the application is supposed to behave.  They can actually foresee some of the challenges ahead and can be much more thoughtful about the architecture.  That’s not to mention that their velocity is likely to increase because they have more clarity on what they are building.

    Last, but certainly not least, is the effect on the user.  The great thing about using a high-fidelity prototype as your ‘source of truth’ is that you can actually put it in front of users to get feedback.  This enables you as a product team to ‘test early and often.’  And instead of taking all that extra time to ‘write up’ your learnings from user testing, you can just work with the interaction team to evolve the prototype.  Which means you can iteratively test it again and again until you’ve gotten the experience right.  You are able to test much more easily at this stage because the cost of change is so much lower than it will be further downstream.  Once you are ready to begin implementation on the prototype, no additional administrative work is needed (in the form of writing pages and pages).  Instead, you can just begin involving engineering in the discussions around the prototype and they can begin turning it into a real product.

    Give it a whirl

    If you’re a skeptic right now, that’s OK.  It’s likely that your existing process is painful enough that you’ll get open-minded about this sooner or later.   Next time you have the opportunity to create a product spec, you should consider working with your design team on creating a prototype instead of spending weeks or months writing a longer PRD.  Get that prototype in front of real users (and the rest of your product team and stakeholders) and use it as a catalyst for dialogue and decisions.  When it comes time to implement, bring your engineers into the conversation.  I think you’ll be pleasantly surprised at the result.

  • Magma rails is happening right now :)

    I am thrilled to see the agenda for Magma Rails coming together.   I have a real sense of pride in the fact that I helped start the company (Crowd Interactive) that is putting on the first ever Ruby on Rails conference in Mexico!  What’s more is that it really looks like it is going to be a great conference.

    Some amazingly talented people will be giving talks there, and I am happy to say that I know a few of them personally.  The ones to really look out for will be by:

    • Jon Dean
    • Marcelo Serpa
    • David Padilla
    • Edwin Cruz
    • Jorge Pardinas
    • Juan Esparza
    • Karla Magana
    • Luis Galaviz
    • Roberto Cataneo

    I am truly heartbroken that there won’t be a live webcast of the conference.  I wasn’t able to be in Mexico this year for it, and it would have been nice to tune in!  That’s OK.  I’ll try to make it out next year.  I’ll be looking out for all the #MagmaRails tweets.

    Anyway, I am really proud to have played some small part in the rails revolution happening in Mexico.  Kudos to all the Magma Rails and CI guys for taking it a step further.

  • How to successfully integrate into a new company

    New team-members are not created equal

    I’ve had the opportunity to evaluate and hire around thirty very talented people in the last few months, and it has been a pretty eye-opening experience for a lot of reasons.  Perhaps the most interesting reason is the varying outcomes I have seen from all these new employees.  I have seen some new employees do a fantastic job of integrating themselves with the culture and the team, and I’ve seen others crash and burn.

    It got me to thinking, “what is it that makes certain new people successful in an organization and others not-so-successful?”  If there are certain attitudes and behaviors that drive good outcomes for a new team-member, I’d like to know what they are.  This is especially interesting because I find that some team members who I am excited about during hiring/evaluation process actually don’t do so well in their first 30-90 days.

    So, I’d like to better understand what works and what doesn’t.  That way, I can try to help coach new employees in that direction.   I’ll establish a working list here, and try to add to it as I learn more.

    Things you should do when you join a new organization

    • Respect how the organization got to where it is. The most successful employee don’t just walk in guns ‘ablazing.  Instead, they seek to understand how the organization got to where it is now, and what things have been successful or not-so-successful in the past.
    • Assume that past decisions were made for a good reason. I’ve seen a few new team-members actually disclaim that they ‘they are not here to question past decisions.’  They assume that people made the best decisions they could with the information they had.  This is a great way to start off on the right foot with a new team.  Of course, no organization is perfect, and all of them have skeletons in the closet.  But you are better served focusing on the future rather than the past.
    • Recognize that some of your great new ideas were probably discussed before. This is one of the most common mis-steps.  I see a lot of new people come to the table with ‘great new ideas’ that they assume no one has thought of before.  It’s great to be forward-thinking and to have new ideas, but it makes a lot more sense to first ask if folks have talked about things like this in the past, and what has been done until now.  (Most companies are not short on ideas… they are short on execution!)  If you don’t ask these questions, you look ignorant about the history of the organization and you look like you are trying to take the credit for ideas that people have already had for a long time.
    • Get to know people both personally and professionally. You cannot underestimate the importance of close personal connections in the workplace.  You don’t have to be best friends with your co-workers, but you should make an effort to get to know them and what motivates them.  The more comfortable people are with you, the more likely they are to come to you when they need something.
    • Ask questions… rather than giving answers. This is more of a meta-point that covers a lot of the other points above.  But it’s a great rule to live by.  If you find yourself providing more answers than questions in your first month, you are almost certainly doing something wrong.  You have to seek to understand before you seek to be understood.  (Take it from Covey!)
    • Seek out a mentor. There is almost certainly someone in the organization who knows more about the brand and the culture than you do.  Don’t be afraid to ask for help.  It’s not a sign of weakness, it’s a strength.

    This topic is not only timely for me, I think its hugely important in any rapidly growing organization.  There are lots of new faces and there is a lot of uncertainty.  What I have found is that some of the brightest people have the least organizational savvy.  So if you think this advice doesn’t apply to you because you ‘smarter than that,’ I encourage you to think again.  No matter how smart you are, you are not going to be effective in an organization where you haven’t built trust and don’t have the ability to gain buy-in.

    Joining a new organization can be harder than most people think.  Hopefully some of this advice helps people on their way…

  • Creative and engineering .. how different are they?

    I often hear practitioners in creative fields (such as photography, design, and writing) and engineering fields (such as development, QA, systems, infrastructure) talk about how different they are from the other group.  This is sometimes in reference to processes from the other camp that ‘won’t work here’ or in reference to a frustrating experience that leaves people wondering how they could be so different from one another.

    In either case, this is a topic that I’ve noticed people get pretty impassioned about.  It’s an interesting topic to me because creative and engineering practice areas are so critical to success in the my world of entrepreneurship and technology.  So I think it would be fun to explore (out loud) some of the similiarities and differences between to the folks in either practice areas.

    I have to warn, of course, that this based on anecdotal evidence only and is in terms of my experiences.  I know there is a bigger world out there, and I am not trying to make sweeping generalizations here.  Anyway, here goes:

    How are engineering and creative different?

    It’s obvious that people in engineering and people in creative are different.  But people often draw this conclusion only by outward appearances, which I think is misleading.  So let’s dig deeper into the real ways in which the two archetypes are different from one another:

    • They often work in different cycle times.  I have seen good engineering work and creative work happen iteratively.  But what I have come to notice is that the right cycle time for each type of work is often different.  Creative work generally operates on shorter cycles (1-day to a week) whereas engineering work often spins in longer cycles (1 week to a month).
    • The way the teams collaborate is different.  Because of the cycle time of much of our creative work, one person can often own a task from start to finish without creating a reasonable burden of time.  (A great example of this in our organization is the creative writing team, where each writer can often take full ownership of writing a piece.)  Whereas in engineering, because of longer cycle times, usually a small team will take on a task, collaborating just to get to a 1.0 version.
    • They talk differently.  Each group has their own set of acronyms and buzzwords.
    • Their work has a different level of visibility to the user.  Basically everything that is done in creative is a direct touchpoint to the user.  While many technical tasks share this trait, there is a whole category of technical tasks that are completely under-the-hood.
    • Non-practitioners shy away from one rather than the other.   Almost everyone in the organization has an opinion on creative, whether the have a depth of expertise in the practice area or not.  Engineering, on the other hand, is something that folks rarely comment on.  This likely has to do with the visibility point mentioned above.
    • The skill it takes to do each kind of work is different.  This is obvious, but it’s worth noting.  There are people who ‘bridge the gap’ of skills between engineering and creative very well, but in my experience, those folks are few and far between.

    How are creative and engineering the same?

    Surprisingly, I think that there are quite a few similarities between folks in engineering and in creative.  Here are a few:

    • They both require a strong attention to detail.  Whether you are 1 pixel off or you are missing a semi-colon, the tiniest things can throw a huge wrench in your day.
    • They both collaborate to get meaningful stuff done.  I mentioned above that these teams often collaborate differently, which is true.  But collaboration in and of itself is critical to people in these practice areas getting quality work done that is consistent in architecture and/or style.
    • The number of ways to do any one thing approaches infinity.  There are a million ways to design, photograph, or write something.  Similarly, when it comes to solving a technical challenge, there are a million ways the solution can manifest itself (even down to difference in technology choices!)
    • Having ownership of a problem is critical.  Folks from either group hate it when solutions are prescribed to them.  The reason they are in their field of work is because they want to solve interesting problems and they want a sense of ownership of those tasks and initiatives.  Neither group wants to feel like drones that are simply doing monotonous tasks.
    • User feedback drives their worlds.  Neither group can create terrific results without being plugged into the user community that actually touches their deliverables.  If either group operates in a vacuum, their likelihood of greatness hinges mostly on luck.
    • Perfectionism comes stock.  In either group, skilled practitioners have a hard time ‘letting imperfection slide.’  If something doesn’t seem right, its going to gnaw away at them forever until they fix it.  Also, because there are a million ways to do something, the natural tendency is to try a number of possibilities.  (If we didn’t have a strong sense of urgency from the business side, most of us would just ‘geek out’ with the possibilities, in either camp!)

    Conclusions and other thoughts

    After exploring this a little bit more, it has become clear to me that these groups are not as different as everyone builds them up to be.  The similarities are more striking to me than the differences, at least to me.  At the end of the day, good practitioners in either category are committed to building great stuff.  In the end, I suppose thats what matters.

    Most businesses seem to lean one way or the other when it comes to these archetypes.  That generally has to do with the founders coming from one background or the other.  This is something that I think it is very important to avoid.  Being out of balance in the direction of creative or engineering often causes more harm then good.  I think the degree to which these groups can collaborate together effectively is has a huge impact on the success of your business.