Engineer Whispering - insights into the technical side of the table
In preparation for my talk at Seattle Interactive on October 30th this post covers some of my ideas on this topic - I hope you like it! And if you have other ideas or suggestions, leave them in the comments - I am still putting my slides together and could always use more ideas! -kate
Engineer Whispering - insights into the technical side of the table
If you’re in a non-technical role like marketing, sales, or design, you probably have to interact with engineers on a regular basis, but may find that it doesn’t always go the way you had planned. Engineers think and work differently from almost everyone else in an office, and this can sometimes lead to unpleasant interactions, delayed projects, and unproductive meetings.As a former software developer who now manages teams of engineers, I’ve seen my fair share of breakdowns between engineering teams and other departments within several companies. And it’s not pretty.But it is avoidable.So if you’re working with an engineer, how can you make sure everyone gets what they want and comes away from the project feeling like their contributions were heard and mattered?;
Understand what engineers do - and who they are
This doesn’t mean you have to start reading books on Ruby every weekend! But I think it’s important for people to understand how engineering is different from most other roles in a company. Understanding those differences allows you to approach and work with engineers in a way that productive, not frustrating.Engineers like clear directives and specific problems. In a lot of other fields, you can start working on a project and if one aspect of it isn’t completly fleshed out yet, you can just come back to it later when you have more information. In engineering, though, the opposite is true.In engineering, you can’t wait until the product is almost done to decide what you want it to do. We need specific directions up front, otherwise we’ll have to scrap the product and start over if you decide it needs to do something new at the last minute.There are a lot of intricate details on how software pieces fit together, and simple assumptions about the data in the backend can limit what is possible in the UI (or efficient and performant). And to borrow an analogy from my friend Nicholas Zakas [who also wrote an amazing post on working with engineers], building software is similar to building a house (although he might say creating), since it is hard to build parts of it without understanding the blueprint and plan. And moreover assumptions like the number of floors in a house are difficult to change mid-way through the project. Or making those types of changes can drastically impact the cost (amount of work) and time-frame of the project.And an engineer’s work is almost never done. Once we’ve created a new software or feature, our job is just beginning; keeping existing programs functional is a huge part of what an engineer does all day. This is why engineers don’t want to build a crappy product fast, just to get something out on the market - because we’ll have to spend so much more time keeping a bad product operating.One company I worked at previously had a marketing staff who requested so many new features from the engineering team that we just couldn't keep up (since they had goals and directives to meet too). So they went out and hired their own contractors to whip up the small features and landing pages they needed; thinking that the faster and cheaper the better. While short term this worked out nicely, but long term this ended up a big mess. What ended up happening was that in 6 months my team was rewriting these features and spending the a substantial amount of our time trying to keep their low-quality code up and running; falling even farther behind on creating the new features needed by the business. Not to mention being a major drag on my team who would love to work on new features, but were stuck in sustainment hell.It wasn't productive for us, for the sales team, and especially not for our company.Mutual understanding makes any relationship better.Here are some guidelines for getting to know the engineers in your life. :);
[ Know Your Engineers ]
- I love a lot of the points in this article about working with engineers, but one of my favorites is the idea of finding a “technical mentor”. This person can show you the ropes of engineering, so you begin to develop the vocabulary to talk with engineers in their language. Spending time with a technical person gives you insight into what engineers value and how they approach problems.
- It’s important, too, to understand that while a lot of engineers have brilliantly developed technical skills, they often lack “softer” skills like communication. Engineers are logical, hardworking, and almost always blunt. If you can adjust your communication style to be specific and direct too, you’ll get a much better response and better product.
- Despite the lack of soft skills, engineers are actually pretty creative people. So don’t be fooled into thinking engineers are just like worker bees, and that they’re not attached to the strings of numbers and letters they’ve created. Code is like art - engineers need focused time and an environment to be creative. This means being considerate about interrupting themand not inviting them to meetings unless you really need them (and then make the meeting efficient).
- Be strategic about interrupting engineers at work; changing contexts suddenly is costly. Last month I was working on an objective-C project; I noticed that I was fastest and most productive when I had been working on the code for a good 1.5 - 2 hours because I had loaded all the files, function definitions, and parameters into my brain by that time. I was able to write new functions and features quickly - almost like I had loaded the code and framework into the cache of my brain. Getting up from my desk to go to a meeting meant that it took me a lot longer to warm up my brain again and reach my peak efficiency again.
- Making engineers part of the entire decision process for a project means you’ll avoid major headaches later. If you’re not technical, you probably have no idea how much more complicated on feature it to build than another. Presenting engineers with the problem and asking how they would solve it means you won’t waste time dreaming up a software they wouldn't build.
Establish relationships (before you need them!)
As any regular reader of this blog knows, I think good personal relationships are the key ingredient for successful professional ones. Establishing trust and understanding with the people you work with means that when it’s time to get down to business, everyone knows you’re on their side - and you know that they’re on yours too.So take the time to get to know your engineering team before you’re working on the next big project together. You can accomplish this in a number of ways (try a little bit of each one for best results!).
- Make personal connections. Invite an engineer you work with out to lunch, coffee, or happy hour - and find out a little about them. It’s a really simple gesture that means a lot. Knowing someone makes it easier to work with them, since it allows you a perspective you won’t get just passing them in the kitchen every day. Get to know what someone is passionate about and spend time with them outside of work - it builds trust and positivity, which are invaluable resources.
- Ask meaningful questions. If you’re in a non-technical role, odds are there are aspects of an engineer’s daily work that you don’t fully understand. So ask! Not only will you grow your own knowledge and be able to communicate with them at a higher level on future projects, but you’ll also demonstrate that you are interested in them and what they do. People want to know their work matters to their peers.
- Get their opinion. Ask an engineer what they think about a project you’re working on. This helps build trust, since it shows that you care about their opinion. But it also helps give you a look into how they approach projects, which will help you work together better in the future. Find out what their priorities are and how they problem-solve, and you’ll be better prepared to meet their needs in the future. Many engineers tend to think about things before they speak up, this means that sometimes to get their ideas and draw them out in a discussion you need to be quiet and really listen.
- Recognize successes. Everyone wants their work to be well-received, but it’s easy to skip opportunities to recognize good work when you’re a growing company under constant deadlines. Let people know when work they’ve done has helped you personally (extra points if you do it in person and not an email!), and seek out opportunities to offer praise more publicly when a really successful feature has launched. Engineering is a long-term process, without the same concrete successes and numbers of a department like sales, so don’t leave them out when things go well.
Align your goals
I once worked as a developer at a B2B company where the relationship between the engineering team and the sales team almost completely broke down. The root of the problem? Misaligned goals. The company was driven by sales, so the engineering staff was constantly being asked to create new features, at a rate we just couldn’t keep up with.And though the problem was simple - misaligned goals - it manifested itself in a million little ways that made both teams unproductive and built tension and animosity within the company.The sales staff was frustrated, and blamed us for them missing their numbers. We were frustrated that we were asked to create a new feature before we even got the last one to work. They wanted more sales, we wanted more time to produce quality work. See the problem? Our priorities were both valid, but completely different.Remember you are one team, and you have the same goal.No matter what your role, you need to champion the causes of your department while keeping in mind the ultimate goal your whole company is working towards. Keep conflicts in perspective and find ways to compromise and help each other for the good of the business.It’s not enough to just tell everyone you’re on the same team, though. You’ve got to demonstrate it:
- Speak their language. Engineers are detail-oriented and mathematical. Be as specific as you can when asking for features, and give physical evidence like screenshots to track bugs. Change “this isn’t working” to something concrete they can take action on.
- Use the same tools. Find out how an engineer you’re working with likes to get things done. Ask them about their process so you can follow their formula. Find out what tools they’re already using and use them too, so you can actively track and collaborate on projects.
- Get involved in their process. Getting design and marketing details at the end of a project can sometimes mean erasing hours of work for an engineer. Make big decisions up front and be as specific as you can.
- Explain why. To an engineer, “fit and finish” work seems unnecessary. Rather than simply asking for minor touch-ups and detail work, take some time to explain the impact the minutiae has on customer reactions to a product.
Understand the importance of others
The importance of learning how other teams work is one of the main motivations I joined SEOmoz (my previous company). I wanted to understand marketing - a concept I previously hadn’t given much thought.I once worked at a company that had a fantastic product and a brilliant engineering team. We figured our product was so good that marketing would kind of take care of itself, as long as we focused on making the very best product out there. We did, and yet we struggled to “figure out" sales and marketing and ultimately the company didn’t find the success and growth that the product and team might have warranted on its own merit. In many ways we failed because we ignored the importance of marketing. (Remember Betamax? That was marketing too.)After this experience, it mattered to me to understand the basics of marketing and how to evaluate good marketing from bad, hire sales people (which is damn hard - their job is to sell you after all), and at least understand these aspects of a business so when I went to start my own company in the future I would know how to make it great.To engineers, doing things for the marketing team like creating landing pages and HTML emails isn’t very sexy or exciting. They’d rather be building new product features or learning a new technology or skill. But landing pages and emails are important too (at least if you want to reach and convert customers), so it’s helpful to make sure other teams understand why.Prioritize understanding between departments so everyone knows why everyone else’s projects are important, and why they should help. This also extends to marketers too, since often times miscommunication or perceptions of unhelpfulness result for misaligned goals or objectives. Each team is so laser focused on their goals that the needs/desires of the other team aren’t considered, and can result in resentment on both sides.It creates what I call the “us vs. them” mentality.And this division isn’t good for the company - everyone should be working to make the business successful.
Close the loop
We’re often told at the beginning of a project how important our work will be to the company. We get to work, spend long hours perfecting, problem-solving, and iterating, and many times don’t hear about the project again once it’s completed.Even worse, sometimes the only feedback engineers get is when a feature isn’t working.It’s incredibly valuable to go back to a team after a product has launched or a project completed to let them know how their work positively impacted the company. Unfortunately, it’s rare that this happens.Not only does letting people know how their work led to the success of a project make them feel good, it also fosters understanding of how they fit into the entire team. It builds positive feelings among departments to see how all the pieces they each contributed fit together in this successful launch.So share goals at the beginning of a project, and remember to share results after the facts. Give people sales numbers, customer data, anything concrete that can show what an impact their work made on the company. We all go to work to do a good job, so let people know when they’ve done so.
Working as an engineer and with engineers can be complex, and there’s probably much more to say about it! What have you learned working with engineers? And engineers, how can you improve your relationships within your company? What can colleagues do to improve dynamics?