Advice from the Trenches: Working with your Dev Team

So you hired your team. They are a bit funny looking over Zoom, but you vetted them and are confident that they are ready to develop your big idea. What do you do now and how do you get along with a bunch of weird techies? More importantly, what do you need to do to keep things on budget and on time?

Whether you are working with your own internal dev team, outsourced to an outside firm, or you just found “a dude” to write some code, your project will not be successful if you do not know how to manage the nerds and keep them focused. Here are some tips and advice to doing just that.

It Starts with Trust

The foundation of a successful development project is trust. Now this could be said about most things, but it is especially true with development. Creating software is a tricky and often messy business and even the best teams with the best intentions can go over budget or miss a deadline for completely valid reasons.

At the beginning of any new relationship, the onus of building trust is primarily on the dev team. Now that doesn’t mean they bear all of the responsibility, but it is their job to prove themselves as a capable partner right out of the gate.

So how do they do that? What separates the amazing teams from the skeezy ones we want to avoid? Transparency and communication. A trustworthy dev communicates a lot, especially if something goes sideways. You should never find out the day something is due that they are behind. They should have told you as soon as they realized it and came up with a game plan on how to correct the situation. When things are going well you should get links/movies/something that shows that and keeps you engaged and excited about the project.

As the manager/client/big kahuna, you should accept no compromises here. If your team “goes dark” that is often a bad sign. Poke them regularly to make them communicate and set those expectations.

In the end, the head of your dev team should feel like they are a part of your company. This sounds a bit silly if they literally are a part of your team, but what I mean by that is they should be an advocate for your project and someone who not only understands what you are trying to achieve, but is excited about it and wants you to be successful. It should be more than a paycheck.

Managing Creep

The biggest friction point you are going to have with your development team is almost guaranteed to be around scope. Now, there are a million ways to define scope, but just for clarity, I define scope simply as “what is going to get done, how much it is going to cost, and how long it will take”.

These expected features, timelines, and cost are defined in what is known as specification document or “spec”. The root of the friction is that spec documents rarely get into the super nitty gritty and as such there is almost always a bit of wiggle room for the dev team and the client (i.e. you) to have some form of misunderstanding. This is 100% normal.

“Scope creep” is when the features begin to wander outside of the agreed upon spec. This can happen with a friendly email asking for a new feature, the dev team misunderstanding a feature and building the wrong thing, or a “WE NEED THAT” moment from the client (or often the client’s boss). Bottom line though… a change is a change is a change. It needs to be captured and factored into the project.

So what is a great client and manager like yourself supposed to do here? Ask a lot of questions and communicate.

What exactly took more time? Let the devs get nerdy here. You don’t need to understand the ins and outs of the code, but the more detailed they are, the more likely this isn’t just smoke and mirrors. If you still have doubts or this is a common occurrence for your team, it might be worth bringing in an outside expert who can see what is going on inside the code. Your dev team should welcome an audit. They should be proud of their work and happy to walk through it with just about anyone.

Can we meet before the next deliverable to make sure everything is clear and this doesn’t happen again? Often more communication will find paths around things that are more complex. Perhaps feature X can be simplified or avoided all together? Or maybe there is a better way to build X?

I will talk about this in more detail a bit later on, but the biggest cause of creep is when too many people have access to the dev team so keep it focused.

A good relationship should have a give and take when it comes to scope. The dev team is on your side and therefore should be willing to do their best to keep things tight and on budget even with a bit of creep. Development takes time and expertise. If something needs to change then both sides should be upfront and honest on who is taking it on the chin. Sometimes the client pays more money (or adds time to the deadline) and other times the dev team works extra to get it done.

Let Experts Be Experts

You are an expert in your field. You know all the widgets from the doodads from the gizmos. This is what makes you excellent at your job. Coincidentally, this is also what makes your dev team excellent at theirs.

What often happens when it comes to managing a dev team is that a client believes that their expertise in their field translates directly into software design. While your knowledge is critical to the success of the project, it is important to let your devs offer solutions to the problems you need to solve. They will often surprise you with inventive solutions that are easier to build and will save you money.

Development is a collaborative effort and both sides have value to bring. You know your business and they know theirs. Trust is, again, crucial here. If the devs say X feature will take 40 hours, feel free to ask for a breakdown so you can make sure you are on the same page, but trust it when they give it to you.

One Throat to Choke

As I mentioned earlier, the number 1 reason for projects going sideways is that there are just too many cooks in the kitchen. Clients often lead by committee which means everything….is….slower.

Ideally, try to have a single point of contact in your company to have the final decision, manage the scope, and talk to the dev team. Having too many people reaching out to the dev team can create a confusion of expectations, priorities and will result in a constantly changing spec. No good comes from that.

This goes for the dev side as well. They should have a front person that helps you strategize what should be built and then communicates that back to the team to get it done.

Now I am not suggesting that all communication between teams should stop. Again, let experts be experts… Bring in the designers when you need a new screen or flow, or if a subject matter expert on your team needs to talk, then encourage it and take notes. The key is that at the end of the discussion all tasks should come from one person to one person. That way there is much less room for confusion, which leads to clear expectations, which leads to magic.

Feedback is Required

As the project moves forward, it is imperative to provide thoughtful, consistent feedback to the team. If your dev team is missing the mark, then say something! Without feedback, they will assume they are on the right track and continue building. If they are going the wrong way and no one says anything, what do you think happens to the project?

My recommendation is that for any ongoing project (i.e. more than a month long), the leads on each team should meet once every one or two weeks. Catch up, build rapport, discuss the good/bad/ugly and plan for the next push. It shouldn’t take more than an hour and it will keep the project chugging along.

I have said before, but it bears repeating… building software is hard. It is hard to do and it is also hard to manage. If you have read this far, then you are already way ahead of a lot of clients because you have shown a desire to learn and treat your team right. That desire will help you get the software you need built well, on budget, and on time.