Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
  • Blog Articles

    Criticial Ransomware Incident - Massive cyberattact through tech provider Kaseya

    IT management software vendor Kaseya whose VSA software platform is used by other tech companies to monitor and manage customers’ IT networks, has been the victim of an audacious cyberattack. On July 2, the business issued a security advisory urging its customers to immediately shut down versions of VSA running on their own servers. It also suspended its own cloud-based VSA service.
    Kaseya VSA is a remote management platform for MSPs that provides solutions such as automated patch management. According to Kaseya, the platform has been used by more than 36,000 MSP customers worldwide.
    "Beginning around mid-day (EST/US) on Friday, July 2, 2021, Kaseya's Incident Response team learned of a potential security incident involving our VSA software," the company's CEO Fred Voccola said in a statement shared late Friday.
    Kaseya's official recommendation is to:"IMMEDIATELY shutdown your VSA server until you receive further notice from us."
    This attack already has compromised eight of Kaseya's MSP customers with 200 businesses linked to three of the victims reporting instances of file encryption. This Reddit post from huntresslabs show the progress of sorting out how to fix this ransomeware attack.
    On Friday, Mark Loman, a malware analyst at security firm Sophos, tweeted the hackers demanded $5 million as ransom in exchange for the file decryptor. Image comes from thehackernews.com.


    This seems to be quite nasty and here in Sweden it has affected one of our chain of groceries stores as they are unable to make payments due to this affecting their cashiers. In the US hundreds of companies have been affected and it is safe to assume that many companies in the EU and elsewhere might be affected as well.
     

    Serious vulnerability in Windows Print Spooler "Print Nightmare"

    If you have the "Print Spooler" service enabled (which is the default), it means that anyone with access can execute code as SYSTEM against the Windows domain controller. At present, there is no patch from Microsoft. So take a break from your vacation and turn off the service immediately.
    From Tenable's blog:
    E5GOlYUXwAUyqzU.mp4
    More information from Microsoft: https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-1675
     

    Atomic CSS - what is it and is it useful?

    Atomic Design, or Functional Design as it is also referenced, is a bit of a weird beast. On one hand, it is a programmatic shorthand feature that allow you to use short code in development that then render CSS based on that, but it also a philosophy of sorts on how to organize CSS. A philosophy that very much resemble the inline-css era of old.
    The problem statement
    I think this statement says a lot on how ACSS and to some degree Atomic Design itself see the world of CSS. Anyone working with wild or free CSS development can certainly recognize some of these pain points. This is not uncommon in scenarios where many developers work in the same project or you have to work on top of a not so well-designed product.
    The question is, though, how many still work in that way and why?
    In a scenario where you have a defined design pattern, which should be the norm these days, this is rarely an issue. Regardless if you do atomic design or component design, your styles should be easy to maintain and define. Despite this I still see a lot of JS developers adopt inline styling and duplication of CSS in components. This is more common in libraries like React and Angular, I feel (personal experience, no real numbers to support that).
    So it is not surprising to see a rise in areas like Atomic Design or ACSS since that help bridge the gap in skill levels some JS developers have and the inherent despise we have to spend more time than we have to on things we don't really enjoy doing. Not to mention, there are some benefits that should not be overlooked.
    ACSS - Atomic Design as a preprocessor
    ACSS is a preprocessor that will transform inline HTML variables and create CSS from it. It has a fairly simple syntax and it works by looping though the HTML and scrape up the variables and then make a CSS file from what it finds.  In many ways, this is similar to inline CSS, but you would get a static CSS file instead of just printing it out in a style tag.
    If we borrow an example from the excellent CSS-Tricks site that I highly recommend you check out, then here is a snippet of code where we declare some classes and input a variable to each.
    <!-- Programmatic Atomic CSS Example --> <div class="Bgc(#0280ae) C(#fff) P(20px)">Lorem ipsum</div> The output from this would then generate the following CSS:
    .Bgc\(#0280ae\) { background-color: #0280ae; } .C\(#fff\) { color: #fff; } .P\(20px\) { padding: 20px; } This may seem quite useless compared to a well-defined CSS with variables declared that I could just input, but you could use both of course and use this to override in certain situations. Similar to how you would use inline styling.
    The biggest benefit of this however is that the CSS generated would be as small as you could make it. This is because the CSS would be based only on what can be found in the HTML. This can be useful for development in for example Angular and React, where I assume this is mostly used.
    In situations where you have classes reused over many components, like this website however, that would not really be as beneficial as having multiple CSS files is never a good thing and you would see duplication of classes. This is of course if you generate the CSS on a modular basis, but not if you render it globally on load somehow.
    Overall, I do not see any need for me working with sites like Invision Community and I feel it would not really work well in an atomic design situation with defined styles in both the UI and the HTML/CSS that is reused across components.
    I may be completely wrong about that, as I have not tried it and if so, sign off in the comments to tell me I am wrong 🙂
     
    Atomic Design as a Philosophy
    The idea of Atomic CSS is simple and, to be honest, not very new. The idea is to create single attribute classes and then stuff the HTML with them. Kind of like you would do using Inline styling, but with a global definition of the styles. It would look something like this.
    /* naming utility classes */ .relative { position: relative; } .mt10 { margin-top: 10px; } .pb10 { padding-bottom: 10px; } I say that this is nothing new because this has been around since before inline styling even existed. One reason it is not widely used is because it makes the HTML cluttered and hard to read. It is also a bit annoying to work with compared to having well-defined CSS classes as you will have a ton of attribute shortcuts basically rather than a library of styles.
    If you are used to working with frameworks like bootstrap, then you are already familiar with the concept, since those frameworks also have libraries of smaller styles that you can mix and match. Atomic CSS is much smaller however and rather than having for example a flexbox class that have the standard values you use all over the site you have to build those up with a set of classes inline in the HTML.
    Is it a terrible idea?
    Atomic design as a concept can be traced back to October 2013 and an article written by Thierry Koblenz. It has since evolved and you will often see it in reference from the new breed of JS developers that work in frameworks like React and Angular. While it may be a bit unfair to say that these new JS developers do not have that same deep understanding of CSS as the "regular" front end developers, I do see this distinction growing.
    For the JS developers however, this is pretty useful as they can focus on function rather than form. You have probably seen the mess that sometimes happen when JS developers mix inline styling, component specific styling and global styling. It is as bad as having multiple novis CSS developers trying to use EM when they do not control the output containers...
    I hear some arguments that this makes it easier to avoid specificity issues, but I do not agree with that. If you control your code, then you are a pretty bad developer if you can't handle your classes properly. It all comes down to planning and setting structures after all, unless you are just playing around like I do on this site.
    I digress though and to answer the question if this is a terrible idea I think there are use cases for when this can be useful. Since that article in 2013 however, I think those use cases are less now, especially with the introduction of CSS variables. I do however think there is a very good case for using this same idea for defining variables and to keep your classes small as a philosophy.
    I do think there are certain scenarios where it is a good idea to use the concept of Atomic design, and that is for overrides. Things like fonts, colors and spacing can be useful to sometimes just make a small adjustment rather than building new components.
    Also, if you generate your content at runtime on the server, there are benefits to this since you can combine it with CSS-in-JS to dynamically generate very small CSS files. I guess this is why React and Angular developers are liking this way to organize your CSS classes. You can still do this working with regular CSS, but the files will be bigger since you are bound to have duplicate attributes in your classes.
    So it is not a terrible idea, but it comes with some issues.
    Allow me to explain...
    My Thoughts
    While there are benefits in some cases, there are some negatives as well. The biggest issue for me is that while we reduce the CSS, we instead increase the size of the HTML. The HTML also becomes much more cluttered and harder to read because unlike CSS where we can group classes, or even split them on multiple files, HTML will just be one big garbled mess.
    Consistency is also an issue because the idea of recreate clusters of classes to achieve the components is done manually every time, then you will see consistency go out the window. We see this all the time in wild or free CSS, where pretty much every component have its own class styles uniquely. This is especially problematic if you have JS developers that are not very good at using CSS and you try to set up a design library.
    At the end of the day however, front-end developers are flexible and resourceful people. All of these potential pitfalls can be managed and if Atomic CSS works for you and those that you collaborate with, then go for it. Just don't make the decision just in the development team as you need to work well with both Design and Test so they should have a say as well. Also, your way of working must work across teams, so don't start using Atomic CSS if you at any time will have other teams working in the code as well.
    You know all that of course, but it is something that you can never repeat too many times.
     
    Do you use Atomic Design today?
    If you do, what benefits and pitfalls have you uncovered?

    Project, Maintenance or Line Work - what is the difference and does it matter?

    If you work in IT, you have probably heard the words projects and maintenance many times. Usually it is in reference to different teams and organizations, but not always. Sometimes the same team can do both projects and maintenance, which can cause some confusion. To add to that confusion, you will sometimes hear the word line work as well. As these all see to be a bit malleable, it can cause some annoyance. With this article, I hope we can make a definition so we all know what we are talking about.
    These are all financial constructs
    Before we begin, let us define what these three terms refer to, since they are sometimes confused with processes or even methods. Projects, maintenance and line work are all financial constructs. This means that they exist as a way to manage budgets and resources. In most cases, projects and maintenance exist together and form sequential ways of working (waterfall, RUP and so on) while line work is the basis for iterative forms of working (Agile). This is also reflected in their financing where projects and maintenance mostly have fixed budgets and scope, while line work have fixed budgets, but scope is more loosely defined against value themes.
    Project
    A project is usually the easiest to define of the three. This is because most of the work in IT are still project based, so most people still work in projects. Projects are by their very nature sequential, meaning that they follow a step-by-step process to get funding and approval based on certain values. These values are often defined as features, but in some cases it can be other types of values. The difference between projects and line work is however that value need to be measurable and once set it normally can not be changed.
    Projects are defined as time limited bubbles of time, scope and resources that can span across different borders such as systems, organizations and even companies. When this happens, the project is split between the different areas and placed under an umbrella structure we call program. This makes projects the easiest form of financial structure to organize when you need to span multiple areas.
    Most companies that have been around a while also have a strong culture of organizing external resources around temporary work as projects as well. This is usually well-defined in their vendor management structure as well. This is why projects are the most common form of financial construct in most companies.
     
    Maintenance
    One of the most misused term of these three as it is often used for anything that is not project based. It also comes in two very different forms based on how contracts are defined in Vendor management.
    At its core, maintenance is nothing more than making sure the systems are working properly once a project has ended. This means that as a project ends, there will be a list of items that need to be taken care of, usually in the form of known bugs and technical debt. After the handover, maintenance handle unexpected incidents in production, problems and in some cases it also includes enhancements such as refactoring to make the system more stable.
    In some cases the maintenance get to work right after a release. This is when contracts are written without post go-live support, meaning that as soon as a delivery is accepted and released, the team in charge of the development no longer are responsible. This is often an awkward situation where the maintenance team and the development team can start to resent each other if there are a lot of incidents being released to production due to poor testing and acceptance processes.
    All of this is handled in a service management process that is matched against a contract with SLA and a budget for the work to manage the system or systems. This is often paid for by the product owner(s) or a business area within the organization on an annual basis, which is often managed through maintenance plans.
    Unlike project and line work, maintenance are not generating new value. The purpose of Maintenance is to maintain value, or to correct loss of value due to problems and incidents.
     
    Line work (line organization)
    If you have ever worked in maintenance where you also do development for new features as part of your work, then you are probably in some form of line organization doing line work. The term refers to a manufacture line where you continuously build things. Unlike a manufacture line, where you do the same thing all the time, line work in this context refer to continuous improvement when it comes to development.
    Line work, just like maintenance, usually have an annual budget. Unlike maintenance where the goal is to maintain value, line work have the same aim to produce new value in the same way as projects. In line work, however, this value is usually defined in terms of focus areas, or themes, and larger goals rather than defined ones as you have in a  project. This makes line work better suited for exploratory work such where value creation is iterated based on result.
    Line work often employ a flexible workforce, allowing them to quickly adjust resources based on need. This also works well for larger initiatives where the flexible workforce simply expand their numbers for a period of time and then shrink again. This however require a different way of handling vendor management and contracts as you can not define them around deliveries, but rather against value creation.
     
    The confusing mix
    It does not really matter what form your financial construct have, because at the end of the day you will adjust your preferred way of working anyway. You can work in an Agile methodology within a project and you can do waterfall in a line work setup. There will be challenges of course, but people do it every day all over the world.
    It is when things get mixed up you start to get problems. This usually happen with line work and maintenance, or projects and line work.
    Anytime you hear that maintenance also should so development of new features, then you are fading into a mixed situation, or are moving towards line work. This is confusing because you mix the concept of not generating new value in maintenance with creating new value as in line work, but without the flexibility in financing. This can cause headache, not just for managing the budget, but also because maintenance usually do not have a requirement process defined. The situation can be fixed however by moving over to a line work setup instead.
    The most common situation however is when projects try to mix fixed time and scope with exploratory methodologies. This is often done by implementing a sequential scrum methodology and an ad-hoc requirement process. Scope creep are very common and frustration high from confusing requirements and trying to iterate value within a confined time frame with fixed budged and deliverables.  The solution for this is usually to focus on requirements to reduce the ad-hoc situation and try to iterate withing the limitations presented in a more flexible way, rather than agile.
     
    I hope this helps
    As I see these terms used on a daily basis and sometimes in a very confusing way, I hope this definition helps. If you disagree with my definition, feel free to write a comment and we can discuss things. If you like this article, or better yet, find it useful, a comment or like is always welcome 🙂

    5 interviewer tips - for landing a senior employee

    We have all been in those interviews where the interviewer completely botch the interview. Weird IQ tests, being asked to do design or code on the fly or questions that are irrelevant to the work at hand. Sometimes it may even be that the interviewer is completely the wrong type for the interview and so on. In this article I will list my five top interviewer tips for interviewers to land that awesome employee contract for a senior IT or design person.
    Tip #1 - You are the one that have to sell the position
    Surprisingly many interviewers have the attitude that they are doing the potential employee a favor by letting them come to an interview. This may be true for other types of work, but professional IT people are in very high demand and for a senior person it really is their market, not yours.
    So if you come from another field where there are more people to hire than there are positions, you need to adjust that mindset. Otherwise, you will have a very hard time attracting people or worse, keeping them.
    People that are junior or new to the field often bend over backwards to land a job at a prestige filled company, but most seniors have already filled their CV/Portfolio and are done with the backfilling process where you endure crappy jobs just to build a CV/portfolio.
    These people know that they can afford to be picky, both in terms of job descriptions, workplace satisfaction and of course salary. You often compete with a dozen or more other companies for a senior employee.
    So rather than asking them to prove to you that they have what it takes, you need to prove to them that you are worthy of their time. That is quite different compared to dealing with junior employees or recruitment in other fields.
     
    Tip #2 Don't waste their time
    Unless you are offering someone's dream job that you know they will do anything to secure, don't waste their time. Asking a senior employee to do code tasks or design tasks to "prove" their worth is a sure way to turn many applicants away. The only people that will put up with that kind of nonsense are people that are unemployed or are still building up a CV/Portfolio.
    If you are looking for a senior employee, they will rarely put in extra work just to get to an interview. They have other options that don't require them to work for free anymore. Besides, they can easily pay someone a few bucks to do that assignment for them anyway, so it is kind of pointless from a validation perspective anyway.
    If you want to verify someone's skill, then just have another senior developer in the interview and have them go over some code or design together in a think aloud fashion. The other senior employee will pretty easily spot if the person know what they are talking about or not.
    Just be mindful that a lot of people get brain freeze during interviews, so this should not be your only interview point.
    IQ tests and personality tests are not uncommon either and I would strongly advise you not to use those. Most people don't like these kinds of test and they are likely to drop you as a potential employer because of that. They also do not really give you any information that is beneficial for your decision to employ or not.
    I kind of enjoy doing these, but that is because I already know my IQ is high and I have done a lot of personality tests so I know what to expect from them. Others don't like this kind of surprises as much though...
    If you want to have a psychological test that is actually beneficial, then you should look into the dark trinity traits, but then you are diving into a whole different set of pitfalls and problems.
     
    Tip #3 - Do your homework
    Just as the person you interview will do their homework to look up your company and it's values, you should also do your homework. I don't mean that standard homework to make sure the person you employ is not a hateful bigot or a criminal, you should also try to find out as much as you can about the person.
    Introverts and extroverts are quite different in terms of what they need and how the information you present should be done. Introverts often prefer more structure and information as bullet points with clear decisions and distinctions. Extroverts often like conversation and more visual information and so on.
    Some people are social hotspots and can chat up rocks, while others are less comfortable and prefer others to lead the conversation. Knowing what type you are meeting allow you to design the meetings accordingly.
    Knowing things like hobbies, passions and peeves can help you connect far easier, even with more closed people. It also offers a way to make the person you are interviewing to feel more familiar and comfortable.
    If you have someone close to you that know the person you are about to interview, talk to them and ask them about the person beforehand. This will help you tremendously in your interview.
     
    Tip #4 - Represent your culture
    I have seen this a few times when the person doing the interview is not a good representative of the company culture. It can be that you have a company that is all about the people in the company and making a difference in the world that has a recruiter that look and behave like a sneaky car salesman. Or it can be a sales oriented company that is all about winning and celebrating victories where the recruiter is all about caring and making the world a better place.
    The problem you face if your style does not match the company culture will most likely happen later in the process where the potential employee will meet other people in the organization. Or it will happen after employment which often lead to that person leaving very soon, or become a source of negativity in the work place.
    So make sure you adjust your interview technique and your look to fit the culture and values of the company you represent. As you are often the first point of contact, your impression will be crucial in landing the right kind of employees that will fit into the company's values and culture.
     
    Tip #5 - Don't brag about hiring people to fill a quota
    It's not that common for people like me that are white males, but I have seen it and heard about this way too many times. No one want to be told that the reason you are called to an interview is because of your age, gender, race or your sexuality. Also, no one like to hear that they did not get a job because another applicant was of the preferred "type" and you were not.
    I know that it is generally a good idea to make sure you have many types of people in a  company and I love working with people from all walks of life, but never, ever, discuss this during interviews! It is offensive and in many countries even illegal to discriminate in such way.
    If you have two applicants that are equal in qualifications and you like both, then it is up to you which one you want to hire and adding more diversity is almost always a good idea. If however one applicant have better qualifications and you still hire someone else based on other things than their qualifications, then you are digging your own grave.
    Not only are you discriminating people, but you are also making the life of the person you hire difficult as other employees will notice that that person is less qualified than her role demands. This leads to friction and envy from other employees and the person you hired will suffer more from that feeling of being a fraud and not good enough.
    Be fair and hire the best applicant, regardless of other qualifications not related to work. There are plenty of amazing people of all "types" out there, if that is your goal.
     
    Don't be a bigot.
    This is not a tip, it's common sense. Or at least it should be. I know a lot of people that feel that they must change their name to get work due to bigotry. So if you discard applicants based on name or how they appear in a photo, then you are an idiot. And a bigot.
    Not only will you must definitely miss out on some amazing employees, you also put constraints on your business because you will miss so many amazing points of views and experiences.
    I have worked with people from all over the world and it has been the best experience you can imagine. I have worked with Jews, Muslims, Christians, Buddhists  and other religions. I have worked with people from all political affiliations as well as people from the whole rainbow of sexuality (almost). I have worked with disabled people that have taught me more about my work than I could ever have imagined.
    I have worked with people from simple and poor backgrounds and people from rich backgrounds. I have worked with people that could not read a book if their life depended on it, but they can build anything with their hands. I have worked with people that could not handle a tool if their life depended on it, but who could solve any problem with their mind.
    Some of the most amazing people I have worked with have been from other countries such as Lebanon, Morocco, Vietnam, Syria, Germany, Croatia and India to mention a few. I have learned so much from these people that goes beyond work and as someone as work in a male dominated field I constantly have my mind blown by amazing women that can see things differently than I can.
    I can tell you from experience that being afraid to the point where you get prejudiced is normal. We all fear what we don't know or understand. The best way to break that is to take a leap of faith and get to know the things you fear and more often than not you will find that the prejudice you have are wrong.
    So don't be a bigot.
    Be Awesome.

    The bad boss - what is a bad boss and what can you do about it?

    Employees don’t leave organizations, They leave bad bosses. We have all heard it and we all probably have a bad boss experience or two in our career. But what is a bad boss really? Are they just terrible monsters that tear organizations apart, or are they just people like you and me?
    Just as people are different, so are our perception of what a bad boss is. What I consider to be a bad boss, may not be a bad boss to you. It all depend on who we are as individuals and what we currently need. Regardless of who we are though there are three mental types that everyone dislikes and those are psychopaths, narcissists and machiavellians. This is how Birgit Schyn, Barbara Wisse and Stacey Sanders describe these types in their article Shady Strategic Behavior: Recognizing Strategic Followership of Dark Triad Followers:
    “Narcissists have a strong sense of entitlement and a constant need for attention and admiration. They are arrogant and consider themselves to be superior to others. “Machiavellians are sly, deceptive, distrusting, and manipulative. They are characterized by cynical and misanthropic beliefs, callousness, a striving for … money, power, and status, and the use of cunning influence tactics. In contrast to narcissists, Machiavellians do not necessarily have to be the center of attention and are satisfied with the role of puppeteer, unobtrusively pulling the strings.
    Psychopaths “are unlikely to consider the needs and wishes of others and are unafraid of crossing moral boundaries. … By creating chaos in the organization, as well as in coworkers’ personal lives, they can pursue personal agendas without detection. They do not only enjoy hurting people, they strategically use humiliation and bullying to direct other people’s attention away from their hidden selfish activities. … psychopaths are often viewed as the most malevolent ones of the Dark Triad.”
    We call these collectively Dark Triad personalities and when you encounter them there is very little you can do but to leave the organization. These are not bad bosses, they are bad people with mental issues that can hurt you, so stay away from them whenever possible.
    These are not the bad bosses we are looking for however, because there is another group, that is far more difficult to handle than the Dark Triad bosses. I am of course talking about the Sudden Asshole Bosses and the Micro Management Boss. These are people that actually are very good people, but they suffer from insecurities and inexperience as leaders.
    These are usually people that others like because they are caring, well-spoken and often action driven people that listens and take care of problems in a way that make everyone happy. Then when they get appointed to a leadership perspective they change overnight to become a controlling asshole of a boss.
    Why do good people become bad bosses?
    My personal experiences and observations is that this happens to new and inexperienced people due to a shift in the direction of care. By that I mean that as an employee my direction of care is usually towards my co-workers. That would be the other employees. As a person moves up and become a manager you have new responsibilities to people above you in the hierarchy. That means that you naturally shift your direction of care upwards.
    This is nothing bad, but if you add stress and the feeling of not being a hundred percent sure of what you are supposed to do as a manager, then the need for control start to take over. As we know stress does not help with maintaining a kind a generous disposition, so that does not really help the situation either.
    We also tend to adopt behavior from those that we work with. If a new manager are unfortunate to have others around them that belong to the Dark Triad, or that have fallen into the trap of micromanagement, then it becomes natural to be drawn into that. This is not because they want to be bad bosses, but because they need something to cling to as managers very rarely get any leadership training before they are tossed into the new roles as managers.
    People that feel insecure, or that are in a position where they feel they have to live up to certain expectations due to their gender, religion, sexuality or race, they are more prone to this in my experience. Not because they are any worse or better than others, but because they fear failure or letting down others more. Fear is a great motivator, unfortunately it often motivates good people to become bad bosses...
    How do we get bad bosses to become good bosses?
    Most Sudden Assholes and Micro Managers tend to get over the initial shock of becoming a manager. With time, they will again shift their direction of care to the people they are in charge of. They will learn how to navigate the minefield of leadership and distance themselves from behavior that is detrimental to the people under their care. They will also realize that micromanagement is not a healthy or sustainable way of working and as they feel more secure in their roles as leaders that need will dissipate.
    As people feel more secure they will also realize that the very reason they were chosen for leadership in the first place was because they are awesome. More often than not it is also because they add something to the company that is missing. For this reason it does not make sense to conform to what already exist. Many leaders blossom greatly when they realize this and a lot of people transcend from bad bosses to amazing bosses.
    For some however the bad boss attitudes get stuck. These are people that need help to break free from the bad boss loop. In my experience there are three things that seem to work well on most people:
    Time - One of the bane of new managers is stress. Helping your manager to reduce stress is a great way to help them get over the hurdles of transition from bad boss to great boss. Be proactive in providing information and take care of problems and you will quickly see a transition in attitude.
      Proximity - Being away from the people you are supposed to lead make bad bosses feel more connected to other bad bosses instead of the people you are responsible for. Break this by asking the bad boss to spend more time with the team. Don't let them hide in a closed room, bring them out in the open and in close proximity of the team. The bonds will naturally reforge with the team and the bad influence from other bad bosses will be reduced.
      Respect - Even if you are getting treated like crap and you are frustrated, show respect to your boss. Remember that they are probably struggling badly with things you have no idea of and with a show of respect you can ease that stress. Also remember that they are human and that the goal is to help them over the speed bumps of being a bad boss so they can become great bosses. Showing respect reduce their insecurities and remind them how awesome you are as well. I am not saying this is easy or even feasible in some cases, but just remember that bosses are people just like you and me and they have things going on in their lives you probably have no idea of.
    I know of one middle manager that was pretty much ambushed by several teams that gave him hell for almost 30 minutes before he broke down crying and told them that he had cancer and did not know how to deal with that.
    A woman I read about a while back was struggling because she was gay and was afraid that people would find out and she would be fired, only to find that everyone already suspected it and loved her regardless.
    Some are struggling with addiction, others with family issues such as divorces or deaths in the family. Some are struggling with bigotry from higher up in the company, some have asshole bosses of their own to deal with. Others may have illnesses or suffer from anxiety. There are a million reasons why someone may behave poorly in certain times of their lives.
    Just be open to the possibility that bad bosses may just be amazing bosses trapped inside their insecurities, bad company and a stressed out mind.
    You may hold the key they need to break free.

    Value Stream Management - another top down approach to ROI?

    Value stream management, probably most noticeably introduced as a part of the SAFe framework in nothing new. It is a simple visualization of the value creation process connected to the financial aspects. In short, it is a way to organize work based on finance and perceived value to the end user. This approach is another top-down version and as such it comes with both positive aspects and negatives. If handled correctly it can be mostly positive however.
    Let us begin by setting the stage for what Value Streams actually are: artificial constructs designed to match value with cost. In a sense that is the same as a line organization that continuously create value, but with a specific value in mind that is not tied to IT structures such as systems.
    This is where the first problem usually start to show itself: what is value and to whom?
    If you have spent any time with Agile or Lean evangelists then you know they will talk about the end users experience as the one and only metric of importance. I find that to be a naive and narrow point of view because as a company you are in the business of making money. That means that the metrics that matters is what do we benefit from as a company. In order for the company to benefit you usually want end user satisfaction, but it is not the only metric.
    There is no benefit for the company if the end user is satisfied, but the company lose money because of it.
    In order to set any form of metric to measure value you need multiple perspectives and this is very difficult when you have experts that either focus on end user satisfaction or company profit. The answer is in the middle, but very few companies have the capability to bridge the gap and find that value.
    Defining what value is
    What happens is that value often are defined in services rather than value. Customer support for example or E-commerce. In some cases it even is split into business areas such as countries or brands. Neither is probably what constitute a value stream, but then again value streams are artificial constructs that still are very poorly defined other than "what drives value" in a typical theoretical abstract manner.
    My advice for this is to define what value are you driving and how will the company benefit from it. This is something almost all companies already have as it is a part of Portfolio management. Everything that you have a budget for already have value creation as part of the metrics used to motivate the funding. The only thing you need to do is to take your portfolio and sort the items in there into recurring areas. You can do that with a simple card sorting activity because if you work with Portfolio management you probably already have this in place in a way and you just need to challenge the structure a bit.
    It is worth mentioning that value streams are not organizations or departments. They are time limited artificial structures that you should treat as long term project or programs. Eventually these value streams will change, in fact you should have a process to re-evaluate value streams annually or at least bi-annually to verify that the value creation are still in line with what you expect from a value stream.
    Value Streams live on top of systems
    This is as true for Value Streams as it is for programs and projects. All IT organizations are system based and no matter what financial body you place above it should live above the system structure. What I mean by that is that each system should have one truth when it comes to documentation and competence. So financial bodies that touch the system will "borrow" competence from that system and they will share documentation with other financial bodies that touch that system. This prevents fragmentation of information and duplication of technical roles such as architects and test.
    It is common that when you define value streams that you will define entire systems as part of that value stream. This makes sharing systems less of an issue, but you should still keep in mind that the value stream is more or less hiring that system to deliver value and that other can, and usually will, have reason to pass through that system as well.
    Measuring Value. Actual value.
    When you start working with the value stream you will have certain things that you measure to see how well you deliver value. If you have defined the value  correctly as suggested above, then you will get multiple points of value to combine into the actual value. This is where it is common that companies realize that they do not have the tools to actually collect the metrics. In some cases they get the metrics, but do not know how to combine them into actual value.
    My advice here is to make sure that you define value the same throughout the company. Don't use arbitrary points of measurement like t-shirt size or story points because they will be useless at scale. You also need to measure cost, for real. Most companies only start to measure cost after the requirement phase, which provide a very skewed perspective as there are a lot of costs involved in defining a need.
    So start measuring all aspects of the processes before the need hit the development team and you will probably be amazed about how much time is spent defining the need. Ideation, meetings, workshop, decisions, estimations, technical solution design and requirement analysis easily add up to 50-500 hours of work for even small needs. I have seen features that added only a visual effect on the side with negligible value cost well above $50.000 just in meeting costs to argue about the correct implementation.
    You also need a way to translate other arbitrary measurements such as customer satisfaction into something useful. Hopefully you already have a template for this if you work with ROI from CRO, or at least you have some way to measure how an increased customer satisfaction also increase profit for the company.
    When you measure actual value and not just a part of the value creation, then you usually will have very different results than if you only measure single points.
    Value Streams. For real.
    Like I said, value streams are nothing new and most organizations already have it based on either financial value or customer value. The trick is to combine the two into value streams that give you the real answer to the big question: what creates value for the company and how do we improve that.
    Combining soft values such as feelings with hard values such as money is no easy feat however. As you dive into the esoteric and abstract world to try to combine the intangible with hard realities you should expect to fail initially. There are no magic formulas for working with value streams, which is why you should be aware that this will probably be a very expensive exercise of futility unless you truly commit to making it work.
    If you commit and you find that sweet spot between measuring too much and not measuring enough, then I firmly believe you will have a big advantage compared to your competitors. If you also work with predictive activities to test theories before you commit to them, use predictive data analysis and engage with the end users to drive decisions, then you are a winner, regardless of what field your business operates in.
    Just don't throw in Value Stream Management as some form of magic bullet, because it is not.
    You will not be the best in the world by adding a new way of training, you still need to put in the hard work. This is true for sports and it is true for business processes as well. You do the work and you commit to it. Or you fail.
    Commit, or fail.

    Linkedin adds pronouns and video - is it really what we need?

    LinkedIn has recently announced some additions to their services that has been received with some skepticism. While I understand the thought behind adding a more permanent version of Stories and the debated gender pronouns, I don't think it will benefit the users. The only change I really liked was the Live Broadcaster showing the broadcast in the banner.
    Pronouns

    Pronouns are heavily debated all over the world, even if it is mostly affecting lives of people in the US and Canada it seems. While I see why adding it can be a good thing for those that think these things are important, I fear they will add another roadblock for gender fluid individuals. I know for a fact that some companies will not hire anyone putting anything other than he or she in there. I also know for a fact that some companies will not hire anyone with he or she in there, but they are far less if I should venture a guess.
     
    Cover Stories
    Video cover stories is next and it is an extension of the existing stories. The current stories only exist for a day, but Cover Stories are supposed to be a more permanent. It is kind of the old video presentations that was popular back in the days. Until it turned out that people were discarded as candidates based on physical attributes before anyone even looked at their resume. I fear this will have a similar effect and I see several people already have addressed this and how it goes against the trend of having less identifiable data to determine the best candidates.
     
    Live Broadcaster
    Now this was a pretty cool feature, even if it may not be the ultimate experience for anyone wanting to view a broadcast. Whenever you broadcast your banner in your profile will start showing your broadcast instead of the image. Not only does in look cool, but hopefully it will draw some people to your broadcast. I hope this also will bring in more people trying out broadcast.

     
    My Thoughts
    Will these new feature make it easier to get a job or find new candidates? No, it will not. It will be nice toys for people that are already doing great at interviews and for people who love video presentations. In some areas where presentation skills are important it will add value, but in every area where the job is to focus and build things it will probably not be very useful.
    Pronouns are something I still don't understand how it is supposed to work as it is arbitrary labels that can not be discerned visually, making them kind of pointless unless you already know the person. It makes a lot of people uncomfortable and I think it will be something that can lead to exclusion or getting hired based on virtue signalling. Neither of those options will do the gender fluid any favors.
    I also think that some companies might demand that their employees either add video and/or pronouns, or forbid them. This is because both can add or reduce the chance of getting contracts for the companies. That can cause some bad situations and cause discomfort among the employees.
     
    On the upside you have a great new tool to promote yourself using video. This is great for some groups and I think a lot of people will love to add that to their otherwise dry resume. It is also a great way for young people that don't have a resume yet to still show their enthusiasm and their passion for their chosen field.
    For anyone who really feel that pronouns are important it is great that this feature now is added. I know that some people will feel a great relief over this and to be honest, what harm can it possibly do if it is voluntary? If it helps the gender fluid community feel more at ease, then I am all for it.
    The Live Broadcaster feature...yeah, it is all good.
     
    While I do see some concerns for these features I think it is great that LinkedIn experiment. Try out new features and see which ones are appreciated and which ones that are not. As they are optional it gives the users the power to decide what they want to use and what they don't want to use, which is great.
    Overall I give these changes 2 thumbs up and some fingers crossed that they will work out fine for the people that use them and that they will improve the chances of finding work instead of the opposite.
    What are your thoughts?

    Insight free with JSM Premium - Jira Service Management just got a lot better!

    Yesterday I got a mail announcing that Insight, the powerful CMDB tool from Mindville that was recently acquired by Atlassian is going to be included in the Jira Service Management Premium & Enterprise plans. This is a huge announcement and I very much look forward to seeing this rolled out in the coming weeks.
    If you don't know what Mindville Insight is then you can check it out here. In short, it is a tool that allow you to manage all your assets and configuration items in an easy to overview database. With the connection to Jira Service Management and Jira Software Insight give you all the information you need in one overview.
    We will write more about Insight later to show you it's many features.
×
×
  • Create New...