Top 50 Information Security Professional

by Leave a Comment

TechCXO’s Kevin Carlson has been recognized as one of the Top 50 Information Security professionals in the world. Kevin is a TechCXO partner and supports clients as a fractional CISO and CTO.

He was honored alongside other CiSO and Global Security Officers from organizations like City of Tucson, Equifax, Harley-Davidson, The Hershey Company, Kraft Heinz, Oracle and the US Secret Service. The 2021 OnCon Icon Awards recognize the top information security professionals and information security vendors in the entire world. Finalists were voted on by peers to determine the winners.[/fusion_text]

How to Get the Best Offshore Results

by

In his 2005 Book, The World Is Flat, Thomas Friedman sums it up pretty well. “There is just a job, and in more cases than ever before it will go to the best, smartest, most productive, or cheapest worker—wherever he or she resides.”

My first experience with offshore teams was well before that. Albeit not the best experience, it got better as we figured out how to work together. As distant economies bring the best and brightest online, the world is flatter. To succeed you need to make it a smaller world, too.

[This article was adapted from Kevin Carlson‘s original blog post.]

To best manage these challenges, follow three basic principles to deliver top results.

1. Lead With a “Single Team” View

Nothing kills productivity faster than “us and them”. Unfortunately, a lot of companies experience this. . And it exists in companies with only local resources! With offshore teams, that chasm occurs even easier.

When everyone is working together toward a common goal, you have a team. A team functions best when there is unity and everyone is accountable to the same standards.

In my work, I see this most often between business stakeholders and technology teams. It’s a lot worse when there is another “us and them” on the technology team. Fragmented teams always struggle. Teams with many fragments rarely produce what they set out to build. In the rare case such a team delivers something of value, its perceived value varies to a high degree.

To build a cohesive team across many time zones, always treat every team member as if they are in the same room. One’s physical location should not influence importance, impact, or influence.

A technique that I use to keep this in perspective? Imagine that team members on the phone are working from home that day. Sounds simple, yes, but it works.

As a leader, you set the tone. You set the example. Others will follow and those that don’t, regardless of location, may not be best for the team. Sometimes, you’ll have to make tough choices. When you do, make them early and move on.

2. Define a Single Process for team interaction

Technical projects can be difficult enough when coordinating tasks and information. Business stakeholders, product owners, user experience, developers, QA, DevOps. Everyone needs to know where things stand and what’s coming next.

Whatever method you use to manage the process, make sure it’s easy to use. The more areas in which it’s easy to go around the process, the worse things will get.

I’m a big fan of using tools to create a workflow that — at a glance — shows an accurate picture of things. But be careful, as many out-of-the-box workflows are useless. They are simplistic and a general free-for-all with no permissions or data requirements. In other words, they fool you into believing you have something useful when you don’t.

Don’t Be Shy About Workflow Stages

Take the time to define the process with as many stages as it takes. Permission transitions to specific project roles. Require data when moving items from one stage to the other. And above all, let everyone see where everything is!

On larger teams, create specialized role-based dashboards, too. For example, create a view for the QA team to see what’s in development, what’s ready for QA, what’s in QA, and so on. The combination of these dashboards allows for team-wide accountability and role specific focus.

If you find a workflow isn’t effective in a particular area, change it. Every situation is different and requires monitoring to be effective. I promise, you won’t get it right the first time. I never have.

Keep it Transparent

Avoid the temptation to deny access to dashboards. It sends a message that some information is only for some. It erodes trust, visibility, and feeds the “us and them” mentality.

Of course, there are areas where information is very sensitive and requires care. Security and compliance related issues are examples that may dictate limited access.

3. It’s All About Communication

Communication is the glue that holds a team together. Doubt it? Spend time in a company where leadership sequesters themselves. These organizations become weaker and more brittle by the day.

To make sure the glue is strong, communication must be consistent and frequent. And most important, don’t forget that great communication begins with great listening skills.

You’ll have team members that don’t understand an approach or a goal. They may flat out disagree. Any they may be right. Listen and you will be a more effective communicator because you understand the team.

Don’t Slack on Frequency

Leaders will sometimes slack off on communication frequency. It’s an easy mistake to make. Always remember that a lull in communication provides fertile ground for doubt.

If you’re in a leadership role, turn this around to understand it. Image a dedicated team member that stops contributing ideas. They’re less vocal during stand-ups. It would be natural to think something might be wrong.

That’s exactly how the team feels when leaders stop communicating.

Maximize time overlap

When working with teams across many time zones, it’s important to provide overlap. Even with a 12 hour divide, adjust working schedules to make sure there is ample discussion time.

Teams that don’t get a chance to talk are rarely the most efficient. People will act on assumption instead of understanding. In my experience, this increases churn and rework.

Use video conferencing

There’s nothing like being face-to-face, even if it’s on a screen from thousands of miles away. Body language is necessary to pick up on nuances. Phone calls hide body language. Email hides voice inflection. The less cues one team member is able to give another, the less able they are communicate well.

There are a lot of free services that enable this. If you have a larger team, paid services can provide the best experience. And, if you think you can’t afford it, wait until you see what miscommunication costs.

I recently worked with a company that had screens and cameras in team rooms. Quite often, a remote team member would connect and be “on screen” most of the day. It was like they were actually there.

A Flat, Small World

Things have changed since I entered the technology world. Global competition has made us sharper and global collaboration makes us all better. It is indeed, a flat world.

Using proven practices around team identity, process, and communication increase effectiveness. They serve to make our world smaller, which serves us all better in the end.

CEO vs CTO: Fixing a Broken Marriage

by

CEO vs CTO – Fixing a Broken Marriage

Many times IT dysfunction in a company comes down to the inability of the CEO and the CTO (or CIO) to effectively communicate.  When you talk to the CEO, the problem is that, “The CTO just doesn’t get it.  Every time we ask for something the answer is ‘no’ or that we need more resources to do that.  There just doesn’t seem to be a sense of urgency, or even an understanding around what are obviously the most important goals of the business!  I think we need to go in a different direction.”

And from the CTO’s perspective, the typical assessment is that, “The CEO just doesn’t get it.  She has no idea how much is on our plate and what actually goes into building the platform – and if she would just stop changing direction every week, we might actually get something done!”

The reality is that there is truth in both perspectives and until both parties accept that, you will never get the productivity that you want and need from your technology team.  So… for the CEO, once you admit that the CTO might not be clueless, here are some practical things you can do to repair this relationship and, in turn, maximize the output of your delivery organization.

  1. Accept the Difference – The CTO most likely doesn’t think the way that you do, hang in the same circles you do, dress like you, talk like you, etc, etc, etc…..  It is not surprising that you might have some challenges communicating effectively!  If you can accept that and not try to force a round peg into a square hole, that alone will go a long way towards improving the relationship.  But to take it one step further, spend some time together outside the direct context of business.  Get to know the person.  Have lunch together, go out for a beer after work, maybe you both like to play golf, do something!  It might not help but then again, it might make all the difference.
  2. Get Alignment – make sure that business goals and objectives for the coming month/quarter/year are well understood by the entire technology team and that the plans for that team are in alignment with them.  Even better, include the CTO in coming up with the strategy and goals for the business – you will secure much better buy-in and you will likely get some great insights to help shape that plan.
  3. Trust – Unless you want to learn all things technical, you must be able to trust your tech leader.  If you think that team is not working hard enough or not getting enough done or you think estimates are too high and you try to micro-manage your way to justifying that belief, it will backfire – guaranteed.  If you don’t trust the CTO, get someone in who can validate or assuage your concerns.  If the concerns are valid, replace the CTO ASAP and move on.
  4. Stay the Course – Yes, you must be “nimble” and the company may need to pivot from time to time and you must also be responsive to your customers, however, none of this is an excuse for being all over the place.  Developing software (and other complex IT systems) is a lot like building a house – there is way more that goes into it than just the parts you see and when you change direction (let’s move this room over there), that will likely result in expensive “foundational” changes.  Continual changes like this result in greatly diminished productivity, morale problems, a shaky platform that will not scale, and, ironically, to you thinking that the CTO cannot deliver. 

 At TechCXO, our fractional CTOs/CIOs have significant experience helping to bridge this gap and make the CEO/CTO relationship functional.  From advising the CEO to mentoring the CTO to even taking an active leadership role over the Technology team when things are beyond repair, we can help you get to where you need to be from a product development and technology standpoint.

Greg Smith is TechCXO’s Managing Partner – Product & Technology.  See his full bio and contact information here.

Acquisition Integration: Systems and Technology

by Leave a Comment

Part Three: Systems and Technology

Companies seek to accelerate revenue growth or enter new markets through mergers and acquisitions. They spend a lot of energy and resources identifying the right targets based on synergy and combined financial models.

But oftentimes, the real value of the acquisition is not realized. M&A typically fails during integration. All that effort and capital spent on acquiring the target is wasted.

There are multiple factors from a technology perspective that can cause problems for acquisitions. In this segment, we will look deeper into those challenges and talk about how best to approach this important aspect of acquisition integration.

What are the things to be integrated?

To kick off the conversation, it is helpful to identify the various systems and tools that need to be integrated as part of an acquisition. It is easy to minimize this aspect of integration because the people who put these deals together (and who are likely reading this article) don’t live in this world. However, there is a lot to consider here and if not managed and executed properly, the anticipated timeline and synergies of the acquisition can be missed.

The items below represent the core systems and tools relevant to any acquisition scenario:

  • ERP / Accounting / Expense reporting
  • CRM
  • Phone Systems
  • Internet & Networking
  • Email / Spam Filtering
  • Single Sign-on (SSO)
  • Network Drives / File Sharing
  • Backup Systems
  • Chat / IM Tools
  • Web & Video Conferencing
  • Mobility (cell phones and hot spots)
  • Internal Servers / Hosting
  • Website
  • DevOps Tools (remote desktop support and system monitoring)
  • HR Systems (time tracking, performance management, PTO)
  • Marketing Automation Systems
  • Project Management Tools
  • Helpdesk Tools

If the companies involved deliver a technology product, the integration effort must also take into account those products, the teams that develop them, and all the tools and processes that are part of that development effort. And while the items listed above represent a formidable integration challenge, bringing together multiple products and product development teams is an even greater integration challenge.

Integrating Core Systems

There is no set “right” way to do this, however, I do think that there are some guiding principles that can help you focus first on the things most critical to the overall success of the acquisition.

  1. Shared Identity – once the deal is done, focus first on the tasks that will allow the combined organization to appear as one – both internally and externally. Internally, make it easy for the new teams to communicate with each other and access shared resources. This ties back to chat/IM tools, SSO, access to shared drives, and a unified phone system – things that makes it easy for everyone to communicate and feel like they are on the same team. Externally, the new entity should appear integrated absolutely as soon as possible. Shared email and phone systems are a couple of quick wins in this category, but the website is the big thing here. Depending on the nature of the businesses being merged, this could represent a large redevelopment effort, however, a staged approach is a good way to tackle this. Start off with a quick project to either brand the acquired site or to redirect the acquired site to the main site. You can then follow along with the full project to redevelop the main site to reflect the new, combined entity.
  2. Organizational Efficiency – this category of tasks represents most of the work but also is where a tremendous amount of the anticipated synergies will be realized. It includes systems such as ERP, CRM, HR systems, etc.., each of which is a significant project unto itself. To determined the best approach, it is important to start with an in-depth and independent assessment of the current systems in place in each entity to determine requirements, capabilities, and effort to convert. And don’t always assume that the acquiring company’s systems should be the ones that win out. Either way there is a significant conversion effort at hand, so maybe there is an opportunity to replace an internal system that you have been struggling with – either with the corresponding system already in place with the acquired company or maybe even one that is new to both.
  3. Technical Efficiency – many tech teams will jump to the items in their world as the place to start after the acquisition. While there is certainly inefficiency in different hosting facilities, different helpdesk tools, and different remote desktop support tools, that inefficiency is mostly limited to the IT team and does not impact the rest of the organization. This is why this category of tasks should be last. To do this work last may require carrying additional IT personnel longer than planned, but it is worth it in order to get the combined business operating efficiently as the new entity as quickly as possible.

Integrating Products and Product Development Teams

If the acquisition is bringing together companies with either competing or complementary technology products, there were synergies anticipated in bringing the deal together. To realize those synergies will require many difficult decisions and development efforts to make the products in question work together.

However, unlike the “core” tools and systems outlined above, there is tremendous passion and pride of authorship around internally developed systems. And to make matters worse, since you have to figure out organizational issues as well (including potential elimination of positions), it is very difficult for employees to separate themselves from the emotion to provide objective input. This is why is it critically important to get outside help to do an independent assessment of these systems and the teams supporting them to help determine the plan forward.

There are multiple important questions to be answered such as:

  • Which product(s) should be sunset?
  • Who will lead the combined team?
  • What does the new IT/Product Development organization look like?
  • What toolset (Agile PM, defect tracking, build & release, etc…) will the combined team use?
  • Which customers will be migrated to other systems?
  • What is the right technology stack moving forward for the combined entity?
  • Should the systems be integrated at all?
  • Etc, etc etc…

Furthermore, it is important that these decisions not be driven just from a technical perspective. Technology people focus on technology solutions which may not be the right thing for the business. As an example of this, I was recently working with a company that acquired another company that provided the missing piece of an overall solution they needed to compete effectively in the market.

Shortly after the acquisition, the technology team determined that the effort to integrate the two platforms wasn’t that much less than the effort to build the acquired functionality into their existing platform. And since having a single system with a shared UI, DB, technology stack, and development team was “better” for the company, that was the path that was chosen. Needless to say, the redevelopment of the acquired platform was far more complicated than anticipated and the team also underestimated the effort required to support both systems during the effort. So, after 18 months, not only do they not have the new functionality they made the acquisition for, their existing product and customers have suffered because their focus has been on this redevelopment effort. None of the anticipated benefits of the acquisition have been realized. If, however, the approach had been to loosely integrate the two applications (SSO, Billing, UI refresh, etc…), those benefits could have been realized within a few short months while still keeping existing customers happy. While perhaps not the best “technical” decision, it would have certainly been the best decision for the business.

Fortunately, the acquisition integration risk can be greatly reduced by bringing on the right leadership. TechCXO has partners with extensive experience in the area of systems and technology integration that are ready to help you make your merger successful.

What is the right cloud spend?

by

I was recently asked by a client – What is the right spend on cloud for my organization?  The client was asking about both cloud software (SaaS – Software as a Service) and cloud infrastructure (IaaS – Infrastructure as a Service).  In their technology profile, they had the opportunity to use several cloud applications that ideally fit their organization but they also had some proprietary systems that were a key competitive advantage.  In this particular instance, they had a significant investment in servers and infrastructure in two on-premise locations.

Beside cost, we discussed several other considerations.  From these considerations, we developed a method to evaluate their “public” cloud vs. their private cloud / on-premise spend.

Cost:  Cost is a critical component of the cloud decision-making process and any comparison needs to be apple to apple.  We included people, infrastructure, disaster recovery systems, information security spend and several other components to evaluate cost.

Functionality:  For the software component, there were a number of cloud software systems that fit their needs well and they selected several platforms and migrated their processing to them.  However, they kept some of their custom written systems since they felt those provided a competitive edge.

Integration:  For integration, they selected a cloud-based system to integrate data between their cloud software platforms and to/from with their on-premise, proprietary systems.  This was very cost effective, as they built most of their integrations in a single tool.

Flexibility: One of the reasons they choose to keep some of their proprietary software was their need for flexibility in their core business.  While some cloud software vendors have good flexibility and market add-ons that can add functionality, there are often key business areas that require highly customized software and systems.  

Availability: Cloud infrastructure and applications are designed to be highly available.  On-premise can take much more internal effort to be highly available and to ensure there is a disaster recovery capability.

Scalability: A huge advantage for cloud software and infrastructure is scalability as many customers depend on it and the providers have made it easier to scale (up and down).  On premise / private cloud needs to be designed properly for scalability and can be less adaptable for scaling.

Deployment: Cloud software and infrastructure is easily deployed (sometimes too easily and there can be pockets of subscriptions that are not being used).  On premise systems can suffer from slow deployment.

Security:  Many think that public cloud security is a big challenge, but many of the cloud companies have invested heavily in protecting their client’s data.  Good due diligence about information security is still a key factor in the cloud decision.  On premise software can be expensive to properly secure and monitor. 

The client ended up with a “hybrid” model, which is where many companies operate – some cloud capabilities and some on-premise/private cloud.

Conclusion:  The “right cloud spend” should be evaluated from an overall cost and a strategic perspective, taking into account a number of key decision criteria.

dan-brown-techcxo

Dan Brown
Partner, Fractional CIO / CTO; Interim CIO / CTO
dan.brown@techcxo.com
(770) 365-1901

Dan Brown is a senior technology executive with a wide range of technology, operational and senior leadership capabilities. As a strong leader, he has a proven track record of aligning technology organizations with corporate strategy, building / rejuvenating technology teams and leading organizations through growth and rapid change.

Business Continuity Plans

by

Here’s a rhetorical question… When is the best time to prepare for a hurricane or tropical storm? (BEFORE it strikes).  If you weren’t dealing with the busy hurricane season directly, you probably had at least a passing thought about your business continuity plans.  The good news is — like holiday shopping — there’s time: hurricane season doesn’t officially end until November 30.  So, for those marginally impacted or fortunate enough to escape unscathed, now is good time to reflect on your preparedness.

To avoid any confusion on the subject, the definition of Business Continuity Plans (BCPs) are those preparations focused on maintaining continuous operations even in the event of a emergency. They typically involve communication plans, alternative work sites, system failover/redundancy, and any number of “contingencies”. Compromises like operating in a reduced capacity can be an option based on the agreed risk acceptance of the company. Disaster Recovery Plans (DRPs) are invoked at the point that BCPs fail and the business is interrupted beyond what is acceptable in the BCP.

While the process my vary based on the size and risk profile of your business, you can develop a sound BCP by including these four main phases:

– Project Scope and Planning (Who will be involved in the organization’s planning and execution?)
– Business Impact Assessment (What are the priorities of the business? What are the risks and impacts?)
– Continuity Planning (What strategies, provisions, processes and assets will be invoked?)
– Approval and Implementation (Approval, training, testing, implementation and maintenance of the plan)

These documents are fairly straightforward to create. If you’d like templates for any or all of these documents, email me directly at: olin.wise@techcxo.com and I’ll be happy to send them along.

Olin Wise TechCXO

Olin Wise TechCXO Product & Technology Partner

Olin Wise is a Product & Technology partner in TechCXO’s Atlanta office.  See his full bio here.

The Crucial Computer Science Skills Employers Are Craving

by Leave a Comment

You’ve spent a lot of time around technology. Whether through formal training or pursuing your natural interests, you have likely developed a skill set that employers all over will value. But if Computer Science is your subject of choice and potential career direction—you might well wonder if what you have is enough.

What computer science skills matter most? What do you need to land a job in one of the many careers a degree in Computer Science can lead to? How can you demonstrate your abilities to potential employers and turn your skill set into a salary?

Whether you are considering a career in computer programming, web development, software development or one of many other careers tied to this booming field, you want to make sure what you learn will match what employers want. Keep reading to find out which computer science skills matter most to hiring managers and a few bonus skills that will really help you stand out.

This article appeared on Rasmussen College’s website. TechCXO Partner Kevin Carlson is quoted.

The technical computer science skills employers want

We analyzed nearly 3,000,000 online job postings that sought applicants with Computer Science degrees in the last year to find out which technical skills employers were most commonly seeking.* Note that these skills aren’t pulled from listings for a specific job role—they reflect the skills identified in any job postings that are seeking candidates with a Computer Science degree. These are the desired technical skills listed:

  • Java™
  • SQL
  • Software development
  • Project management
  • JavaScript™
  • Software engineering
  • Linux operating systems
  • Python™
  • Business process analysis
  • Information systems design

But hiring managers and experts in various fields assure us that technical skills, while sometimes required for a position, aren’t necessarily the green-light signal job applicants might hope for.

“I care most about an applicant’s ability to solve a problem, how they think through a task and communicate with those around them,” says Kevin Carlson, vice president of development at DataFinch Technologies. “This shows me how they’ll work with the team long-term. I couldn’t care less if they can pass a pop quiz on a certain technology.”

Carlson explains that too many candidates think about meeting short-term needs and whatever is trending in the moment, when hiring is really a long-term play. In technology, constant learning is almost guaranteed, so some employers will be less concerned about which specific technical skills you have and a lot more interested in the soft skills and less-tangible traits and abilities you bring to the table.

Remember, an employer can always teach you a new process or platform—but it’s hard to teach someone to be a team player or a motivated problem-solver.

Continue reading the article

Three Non-Technical Things a CTO Must do to Survive Growth

by

A growing company is a great place to be. It’s fun to see customer acquisition rates and revenue increase. You’re excited for each new day, each new customer, and each new employee that joins. You’re working like crazy, but it doesn’t feel like it.

And then it happens.

Your team isn’t getting as much done. Quality drops. Employees feel stuck in maintenance roles. It’s a very common occurrence in a growing business and it’s one that you can’t solve with technology alone.

You’re heading down the straightaway and it feels great. That corner you’re approaching is going to be a challenge. The good news is that you can prepare for it. The bad news is that everyone may not make the turn with you.

Below are the top three things that you as a CTO must do — all non-technical — to help a company survive rapid growth. By the way, they’ll help you survive it, too.

Pay Attention to Process

I used to think process was boring. That it stifled creativity. I was a young man, a software developer. And I was quite wrong.

It wasn’t until I worked for a great manager, one that understood techies and was one herself, that I learned. Process is not only necessary, it enables growth.

[The article was adapted from Kevin Carlson‘s original blog post]

Defining a process takes the guesswork out of knowing when something is complete. At a meta-level, each process should mesh with the next stage of work so that handoff errors are minimal.

Here are a few places where processes can usually improve:

  • Development: How does a story, a bug, an enhancement flow through your team? Who handles a task and when? When is it done?
  • Communication: What events do we need to communicate? When? To Whom?
  • Hiring: What roles do you need? How are they approved? Who is interviewing which candidate and when? How are we communicating the each candidate and hiring manager?

Process is nothing more than describing how things move from concept to completion. It’s also not static. Review the effectiveness of a process and make changes, as needed.

Process helps teams align on how things work and will help the entire team function in a focused way.

Define Metrics and Share Them

Every development team I’ve worked with has shied away from publishing metrics. It’s a common theme.

Here’s how development teams learn to dislike providing data:

  • Development publishes a release date.
  • There are unforeseen technical difficulties or unplanned additions.
  • Development misses the release date.
  • The business blames development for being late.

Common result? Yes, but the on-time metric doesn’t tell the whole truth. Metrics can tell the entire story, if you track a holistic set and report on them.

I worked with a team in the past that was being criticized for Sprint velocity decreases. When we began tracking hours, it was evident that the decrease in velocity was due to the unplanned. Bugs, enhancements, and other issues were devouring an increasing part of each Sprint.

When the management team had the entire picture, it was clear that a lot of people played a role in the delay. So they took steps to make things better.

Anyone can stand on the accelerator and get a car to top speed. If speed is your only focus, good luck getting through the next turn.

Everyone wants to track velocity. The problem is that, in and of itself, it’s meaningless. You should also track metrics that uncover issues with quality, bottlenecks, and unplanned events.

It’s true — what you measure is what matters. So measure things that tell the whole story, not a fraction of it. Then, tell the story to everyone.

Hire for the Long-Term

It’s normal to have a cafeteria-style list of skills when looking for a new hire. It’s important to make sure you hire people that have the skills to do the job. But watch out for the pitfalls with taking only that approach.

I’ve participated in many interviews with clients that are more like a pop quiz than an interview. If your goal is to figure out how much someone knows about a given technology, sure, ask the questions. But if that’s your only goal, you are focusing on short-term benefit at the expense of long-term value.

Yes, they have to be able to ramp up in a reasonable time frame. No, they don’t have to have encyclopedic knowledge of an SDK (they publish that stuff online, you know).

Focusing on the skills of problem solving and communication provide longer term benefit. Avoid the temptation to skip this bit when technical needs are critical. Also critical, make sure your recruiting process is communicating your values.

During the recruiting process, ask questions that drive inquiry. Find out if the candidate asks thoughtful questions or if they jump right into code? Do they prefer the details of NodeJs or do they ask about the user?

Make sure to ask questions that can uncover problem solving ability. Experiencing how a candidate thinks through a problem, and how they communicate with others, is the best indicator of long-term success I have found.

Enjoy the Ride

Hard work, great colleagues, investors, and advisors contribute to building toward rapid growth. Enjoy that and realize that rapid growth may require a shift in focus.

A CTO’s role is one that needs to change as the company moves from one stage to another. You may have been the superstar coder and founder that built everything in the early days. Now, you have a team that requires a different focus and skill set.

Focusing on these non-technical tasks will help ensure you survive the transition.