skip to Main Content

What I Learned From Working With a Big Team

Working on a team is different from going solo

Working on a team is different from going solo

I’ve been working very hard for the last few months on a project to integrate FileMaker with a corporate Enterprise Resource Planning (ERP) solution. Originally, the official decision was to work towards replacing the current FileMaker solution with the enterprise-level tool, but in the end it was much too expensive and inflexible to do so, and FileMaker won the day! (Phew.)

We just implemented into the live environment and everything seems to be going smoothly (so far!). The integration involves passing pipe-delimited text files back and forth between the two systems. FileMaker uses a server-side script to check a watch folder on a schedule for files to import.

Because the data is pipe- and not (the standard) tab-delimited, I use the BaseElements plugin to acquire the folder contents and then process any files contained there. A second server-side script exports any resulting records to a different folder. A custom-built, third-party man-in-the-middle routine is responsible for moving the files across the network to their final location whenever a file appears in the watch folder.

This was a different experience for me. Usually, I’m pretty much on my own and only accountable to the user group who are my clients. I get to design interfaces a little, script a little, troubleshoot and solve problems a little, train and help users a little, project-manage a little. I don’t go to many formal meetings with lots of attendees.

I like that I get to do a lot of different things, and am not just assigned to work a tiny slice of something huge. So I’m kind of glad to be back in my little corner doing my own thing. That said, I did learn a few things from this project.


• A formal development plan is handy for keeping things on track. I usually operate on a more informal plan, but having something a bit more detailed helped me stay focused on the goal. The plan doesn’t have to be set in stone, but thinking through all the phases in advance helps manage everyone’s expectations.

• Having one point-person who knows enough about the project to communicate with both end users and the developer/s makes things run more smoothly. When a development problem crops up which affects business rules, or when the business asks for a process change that affects the data or development, talking to someone who knows both sides–or at least knows who to ask–eliminates a lot of back-and-forth.

• Making decisions is the most time-consuming part of building a system. Deciding what to track, who will do what part of the process, and how it all goes together takes a lot of time and effort, but it’s the most important part and you can’t skip it! Clients/end users sometimes feel like nothing is really being done in this phase, because they can’t see the output, but it’s worth the effort.

If you fail to think things through at the beginning, you’re just asking for bigger problems down the road (that end up being harder to fix). Resist the urge to just dive in and start coding before you have clear idea of what you’re doing.

• At the same time, you can’t think of everything, and later phases will naturally be fuzzier than earlier ones. Put in more effort to details that need clarification immediately and in the near future, and you can leave later details a little sketchier, as long as you have a good general idea of how it’s going to work.


• Read the material that is sent to you, before you start asking questions. Odds are, the answer to at least part of your question is in there. One of the most frustrating things for me was when someone would ask me a question I’d already answered, they just hadn’t bothered to read it the first time. This made me feel that they weren’t really listening to me, and I started wondering what else they were missing that might be important.

• There will be things you haven’t or couldn’t have thought of in advance. Don’t panic! Frame the problem clearly in your mind, do some research, try to think of at least one or two reasonable solutions, then inform the other team members of the problem and the options for fixing it. Depending on the severity of the issue, this could take five minutes, an hour, or a day. Let them know if you have a preferred solution and why.

• Agree to what you can and can’t do. Don’t be afraid to say, “I’m not sure. Let me get back to you on that,” if someone asks for something you’re not sure about.  On the other hand, be clear about what you’re agreeing to. Ask questions if you need to. I probably sometimes risked being seen as obtuse but I’d rather that than agreeing to something I don’t understand.

• Others don’t have the same specialized knowledge you do. Sometimes you have to be patient in explaining things, or explaining it a different way. After all, you want them to do the same for you when you don’t “get” their area of expertise.

• If people use acronyms you aren’t familiar with, ask what they mean. Sometimes corporate-speak can be confusing: I received an email asking me to “activate and release” jobs in FileMaker, but I had no idea what that meant. I asked for clarification, and found out it meant, “Confirm the server-side script is running on the correct schedule.” Who knew?


• Only call a formal meeting if absolutely necessary. Can the question be answered in an email or an informal meeting at someone’s desk? I’m pretty sure I infuriated more than one person by refusing the meeting request and sending an informed email about the meeting topic instead.

• Keep meetings brief and adhere to expected start/stop times. This builds trust, shows you’re sensitive to others’ time, you’re sure what you’re asking is important, and that you’ve thought through how much time you need to address it.

• Have a clear reason for calling a meeting. Everyone hates those meetings for no reason. I just don’t go if there’s no clear reason to.

• Make sure the people coming to the meeting have the knowledge they need in advance. I once had someone arrange a meeting between me and a third person who had no background on the project, hadn’t read any of the documentation, and wasn’t sure what they were being asked to do. Needless to say, it was a waste of everyone’s time. Give people a chance to prepare by allowing them to ask questions of stakeholders or end users, read documentation, or research potential problems ahead of time.


• If possible, do a dry run, end-to-end, before final implementation. Despite your best-laid plans, unexpected stuff happens. See above about clearly understanding the problem, proposing solutions, and informing stakeholders.

• Be responsive during testing. Problems are bound to come up, and it’s your job to figure out how to fix or work around them. Usually these things are minor setbacks, but they can pile up one after the other and be frustrating to deal with just when you think you’re done. Keep your cool and keep the lines of communication open.

• Being a FileMaker developer is awesome! We can do things in five minutes that take two days for other kinds of software (not just because of technical limitations, but because of the difficulties inherent in working on huge software projects). I love being able to say, “It’s done!”

Are there things you’ve learned about working with large teams you’d like to share? Let me know!

Leave a Reply

Your email address will not be published. Required fields are marked *

Back To Top