Adding dev to tags (#5)

* Update benefits-of-peer-feedback.md

* Update citizen-developers.md

* Update do-not-open-new-tabs.md

* Update finish-what-you-started.md

* Update importance-of-visibility.md

* Update benefits-of-peer-feedback.md

content/Blog/benefits-of-peer-feedback.md

@@ -6,6 +6,7 @@ tags:
 - Management
 - Engineering Management
 - Performance Reviews
+- DevTo
 description: Feedback from another employee can be very helpful for your performance review, but it is most useful if it is written with specific details about your work and it's impact.
 ---
 

content/Blog/citizen-developers.md

@@ -6,6 +6,7 @@ tags:
  - Software Management
  - Coding
  - Microsoft
+ - DevTo
 ---
 
 In any organization, users will end up creating their own tools, outside

content/Blog/do-not-open-new-tabs.md

@@ -5,6 +5,7 @@ type: posts
 tags:
  - Web Development
  - Accessibility
+ - DevTo
 techfeatured: true
 description: Every few days someone will suggest we have our links open in a new tab by default, here is why that is a bad idea
 ---

content/Blog/finish-what-you-started.md

@@ -5,6 +5,7 @@ type: posts
 tags:
 - Management
 - Engineering Management
+- DevTo
 description: Software development projects can only have an impact if they make it to production, so instead of having forty partially done bits of work, you should always prioritize having something actually done.
 ---
 
@@ -73,4 +74,4 @@ Finally, and this is one of the most difficult situations to find yourself in, i
 
 If you’d like to do more development in this style, but don’t have the agreement of the rest of the organization, I’d suggest one of two approaches. Either convince them that it is worth trying on a few features, the set of work planned for an upcoming quarter, or the work being done by one specific development team or alternatively go ahead and do it behind the scenes.
 
-The first path is nice, because you can be open about only building the full plan for each small release, and hopefully everyone will agree it is working great. The second path is more complicated. You’ll have to have a larger release planned, with release dates and a committed set of features. You can then implement it in small pieces, building and releasing each phase completely behind a flag, and never shipping anything to the real users until the end. That removes many of the benefits, but it can get your developers used to working in this mode and produces a more stable result because each phase had to be shippable. It also gives you the option, and multiple points in the development process, to ship a limited version of the full project, if you can convince your stakeholders it is valuable at that time.
+The first path is nice, because you can be open about only building the full plan for each small release, and hopefully everyone will agree it is working great. The second path is more complicated. You’ll have to have a larger release planned, with release dates and a committed set of features. You can then implement it in small pieces, building and releasing each phase completely behind a flag, and never shipping anything to the real users until the end. That removes many of the benefits, but it can get your developers used to working in this mode and produces a more stable result because each phase had to be shippable. It also gives you the option, and multiple points in the development process, to ship a limited version of the full project, if you can convince your stakeholders it is valuable at that time.

content/Blog/importance-of-visibility.md

@@ -5,6 +5,7 @@ type: posts
 tags:
 - Management
 - Engineering Management
+- DevTo
 description: Making sure the work you do, and the impact it has, is visible and understandable to others is one of the most useful skills for anyone in the workforce.
 techfeatured: true
 ---