How To Structure Your Slate Implementation Team
This is part two in a series of posts about the 5Ws of Slate implementation. You can read the introductory post here.
When I started with RHB, I, like all of my colleagues, took the Kolbe Index. The Kolbe isn’t meant as a personality test, but rather an assessment of your natural behaviors when faced with a variety of scenarios. Kolbe is designed to determine: the degree and precision with which you gather information; the approach to orderliness you employ when organizing information; how you deal with unknowns and your degree of inclination towards risk, change and innovation; and, how you handle tangibles, or how you deal with elements such as nature, tools or technology. Employees of RHB take the Kolbe not as a metric of personality or social style, but to gain an understanding of how we function as a whole. Like most companies, the team at RHB represents a mix of natural advantages, or personas, such as researcher, entrepreneur, theorist, designer or quality controller. These differences, neither good nor bad, allow us to operate as a coherent team.
Coherent teams are necessary for companies and projects to be successful. Having the opportunity to work with many teams in their implementation of Slate, I’ve had the chance to see what teams work well and where teams can be improved. While not every institution has the staff resources to build a large team, and some implementations fall entirely to one person, I’ve found that implementation teams excel with the right combination of personas, as well.
The Philosopher
All of your implementation team members have the ability to see the big picture. But the philosopher asks the why questions (more on that in a future post!) and constantly encourages the team to rethink old processes and “the way it has always been done.” Philosophers take a high-level view of the project and are curious about how the various elements of the tool should fit together. They challenge the team’s ideas and encourage the elevation of processes to the next level. The philosopher sees implementation as an opportunity to go beyond the technical in order to create efficient processes.
The Architect
The architect works with the philosopher to transpose those concepts and ideas into an actionable plan. The architect extracts the ideas from the philosopher and gets them on paper (or computer). They’re interested in mapping the project out from start to finish and in providing an overarching blueprint for the project, including actionable items that need to be carried out at each phase. The architect wants to keep the team on task and creates a tangible plan for doing so. It might be on a whiteboard in the office or through a project management tool—and there will probably be a GANTT chart or two—but the architect will do everything possible to communicate the project plan, deadlines and individual responsibilities. The architect will keep the team accountable.
The Maker
I’m sure you know where we’re going with this one. And, hopefully, you’ve got a team full of makers. The maker is going to be the technical point person on your team. She is going to know the modules inside and out, how they impact one another and how they should be configured. The maker will know the clicks, the settings, and the order necessary to bring the components put forth by the architect to life. As the person breathing digital life into the tool, the maker will likely push back on the architect and philosopher at times, understanding either the limitations of the product or that one element must absolutely be in place before another is built. The maker will also be someone who understands departmental processes and will build the tool around those.
The Professor
No implementation team would be complete without someone willing to teach others how to use the tool at hand. But, we all know that a good professor doesn’t just teach. Professors are a blend of all of the personas here. They ask the deep questions of the philosopher and encourage their colleagues to think creatively, to keep an open mind and to question why things were built in a specific manner. They sometimes assume the role of the architect and expound on the importance of following documentation, staying on task and providing materials that are both relatable and understandable by their colleagues—describing a technical project in a non-technical way is a skillset unto itself. Finally, the professor morphs into maker, teaching best practices and helping fellow team members to not only troubleshoot problems, but to understand how to resolve errors on their own in the future.
Learn more about how RHB can provide you with strategic counsel for your implementation of Slate.
Each of these roles plays an important part in the success of an implementation. You might find that there are individuals on your team who are both philosopher and maker or professor and architect. Maybe you have one person who is everything. Regardless of the composition, considering these four personas as you build your implementation team and how individuals will work together toward the mission of bringing your system live will pay dividends toward the success of the project.
