<?xml version="1.0" encoding="utf-8" standalone="yes" ?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>software management on Tony Talks Technology</title>
    <link>https://blog.tonymorris.io/tags/software-management/</link>
    <description>Recent content in software management on Tony Talks Technology</description>
    <generator>Hugo -- gohugo.io</generator>
    <managingEditor>hi@tonymorris.io (Tony Morris)</managingEditor>
    <webMaster>hi@tonymorris.io (Tony Morris)</webMaster>
    <lastBuildDate>Wed, 18 Apr 2018 00:00:00 +0000</lastBuildDate>
    
	<atom:link href="https://blog.tonymorris.io/tags/software-management/index.xml" rel="self" type="application/rss+xml" />
    
    
    <item>
      <title>My Core Values</title>
      <link>https://blog.tonymorris.io/2018/04/my-core-values/</link>
      <pubDate>Wed, 18 Apr 2018 00:00:00 +0000</pubDate>
      <author>hi@tonymorris.io (Tony Morris)</author>
      <guid>https://blog.tonymorris.io/2018/04/my-core-values/</guid>
      <description>&lt;p&gt;I&amp;rsquo;ve been doing professional software development for nearly 10 years now.
Throughout that time, I&amp;rsquo;ve worked at a number of organizations, I&amp;rsquo;ve been
managed by a number of different people, and I&amp;rsquo;ve attempted to absorb as much
knowledge (both technical and non-technical) as possible. After that long of a
time, I&amp;rsquo;ve come to realize a bit about what makes me who I am, and what drives
me as a person and developer.&lt;/p&gt;</description>
    </item>
    
    <item>
      <title>Working Harder Isn&#39;t a Strategy</title>
      <link>https://blog.tonymorris.io/2017/07/working-harder-isnt-a-strategy/</link>
      <pubDate>Mon, 10 Jul 2017 00:00:00 +0000</pubDate>
      <author>hi@tonymorris.io (Tony Morris)</author>
      <guid>https://blog.tonymorris.io/2017/07/working-harder-isnt-a-strategy/</guid>
      <description>&lt;p&gt;As a technology professional on the development side of the house, I regularly
have to provide estimates for when my work will be done. This work includes
writing code, packaging up a deliverable, writing documentation, or anything in
between. Following the estimate delivery, there is a level of &lt;strong&gt;trust&lt;/strong&gt; that
exists between the technology delivery team and the project/account management
team in that the estimate 1) will not be inflated by the technology team, and 2)
will not be altered by the project/account management team.&lt;/p&gt;</description>
    </item>
    
    <item>
      <title>Stop Celebrating Superheroes</title>
      <link>https://blog.tonymorris.io/2017/05/stop-celebrating-superheroes/</link>
      <pubDate>Mon, 29 May 2017 00:00:00 +0000</pubDate>
      <author>hi@tonymorris.io (Tony Morris)</author>
      <guid>https://blog.tonymorris.io/2017/05/stop-celebrating-superheroes/</guid>
      <description>&lt;h1 id=&#34;the-death-march&#34;&gt;The Death March&lt;/h1&gt;

&lt;p&gt;In most development walks of life, any given software developer will run into a
project known as a &lt;strong&gt;Death March&lt;/strong&gt;. These projects have any number of problems,
but the most typical ones are:&lt;/p&gt;

&lt;ul&gt;
&lt;li&gt;Too much scope for the timeline&lt;/li&gt;
&lt;li&gt;Not enough resources for the scope&lt;/li&gt;
&lt;li&gt;Resources have the wrong skillset for the project&lt;/li&gt;
&lt;/ul&gt;</description>
    </item>
    
  </channel>
</rss>