One-on-One with projekt202: Solutions Architect Drew Loomer
In this projekt202 conversation, Solutions Architect Drew Loomer discusses the ways he helps companies improve their digital experiences for customers:
As a Solutions Architect, what does your work at projekt202 involve?
Really, when we're talking about working in the front-ends, that would be implementing designs that are worked out by our UI/UX designers and then interfacing with the client to ensure that what we're building actually meets their needs and that it meets all the business requirements.
When you meet with a client, are you meeting with engineers or stakeholders?
It's both, yeah. As an architect, you're interfacing with the stakeholders and taking their requests and their requirements, and translating them into actionable items for your development team, or if you're working in an integrated model, it will be with their development team as well.
When people ask you about your work, what's the quick answer to that?
I would say, "I work with the internet, creating online experiences and web applications to work the way you would expect them to work. When you go to a site and you are clicking and interacting with buttons and things, that's what I do. I make those buttons and those things."
Can you describe a typical day as a Solutions Architect?
We work generally in an Agile environment, so an average day can depend on where you are in that cycle.
In general, it's checking in with your team, making sure that they have enough tasks on their plate to keep them busy, working with front-end developers on my team to make sure that they have specific users’ stories that they're working off of and that they're working on the right stuff that's been prioritized, all of that. Then, keeping that feedback loop open with the client, so that they're aware of exactly what we're working on and, as their priorities might change, we can adapt to that.
"We've created an ecosystem for this company's internal developers to keep it running ..."
The average day is doing a lot of coding myself, doing a lot of wrangling of people and making sure that they know exactly what they're supposed to be doing, and then working with the client to make sure that my understanding of what they want is actually what they want.
It sounds like a lot of communication and collaboration to unveil “What are we actually going to build? What technologies are available to us? What are we going to actually do with all of this?"
Absolutely. What a stakeholder might think they want might not always be evident in how that transfers to the work that we're supposed to do. They might have a request, for instance, and we might have a better idea of how to go about implementing that.
It is about communication and making sure that we have the best solution for a problem and ultimately putting out the best product that meets the requirements of not only the business, but also delivers a user experience that is going to be ideal and lead to more conversions for the client.
Can you tell us about a recent project success?
A project I've been working on lately is for an enterprise design language. That is a set of user interface components and best practices that a client is using to take all of their pieces of software and start to make them look and behave similarly. They have several hundred pieces of software that they've either built or acquired over the years, so things look very different and are built using different technologies.
What we've been doing is building out basically a tool kit for their development teams to use going forward as they revamp and rework their existing applications to start to bring them all into alignment visually and from a user experience standpoint. It’s how all of the pieces on the page fit together and crafting a tool for them to use internally.
Is this tool digital or interactive, so that another engineer or front-end team could use it?
Yes. It’s custom-tailored to the needs of this particular industry. What we're really delivering is a set of tools for them to use, and a bunch of guidelines and documentations for how to use them, when to use them, where and why to use them. For example, when do you use a checkbox versus a toggle and all the best practices.
When is this going to be used? Is this something that has a lifespan or is this something that's going to grow over time?
It's already in production, actually. We've worked on it for six months or so, kind of reaching critical mass in the number of problems we've solved.
Basically, we started by identifying all of the components that go into making an online experience or web application. Then, the domain specific components for this industry and prioritizing all of these features in a huge backlog. We've been working our way through all of these components and patterns starting with the most common ones first.
We've created an ecosystem for this company's internal developers to keep it running, add their own bug fixes, add new components or modify existing ones as requirements change or even as tastes change. You know, in five years maybe, people may want the toggle to look differently, so now they can in from one centralized place, make a change and have that propagated about to all of their software.
Can you share a favorite experience from your work at projekt202?
What I really like about working at projekt202 – and the whole reason I really wanted to work here and continue to work here – is because it's a place that is really into employee development and building each team member and their skills. Really, my favorite thing so far of my time at projekt202 has been growing as an individual and as a team member, and as a leader, as a developer.
Across the board, I feel like I came in here 10 months ago and I'm infinitely better. I feel better about myself and what I can offer. Some of that happens naturally over time, but making that change happen is such a part of the culture at projekt202. I've been floored by how easy they've made that and how important they've made that transformation.
Is that because of the type of people you're working with on your team or is that because of the leadership at projekt202?
It's really all of those things.
I work with great people who come from different backgrounds than I do, who teach me things every day, but then, the leadership at this company, it starts there, this drive to make everybody better.
Honestly, they want us to stick around and you can tell they put these programs in place – like a mentorship program or management training, all of these things – that it's like an institutionalized, defined way to better the whole team by helping us better each other.