devopsy.kinsta.cloud

Tag: interpersonal skills

  • DevOps Institute Upskilling the Enterprise

    DevOps Institute Upskilling the Enterprise

    DevOps Institute released its annual Upskilling the Enterprise survey and the results are as interesting as last year. The organization of DevOps teams and its interaction with speed/success was one area that intrigued me, and sent me off looking for more information on the topic. This led me to this interesting site that does a great job of delving deeper than “We’ve all heard of Conway’s law.”  Good descriptions there on what works and why that will be useful to many organizations. The only true weakness in the content that I found was the “vacuum syndrome” that doesn’t delve deeply enough into what’s right for your organization, which certainly impacts your choices.

    DevOps Institute’s discussion of soft skills and DevOps roles being hybrid is also interesting. It creates a bit of a conundrum. We all wish the technical genius was also a charming personality, but often that is not the case. In the end, our job is technical, and we need to deliver technical solutions. There is a balance between making the genius more personable and finding personable people capable of achieving the goals. Considering that hiring is currently a struggle, we often do not get to choose. Training can help a lot, and in the end, finding a balance that works for a given organization is going to be a bit of work for management.

    What comes as no surprise is the finding that CI/CD are the entry level required skills for DevOps. No matter how far along on your DevOps journey you are, CI and CD are core to the job at this point. Expect that to change over time as deployment and security become more core and commonplace. In the end, great CI/CD is not much help if deployment and monitoring are weak, so the tools that win these battles will rise in importance over time without taking away from CI/CD.

    Their idea of the E-shaped human is interesting, but in diagramming, some detail is lost in the abstraction.

    I once worked with a super-genius DBA that could do anything with the database. We (managers) met with him on issues and let him tell us how impossible it was and that we were destroying the enterprise’s data integrity. Then gave him a day and let him tell us how it would get done effectively without major disruptions. Only after we’d met with him the second time did we move forward with the project, talking to business owners. Essentially, we became the wall between him and anyone who would be put-off by his face going red and his angered declarations. It was an acceptable arrangement, and he never let us down. I worked with him on dozens of projects, and only once did I see him exposed to outside consultants (against the wishes of several of us), it was ugly, and they pegged him as a stone-waller. He wasn’t, just needed to vent first.

    This person was responsible for the stability of our data, for upping the volume of throughput when needed and for making sure SQL didn’t get past DBAs without being safe. Would we have liked him but with a sunny disposition? Sure, but given a choice, I for one was happy with him and an angry disposition. I worked other places I wished I had someone with his unparalleled skills on the DBA side. So, all of IT needs to get better at interpersonal communications in a DevOps world, but “better” is relative. I’d still keep him in the back, making sure our systems got what they needed.

    The survey head-nods to this reality where soft-skills came in third as important skills. Still high on the list because it is important, but it shows that technical skills are why we have the job. Soft skills are how we do the job with less friction.

    Considering that I am the communicator/negotiator, it might sound strange for me to stand for tech skills first, but that is who we are–technicians. Highly skilled and highly compensated, but technicians. There are few (as a percentage) people who can handle both technical and communications, but by the same token, there are few people who can be an absolute boss at their technical responsibilities and see each unexpected event as a challenge to be overcome. I love to learn new things, and at that job I learned a ton of Oracle stuff from our tech genius. But I would be foolish to believe I’d ever match him in both domain and tech knowledge when it came to databases and our employers’ needs.

    Anyway, I picked three of the points that interested me to expound upon. The entirety of the report is definitely worth a read to get a feel for where others are on their DevOps journey and offer some ideas for yours.

    Meanwhile, keep kicking it. We’re in the midst of COVID-19, and I hear you, some of you are simply buried in organizations that weren’t prepared, others are suddenly looking for work because your previous employer is suddenly not a viable business. Here’s hoping it gets better for each of you, while the rest of us struggle on.

    — Don Macvittie

  • Putting People Before Software

    Putting People Before Software

    Software development teams typically are focused on a single goal: delivering new, killer features that users love. Driving revenue and usage is core to Agile and DevOps. Yet without motivated, productive people, you can forget about building good software.

    Heightened competition requires companies to go the extra mile to develop and retain employees. Here are several ideas for team-building and personal development, while still pushing an awesome product out the door quickly.

    Focus on high performers first

    Struggling employees often receive the most attention and oversight from managers, but it’s really the top performers who should get the majority of the attention and development opportunities. While modern learning and development methods can be less costly than traditional conferences and seminars, the same philosophy rules: spend the most time and investment on those individuals with the highest potential. Don’t underestimate green developers who are eager to grow; they may not have shown their colors yet, but you can typically see early on if they will with a little push.

    Ditch the annual performance review

    Over the last few years, companies of all sizes are starting to move away from traditional generic performance review metrics and processes. The annual review is nearly obsolete, given the pace of change in business and the fact that employees change companies so frequently. Goals set forth a year earlier may no longer be relevant after six months. Performance review planning is also too time-consuming for busy managers these days.

    Instead, consider a more organic process where the employee and manager visit quarterly, developing mutual agreements and goals for the coming months. The customized approach is more meaningful and real-time for everyone. A useful reference on modern employee retention tactics is “The Alliance,” co-authored by Reid Hoffman, a founder of LinkedIn. The book’s premise: Stop thinking of employees as family or free agents and start thinking of them as allies on a tour of duty. The “tour of duty” theme is highly relevant in software development, where tactics and objectives are constantly changing and the pressure can be intense. As long as the employer and employee are constantly seeking to get the most mutual value out of the relationship, employee retention should not be an issue.

    Offer diverse experiences

    Younger employees, including those of the Millennial generation, typically enjoy working in a flat organization where they can take ownership of projects and feel they’re advancing within the organization. Take advantage of that independent ambition by creating smaller teams and giving leadership roles to those who are ready. Younger employees also covet change, so rotational roles can be an excellent way to give them that diversity in experience while also monitoring their progress for long-term career growth. Mid-level employees often feel the highest level of stagnation due to the typically long process of promotion into senior management, so it’s critical to have a strategy for developing and retaining those positions as well.

    Motivate and grow senior developers

    Organizations often go to great lengths to bring in promising young talent and grow them into senior developers. However, the path beyond for a senior developer often provides a fork in the road, with options to either focus deeper on the technical side as an architect or on the people side as a manager. Executives should support senior developers early in this transition and identify key candidates for each role, and then help them to prepare accordingly.

    Make collaboration fun

    Developers today should be groomed and evaluated for their collaboration skills. There’s no right way to do this, but a good start is by making collaboration easy and even fun for those highly independent people who haven’t had to communicate much with coworkers in the past. Offer simple chat and social media tools for real-time, online collaboration or feedback tools such as TINYpulse, which can mask someone’s identity if they are too shy to share feedback otherwise. Requiring team members to demo their work in progress for colleagues can encourage collaboration and sharin, and boost product quality through timely feedback. Offer perks or bonuses for those team members who show initiative in teamwork and cross-team collaboration. Needless to say, FACs (happy hours) and other offsite opportunities for the team to unwind together also can break down barriers.

    Make innovation a cultural trait

    Measuring innovation isn’t straightforward, but making room for it within your organization is a powerful way to both motivate and retain employees and, ultimately, generate business value. Google grabbed headlines a few years ago when it shared its policy of giving technical employees 20 percent of their hours every month to work on independent research projects. Granting employees free time to work on new ideas is smart, but works best if developers are passionate for the business and will reinvest that time in areas that add business value.

    More importantly, recognize that innovation is not a program but a cultural value that can only be communicated from the top. Senior-level support for innovation, along with free sharing of ideas, should be baked into team processes and communications. Finally, time is a finite asset. If you’re going to give your team some time off for creative brainstorming, don’t penalize them for lower output or require them to work weekends to make up for it.

    Push the soft skills

    This is a no-brainer. Modern development teams increasingly are linked hand in hand with business goals and customer outcomes. Therefore, developers must be able to work effectively with business counterparts and understand the language of the business. Give your developers frequent opportunities to present in front of their co-workers for practice, and whenever possible, the chance to work directly with business units on projects.

    Look to the community

    The days of structured career paths and employee development programs are largely over. Employees want and benefit most by self-learning and exploration with their external communities. This entails giving people leeway to attend meetups, participate in developer contests or attend half-day workshops where developers can interact with others in their field. MOOCs, online degrees and certifications are gaining favor as flexible ways to quickly gain new skills. These informal learning opportunities are much more cost-effective than formal training programs of the past and more relevant. They help employees gain general marketplace knowledge on new development trends and tools, rather than company-specific knowledge and processes.

    Investing in technical skills is imperative, yet developers also to want to feel part of a team and work with someone looking out for their career potential. By paying more attention to developers’ personal goals and the needs of the team, software development organizations gain more stability to do what they do best: develop great products.

    About the Author/Kevin Dunne

    Kevin Dunne picKevin Dunne is VP of Strategy & Business Development at QASymphony.

  • DevOps developers; don’t be a DevGoof

    DevOps developers; don’t be a DevGoof

    There was a lot of brush back last week over Jeff Knupp’s post about how DevOps is killing the developer. Frankly I wasn’t shocked by Knupp’s opinion that developers “are the dentists in the dental office”. In my 30+ years of involvement in the IT industry my experience is that developers often think of themselves as the only smart person in the room. Often times that is the reason they are are the only person in the room, lol. The fact is many developers relate better to code than to people. For me all this talk about DevOps killing the developer is akin to saying power steering killed the driver. Just because you can do more with new technology, does not mean one dies, one just has to pivot and in this case become business social.

    Now the sociable part may be the problem. Sometimes I feel that DevOps is trying to create a love fest between Ops, Developers, QA, security and the rest of the IT stack. While they may not have to love each other, I do think they all need to be nice to each other as opposed to ignoring  or just going around each other, as was all too often done in the past. A common scenario I have seen for example is for developers to rollover Ops by stating this is mission critical for the business. These tactics will no longer work to let developers have their way.

    Developers need to realize they need to become a normal part of the business social structure. They will be required to talk and work with people, not throw tantrums when they don’t get their way. Left unchecked, certain developer personality types can sabotage your project, or worse, make themselves no fun to work with.  I am sure we have all met and unfortunately had to work with people like that. In my career, I’ve encountered virtually every personality type. In fact, I’ve also knowingly hired all of them. They know who they are; they are the developer that if challenged or worse accurately taken to task for lack of being part of the team; quit cause they can’t manage the confrontation, thus interpersonal stress. In the old days they would not come out of their house for weeks continually playing Leisure Suit Larry, if your not familiar with it Google it

    I remember one of my good friends telling me this story that sums this whole developer persona issue perfectly. This company, we will call DevGoof, was a well funded start up. Every quarter they held a meeting with all the employees to let them know how the company was doing. Most employees had some kind of equity play in the company, so everyone was incented and theoretically interested in company performance. Several quarterly meetings came and went and not one developer showed up. Eventually DevGoof management got concerned and called a mandatory meeting for all developers’.

    DevGoof management put out some pastries, juice and coffee for the brain trust. Then proceeded to tell them why these meetings were important to them and their fellow employees. Notably pointing out how it is not just about them but also about the rest of the DevGoof team. This meeting went on for about one hour and not one developer asked a question. So eventually this meeting was over and everyone went back to developing. The next morning,   about 50% of the developers quit and some in a not so professional fashion.

    The moral of this blog is the DevOps is going to force the development community to become more interpersonal within the business environment. This will lead to personal success within the new world of DevOps. The DevOps Developer/Engineer that can demonstrate leadership and compassion for team will be the one leading the DevOps way within the organization. Don’t be a Devgoof!

    If you would like say something; email parker@devops.com and don’t forget to comment here.