Tech Leaders Describe the Greatest Challenges
Tech Leaders Describe the Greatest Challenges
The Codeship team asks leaders in technology: "What are the challenges of leading in tech?"
Join the DZone community and get the full member experience.Join For Free
Download the blueprint that can take a company of any maturity level all the way up to enterprise-scale continuous delivery using a combination of Automic Release Automation, Automic’s 20+ years of business automation experience, and the proven tools and practices the company is already leveraging.
You may have noticed that we’ve chatted with a lot of really smart people through our Inside Look interview series. As we wrap up 2015, we’re revisiting some of the sage advice we’ve encountered from these founders, CTOs, and engineers.
Let’s continue this week with the question that has a billion answers: What are the challenges of leading in tech? Today’s tech founders and lead engineers are facing some brand-new issues alongside the usual challenges of building a business. So what are the roadblocks to staying ahead in the quickly changing world of tech?
According to our interviewees, the challenges of getting to and staying at the front in tech include maintaining security while still offering great customer support, finding investors who believe in your vision, and building infrastructure for industries that are historically slow to change.
We’re always looking to improve is our provisioning and deployment. We have a service-oriented architecture or microservice. That makes it hard to monitor your system and to identify the next thing.
On one hand it’s easy to spot a problem when one service is failing — you know what’s going on in there — but it’s also very hard to put that into the bigger picture. Why it’s failing, who’s calling, who’s using this service, and what does it affect.
It can be difficult to get answers out. For example, knowing what the impact of user actions will be. Having a picture of all these actions is valuable, but it’s not easy to capture. It’s hard to maintain, to get all the data of the system, because our system is changing so fast. Because it’s service-oriented, stuff basically gets rewritten every once in awhile.
There are problems where I can only provide tools to the customer so they can correct issues on their own. I can’t just jump in and say, “Let me handle that for you.” But that’s what I’d prefer: “Let me handle that problem for you.”
If we were running anything that didn’t have to be host-proof, then it would be so much easier to write server-side tools or even admin-side tools that we could go in and fix stuff for people. I want people to write in with a problem, and when I write back, I say, “Okay, it’s all fixed.”
Docker and the entire suite of Docker-supporting tools are changing so quickly that it’s a really unique challenge to choose the right thing at the right time. You basically have to make a bet that your implementation is going to grow as the supporting ecosystem grows and as the size of Codeship’s userbase increases.
Some people find this insanely frustrating, but I love the opportunity to learn so much new stuff all the time.
One thing we’re working on right now—and will be working on until the end of time—is measuring and really understanding video playback performance. It’s a very difficult problem because so many factors are out of your control. When you measure things like that, it’s very difficult to figure out what to measure and how, because there are so many variables at play.
Take, for example, your user’s connection speed. It’s not a static thing. It’s constantly changing, and for video in particular, there are different ways to balance quality and deliverability, based on what device they’re using, where they’re located, macro-conditions on the internet, etc.
You have to choose what things you want to optimize for. It’s something that we’re pretty good at, but I also feel like we haven’t solved the problem. I’m not sure we ever will, but it’s a really fun one to work on.
We want to make the entire experience of healthcare transparent and immediate. We think that’s the basis of a really good customer service experience. That’s really never been built in healthcare before.
The reason it’s never been built before is because healthcare has not seen a lot of software development and a lot of automation. Other industries have a whole set of APIs which create building blocks to build on — like Stripe for processing credit cards. We are building that infrastructure in healthcare so that our customers have access to the information they would expect in any other industry; like what is their insurance going to charge them for a medication, or has the physician sent us their prescription.
We are taking a medical world designed for paper and trying to make it behave like a structured set of APIs. To do this well requires dealing with messy and ill-structured data and lots of complex distributed systems.
I think that’s great, but it also introduces a lot of new challenges in terms of managing the complexity of projects over time. It’s wonderful that we have these new tools that make it possible to digest this complexity. It’s easier to build your product in multiple languages if you use tools like Heroku, which allow you to deploy all your applications the same way, no matter what language they’re written in.
On the other hand, I think it’s getting harder and harder for developers to pick tools, because there are so many options which appear viable but that may or may not survive in the market.
The biggest challenge was that it wasn’t something we could bootstrap on our own and sustain ourselves for very long. We had a big vision, ultimately, for what we wanted to do even if we didn’t know the specifics, and we knew that was going to take time. The first challenge was getting the funding in order to be able to start the company and hire some people and start tackling some of that vision.
Ultimately, I probably had 50 or 60 different investor meetings before we got a term sheet to actually get going. We were probably three weeks away from giving up on it and just stopping altogether.
Trying to understand your core customer, how many iterations of the product you have to go through, how you get the right economics for the business to work. Like many startups we wandered in the desert for a few years trying to figure that out.
Published at DZone with permission of Moritz Plassnig , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.