Software developers, have you ever felt misunderstood by your non-developer teammates? It happens to most of us, which is why I wrote this post to help clear up some of the most common misunderstandings, miscommunications, and missed opportunities. Feel free to pass it along to anyone who’d love to have an easier time working with developers.
Below, I'll be sharing my (completely unbiased 😉) perspective on how to work with software developers. My goal is that after reading this article, every reader feels confident they can work effectively with their development team thanks to some proven tools and strategies we'll review together.
Developers: They're Just Like Us... or are they?
So why is this talk necessary? Are developers really so different from your average co-worker?
Yes. Yes, we absolutely are.
Take Flatiron School's engineering team, for example. Here's a picture of us from last summer, happily hacking away in the park outside our office.
Why are we in a park? Well, this was moments after our building was evacuated during a fire at about 5:30pm in the afternoon. When the alarms went off, the rest of the office did what you'd expect: went home for the day.
Not us. Without any pre-planning or conversation, every single one of our engineers picked up their laptops, filed outside, sat down on the nearest benches, and immediately went back to work.
Like I said, we're a little different.
Why Bridge the Divide?
As a bootcamp graduate, I didn't begin my career as a programmer. I’ve worked in a number of different fields - both in and outside tech - and in every workplace, there’s been a divide between developers and the rest of the company.
Having been on both sides of that divide, I like to think I have a uniquely well-informed perspective, and as far as I can tell, the problems are almost exclusively due to miscommunication.
That’s a good thing, because it means that with a little empathy from both sides, we can bridge the divide. And we want to, because the rewards are unquestionably worth it.
Succeeding here is in everyone's best interest. It's good for your business to have a happy, productive office. But it's also good on an individual level. Being able to communicate with the “other side” is one of the most valuable skillsets you can bring to the table.
- An engineer who’s a good communicator is perceived as better than an engineer with more technical skills but poorer communication skills.
- Likewise, a non-technical person who can “speak developer” is perceived as more valuable, because engineers are more likely to get stuff done for them.
So what are some of the obstacles we're up against? We'll look at two of the biggest: vocabulary and misconceptions.
Vocabulary
Developer, engineer, programmer
What's the difference between these terms? As far as your average day-to-day work is concerned, nothing. These terms all describe people who code. There's no need to make it any more complicated than that.
For anyone interested in the technical distinction, check out this blog post from Alan Skorkin.
Feature Development
What does the engineering workflow look like at most companies? Most startups follow some version of the agile scrum process, where team members from the Product, Engineering, and QA teams work together with stakeholders to deliver a feature.
- Product manager oversees feature ideation, manages backlog.
- Product manager works with stakeholders and engineering to identify discrete set of stories/tickets for sprint
- Product manager (and/or engineering manager) assigns tickets to developers.
- Developers work through stories, with daily standups and feedback from product manager.
- Engineering and product work with QA to fully test before launch
- Review (ideally with a “retro” where everyone involved provides feedback)
- Launch / deliver to stakeholders
- Repeat
That's the ideal flow. See the “real” picture: http://www.projectcartoon.com/cartoon/2
Stories / Tickets
During a sprint, engineering work is broken down into stories (which you may also hear referred to as "tickets"). Each story represents a discrete task or unit of work.
Tasks are typically assigned to an individual developer.
At Flatiron School, we like to manage our project queues using Github Projects (read more here and here).
The Stack
You may hear engineers referring to the "stack".
"What kind of stack are you working with?"
"What's your stack look like?"
Wikipedia defines a software stack as:
“A set of software subsystems or components needed to create a complete platform such that no additional software is needed to support applications” - https://en.wikipedia.org/wiki/Solution_stack
Here's a diagram of our stack that supports Learn.co.
Yes, I mainly showed this diagram to scare you.
If you ask an engineer to describe your company’s stack to you, they’ll probably sketch out something like this. Entities and relationships, more of a high level abstraction than exhaustive detail. And that’s the right amount of information for most people. Think about a car engine, for example. Most of us don’t need to know the exact inner workings. We can get by knowing that gas goes in and force for turning the wheels comes out.
So don’t sweat having a perfect grasp on this stuff. It's complicated for everyone, even the most experienced engineers.
Backend vs. Frontend vs. Full Stack
You'll also hear engineers talking about what part of the stack they work in.
"We're looking for a front-end specialist."
"She's a backend engineer."
"We expect all our engineers to be fullstack engineers."
These terms loosely refer to what part of the codebase the engineer spends most of their time in.
- Backend deals with data handling.
- Frontend handles UI/UX (User Interface, User Experience).
- Fullstack can do a little bit of everything.
Keep in mind the divisions between these categories are fluid / fuzzy. Few engineers are purely one or the other. Most work across multiple parts of the stack, mostly be necessity.
Read more on the differences here.
API
API stands for Application Program Interface.
APIs define an interface that developers can use to request and receive data from a data source.
Flatiron School's founder, Avi Flombaum, likes to use the restaurant analogy to explain APIs. Say I go to a restaurant and I really want a grilled cheese sandwich. I'm not just going to walk into the kitchen and start grabbing sandwich ingredients. Instead, there's a protocol. I ask the waiter for a menu, and make my selection from the menu's pre-defined choices. My request goes in, then the waiter brings me back a grilled cheese sandwich.
Think of that menu as your API. It has predefined choices set by the restaurant that allow you to request and receive food.
A public API works the same way. For example, if I want to put a Twitter feed on my website, I can use Twitter's API to request tweet data, following the rules they've defined and documented.
Read more on the HandsConnect blog.
The :shipit: Squirrel
This little cutie started as an inside joke at Github, but its adorableness quickly permeated the industry. When your code has been approved to ship, your teammates tag it with the :shipit: squirrel, the universal mascot of pushing code.
So if you notice your engineering team sharing a bunch of squirrel pictures, don’t worry - they haven’t lost their minds. They’re just excited to push some new code to your users.
Read the full lore here and here.
Misconceptions
Misconception 1
True or false? "Engineers... do not like speaking with people. Coding all day is good fun, talking with people is torture."
False.
Engineers are just as social as your average co-worker. We’re just very protective of our precious (and limited) attention span.
1. Choose the appropriate communication channel for the situation.
Different situations call for difference means of communication. Choose the appropriate channel based on the urgency of the situation.
| Situation | Timeframe | Appropriate Channel |
|---|---|---|
| Emergency | Cannot wait. Equivalent to pulling someone out of a meeting | Tap on the shoulder |
| Urgent | Within the hour | Synchronous channel (ex. DM) |
| General | Within the next few days / weeks | Asynchronous channel (ex. email) |
2. Respect chain of command
Most of the time, you’ll want to talk to a manager first, rather than an individual engineer. Managers are the ones who have the most information about their team’s availability, abilities, and work load. Trust them to triage your request appropriately.
| Type of request | Contact |
|---|---|
| Feature request | Product manager |
| Technical issue | Engineering manager / QA manager |
Misconception 2
True or false? When you ask for something from an engineer, don't get too detailed. They're the experts, so let them decide how to do it.
False.
Engineers are detail-oriented problem solvers. Ambiguity slows us down; the more blanks we have to fill in, the more likely we’ll end up with a final product that doesn’t make anyone happy.
Here's a true story from Salesforce's engineering team about the importance of being precise. A Salesforce product manager asked that “when an account was updated, shoot the owner an email.” The developer said ok. Then the first email the account owner received read “TRUE”.
Remember to clearly define your desired outcome, but not the means of getting there. For example, often times a stakeholder will ask for data in a specific format - like CSV - which they then take and upload into Google Sheets and spend hours making pivot tables, etc. An easier route would have been to just tell the developer that they need to know X from this data. The developer might know an easier, faster means of analyzing the data (using tools like Periscope, for example).
Finally, don’t hide things from developers; if you think feature requirements will change soon or eventually, disclose that up front. That way the engineers can adjust their design accordingly, with the right balance of flexibility vs. speed.
Misconception 3
True or false? Engineers love details and hate meetings, so don’t bring them into a project until you’ve mapped everything out completely in advance.
False.
Bring engineers in early. Their insights can save you from sinking time and effort into unrealistic goals, and by including them in the decision-making process, you’ll help them feel more invested in the project and its outcomes.
Cliff Gilley describes this problem very well:
“..there’s a tendency in many companies to ‘insulate’ the development teams from ‘the business’... This is a very sideways way of thinking, which usually results in expecting people to execute without context — without understanding the vision, the strategy, the tactics, or especially the customer. And therein lies the problem — people are motivated most when they share a vision of what the future might be, and can see themselves and their contributions in that picture.” [source]
Exercises
Let's practice what we've learned so far. All examples are credit Spencer Rogers, one of our top engineers at Flatiron School.
Conversation 1: Project Manager to Engineer
Project Manager:
How’s the password reset feature going?Developer:
I started looking into the Postmark API and installed their client library, but I started running into some issues in my development environment because of an outdated library we’re using for image handling.
Rough translation: I am working.
How could this make the project manager feel? Confused, agitated, stone-walled, impatient, questioning the common sense of the developer
Is this good communication? No.
What was the meaningful information? I need an update on your progress, so I can assess whether to assign more or less resources.
What would be useful to have said instead? I hit a roadblock, which set me back by ~1 day.
How could the other party respond to invite a better answer? How does this affect the original estimate? Do you need anything from me to get past this?
How could the initial question have been asked better? I’m working on assignments for next week. Can you give me a quick status update on the password reset feature?
Conversation 2: Marketing Manager to Engineer
Marketing manager to developer:
Can you please build us something to address the sign-up conversion rate by the end of the day?
Rough translation: Can you do something you don’t know how to do in an arbitrary time frame that may or may not be realistic?
Is this good communication? No.
How does this make the developer feel? Overwhelmed, unsupported, disrespected, cog-in-machine, irritated that question is so ignorant of their capabilities, reality, etc.
What was the meaningful information? We need something built to solve a business problem.
What would be useful to have said instead?
a) Not a lot of people are signing up for the new service. Do you know how we can fix it? No? Well let’s figure something out that you can build within our deadline.
b) Not a lot of people are signing up for the new service. Do you know how we can fix it? Yes? That’s great. How long would something like that take to build? (then potentially) That’s too long, is there a simpler or interim solution we could use?
How could the other party respond to invite a better answer? I can try my best, but I’ve never had to do that before and I don’t have any idea how long it will take or whether it will be effective.
Conversation 3: Engineer to CEO
Developer:
I just used a really cool algorithm to guess similar words using something called “Levenshtein distance”. The data consistency problem should be fixed by EOD.CEO:
Ok, but what about the landing page update?
Developer Rough translation: I just did something cool to fix the problem and deliver it on time.
CEO Rough translation: I expect you to fix problems like this, what about the stuff that’s actually going to move this business forward?
Is this good communication? Nope.
How does the developer feel? Proud, unhappy that their work wasn't appreciated, rushed.
How does the CEO feel? Agitated that something that set the business back is being celebrated before something that is completing the CEO’s vision of the company is finished.
Two perspectives:
1) Developers spend 99% of their day working on stuff that many people can’t see or appreciate. It can be frustrating, especially when they’ve built something they’re proud of and it’s all they’ve thought about for weeks.
Some developers make themselves less efficient simply in order to manage the expectations of the people waiting on their product. It is tough to gauge if you don’t have a window that you can trust.
There’s also many ways to be a “good” developer. At a small startup, a good metric is whether the developer is producing value for the company, which can be difficult to measure. Many of the ways a developer produces value are not visible to a lot of the company.
CEOs ultimately want their company to be successful. As a developer (or anyone), you should do your best to understand the high level goals of the company.
This doesn’t mean that they’re going to be mean by default. If you had two companies, both producing the exact same revenue, but one had a healthy culture and one had an unhealthy culture, which one would you choose as a CEO?
2) It might be better to find someone else to tell about your cool algorithm, though.
Conversation 4: Engineer to Product Manager
Developer to product manager:
I’m working on the search feature and noticed that some of these filtering options don’t make sense together. What if we did it like this instead?
Rough translation: I was working on this but my common sense kicked in and realized it didn’t make sense. I have an idea that would fix it though.
Is this good communication? Yes.
What was the meaningful information? Everything.
What would be useful to have said instead? Maybe an estimate for the proposal.
How could this have gone wrong? If the dev had changed stuff without talking to someone. It doesn’t mean they have to give up total ownership of the product, but everyone should be on the same page. A lot of people have probably been thinking about this feature.
The best course of action here isn’t the best course of action everywhere. Have an understanding of how these things should work.
Takeaways: Things You Can Do Right Away For Great Good
- Take an engineer out for coffee :)
- Get their perspective on this subject - what’s their advice for working well with developers?
- Ask them about what they’re working on
- Ask about non-work stuff too
- In general: spend time with people from other departments - game nights, lunches, coffee
- Attend open engineering events (demos, retros, code talks)
- Get familiar with the team and what they’re working on
- Get comfortable with shared vocabulary, company terminology
- Get into the product
- Look for opportunities to work with developers (doesn’t have to be on a development project; could be event organizing, etc)
- Volunteer to help out on other teams. Some personal examples:
- helping with QA / user testing
- hosting meetup events (and helping with set up / tear down)
- writing blog posts
- user outreach
Last but not least, let developers know when you appreciate their work. Thank you!
Interested in working on a team that values effective cross-departmental communication? Flatiron School is hiring!
Resources: Articles
- Krzysztof Rakowski - How To Communicate Effectively In IT Projects
- Julie Zhuo - How to Work with Engineers
- Nicholas Zakas - The care and feeding of software engineers
- Cliff Gilley - How to Work Effectively With Engineers
- June Cohen - How to Work with Engineers on a Web Development Project
- Stella Garber - 5 Best Practices for Working with Developers
Top comments (14)
This was an awesome read, and I plan to re-read it a few more times for clarity.
This is super well articulated. Definitely going to share.
Yes, we value focussed attention time but there's also a myth that programmers somehow ned more focussed attention than other knowledge workers. We propagate this myth because it makes us feel special. But most of that need for focus is caused by not breaking the problem into small enough chunks, so we have to keep a bunch of stuff in our head. If you're always in the middle of something massive, any interruption is incredibly irritating. If you break your work into small enough chunks, you have many natural breaking points where you can make time for interacting with coworkers.
This talk goes into that problem, ad it's my favorite programming-related talk right now.
Thank you Ben!
Awesome ! I had so much fun reading it, I wonder if some people actually need it ..
Though this article has a lot of useful information I can't agree with the general tone of developers being different. It paints a broad stereotype of what ultimately is an individual.
A lot of the issues I've seen in companies are directly due to how teams handle each other as foreign entities. Identifying as a class of person inevitably leads to a break down of job roles and puts up walls between the teams.
If you treat a programmer, just like anybody else in a company, with respect, you should be fine. Understand that programmers, just like all people in the company, have interests, have good/bad days at work, have issues with management, and don't like the new coffee machine. The amount of similarity between workers is far more significant than the differences.
Great article with lots of good advice. I also think this is something that will help dev teams. We run a 1 day workshop on working with developers for companies who employ Devs and want to understand them better.
maydenacademy.co.uk/training/#trai...
Loved almost all of this and will be sharing it to my team (we've had some of the communication issues mentioned here!)
One tiny thing is: some of this is culture specific. If you told our team that the product owner (who is also an engineer by trade went down the PO path) was going to assign work, there would be a small revolt (PO included)! We've found the best way to increase engagement is to let engineers assign themselves work based on their interests and the PO simply watches out to make sure no one gets in over their heads. Works for our team, but ymmv. Working this way with my last two teams has built a strong dislike for anyone who wants to hand out assignments haha! :D
Easily one of the best articles I read this year. 👏👋👌✌
Oh god, it's was a increíble/amazing/great read.
You has a great research, thanks very thanks for sharing.
I've truly needed i usually talk of my 'cool algorithms' Haha. Oh thanks.
It is was a read very gratifying.
You and me both 😉😊
This is an amazing read, but being just out of college and creating simple web apps to apply for jobs, I got confused at some points to many degree :D
Amazing, the same problems everywhere :) I bookmarked this page so i can show it to some colleagues later.
Here are a few more tips: israel-product.online/how-to-work-...
This is just.... incredibly accurate. I think everyone could learn a few things by reading this.