managing retrospective
I was just updating my tech i know and tech i use pages. It strikes me how far I have come since I started those pages and a lot of the i don’t know… section now belongs in the i’m learning section.
Also, my interests in web development and web design have matured. Today, I want my focuses to be on the design side of development, still very much the front-end, creating design systems, pattern libraries, and component libraries as well as supporting user interfaces for the web. This is a huge rabbit hole of technology that bleeds into everything from performance, accessibility, web components, libraries, frameworks, and so much more.
With all of this in my focus, where do I stand today?
best of both worlds
I’ve worn a lot of hats in the last decade of my career, most recently the hat of an engineering manager. There’s a point where you go from being a senior developer, who’s been in the throw of code and development for much of his or her career, and decide on how to move forward either with more contributor roles or with management roles. In fact, engineering management is a parallel track to engineering or development, it’s helpful to lead by example, when there’s time and availability.
As a manager, my strengths are in the collaboration and partnerships that are needed and required to move forward. I bring a lot of passion into the positions I take on various projects or ideas. In fact, I can be so eager to move an idea forward and the controlled chaos that ensues. As a product strategist, there’s so much potential to look for optimizations and efficiencies to get things done. In my last year of management work alone, I’ve come a long way to move the needle in the right direction, looking for compromise and yet pushing for effective outcomes.
I find it satisfying to put in any time I can on both coding and managing where it makes sense, where my abilities best serve the team. As a manager, I make a conscious effort to not to move the needle for a project. It’s my number one job to enable and support the lead developer/engineer to make these moves.
we are all designers
One of the main takeaways from the various projects I was involved with the last few years of my career is that the software development life cycle (SDLC) that we all know is pretty out of date. In so many companies, There’s still this mentality of waterfall models, hand offs, where all the concerns and ownerships are still so isolated from each other.
What I never really understood, but I feel is crystal clear today, is we’re all involved in the design phase of the SDLC. Our primary concern, regardless of content, components, code, copy, creations (how many Cs can you think of? :) is the design of everything. In the spirit of my interests at the beginning of this writing, we should all be talking to each other from the very beginning. Content people are writing primarily for what they know, but if they could talk about the user journeys from a design and development perspective, in addition to content management or SEO, it might unlock new potentials for what the most effective content is.
As a designer, we should also have the ownership to create in the medium we publish. This means relieving ourselves from leaning on a lot of abstract tools. What if we were all able to start and finish a project inside of the same, exact tool? Just as our desktops should get out of our ways to create, so should our tools get out of our ways to produce.
Each stakeholder, each expert in their domain, should have the autonomy to do their job. We all need a sense of ownership and agency in the work we produce. At this point, however, we shouldn’t be isolated or siloed in how we move together. You work with a team, move as a team, and succeed as a team.
the ideal
If there was anything that could feel the most relevant to my career, it would be to improve the SDLC to focus everything around the design experience, to congregate teams to use the same product from end-to-end of the cycle, and to heavily focus on systems. Web teams should put as much energy and focus into design systems as possible, encircling this idea with all the libraries and guides needed to move a product cycle forward.
The most efficient path is the one where all the stakeholders are included in the same suite of software and products to deliver results efficiently and effectively. We shouldn’t be waiting on each group to completely finish their work; how many times have I waited first on content managers, THEN on designers, THEN on project managers, etc, etc., before being able to move on code. So much wasted time and lots of problems delivered to the developers! Hand offs were kind of effective in the years past, but today’s agile environment needs more collaboration and teamwork.