Some things I’ve learned from startup consulting
This is the second time in the past decade that I’ve stepped away from a full-time position and gone the route of being a lone wolf. This time, for the past 6 months, I’ve been working with a handful of different companies across the country to help them address the issues they’re facing as growing technical teams. This work has been extremely interesting and varied: I’ve been low-level, hands-on helping with performance problems to very high level, helping a small team figure out their work and hiring roadmap. I was able to share a lot of knowledge with all of these teams, but it’s been rewarding to be able to learn a lot from them as well.
We’re all the same Special Snowflakes
The first thing you experience being thrown into a number of different functioning teams, is that they all believe their problems are unique and they all have very different ways of solving them. Taking an outsider’s perspective, you start to realize that while, yes, the large number of individuals and choices that led each organization to where they are today are unique, every modern engineering team suffers from a lot of the same symptoms. We can call these patterns or anti-patterns or commonalities, but the fact remains that when you have the opportunity to put these situations side by side, you see the same threads.
This shouldn’t really be a surprise to anyone — the confounding part is that many people want to believe that they have it the worst (or the best) and refuse to look outside for help or even just compare notes with other people in similar positions.
I’m barely talking about technical problems here. We all blog and talk about the challenges of this language or framework and how we moved from x.js to y.go and from mono-services to micro-liths. We hear a lot less about all the problems of our personal infrastructure and how we plan (or don’t) to refactor them. This is certainly in part because we have this strong belief that these problems are ours and ours alone and how could anyone benefit from conversation around it? I’ll keep saying this until the day I quit tech for good, but your biggest problems are always going to be people problems and the only way you’ll improve is by talking and listening to other people (historical or present).
As a consultant I’m able to gather expertise because I’m able to see, communicate, and act on these similarities between teams. If every team was a special snowflake and singular, then the work I do would be almost impossible.
Everyone is swimming in Technical Debt
A primary reason I’ve been called in is to help a team navigate and come up with a plan for addressing their technical debt. There’s a general assumption amongst teams that technical debt is a product of “moving fast”. While I don’t disagree that this often exacerbates the situation, the buildup of “legacy”, broken, and problematic code is just a fact of working on a long running project. If you have a reasonably successful product with a team thats grown and changed over time, there will be areas or whole repositories in your code base that people are afraid to touch, that emit a horrible odor, that “we don’t talk about”. I’m not saying this to complain — I’m saying this because every team has to deal with this. When you’re tip-toeing around a codebase and cursing the state of things, it might be helpful to remember that despite the claims of other teams on the internet of their glistening and healthy code bases, they too have a bunch of dirty corners where they sweep things that they just don’t talk about. Either you’re swimming in technical debt or you’re just too early or too unsuccessful to have accumulated it.
How teams manage this and continue to grow and even thrive is what I’m interested in. The challenge is not only around actually planning and implementing individual fixes, but addressing these in a functional and long term way. I’ve said it before but big rewrites are rarely the solution, so working in the scope of incremental changes, though harder to plan up front, is usually the only achievable solution. I’ve seen this work. It’s not an overnight change, but with dedication and motivation, I’ve seen codebases shift.
Technical Debt is easier to solve than distrustful workplaces
The thing about technical debt, though, is often its rate of growth or stagnation is tied or exacerbated by other dysfunctions. It’s one thing to have to put refactoring aside to just maintain the status quo as a user-base grows. It’s an entirely other thing when wounds are taken for throw-away features, endless scope-creeps or clever developer tangents. These are all side-products of teams that are not on the same page about goals or teams where the balance of power and ownership is off-kilter.
In a vacuum, tackling mountains of bad code is challenging, but not impossible. You can see a solution and work your way to it. In the real harsh environment of Planet Startup, if you can’t effectively communicate the need or the severity of the work that needs to be done, it will never happen. The test then is not the actual work of writing code, but the work of navigating the politics and demands of a growing team. Reminder: this isn’t impossible, but it might not be the challenge that you set out to solve.
Sometimes all you need is a spark
In technical operations we often talk about “the probe effect”, in which the tools you use to measure (performance, load, etc) often have a visible effect on the system they’re measuring. I’ve noticed a similar effect when I’m working with a team — the act of taking the time to talk about and start to address some of the known issues makes a difference in-and-of-itself. I’d like to believe that my presence, guidance, and positive energy has something to do with it, too, but I can honestly say that a large part of making progress is just about making the space for progress. Working with an outside perspective that’s only there for a limited time forces this and ideally lights a little fire under everyone to really start moving on some of the goals they want to achieve.
In all of these organizations, I’ve observed a lot of very talented people who are wholly capable of getting massive things done on their own being restricted by lack of time and clear direction. This is not a problem with an individual — it’s an organizational problem, one that is common and takes a lot of work to actually solve. There are ways to get big wins with minimal effort, though: giving these ambitious individuals clear and achievable goals and the ownership and help to reach them goes a long way.
As a consultant I’m given a bunch of special powers of internal navigation and leeway that I wouldn’t get as a full time employee. That has advantages for me, but it also speaks to how much more is possible when individuals are given trust and leverage to make change. I’m not suggesting you treat every employee as a consultant, but sometimes trying to look past the institutional weight of change can allow for the spark that people need to do greater things.
If you’re interested in working with me or just want to talk more about this, you can email me at aaron@quirkey.com or find more information about the work I do.
