5 Things All Stakeholders Should Know About Developers

As a developer in the Marketing Department at WP Engine, I get the opportunity to work with people from every department in our company. I am working with Support to design a new system for embedding video tutorials in our Support Garage. I work alongside Recruiting to add fun and interactive features to our Careers site. And I help our Labs team develop new ways to target content to geographic areas in WordPress using the GeoIP plugin.

Along the way, I’ve had some fantastic experiences with stakeholders, my colleagues from Support, Recruiting, and Labs who I work and collaborate with. Sometimes, however, miscommunications or misunderstood priorities can create some frustration for everyone involved. In the spirit of improving stakeholder-developer relations across the WordPress community, I present five things that developers wish stakeholders understood about how we work and who we are.

Note: all of these scenarios are exaggerations and simplifications of experiences that I and others have had. Hopefully, we can all take a little from the nuggets below to find ways to work better together and build amazing things for WordPress.

1. Communication goes a long way

You are really excited about this project. It’s so close to taking off. You’ve talked extensively with the project manager and designer about it. In fact, you’ve gone through rounds and rounds of revisions nuancing how the project should work and what you really care about. And now it’s come time to hand the task over to the developer. Your designer will pass along some Photoshop files and maybe a few rough notes about behavior and flow. By this point, the majority of the specifications exist in the heads of you and the project manager. There’s a lot to try to write down.

It gets tricky, because, that leaves me guessing about the desired functionality. Should that slider always have three slides, or will there be more at some point? What type of audio files will we embed?

Instead of trying to play catch up, I (and probably many other developers) appreciate being brought into those early planning meetings where the project specifications are defined. The more a developer knows from the start, the better the outcome of the project. Bring me into the conversation early so I can understand what success looks like. I’ll benefit immensely from this. And you’ll benefit too. You can have an expert in the room ready to share ideas about how best to set up the project and who can highlight areas for growth or new features that you may not have thought about.

2. Development isn’t always easy

Oftentimes, things that sound super easy on the surface, are actually quite difficult or require a little more work than a quick fix. For example, changing the background color of a widget is usually a simple task and I can knock it out in about three minutes. But sometimes changing that background color is more complicated than it looks.

The code that defines that background color also defines the background color for several other widgets. Before making any changes, I’ll want to check if the color would work for all of the widgets, or if I need to change only that one.

The widget also has a lot of “legacy code” tied to it – that is, there are a lot of styles and functions left over from older versions of the site that are affecting the widget. I’ll need to make sure any changes to this one widget don’t affect other widgets or pages that share the legacy code.

I’m also concerned about our site’s general performance and design scheme. We’re trying to keep the CSS we have on the site to a minimum so that it loads faster, and every little tweak adds a bit more “page weight” that will slow the site down. At the same time we’re trying to keep the site’s visual feel consistent across all pages and the background color is a new one that we don’t have anywhere else, which can add more complications to our design scheme.

So it may take a little longer to change the background color than we thought. Please be patient with me and answer my questions as I try to work through all the ramifications of that simple change.

3. Development takes a while

Just like everyone else at a startup, I work on many projects at once. And my team and I have a complex process for determining the priority of what gets worked on in what order. Sometimes that means your project will have to wait a little while for me to get around to it. That small section on the About Us page to showcase our new office may take a back seat to fixing a major bug that we found in our customer signup process or a new marketing initiative that’s launching next week. I may have some other tasks ahead of me that are critical for our business. That doesn’t mean I don’t want to help, or I think less of other projects. There are just some immediate needs that have to happen before I can work on your project.

We use an agile development workflow, which means is we work in two-week “sprints” and any changes to a website will only happen at the end of that sprint. My project manager and I add new projects to our next sprint, which means we’ll get to it soon, but it won’t be live for another three weeks. Again, please be patient.

And if you’re curious about where your project sits in my queue, feel free to ask. My answer may be brief because of the complexity of prioritizing all of our tasks. I’m happy to explain all that to you.

4. Initial designs are not a guaranteed result

Wow, that new design you have for the blog is gorgeous. I love that grid layout. It’s really clean and simple. My concern is that design may look completely different on a small Android tablet, since the mockups were only for an Apple Thunderbolt monitor and an iPhone 5.

I’ve redone the theme templates for the blog to match the design as best I could. Those post titles are jagged now because I found that cutting them off to fit in the grid made them too short for readers to get the topic of the post. And I had to make a judgement call about the layout for those small Android tablets. The pages just looked really cramped and narrow.

At this point, everyone involved in the project should get together to talk through the design again. Sometimes we get to the point where the gorgeous design doesn’t function like we thought it would. We’ll need to rework the design a little. Please be open minded about the design. Try to keep in mind what really matters and what the end goal for the project is. That gorgeous, clean layout may become a little messier to work well with the content. If we can work together, I’m positive that we can find a balance between the design, the functionality, and the user experience that will make everyone happy.

5. Some developers are withdrawn

I know this is a stereotype, but I do tend to be withdrawn in social situations. I’ll be the one who’s quietly sitting in the corner. And when we have the meeting I’ll spend a lot more time listening than talking. I’ll speak up when I feel I have something important to contribute. It will take a bit of bravery from me but I do want to make this project a success. I’m the kind of person who thinks things through before I talk.

What that means in our meeting is that I’ve thought through my idea for improving the project and would love a few minutes to discuss my idea. Remember, it’s coming from a different perspective than the other stakeholders in the room. My idea may address an area of the project that we haven’t talked about yet.

If we both put forth a little effort – me to speak up and you to listen – we may take this project to the next level.

Want to show a dev some appreciation? Hug them! That’s right, hug them. We’re declaring November 1 through November 7 “Hug a Dev” week. During this week (and really, for as long as you’d like to) we’re asking that you tweet a photo of yourself hugging a developer and use the hashtag #hugadev. We’ll pick our favorite photos and reward the senders with some sweet WP Engine swag.