For decades, traditionally non-tech/low-tech companies have started to realize the competitive edge to be gained from investing in technology. We’ve seen an explosion of various “must-have” technical capabilities: real-time customer insights, predictive modeling, search engine optimization, personalization AI, just to name a few. The result of this is that the demand for engineers has also exploded and it would be a challenge to find an organization, in any industry, that does not have open positions for engineering roles.
A side-effect of this trend is that every company has placed tremendous value in the appearance of being a technology company. It doesn’t matter if all of their revenue comes from selling bottled water or fertilizer or dog collars, every organization is actively dodging the imagery of the huge stone building, the giant printer machine that’s always running (because what is Google Docs?), and the sea of cubicles covered in sound dampening wall panels that match the carpets (which are of course tan). They do not want shareholders or potential hires to get a whiff of innovation lag and suspect that the company might be heading towards the fates of Kodak or Blockbuster. Although many organizations have successfully achieved tremendous digital transformations, such as Walmart and LEGO, many other companies are still in the “fake it till you make it stage”. This post aims to provide some tips that may be helpful if you find yourself working at an organization that just isn’t quite there yet.
The best first-step is to realize that it’s ok for a company to not fully embrace the technological revolution. The tech world is a crazy place where the hottest tools from a few years ago are always replaced with something better that all but a few missed. It’s totally valid for a company to fear spending three years moving the entire company onto some new core infrastructure, only for it to be old news moments later. For some organizations, it makes total sense to move with extreme caution and as an engineer, you have to recognize these scenarios. If the company has 250 employees and it’s revenue comes entirely from operating tour buses on Miami beach, there’s no reason to get enraged that “data” still means everyone emailing excel spreadsheeets to each-other. If you’re pitching a facial-recognition software that only lets the bus driver on shift start the car, first make sure there’s been at least one tour bus theft in the twenty-five years the company has been in operation! “Tech for tech’s sake” is a dangerous game to play. You never want a situation where you’re taking huge risks for a small gain.
This doesn’t mean forget innovating all together. It simply means that if you’re pumped about some new high-throughput streaming tool that you learned about at a tech conference, understand that it may be overkill and totally tangential to what brings in revenue (and pays your salary). For many of us who get excited by technology, it’s definitely a hard instinct to fight. Just remind yourself that you never want to end up like all of those Chief Innovation Officers who convinced their boards to ink contracts with Theranos.
Small wins can often be unsatisfying, but enough small wins can collectively tell an amazing story of ingenuity, tenacity, and resourcefulness. If your organization is not willing to endure a year long design, development, and implementation of your greatest idea, find ways to chop up that vision into smaller pieces. If each piece provides a win in and of itself, it can be easier to pitch by highlighting the low-cost for not completing the entire vision. This alleviates the fear of dissociation between technological goals and improving the company’s bottom-line.
Aiming for small wins also helps you fight the image of being some “radical engineer” that more practical corporate-type personas often use as a boogeyman who will spin up hundreds of thousands of dollars in AWS infrastructure just to satisfy some personal intellectual curiosity. It can be hard for some organizations to see that this infinitie curiousity is what makes the best engineers and bold designs can lead to unimaginable ROI. However it’s important to be aware that some organizations need engineers who are very precise like cardiac surgeons and deviating too far into new or experimental technology could make you seem more like Jeffrey Dahmer. Over time, these small wins can help convince your detractors of your larger designs while satisfying your organization’s more immediate goals.
Don’t let a technology adverse work environment stop you from personally growing as an engineer. Today, there are tons of open source projects and new ones are popping up everyday (check out my curated list of projects in the data space!). Some are serious hardcore solutions for the biggest problems in the industry, while others are light-hearted and casual. Many open-source projects also come with vibrant communities that enjoy geeking out about some new library or programming language feature, the kinds of topics that will put your department to sleep if you covered them in a thirty-minute presentation. Use the open source playground to learn, grow, and make friends, all things that will help you tolerate being a factory of quick and primitive solutions at work.
For many traditional companies, labels matter. If something is a “Q4 priority”, the top brass will likely find ideas that are too new and creative as not palatable. Instead, they’ll almost always opt for things that are proven, easily understandable, and repeatable. That being said, you can always bet that they’ll still hedge their bets by devoting some percentage of the company’s time and resources to that magical word—“innovation”.
Under the banner of innovation, you can usually bargain for a sandbox cloud account and 5-15% of any engineer’s time “on the clock” who’s interested in building new cool things. This often forms into a mutually beneficial relationship: they give you free time to experiment in their recording studio and you agree to let them have the songs.
If you’ve ever vented to someone about how your company is afraid of technology and your engineering skills are wasting away, the first piece of advice you probably receive is to just hit the road and find a company that aggressively embraces technology and treasures their engineering staff. Although I believe that’s fantastic advice, let me take a second to explain why I’m mentioning this option at the end of this post.
Regardless of your career or the competitiveness of your industry, you should continuously assess your current employment situation. Careers are no longer built by devoting decades to a single organization. For some hiring managers, this could even be seen as a negative signal, throwing your success and progression into question. Is this person’s success because of a highly tuned company culture that just happened to work for them? Can they be successful in a radically different culture? Have they developed a breadth of knowledge on common problems across the industry or are their skills too narrowly focused?
I’m not suggesting that you continuously bounce to a new company after finishing orientation. What I’m trying to say is that any time is a good time to assess if you should be working where you are. Don’t reserve those assessments for when you get a negative performance review or when one of your design proposals have been shot down. In fact, those may be some of the worst times to go shopping for a new job because it puts you in the wrong mentality. You just really want out and you’re trying not to reveal that too strongly in the interview. Instead of analyzing if a new opportunity is a good fit for you, you end up focused on the bargaining power of having an offer in-hand. A rejection after an interview will inevitably be tied to the dread of having to walk back into a place where you’ve mentally checked out. Instead of focusing on finding the right new job, the entire chapter becomes about the job you’re trying to escape.
In short, finding the best position where your expectations for growth are aligned with the organization’s needs is always a healthy situation that you should seek!
-Sam
Ever stared at a 500 Internal Server Error and thought, “This tells me everything I need to know”? Of course not. Unfriendly errors are the worst. The API consumer gets stuck wondering what went wrong, and you (the developer) end up sifting through logs trying to figure it out.
In software, simplicity is the key to good design. Users don’t need to struggle with complexity; they want tools that help them work, not get in the way. But tools like dbt Cloud, which should make data transformation easier, do the opposite. Instead of a simple process, they wrap users in layers of Git integration, adding confusion where there should be none.
Whether it’s way back when I used to fumble through htop at work to figure out what’s happening with some on-prem server, or if it’s today when
lazydocker and k9s have grown into critical tools that maximize my productivity,
I’ve always been a huge fan of terminal UIs–especially those that are highly interactive.