Skip to main content

Soft Skills: Communicate on Another Level

Communicate on Another Level

Over the years I've dedicated a lot of energy into being able to communicate and understand Project Managers, Product Owners, Programmers with various skill levels and specializations, and APIs. However, that list doesn't include anyone with a broader level of concerns. The past couple years I've noticed I've had to communicate more and more with Executives, Business Owners, and Managers of various levels more and more as my responsibilities increase and my impact on projects become greater. So the goal is to learn to communicate with people who care less about the inside workings of the project at hand and more about funding, timeline, overall health, and impact of multiple projects.

Ground Level

I am a software engineer. I understand how code works and how to take an end goal and break it down into smaller tasks for success including the fine intricate details. I can organize code and explain how code works with other sets of code or services for a project or even multiple projects, and I can write documentation for code too. Unfortunately that is not what is really important on the business level.

A Little More Management Scope

On the business level we move from code concerns to management and profitability concerns. End goals need to be broken down into milestones for tracking progress, and impact for time and resources and less about completing three tasks to get X feature completed. Dependency issues transform from inter-dependency between code to inter-dependency between teams, partnerships, and events. In a sense, its the same concerns but with people/team/resource/business components instead of code components. At this level reporting justifications for initiatives becomes critical to success.

Upper Management

A typical high level manager or C-Suit would never know first-hand what they could have saved in money and most likely isn't collecting metrics to find out an accurate ROI. They are trusting the reports of their subordinates. More importantly they need to understand the relationship of the metric of the report to the ROI. This is why time becomes the primary metric. Its easy and simple The faster its done equals the cheaper it is which means better ROI. Errors are a much better metric to track ROI for because alot of errors generally means alot of people are having terrible experiences. For clarity; we are not talking about engagement values. We are talking about the value of development speed vs quality. Is it justifiable to have higher quality development?

Comments

  1. A candidate with strong communication skills is likely to be hired over one who is found to be lacking in this area, even if they are more technically skilled. This definitely holds true in the Asia Pacific context. Read : top 5 soft skills employers want candidates to have.

    ReplyDelete

Post a Comment

Featured

Sitecore with VueJS: Reserved Attributes and Ignored Elements

VueJS Strips Reserved Attributes on Ignored Elements Experience Editor is what makes Sitecore EXTRA amazing as a CMS. Don't get me wrong it has alot to offer but the "oohhh ahhh WWoooWws" happen when it starts showing off what it can do through the experience editor. One of the gotchas I ran into when connecting Sitecore and VueJS (and I'm sure its the same for any framework that crawls the DOM to figure out what it should be doing) is that sometimes attributes can conflict with each other. In VueJS world it thinks its a vuejs attribute and will remove it from the dom and try to use it. Unfortunately even on ignored elements it will still strip its reserved attributes... Which breaks the experience editor with sitecore... The Problem VueJS removes Sitecore's attributes like "key" from the DOM even on elements that are marked to be ignored. There could be other conflicts but this is the one that got me. The Solution To make these conflict...

Other Articles

Sitecore with VueJS: Reserved Attributes and Ignored Elements

VueJS Strips Reserved Attributes on Ignored Elements Experience Editor is what makes Sitecore EXTRA amazing as a CMS. Don't get me wrong it has alot to offer but the "oohhh ahhh WWoooWws" happen when it starts showing off what it can do through the experience editor. One of the gotchas I ran into when connecting Sitecore and VueJS (and I'm sure its the same for any framework that crawls the DOM to figure out what it should be doing) is that sometimes attributes can conflict with each other. In VueJS world it thinks its a vuejs attribute and will remove it from the dom and try to use it. Unfortunately even on ignored elements it will still strip its reserved attributes... Which breaks the experience editor with sitecore... The Problem VueJS removes Sitecore's attributes like "key" from the DOM even on elements that are marked to be ignored. There could be other conflicts but this is the one that got me. The Solution To make these conflict...

Sitecore with VueJS: Html Fragment Module

Sitecore Module for VueJS I recently worked on a Sitecore 9.1 project where we got the chance to use a front end framework called VueJS. If you haven't had the chance to work with VueJS you should check them out  https://vuejs.org/ . It was very nice to work with once we got through some of the kinks. One of those issues was that VueJS is driven by javascript (duh!)...not HTML....You know what likes to spit out HTML though? Sitecore! The Challenge How do we make it so we can use Sitecore's placeholders and Sitecore's render methods with all of the nesting glory that can be done with them into a VueJS template? The Solution To make a VueJS component that accepts the same formats Sitecore uses of course! Under the hood, Sitecore renders a begin tag element and an end tag element. What we know: The most basic render method just takes those two properties and slaps them together to form a whole html element. VueJS utilizes a simple tree structure for components ...