By now, everyone who codes should know not to keep important details about your project from the rest of your team. But if you don't notice that you're pushing a teammate into a silo of their own...
The project might as well have been custom-tailored for me. We've been encouraging kids to read for centuries, but just reading as a book-report-level exercise in basic comprehension isn't enough. The app I had just signed on to the dev team for would encourage engagement: chapters of an age-targeted story, sure, but followed by prompts for users to write and share their own spin-off stories and interludes between the chapters. On the dev side, the age of our users meant that everything that could be kept behind-the-scenes where users wouldn't have to worry about the details would need to be kept just there. Exactly my sort of project, complete with flashbacks to my community-theatre backstage techie days.
It's a good idea, and it will be a good app...
My team hit the ground running in the right direction -- or mostly the right direction, at least. We had a few meetings with the designers of the app to clarify requirements and vision, worked out a third-party authorization and payment structure, and set up overlapping sub-teams for front end, back end, integration, and the hundred other details that the users will never notice (if we do our job right). I volunteered for the role I'm most confident with: more back end than front end (I love that backstage work!), but offering to take the lead in ensuring that all of the segments -- the front end, the API, the database, and the data scientists' analytics -- play well together.
We were particularly lucky to have on our team a back end specialist who has experience working with AWS and S3 for file storage and management. Since the rest of our web developers were less confident working with AWS, but were eager to learn, our lead back end dev offered to set up the AWS interface for the back end and then walk us through a working example of the code. A hands-on introduction was exactly what the rest of us needed.
The experienced devs are already shaking their heads at this point. Our plans for dividing up our efforts sounded like they would lead to a smooth and productive dev cycle, except for one minor detail. We had a developer who knew how to work with AWS; he was going to help the rest of us figure it out soon.
We had just siloed our coworker without noticing it.
Of course, that "minor detail", like most "minor details", was only minor until it wasn't. The more infamous pattern of a dev team where critical knowledge is held only by a single team member is when someone does it deliberately to protect their position, but it turns out to be just as disruptive when the knowledge is restricted at the outset with plans to share that knowledge soon. But "soon" is not "now".
In the third week of development, as we built up more robust architecture plans and started building all the components, making sure (just like careful devs!) that we were giving ourselves an architecture that would support all the new features we had planned, outside circumstances forced our AWS specialist to leave the team.
Don't Panic
Luckily, it didn't get bad enough to be an unrecoverable disaster. A three-person web dev team for a project this size is slim, but not impossible to work with.
The change has meant that instead of being walked carefully through using a product most of us were unfamiliar with, we've had to scramble to implement a development-and-testing version of the app into which we can plug progressively more AWS features. It means using a relational database to keep track of some of the file info, and using cloud storage mostly for storage and retrieval of larger files -- and it means building our API with an eye to being able to change the file structure in the future without affecting our front end or user experience. We adapt, we learn, we document our code, we move on.
It could very easily have been much worse. I'm sure everyone on the team will remember, though: don't silo your teammates. Spread the knowledge around from the beginning, even when nobody is deliberately keeping things to themselves. Because you never know when the outside world will intrude on your perfect plans.
Top comments (0)