25 Jul 2016

Why We Need T-Shaped Engineers

The impressive complexity of today’s world forces immense specialisation — people who call themselves interaction designers or marine biologists or regulatory compliance specialists. If you were to go 500 years back in time, and try to explain this to a goatherd, he wouldn’t understand a word of it. You might as well have said that you’re a warp theorist or a temporal agent. In his world, there’s far less need for specialisation. Maybe jobs like a goatherd, a cobbler, a tailor and a healer. Whereas our world wouldn’t be possible without specialists.

But something is often lost when you have highly specialised people coming together to, say, build an app. And that is that people consider their job to begin and end with their narrowly defined role. Many software engineers I’ve worked with do only engineering work, diligently going about writing code to implement an app, not stopping to ask questions like, “Does this address our users’ needs? Is it usable? Is the app behaving in ways that the user expects? Is it asking the user questions that they shouldn’t be asked?” When I asked these questions to fellow engineers, they have, at times, reacted with surprise: “But that’s the UX designer’s job!” or “That’s the PM’s job!” It was almost as if I’d asked the engineer to fly a plane or compose a sonnet. I got this “not my job” answer from my (now former) manager as well. When your nose is to the grindstone, you miss the bigger picture, diligently implementing a flawed product.

Worse than leaving a problem to someone else to fix is not even being aware of it. How sad it is to have a team of highly-qualified people with the best intentions work hard to unknowingly ship a bad product!

One solution to this is to become a T-shaped professional, as IDEO’s Tim Brown calls it. That’s someone who has a depth of knowledge in one specific area (like programming) but also some experience and competence in adjacent fields, like UX if you’re a programmer. You may not be as good as a real UX designer, but you’re good for a programmer. You can do what’s needed. Being T-shaped means having both depth and breadth.

Tim points out that being multidisciplinary creates empathy for different points of view. This is something I found missing in some engineers. When I pointed out that something wasn’t discoverable, I’ve had surprised engineers respond saying, “It’s right there in settings!” In their model of the world, a feature is either there in the app (in which case everyone can use it) or it’s not there. I’ve also heard programmers refer to “dumb users” which, in addition to being arrogant, fails to acknowledge that the fault is in the poor UX. T-shaped engineers have more empathy for the user. Who are the whole reason why they have a job to begin with.

Another argument for being T-shaped is that your organisation may have specialists, like UX designers, but they may not be available for the project you’re currently working on, or may be on vacation today, or are already overworked. Which has happened to me many times. When you have T-shaped people, you are more flexible, and able to do good work no matter the situation. In that sense, you are more competent. That’s useful in big companies, more so in startups, and even more so if you’re working by yourself as an independent app developer. In the last situation, there’s nobody to consult regularly. Being T-shaped opens more options for your career.

Besides, you can’t consult with a specialist for every minute edge case. (If you do, you'll leave them little time to do other work.) Programmers end up making many tiny UI decisions by themselves. For example, how should a certain error message be phrased?

How should a certain action work offline? Should we queue it and perform it later when online, without telling the user anything, unless an error occurs? Or should we tell the user even if it succeeded? Like "Synced". Or should we tell the user when we begin syncing, and then again when it's done? Like "Syncing..." followed by "Synced"?

If we’re opening a document, which requires creating a temporary file, but the file creation fails because the phone is out of storage, what should the error message be? Or is this scenario important enough that we need to change the design and rewrite the code to not require a temporary file?

You can’t go consult the UX designer for every tiny decision. Or you may not even realise that a decision has a UX implication. You often have to make decisions by yourself. In that case, you might as well equip yourself so that you consciously make the right decisions, the right tradeoffs between engineering and UX. As opposed to unconsciously making poor decisions because you understand only one aspect.

This is something Tim Brown mentions in the aforelinked interview: you can judge tradeoffs better when you understand both aspects of the decision. Otherwise, it becomes a negotiation as to whose point of view is more important. I’ve been in discussions where designers propose something with insufficient understanding as to how complex it is to implement, and engineers reject the idea saying it’s too complex, with insufficient understanding as to how much that improves the user experience. Engineers think engineering is important, and the designer thinks design is important. Each side talks past the other. Finally, an arbitrary decision is made to break the impasse and do something, anything, to move forward. A compromise. Not the right tradeoff given the circumstances. You can make better decisions when one person understands both sides of the coin.

You can’t fully separate out engineering and UX, anyway. Or engineering and product design. They blend together, as opposed to having a sharp boundary. You need T-shaped people to straddle the boundary, and even live at it when needed. Siloing them as completely different job ladders (engineer, designer, PM) is a rigid and bureaucratic attitude.

Tim also points out that multidisciplinary people work well with people from other fields. This is again something I’ve seen — many one-dimensional engineers viewed working with UX as a necessary evil so that they can do their real engineering work.

Tim points out that graduates are generally I-shaped, not T-shaped. Particularly in India, where you’re expected to shut up and fit into a system rather than asking how the system can help you. If you take a computer engineering course, you learn engineering and only engineering. Years of working in huge companies only reinforces that tendency. You think of yourself as an engineer, as opposed to someone who has a primary interest in engineering and a secondary interest in UX, say. Your role models are pure engineers. The job ladder and your managers all try to help you succeed as engineers. If you spend time doing any product or UX work, whether understanding user needs, designing the simplest product that meets those needs, sketching out a UI, making an interactive prototype, etc, which takes time away from engineering, you’re told you didn’t write enough code. All this reinforces people’s already existing tendency to be I-shaped.

In today’s hyper-specialised world, it’s hard to be great at multiple things, to be a top-quality engineer and a top-quality designer. What you can do is be great at one, and good at one or more other things. Have a primary skill and a secondary skill.

You can also view branching out as a form of career growth. As you grow in your career, say as a programmer, over the years, you may want to work in different sub-fields. You may branch out into backend work, or frontend, or machine learning, or embedded systems, or some other sub-field of programming. Why not branch out into UX as the next step in your career? It’s no less valid than branching out into search quality.

The best programmers I know don’t think of themselves as, say, Java programmers. They say they are top-quality programmers and they just happen to use Java today, but they can learn any language, framework and platform they need to use. Take that logic one step higher. Instead of pigeonholing myself as an “engineer”, I look at myself as someone whose primary specialty is engineering, but can also do some product and UX design.

Scott Adams has a similar take on this. He says that no matter how good you are in a particular field (whether playing the piano or humor or architecture), you're not the best, or close to the best. But if you’re good but not great at three different skills, say you’re in the top 25% of each of them, then that combination is rare and valuable. He describes his own experience where he had a good but not great sense of humor, a good but not great ability to draw, and a good but not great business experience. Any of these individually wouldn't have let him build a career around it. But when he combined these skills to create Dilbert, that combination was something he was uniquely qualified to do. As Scott puts it, capitalism rewards skills that are both rare and valuable.

In conclusion, T-shaped engineers bring unique advantages with them over I-shaped engineers, producing products that better meet users’ needs and are a joy to use.

No comments:

Post a Comment