3 Things I Learned Working in Tech

Drawing upon my experience working in a number of different industries, I’m ready to start sharing the top lessons from each industry that can be applied elsewhere. Let’s start with my last gig, Director of Analytics and Digital Engagement at PointSource / Globant, a global digital transformation firm. Essentially they do software engineering for enterprise companies (and so much more).

Insight #1: Agile can drive creation and efficient collaboration

#sketchnoteworkbook

For those of you not in the software arena, Agile is a framework that champions agility, personal responsibility, and independent yet interconnected working. Software development often requires that you start a project when you don’t exactly know the problem that you’re solving and you don’t necessarily know how you’ll end up accomplishing it. Because of this, team members all work independently in technical and knowledge discovery but also must frequently share information. This is one reason why they have daily standup scrum meetings for 15 minutes each morning to report on progress and keep the project moving.

Because projects have many interdependent steps, team members each track their own daily work, follow up for help, and monitor in real-time the progress happening on the project. Documentation happens in a central system. The scrum master is the servant leader of the team who helps everything run smoothly.

Work is broken up into (usually) two week chunks called sprints. After each two week sprint, the team mustย demonstrateย in a sprint reviewย what they have accomplished to the larger group of stakeholders. That demo could be screenshots, a working model, or a successful server call. They key is get feedback from stakeholders continuously, in order to prioritize the work items coming up next and to allow for improvement and iteration. Every two weeks the remaining work is reprioritized and rejiggered. So at the end you may not end up with what you originally thought you would. But what you’ve ended up with is a smart, efficient product that has taken all the changes into account that happened along the way and utilized the resources effectively.

Agile should be used more frequently, even outside of software development. After 6 months or more, your goals and circumstances have almost certainly changed. It’s simply more zen to work with the current reality rather than to try to fit the past’s prediction of the future. In marketing, McKinsey explains one agile approach where a focused team or pod of specialists is broken away from their day-to-day work to do iterative experiments. TechRepublic has a good article about other ways to use Agile in a non-tech or software environment.

Insight #2: UX is Make-or-Break

Wrigley SeatsForget the Field of Dreams. You can build it, but that doesn’t mean they will come. If you don’t understand the journey customers take before, during and after their potential interactions with you, you will never get your customer experience right. You can’t simply come at it with what you want to get people to do. The lens must be one of easing the struggles of the user, fulfilling the customer’s needs, and allowing for seamless interactions in users’ every day lives.

We won’t forget that the user’s needs will be balanced with the business’s return on investment. For our clients, I created a prioritization model to rank new software features based on potential user value, business value, and level of effort/time. These factors all play into your capabilities roadmap, whether you are in software or not, because almost every large project touching your customers involves some form of digital transformation project.

When you are doing (good) software development, it starts with customer research based on data, a comprehensive strategy and user experience design. Of course you need visual design and great engineering to get your interaction or software to completion, but without customer or user focus, all you’ll have is attrition.

Insight #3: Innovation is scary and exciting but lack of innovation = death

Innovation chalkboardAt least half of the things a developer or architect is asked to do on a project they have never done before. They may be familiar with concepts, languages or platforms but each project is a unique puzzle to solve. They just read documentation and experiment and try things until it works or it doesn’t, and try, try again. Of course, maybe it’s quite mathematical and satisfying that you generally have a problem and the solution either works or it doesn’t. In marketing and CX it feels harder to measure success. Things frequently end up sort of working and the biggest challenge is to figure out what could possibly be wrong. That’s how I’ve built my career, using the data to figure that out and recommend a path forward.

I really admire the way the best engineers and architects are able to look at each new technological challenge with fresh vision and a drive to make a project innovative. The downside to this is that innovative people get bored pretty quickly when asked to do the same thing twice.

Lack of innovation not only leads to the death of businesses, but the death of the workers’ satisfaction and growth. The goal is to drive toward innovation with a fierce focus, whether you are a creative or an engineer or an accountant. If the client or the boss or company won’t remove the blinders and let you innovate, figure out small ways to sneak in new ways of doing things. Always continue learning. Don’t wait for others to show you the way.

What have you learned along the way?

I’d love to hear some interesting things you’ve learned in one industry that turned out to be words of wisdom for all industries.

 

Leave a Comment

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.