Hubris, laziness and playing with toys: the winning attitudes of a startup engineer
What makes a good engineer, designer, or programmer?
Generally speaking, a knowledge worker is only as useful as 1. the solutions they are able to bring to their employer or clients, 2. in a timely fashion, 3. for the right price (salary or fee). It’s less about their specific skills and experience, and more about how well these skills line up with the assigned tasks.
In the context of product- or technology-heavy startups, we have to explore beyond new hires’ skillset and align their attitudes with company goals. Just as there are “war time” vs. “peace time” CEOs, some engineers are better suited at massaging and finessing the aerodynamics of a plane, whereas others are only happy when they’re building one as they’re falling off a cliff.
And so, what does it take to build a plane as you’re falling off a cliff? The right combination of personal drive, a modular approach to development, and the ability to redefine problems on the fly.
Confidence, or ego?
Grit, perseverance, or sticktoitiveness (yes, it’s a real word) all stem from a combination of behavioral factors. Many recent books (Mindset, Grit, Make Your Bed, etc.) address how seeing work as a challenge rather than a measure of intelligence, as well as focusing on the small victories, can lead you to long-term success.
For anyone embarking on a knowingly difficult journey (a startup, research project, a social venture, or even learning something new outside of one’s comfort zone), it helps to assume that success is always just around the corner. Religiously believing that there is a light at the end of the development tunnel gives you that extra push on those late nights and weekends when you blew your sixth circuit, or your code just won’t compile.
Blindly assuming that a problem can be solved can be your greatest weapon when used properly, or your Achille’s Heel — ignoring problems never leads to breakthroughs. However, repeating the phrase “I will f**king show them” can bring you a surprisingly long way when you’re stuck in the coding trenches.
You have to know, not think, that you will succeed.
There’s always a shortcut…I think
Over time, when established companies find their stride, there’s a pervasive statement that starts getting thrown around to justify processes: “Because we’ve always done it this way.”
This statement, by its very existence, makes me question the goal of the underlying process — does it create value for the company, or does it justify someone’s job? This statement gives you permission to stop thinking about the end result. Being physically lazy (not doing as much repetitive effort) is much better than being mentally lazy (focusing instead on optimization and streamlining).
Now, there are industries that require the stringent oversight of procedures to convey trust and safety — plane sensors, for instance — but the process itself, by its existence, should never be the answer to a “why” question.
If you focus on the results instead of the methods, you’ll notice that a lot of processes around can be greatly simplified. With our clients, our value proposition comes down to accelerating and automating tedious processes, for the large part.
Focus on “what” you want to accomplish and “why”, then think about the “how”.
Distracted by shiny things and pretty colors
Gone are the days that there was one and only one reference manual for a programming language that one would read cover to cover before the first line of code. Every new module and library has a “Hello World” example within two clicks of the landing page, because they can’t afford to do otherwise.
If my previous point was about maintaining a culture of redefining problems, this section is about redefining solutions: why build a complete solution from scratch if an off-the-shelf component can get you 80% of the way there?
By playing around with modules and libraries as building blocks, you can dabble, tweak, replace, upgrade, and substitute components in a system with another. If you can build it through modules, you’re one step ahead of your competitors in terms of time to market.
Always thinking about building a new car instead of reinventing the wheel.
So what now?
Although it’s simple to discuss these points at a high level fashion, I recommend the following:
- Give an enthusiastic “yes” to the next request you get. That energy will make you and your client believe that the project will succeed, which in turn will actually help it succeed.
- Look at where you spend your time and effort. Are you continuously copying and pasting in Excel? Maybe there are ways of automating that. Generating new leads with a pen and paper? Look at what tools are commercially available.
- Try to diagram your processes into functional blocks. Now, look at how you can manipulate these blocks. Can you streamline some? What about eliminating some all together? If they have a similar output, can they be merged? These are all options that are up for discussion.
- Get continuously up to date on the latest technologies (TechCrunch is good for general trends, Hacker News is great for new technology implementations). At Lemay Solutions, we’ve changed our standard offerings three times already because of new technologies that we found, so I’m sure it can do the same for you.
Now go out there and build something!
-Matt.
matt@lsci.io ← This actually works. Click it. Say hi.
LemaySolutions.com
Other articles you may enjoy: