LinkedMa Logo
Site is Under Maintenance
Please come back again in...
00 Days
00 Hours
00 Minutes
00 Seconds

3 learnings to work better with Tech

TEAM
Please wait 0 seconds...
Scroll Down and click on Go to Link
Congrats! Link is Generated

It has been almost two years since I moved from a Business Leadership position as a Marketing Director to one in Tech as VP Product.

It all started as a double challenge, from one side we wanted to bring the Tech organization closer to business, and from the other side, along with several doubts, we wanted to see if someone with a Business background could lead successfully a Tech Department.

Photo by Julian Hochgesang on Unsplash

In these two years, I have learned a lot as I needed to expand my knowledge and perspective on countless subjects. I feel now grateful and enriched by this experience.

Now, I can say without a doubt that to successfully link your business side of the company to the Technological side you need to invest continuously in communication and organizational matters.

Recently I have been asked to explain what are the differences between managing Business and Tech Departments, and here I would like to point out some of my learnings.

Disclaimer: This article is based on my personal experience in fairly sizable e-commerce and is not by any means something that could be generalized as every organization is different. No magic recipe can be guaranteed, instead, look at this article as a reference point to evaluate analogies and differences with the organization you are in. In my current role, I do manage integrated product teams, UX/UI/Research, Product Analytics, SEO, and Taxonomy.

How to work better with the Tech Department?

  1. Adapt to a different way of thinking.
  2. Elevate your understanding of your Tech organization and of the infrastructure.
  3. Communicate always objectives, what, and why?

Let’s start looking deeper into these points.

Adapt to a different way of thinking.

In order to be efficient, we as humans often need to recur to simplification to understand something or explain what is our final goal — spoiler alert — this doesn’t apply to Tech.

I was one of the people saying the infamous sentences: “just copy that, it cannot be that difficult” or “I don’t see the reason why this specific request should take so long” — of course in these cases I was not making any friends in Tech.

The reality is that if this sentence applies to business people, it is actually the opposite that needs to happen when you are working with a good Tech team, even for building an MVP (MVP in my opinion is a concept broadly misunderstood).

In a Business Department, often we try to do things fast, taking shortcuts to prove value, accepting the possibility that something will not work at the beginning and we can always recur to manual work to make it work — the entrepreneurial thinking, in tech companies, is often prevailing.

In Tech, in order to get something straight and right from the beginning, we need to think ahead about the edge cases and we need to know how much code we will have to touch, how many processes will have to be changed, and all the possible consequences that a change in an integrated architecture might generate.

Photo by explorenation # on Unsplash

This is a big difference very often underestimated and not fully understood — often this is seen as an unnecessary over-complication rather than the need for critical pieces of information that might change the scope and the size of a possible solution.

We had recently a request to introduce a new feature in our checkout — the end goal was simple and the stakeholders were expecting this to be a fast, low-hanging fruit. When the estimation arrived with more than 200 man-days everyone from the business was surprised. We did sit with our counterpart and we explained that even if the request was straightforward, doing this epic right would require us to do changes not only in our checkout but also in our ERP — we needed to touch not only the payment process but also the claim and refund process and we needed to do this with mixed baskets, partial payments and so forth.

This was possible because we had a properly written estimation and we could explain and show how many changes were needed in order to meet our end goal.

Another funny example was coming from a conversation with another colleague of mine, a director in another Department. One day he went directly to one of the PMs with a simple Naive question “Hey, is this feature doable?”.

He came back to me and told me — “your PM said this is doable, therefore we should do it now”.

It took me some time to understand this, but remembering my learnings, the first thing that came to my mind was to ask “what did you ask?” — the answer was the one I expected “Is this feature doable?”.

I have learned that if you ask a PM or an Engineer if something is doable, they most likely will always tell you “sure this is doable”.

I had to laugh a bit, but then I asked him, “please go back to my PM and ask him — is this feature doable in the current sprint and in the time needed alongside everything else you guys have planned?-”

He did so, and the answer was now completely different.

So, my advice here for everyone who wants to improve the way they work with Tech is -> be specific, understand the edge cases, and have an open and continuous dialogue (even if you need to cut scope to meet hard deadlines, agree with the Technical team on where this is an option and at what cost).

Bonus point: you will be grateful to have developers who will ask for further and more precise specifications, also from a cost point of view. The cost of developing something faulty and fixing it ex-post is ways higher than investing the time in getting the specification straight from the beginning.

Lastly, try to avoid scope creeping (increase or change the scope of a request) when the development has started — solutions are thought and built with a certain scope in mind, and if you change your scope along the way it might be that the solution that is being developed might not be the right one anymore.

Elevate your understanding of your Tech organization and of the infrastructure.

This is probably one of my preferred learnings.
Often people that are not working in Tech tend to see the Tech organization as a bunch of interchangeable people working simultaneously on every topic that might arise.

More than a Department, organized in teams, staffed with the most knowledgeable people on a given domain, they see a Bazar of hands who can work on any topic and exchange them amongst them — often I have heard the following statement “in the end, they are all developers no?” 🙂

Sometimes even explaining the difference between backend and frontend might be a challenge but what is often truly difficult to grasp as an external is the concept of domains, domains knowledge, services, and infrastructure knowledge.

In a good environment, that’s the leader’s responsibility to explain to the stakeholders the Tech organization and make sure they do understand it — anyhow to be successful you do not only need to explain it clearly, but you also need your counterpart to actively listen and comprehend.

I am currently working with more or less 10 product teams, each one of them has its own domain, but on a quarterly basis, we get ways more requests for a specific domain and the one after for another one. The expectation is that we can move people around easily — the reality is that this is neither easy nor efficient.

People develop domain-specific knowledge, they do work and own the code they have produced, and they are familiar with a certain group of services and apps — every change in a Technological team often generates the beginning of a new learning curve, and most likely will cost some latency.

Photo by Bradyn Trollip on Unsplash

In order to explain and simplify this to my colleagues outside of Tech, lately, I have been using an analogy.

I told them to think about Tech as a Hospital — You might have some generalist doing firefighting and bug fixing, but when it comes to the complex matters you want to make sure that a cardiologist is working on your heart, an orthopedist is working on your bones and a neurologist is working on your brain. You wouldn’t ask your cardiologist to fix your brain!

Despite the fact these are all doctors, they are specialists in a specific area and this area is where they shine and where they are most efficient.

In our Department, we have different domains such as Checkout, Payments, and ERP Interfaces but also Engagement, Awareness, Consideration, and Decision.

These teams are formed differently because they are built to be functional for their domain, we have some domains for example the Payment one that is purely Backend driven, and some others like the Engagement one that is mainly frontend driven and they leverage on a platform team for their backend needs (we have an organization based on the team topology framework alongside our customer journey map for the stream aligned customer-facing teams).

Running efficiently in a fairly sizeable Tech organization requires adopting an organizational setup that is functional to your Technical architecture and that enables the teams to minimize the cross dependencies — on the other side it requires also that the external stakeholders have a clear understanding that Tech is not a big bucket of people, often is several buckets with different backlogs and different staff available depending on their domain needs.

Yes, you have plenty of developers, but, no, they are not all the same 🙂

When it comes to the infrastructure we need to start with a disclaimer.

Very rarely two companies are the same and they can be compared unless you do not have your eCommerce on a SAAS with no customization and comparing with another company with the same solution.

Sometimes talking with my colleagues from different Departments I hear sentences like “I know this is easy to get it done, I have talked with my colleague from company Z and they did it in 3 days” 🙂

I believe that, Good for them, this doesn’t mean it will also take 3 days for us, it might be less as it might be more — depending on what needs to be touched.

In our company we have an inhouse built eCommerce running on a microservice architecture, we have done so because we believe our platform is a differentiating factor and a competitive advantage in our market and because it does enable us to deal with some very specific and complex cases arising from selling products in more than 5 different verticals and 500 categories (eg. deal with products that might have even up to 200 variations).

An architecture like the one we have requires people to keep the lights on and does require people to innovate.

For sure an eCommerce can be built on BigCommerce, WooCommerce, Magento, and Shopify; but this decision is always to be taken into consideration of the specific complexity of your business and your needs to customize the customer experience or the UI.

As said before, you also have the possibility to customize your eCommerce when using a Saas Platform, but also this will come at certain costs.

Decisions about the architecture to use are taken based on different reflections in terms of security needs, traffic demand to be served, speed requirements, and customization requirements.

My suggestion to all the people who want to work together with Tech also here is to get an understanding of the architecture and of the complexity of the same, don’t see this as a burden but rather try to understand why you might have a complex architecture and understand the level of freedom a complex architecture might bring in terms of customization potential.

You might have to wait a bit longer to see your feature live, but you will not get a “this is not possible”.

Communicate always “objectives”, “what” and “why”?

Seems common sense, if you want people to understand their work and ultimately be autonomous you need to explain to them what is the objective to accomplish, why and what might some viable solutions or possibilities to test.

Often, anyhow, not enough time is dedicated to properly communicating with your teams the bigger scheme, the economical circumstances, or simply the strategy of your company/your Department.

Photo by Randy Fath on Unsplash

This usually leads to people doing what they are asked to do without having a clear understanding of the why, fighting changes of priorities instead of embracing them, maturating a certain level of discomfort for the organization they are working with, and ultimately — “not understanding the business or the business requests”.

Also in Tech, as everywhere, Communication is key, and there is no such thing as overcommunicating.

Establishing a routine of meetings where people are made aware of the objectives, priorities, and needs of the company at a given moment and at different levels is crucial for the success of a company.

We managed to change our approach to communication by introducing 3 types of recurrent meetings, one called Leaders Round with only Directors and Senior Leads, another one called Scrum of Scrums with all PMs and EMs plus the leaders, and another one biweekly called Pulse with the entire Department.

This setup is giving the chance to talk about things at different levels of granularity depending on the audience and to coordinate the actions needed to ensure a properly aligned communication across the Department.

With this setup the entire organization is constantly aware of what is happening and what is about to happen — everyone has the opportunity to contribute to the discussion, ask questions, and to understand why. If something is affecting specifically one team, we will have deep-dive sessions with this team.

Guess what?

Is not that developers do not understand business, is that you need to take time and explain to them what’s going on and why priorities might change — instead of just dropping requests on them.

A request per se might seem the best viable solution for a person who does not have a complete understanding of the infrastructure, explaining instead what you want to achieve and why will enable people in your Tech organization to think about other solutions that might fit best your infrastructure, that might be faster, that might be more efficient and scalable (this applies also to UX and Research).

In the end, what is more important? Getting something the way you think should be done or achieving your goal? So, let the expert tell you what’s the best way to achieve a given goal.

Aside from that, we also pushed the EMs and the developers who want to — to be more involved in all meetings with stakeholders and have them even in grooming sessions — this gave the possibility to several people to be more directly involved in the business of different company areas, understand their business KPI’s, contribute with new ideas that can help improving the status quo, this transformed the Tech organization from being a passive recipient of requests into an active partner for drafting, validating, testing, developing and launching solutions.

With this approach now we are going towards the formation of some real cross-functional teams — with other teams we moved directly to only set the objectives and let them work together with the stakeholders on how to reach these objectives — this has reduced drastically the number of top-down requests and increased involvement of the entire teams and ownership to deliver business goals (it is not always like that but it is going in the right direction).

So my last advice here is — to communicate with your Tech organization, and see them as a partner and not as a service agency on demand.

You have already inhouse several brilliant people, get the best out of them enabling their point of view and critical thinking, after some time you will be positively surprised.

If you can recognize some patterns with your experiences, feel free to comment and share your point of view, let us know your challenges and how you solved them.

If you have specific questions feel free to ask.
If you are curious to read more of these, follow us!
See ya!

Post a Comment

Read also:
Flash Sale! Do Shopify customization or bug fixing. Get It Now
Cookie Consent
We serve cookies on this site to analyze traffic, remember your preferences, and optimize your experience.
Oops!
It seems there is something wrong with your internet connection. Please connect to the internet and start browsing again.
AdBlock Detected!
We have detected that you are using AdBlock Extension in your browser.
The revenue we earn by the advertisements is used to manage this website, we request you to whitelist our website in your AdBlock Settings.
Site is Blocked
Sorry! This site is not available in your country.