I’ve spent 20 years helping things make sense for other people. It’s not dramatic, but it’s important, and it gets things done. I’ve done it in tech companies, financial companies, and I’ve done it in my own company. My job is not to be the smartest person in the room - my job is to make sure the smartest person in the room can do their job.
Initially a scrum master role. Out of necessity, it evolved into handling most project planning and coordination for a cloud startup. Established agile practices (modified scrum) for product teams, assisted product development and coached teams into owning practices themselves. Oversaw tools and processes for keeping everything working. Beyond that, covered a wide variety of business needs that the startup had no dedicated role to cover, including competitor research, video production, copywriting, audit support, GDPR conversion and administrating internal systems.
Engaged clients as an analyst to help identify their needs and establish a working plan. Success with these engagements lead to project management roles in delivering work for government clients, mostly the USPS. Transition to project management also lead to education in agile practices (Scrum & Kanban) and update to our project practices.
Analyzed technical, business and regulatory specifications as well as customer needs for credit card processing POS systems, and developed specifications based on analysis. Reviewed and troubleshot large volume transactions.
Despite the changes in company name, title and location, the essential nature of the job maintained a central thread of talking to people within the company, identifying needs, and pursuing the best solution. As an information architect, this centered around documentation, document management and training. As a developer, it revolved around developing internal tools for our intranet. As a system analyst, it moved on to talking with vendors and selecting (or rejecting, as appropriate) large scale tools.
Responsible for talking with teams, getting an understanding of what they do and what they need, integrating that into the larger vision, and communicating their requirements to other groups in a comprehensible fashion.
Working as a NOC technician gave me an understanding of basic networking and network troubleshooting, and strong insight into the difference between how tools are designed and how they are actually used.
Supported judiciary staff by researching issues and legislation, preparing briefs, answering correspondence for the Senator, and covering committee hearings.
Inaction is not an option. If you know what needs to be done, you should be doing it. If you don't know what needs to be done, then the thing to be doing is to figure that out. Uncertainty is not a reason to stop, nor is it a reason to flail. It is an opportunity to find the path forward and learn from it.
This is easy to say and incredibly hard to do, not least because sometimes they aren't. But it doesn't matter - this is the foundation of respect and empowerment. Even when it is not true, this trust allows people to move forward until it becomes true.
I love problems. Any problem that you encounter is a result of many factors - people, processes, incentives, environment and more - and the specific problem is an opportunity to look at those things and determine that if you make a small change in the stack, you can produce an entirely new (and hopefully better) outcome.
And communication is action. Understanding this is essential to achieving clarity in any group of people, because if we take action without consideration of what that action communicates, we invite confusion. If, instead, we take responsibility for communication as part of action, it leads to better action, and smoother sailing, all around.
I used to express this as "fail faster", since that's a common idea in agile circles. Take risks, fail often, learn, iterate and improve. These are great ideas, but over time I have concluded that speed is incidental to the process - done right, it will be fast, but speed is a consequence, not the product. The priority must be to fail in a manner which is most recoverable, and which generates the most actionable insight. This approach must be paired with a willingness to fail honestly rather than an instinct to re-spin failure as a success.
Metrics are critical to any ongoing success, but only as long as they reflect what you're actually measuring. Measurement must be reviewed, tested and iterated alongside everything else. Otherwise you risk getting green lights on all your results right until you drive off a cliff.