The hiring challenge as a way to rethink internal teams and institutional priority.
A big part of my early days at the Barnes have involved strategizing about how to build a digital team. We need to be mindful of the size of our organization while balancing the needs of implementation plans. The aim is to accomplish our projects with an investment that will scale internally while being sustainable in the long haul.
I spent years in my previous position hiring an internal team and, while it was always something I advocated, it was always tough. Competition in the tech industry was beyond difficult. Attracting candidates to our positions at the rates we could pay was not something to be taken lightly and positions were left open, on average, about eight months before we could fill them. This has been an ongoing issue for colleagues across the country, so I knew when stepping into Philadelphia that the landscape would be very similar.
Beyond the practical difficulty in hiring, there are other, more important, reasons to consider. An internal team is a great thing, but it can also hamper development because you can you can only develop so fast. With an internal team of six people, I found that between new projects and taking care of the codebase, we could only really work on one project at a time. In a situation where you’ve built up a sizable foundation, you can work with that limitation to plan projects and set priorities. In a new situation, like the move to the Barnes, the big difference is the lack of technical foundation combined with need to run multiple projects at a high priority. Simply put, we could build a team, but now is not the right time to do so; we couldn’t hire a team fast enough at the size we’d need to get everything done in the time we have.
So, how are we going to do this?
We are looking to hire firms and partners in the short term who can build projects from our ideas. Very frankly, there’s no shortage of good ideas coming from internal staffers across our industry, but there does seem to be a shortage of firms who will take those ideas and build them to spec. In some cases, we’ve been seeing firms come to the table to implement their own priorities and ideas; this is something specific we are looking to avoid. While there will be a lot of creativity involved in the building stages and valuable ideas exchanged, we want the start of dialog coming from our own direction and that will be true in how we want a build projects, too.
We’ve got a set of strong ideas in how we want to work and, sometimes, these could be counter to how firms like to work. For instance, projects will be built using open platforms instead of custom ones. We aim to release all code as we go. We hope to use some unconventional architecture and cloud based SaaS on the backend — more on this soon with the wearable — in places where it makes sense. We’ll take the time to build APIs as the basis for every project, so we can grow them internally or externally at a later date. Most importantly, we will retain the IP in our contracts. Finding partners who are game to develop in these ways will be challenging, but critical moving forward.
HappyFunCorp is building our wearable prototype and it was clear from the beginning that this firm operated very differently from those with which we had been familiar. Ideas start from us and, as their client, our build requirements are considered even when they sit outside of what the firm may conventionally use. So instead of presuming that they know better than us or limiting what they do to what they know, HFC uses their experience to provide essential feedback and ideas based on our goals instead of their own strategies, and executes accordingly. A fundamental of this can be seen in their working process; they don’t recycle code internally from project to project and, guess what, all of their projects feel very unique. You know you’ve got a good player on your hands when they send you the starter contract and the clause about IP ownership gives that right over to the customer as the default position.
When we hire firms and consultants, we are also asking them to blog on our behalf as the project develops, so just as we would with an internal team information sharing is a high priority. To that end the team over at HappyFunCorp is going to start publishing about the wearable build on the newly formed Barnes publication; we hope you will follow it.
For now, we see our selections of partners as key in our efforts to develop important projects and maintain openness while doing so. Moving forward, we are not ruling out a small onsite team and the role they will play. You’ll also hear us talking about the need for in house content teams with as much importance — if not more so — than in house technical teams; this represents a shift in my own thinking that feels pretty significant.
The Barnes Foundation wearable digital prototype is funded by the Barra Foundation as part of their Catalyst Fund.
Want more info? Read more about the Barnes Wearable on Medium and follow the Barnes Foundation publication, where we’ve got multiple authors writing about our projects.
