Editor’s Note: Welcome to a new series of blog posts featuring a day in the life of a WebDevStudios (WDS) team member. What’s it like to work at WDS? You’re about to find out. The first in this series begins with Corey Collins, WDS’ first-ever Technical Strategist. Corey is going to walk us through his typical workday at WDS. Read to learn more.
Corey Collins
Job Title: Technical Strategist
Years at WebDevStudios: 9
Before moving into the Technical Strategist role at WDS, I wore a bunch of different hats.
When I first started at WDS, I was a part-time frontend engineer (or, as we were called nine years ago, “designers”). I helped make the web a beautiful place as we experimented building with different WordPress themes, including some of our own creation. This is also where the company began to get a taste of LESS and SASS.
As things evolved, the “designer” term used to encompass frontend engineers faded away and the lines between backend and frontend engineers began to blur. We all began to work more toward our strengths and passions than being pigeonholed as just one thing. This growth, and stepping more and more out of my comfort zone, led to my eventual promotion as a Lead Engineer.
From Part-Time Designer to Lead Engineer
As a Lead Engineer, I led a team of engineers to ensure our projects were completed on time and with a focus on delivering the highest quality of code possible.
As a Lead, my days involved checking in with the team and having a daily standup at some point throughout the day. As teams changed over the years, this would fluctuate from morning to afternoon depending on when it worked best for everybody.
Aside from calls, I’d review code with a frustratingly sharp eye for detail, user test functionality on the frontend and backend, and just generally try and break as much code as possible in as many different ways conceivable to make sure every scenario had been accounted for.
When I wasn’t diving into writing, reviewing, or testing code then you’d probably find me on a client call discussing the weekly updates for a project, running demos of our progress, providing client training, or running full-site QA and user testing on a project from another team.
As our processes continued to evolve, the responsibility of writing project plans for each project shifted to the Leads who would be running the project. This would translate directly to the Technical Strategist role; as it turned out, I was in the very slim minority of Leads who actually enjoyed writing project plans!
Current Status: Technical Strategist
With the move to the Technical Strategist position, I’m not longer writing code most days, aside from working internal projects here and there, or giving back to the community during Five For The Future.
My days as a Technical Strategist kick off with the usual check-ins: Slack, emails, and Jira/Confluence. The Strategy department will drop a quick message in Slack to let everyone know what we’re planning to work on that day and if we have any blockers. Then it’s off to the races.
Most days will include calls with clients in some stage of strategy. Along with our Digital Strategist and Digital Designer, we’ll discuss the needs and goals of the client so that we can begin to formulate the game plan for what the team will be building.
This is generally not a single call, especially if we’re going to be doing design work or a hefty data migration. Once we have a solidified data and design plan, though, another step in the process kicks into gear. I’ll begin to review everything we’ve done up to that point—call notes, requirements, goals, and designs.
I’ll usually have some UX questions around the mock-ups leading to conversations with our Design Strategist on how they expected a specific feature or design element to work both for users on the frontend and admins on the backend. This is one of many steps along the way where I’ll get into the nitty gritty of everything to a (probably) annoying degree.
For instance, if we’re building a block with a set of cards with images, headings, and buttons, how does all of that data get populated? Does it come from a post type dynamically? If so, does the admin need to be able to customize the query in any way? What happens if the post for a specific card doesn’t have a featured image set? Or, is the content all manually entered?
The Deep Dive
Digging into the designs and functionality in this way allows me to dive into two of the main sections of the project plan: technical requirements and user stories.
Technical requirements are the details that describe what a feature does and what it means for it to be complete. This will include the “done” criteria for a feature with additional notes for clarification for our engineers and our client.
User Stories detail out how everybody will use this feature. This includes administrators down to any different user roles that may need to be considered as well as users on the frontend. Will a logged-in user use a feature different from a logged-out user? What happens on mobile versus desktop? What are all of the actions that a user can take when using the feature?
Everything we gather, in the way of features, technical requirements, and user stories, gets boiled down into the project plan in Confluence. This includes detailing out every custom post type, each custom taxonomy, custom post meta, page templates, and any other functionality we’ll be building as part of the project.
We also like to include a future enhancements section of the project plan for pieces of functionality that were discussed during the strategy process but, for any number of reasons, will not be included in the first phase of the project. While we won’t be building these features in the first phase, we feel that it’s important to acknowledge that they were discussed along the way.
Once we feel the project plan is complete on our end, we’ll schedule a call with the client to review the plan and make any final adjustments as needed. When the project plan has final sign-off from the client, we’ll schedule an internal handoff call with our engineering team and the reigns are passed to Project Management and Engineering.
Wrapping up my day, I’ll check through Slack to see if anyone has any lingering questions for me, do one more quick pass through my inbox, and drop any end of day updates into any Slack channels requiring me to chime in. Then, it’s off the computer and to rub some pet bellies (take your pick of one of our four cats or two dogs), play some video games (a lot of Stardew Valley and Tony Hawk’s Pro Skater 1 + 2 lately), and catch a show or two (crossing my fingers for no soggy bottoms on The Great British Baking Show).
This isn’t the last I’ll see of the project, though. Once the project is complete, I’ll come back in to run QA and user testing on the site to confirm we’ve met all of the requirements and to test the overall user experience. Anything I log as a ticket in Jira will get addressed by the team before we hand things off to the client for their internal testing and QA.
A Badge of Honor
When thinking about what I like most about the Technical Strategist position, it’s basically everything about the job. I love figuring out how things are going to be built and, for whatever reason, truly enjoy writing the technical requirements and user stories for these features. This seems like a trait that has skipped a lot of other folks, so I’m glad I’ve been able to turn it into a big part of my day job!
I also have a deep love in my heart for QA, user testing, and digging into the UX of a project to get everyone thinking about why we’re doing something a certain way and how it may affect the people actually using the site. We can design and develop something in any number of ways, but which way is best for both the site and the users in order to achieve the overall project goals?
I can’t explain what it is about all of these things I love so much. Maybe it’s my love of solving problems, quietly judging things, and smashing the system. When I find a bug in QA, it’s like a badge of honor for me. The team has built this great thing, and through some wizardry, I was able to find the right combination of actions to take in order to get an unexpected result.
In the end, I’m still helping to deliver a rock solid final product to our clients. I’m just doing it in a different way than I did as a “designer,” Frontend Engineer, or Lead Engineer.
Now that you have an understanding as to what a day in the life of a Technical Strategist at WebDevStudios is like, contact us about building your next website with a strategy and project plan in place. Interested in joining our team? We’re hiring!
Comments