Someone recently observed that I was motivated by a big vision and that some engineers are not, and that’s ok. In my experience, it’s not okay. I wish it was. It’s fun to sink into the code and get into the zone and not worry about the complicated real world. However, it’s not fun to work hard and create something over months or years and have it fail in the marketplace or, worse, never ship at all. I’m not talking about research projects where the primary outcome is learning something or publishing a paper. I’m talking about the kind of software I work on, which is intended to be used by other humans, whether they be developers or regular folks.

There are a few common problems I’ve seen happen when a team writes software without a clear and focused vision.

  1. Lots of bugs are discovered late. When engineers are focused on their own specific component or library, it often happens that another engineer will use that library in a slightly different way than was intended. This is especially true for internal libraries where there is little need for documentation since we can see each other’s source code; however, we don’t typically review all off the code our systems depend on. So each part of the code does what it is supposed to do on its own, but when we put them all together, slight miscommunications add up to things not working quite right, typically discovered late in the development cycle.
  2. The system doesn’t work well. When you are building software as a team, engineers work on different parts of the software. If one engineer is making a gaming engine, and another engineer is making presentation software, it rarely comes together to work well at the end. The gaming engine needs a high framerate and quick response to user input. The marketing presentation software need to display text at large font sizes. It’s likely one or the other will suffer, or more typically the software won’t actually work well for either use case.
  3. You delivered the features your manager asked for, but the product isn’t successful. Customers aren’t happy… or they aren’t buying in the first place. New users and people already using your product have different needs and slightly different use cases. It can be a delicate balance to walk. When developing a “feature” it can be easy to miss a step in between what you are working on and something that seems unrelated from the inside, but which people need to use together or in sequence. I call these features in between the features, which are very hard for engineers to see if they don’t have a complete picture of how people will use the product.
  4. Customers are happy and the product is cancelled. Companies have internal metrics by which they evaluate success. Someone on the business side has determined if we expect immediate revenue, or if this is going to be a long bet and expect slow revenue growth while we focus on strategic customer adoption, or if we need a large base of free users before we expect significant revenue. Sometimes it’s a product that supports larger business goals and drives adoption of a different product. If the engineers don’t know what those goals are, they may not get the important details right to make those goals happen.

So, you need to tell engineers the internal metrics, but that’s not enough. No one writes code that by itself increases 28-day active users. Somewhere in the product plans (or the minds of the executives) is a hypothesis that there are some new or improved use cases that will cause people to use the app more (or to sign up in the first place). A lot of teams do document use cases or user journeys and share them with the engineers, which is important, but not sufficient.

Engineers need to know the use cases that everyone believes will be required to make the product successful; however, usually software engineers have to make all sorts of decisions outside of the required use cases for the next release. The software will work better if all of these little decisions are aligned somehow, and the easiest way to do this (in fact the only way that I’ve found to do this), is for the developers to have a shared vision of what this software wants to be — not just in its next release, but in the future. This vision can be somewhat arbitrary for it to work (which means it is totally fine if it changes), the key point is that it needs to be shared, and when it changes, the change and reasons for the change need to be communicated effectively. A shared vision not only aligns all of the little decisions that developers make independently, but also makes all of the design discussions more efficient. We can focus on how we are building a thing, because we already know what we are building and why.

To create a shared vision, we need to answer: who is the target customer? what are the key problems we are solving? what will our customers be able to do with the initial release and what do we hope they will be able to do in the future? Who are the customers who might not be satisfied with our product and that would be ok?

Good engineers will build something that works for a wider audience. Often the software will enable those people to do many more things than the minimum requirements, but focus is key to creating robust software that works well.

I’ve been talking about engineers, since that’s my focus these days and because there remains a persistent myth that engineers don’t need to be distracted with all this business stuff. All of these questions and answers are even more important for designers, technical writers, support, developer relations, support, sales, business development and everyone involved in the making of and communication about the product.

I’m not motivated by a big vision. I’m motivated by impact — not potential impact, real impact. I need to believe that my day to day work is going to add up to something that solves real problems for real people in the real world. I’ve discovered that to reduce risk in software projects, every member of my team must be able to see a through-line from their day-to-day work to shipping software that causes a large number of humans to be empowered to do something new or better, enabling them to solve real-world problems. To do that, I need to convey a vision that lets the individual team members innovate, coming up with creative solutions in their domain that add up to a system that actually works.

5 thoughts on “the vision thing

  1. As usual, I love hearing how you think about complex issues. Motivation is complex! And while it’s likely that complex perspectives are shared by a large number of people, they must be explained in detail, ipso facto, as they say. :-)

    So: when you say Good engineers will build something that works for a wider audience, I think you’re already expecting Good equals super complex thinkers who track and comprehend your vision.

    Which means you all need to have it pretty baked.

    It’s like playing Team Chess!

    For me, it’s interesting to compare when considering this in the context of an existing team one might be corralling, or when putting together a new team of unknowns.

    xoxo

  2. Strangely this way of thinking is not uncommon among female engineers. I know entire post-graduate classes in sustainability engineering and bio-medical engineering that are female and yet almost no women attending lots of the tech events in London and elsewhere (look at the pictures they tweet) .

  3. Good read! We have tried to overcome the above obstacles with added transparency and communication.

    bugs or not working software -> code reviews and quality gates
    product not successful -> follow customer feedback more
    happy customer and cancelled product -> better communication with project sponsors (hasn’t happened)

  4. I never thought of this as a gender-based philosophy. When I think of this kind of vision, I think of Steve Jobs’ “reality distortion field” where his vision convinced engineers to make something incredibly good, Doug Engelbart’s “mother of all demos” which illustrated his vision for the future of computing, and the famous Alan Kay quote “the best way to predict the future is to invent it.” The fact that I don’t have women on that list probably has more to do with an imbalanced coverage of history, where women are less likely to be quoted or credited for their vision or leadership.

  5. Great article, I think there are multiple stereotypes including “Coders don’t need to know business” that need to change. Regardless, to solve our problems with this, we keep our UX/UI and product meetings open to everyone and once in a week (usually fridays) we go over our vision for the product, where it is headed and how the things we did this week effects it.

Leave a reply

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong> 

required