Developers: Time and Teamwork
By Greg Hanson
December 4, 2023
Time and teamwork. How do these two concepts fit together? The focus of this post is how blending them can improve not only your programming skills, but also your timeline of projects.
For a recent project I am the project manager of, we had an urgent request from a client for a developer who could be available in the next 2 weeks to work on a project that had about a 6 week timeline.
The project
Initially, it seemed like a pretty easy request to fill. We had a developer who had worked previously for this client, in the very same environment, albeit on a different project. So the roadmap was there: Get the developer into the systems, get the requirements, and do the work.
This client, like many, had some specific barriers to entry, like needing a company email address, access through a VPN, Duo 2FA, familiarity with Monday.com tracking, Office 365, Microsoft Teams for meetings, and so forth. But, as mentioned, the dev we would be using had worked previously in this environment, and so we already had most of the above in place.
So we got started with the first few initiation meetings, getting the basics of the project laid out, tasks assigned, and timeline established.
Then Mr. Murphy showed up as he often does, and the dev we had planned to use got pulled out of the project for an urgent need elsewhere. Okay, project manager, what do we do now?
Time
Well, we dig into the pool of developers we have, and see what we can do. Here is the first recognition of time. We are already about a week into this thing, and now we are starting over. So time is not currently our friend.
Teamwork
I did, however, have two developers who had worked together on many other projects. Luckily, these two developers had also worked with the first developer who was now leaving the project. So we immediately had a few transfer of information meetings.
Time and teamwork
We had a lot of specific questions about what had been requested, and where it all lived. Because these two had worked together for so long, the time it took to get the two new developers up to speed was greatly reduced.
They were aware of each other’s strengths and weaknesses. As I thought about how much these developers’ rapport sped things up, I realized that this was a direct effect of time and teamwork. Also, because of the time spent together, they trusted each other. Respect was present instead of uncertainty, and exchanges were filled with value.
As most of you who are reading this know, programming can be performed in a number of different ways. You can be a lone wolf, you can be a tag team, or you can be a cog in a very large machine. There are places where each of those approaches is the most efficient.
In most cases when you have a pair or a small group, two minds are better than one. If you add time in as the multiplier so to speak, you end up with another dimension to that. These two developers have worked together for quite some time, and that is what enabled them to move so quickly in an unfamiliar environment. As the project progressed, these two sounded off to each other, and as a result many issues were solved internally, rather than ending up on the client’s board. Time spent waiting for client responses was minimized.
Client satisfaction
That doesn’t seem like a big deal, and the client may not have noticed that there were fewer clarification issues than on other projects. However, this did make a difference, and we were able to recover all of the time lost due to the unexpected loss of the original developer, even shaving off a little time on the overall project.
The result was a very happy client. Remember, this client found out a week into their project that the developer we had assigned to the project was now unable to continue. So there was quite a swing from losing a developer to finishing the project slightly ahead of schedule. Our client will remember that.
So I guess the moral of the story is something we probably all know inherently: Time contributes to the effectiveness of teamwork. The longer the relationship lasts, the higher the respect and trust level is between the team members. Knowing this, we can try to keep compatible developers together as much as is practically possible. Mix and match, and try to grow this trust over time. Build teams and come back to them, time after time.
Comments